TCP/IP Data Communications Model

A Data Communications Model

To discuss computer networking, it is necessary to use terms that have special meaning. Even other computer professionals may not be familiar with all the terms in the networking alphabet soup. As is always the case, English and computer-speak are not equivalent (or even necessarily compatible) languages. Although descriptions and examples should make the meaning of the networking jargon more apparent, sometimes terms are ambiguous. A common frame of reference is necessary for understanding data communications terminology.

An architectural model developed by the International Standards Organization (ISO) is frequently used to describe the structure and function of data communications protocols. This architectural model, which is called the Open Systems Interconnect Reference Model (OSI), provides a common reference for discussing communications. The terms defined by this model are well understood and widely used in the data communications community - so widely used, in fact, that it is difficult to discuss data communications without using OSI's terminology.

The OSI Reference Model contains seven layers that define the functions of data communications protocols. Each layer of the OSI model represents a function performed when data is transferred between cooperating applications across an intervening network. Figure 1.1 identifies each layer by name and provides a short functional description for it. Looking at this figure, the protocols are like a pile of building blocks stacked one upon another. Because of this appearance, the structure is often called a stack or protocol stack.

Figure 1.1: The OSI Reference Model


Figure 1.1

A layer does not define a single protocol - it defines a data communications function that may be performed by any number of protocols. Therefore, each layer may contain multiple protocols, each providing a service suitable to the function of that layer. For example, a file transfer protocol and an electronic mail protocol both provide user services, and both are part of the Application Layer.

Every protocol communicates with its peer. A peer is an implementation of the same protocol in the equivalent layer on a remote system; i.e., the local file transfer protocol is the peer of a remote file transfer protocol. Peer-level communications must be standardized for successful communications to take place. In the abstract, each protocol is concerned only with communicating to its peer; it does not care about the layer above or below it.

However, there must also be agreement on how to pass data between the layers on a single computer, because every layer is involved in sending data from a local application to an equivalent remote application. The upper layers rely on the lower layers to transfer the data over the underlying network. Data is passed down the stack from one layer to the next, until it is transmitted over the network by the Physical Layer protocols. At the remote end, the data is passed up the stack to the receiving application. The individual layers do not need to know how the layers above and below them function; they only need to know how to pass data to them. Isolating network communications functions in different layers minimizes the impact of technological change on the entire protocol suite. New applications can be added without changing the physical network, and new network hardware can be installed without rewriting the application software.

Although the OSI model is useful, the TCP/IP protocols don't match its structure exactly. Therefore, in our discussions of TCP/IP, we use the layers of the OSI model in the following way:

Application Layer

The Application Layer is the level of the protocol hierarchy where user-accessed network processes reside. In this text, a TCP/IP application is any network process that occurs above the Transport Layer. This includes all of the processes that users directly interact with, as well as other processes at this level that users are not necessarily aware of.

Presentation Layer

For cooperating applications to exchange data, they must agree about how data is represented. In OSI, this layer provides standard data presentation routines. This function is frequently handled within the applications in TCP/IP, though increasingly TCP/IP protocols such as XDR and MIME perform this function.

Session Layer

As with the Presentation Layer, the Session Layer is not identifiable as a separate layer in the TCP/IP protocol hierarchy. The OSI Session Layer manages the sessions (connection) between cooperating applications. In TCP/IP, this function largely occurs in the Transport Layer, and the term "session" is not used. For TCP/IP, the terms "socket" and "port" are used to describe the path over which cooperating applications communicate.

Transport Layer

Much of our discussion of TCP/IP is directed to the protocols that occur in the Transport Layer. The Transport Layer in the OSI reference model guarantees that the receiver gets the data exactly as it was sent. In TCP/IP this function is performed by the Transmission Control Protocol (TCP). However, TCP/IP offers a second Transport Layer service, User Datagram Protocol (UDP), that does not perform the end-to-end reliability checks.

Network Layer

The Network Layer manages connections across the network and isolates the upper layer protocols from the details of the underlying network. The Internet Protocol (IP), which isolates the upper layers from the underlying network and handles the addressing and delivery of data, is usually described as TCP/IP's Network Layer.

Data Link Layer

The reliable delivery of data across the underlying physical network is handled by the Data Link Layer. TCP/IP rarely creates protocols in the Data Link Layer. Most RFCs that relate to the Data Link Layer discuss how IP can make use of existing data link protocols.

Physical Layer

The Physical Layer defines the characteristics of the hardware needed to carry the data transmission signal. Features such as voltage levels, and the number and location of interface pins, are defined in this layer. Examples of standards at the Physical Layer are interface connectors such as RS232C and V.35, and standards for local area network wiring such as IEEE 802.3. TCP/IP does not define physical standards - it makes use of existing standards.

The terminology of the OSI reference model helps us describe TCP/IP, but to fully understand it, we must use an architectural model that more closely matches the structure of TCP/IP. The next section introduces the protocol model we'll use to describe TCP/IP.

How to Backup VMware ESX Servers

The subject of backing up ESX hosts for disaster recovery comes up from time to time, but not nearly as often as backing up the virtual machines. To be specific, I am talking about backing up the ESX Service Console. Honesty, to reinstall ESX takes such little time there is really no need to keep a full system backup for recovery. There is an advantage to saving key configuration files and folders to quickly re-apply after a re- installation, however. This can be done without installing a backup agent on the ESX Service Console.

This post provides information on what ESX Service Console files and directories to backup, how to use the tar command to create a backup file, and then how to restore from the backup file after a new installation. The material comes from one of the VMware Authorized Consultant (VAC) toolkit documents that I often use for customer documentation deliverables. To give credit where credit is due, the author of the document is listed as “VMware PSO - Practice Development”.

The rest of this post is copied from the VAC toolkit document except for a few format changes.

VMware ESX Server Host Backups

Backing up the VMware ESX Server host is not a recommended practice since a typical ESX build takes minutes from start to finish. Since all critical data is stored on the SAN, it is not necessary to backup the Service Console.

In the event that VMware ESX Server host has a large amount of customization, backups may be conducted of the files and directories. Within the environment there should not be extensive changes to the default environment to warrant the backups.

ESX Files and Directories to Back Up

File Description
/etc/passwd The password file containing the local users for the VMware ESX Server host service console.
/etc/shadow The shadow password file containing local users and encrypted passwords for the VMware ESX Server host service console.
/etc/group The group file for containing local security groups for the VMware ESX Server host service console.
/etc/grub.conf The boot information for the grub boot loader.
/etc/vmware The configuration files for VMware ESX host.
/boot The boot partition for VMware ESX host. It should be noted that these should be default.
/home/ Any user information that is stored on the home directory on the local machine.

To perform the backup, a file can be generated using the following command:

# tar –cvf esx1-backup.datestamp.tar /etc/passwd /etc/shadow /etc/group /etc/grub.conf /etc/pam.d /etc/vmware /boot/ /home/

VMware ESX Server Host Restore

Normally, VMware ESX Server should be reinstalled and connected to the shared storage. If the above steps were conducted, complete restoration can be performed through the following steps:

  1. Re-install ESX with the same partition configuration as the original host.
  2. SFTP files back on.
  3. Remove the /etc/vmware & /boot directories by typing the following commands

    # cd /

    # rm –Rf /etc/vmware

    # rm –Rf /boot

  4. Restore the backup set on the new ESX host. Be sure to overwrite existing files on restore! For example, from the root directory you can issue the following command to restore from the original tarball:

    tar –xvf ..tar

    # tar –xvf esx1-backup.datestamp.tar

  5. Reboot.

ESX Shell Script VM Creation Utilizing Cloning

##### VM Creation Script Utilizing Cloning ####################
#--------+
# Purpose|
#--------+-----------------------------------------------------
# This script will create a VM utilizing the cloning option of # vmkfstools
command tool;
# The New Virtual Machine Configuration will be set as follows
# Virtual Machine Name = ScriptedCloneVM
# Location of Virtual Machine = /VMFS/volumes/storage1/ScriptedVM
# Virtual Machine Type = "Microsoft Windows 2003 Standard"
# Virtual Machine Memory Allocation = 256 meg
#
#----------------------------------------+
#Custom Variable Section for Modification|
#----------------------------------------+---------------------
#NVM is name of virtual machine(NVM). No Spaces allowed in name
#NVMDIR is the directory which holds all the VM files
#NVMOS specifies VM Operating System
#--------------------------------------------------------------
###############################################################
### Default Variable settings - change this to your preferences
NVM="ScriptedCloneVM" # Name of Virtual Machine
NVMDIR="ScriptedCloneVM" # Specify only the folder name to be created; NOT
the complete path
NVMOS="winnetstandard" # Type of OS for Virtual Machine
VMMEMSIZE="256" # Default Memory Size
### End Variable Declaration
mkdir /vmfs/volumes/storage1/$NVMDIR # Creates directory
exec 6>&1 # Sets up write to file
exec 1>/vmfs/volumes/storage1/$NVMDIR/$NVM.vmx # Open file
# write the configuration
echo config.version = '"'6'"' # For ESX 3.x the value is 8
echo virtualHW.version = '"'3'"' # For ESX 3.x the value is 4
echo memsize = '"'$VMMEMSIZE'"'
echo floppy0.present = '"'TRUE'"' # setup VM with floppy
echo displayName = '"'$NVM'"' # name of virtual machine
echo guestOS = '"'$NVMOS'"'
echo
echo ide0:0.present = '"'TRUE'"'
echo ide0:0.deviceType = '"'cdrom-raw'"'
echo ide:0.startConnected = '"'false'"' # CDROM enabled
echo floppy0.startConnected = '"'FALSE'"'
echo floppy0.fileName = '"'/dev/fd0'"'
echo Ethernet0.present = '"'TRUE'"'
echo Ethernet0.networkName = '"'VM Network'"' # Default network
echo Ethernet0.addressType = '"'vpx'"'
echo
echo scsi0.present = '"'true'"'
echo scsi0.sharedBus = '"'none'"'
echo scsi0.virtualDev = '"'lsilogic'"'
echo scsi0:0.present = '"'true'"' # Virtual Disk Settings
echo scsi0:0.fileName = '"'$NVM.vmdk'"'
echo scsi0:0.deviceType = '"'scsi-hardDisk'"'
echo
# close file
exec 1>&-
# make stdout a copy of FD 6 (reset stdout), and close FD6
exec 1>&6
exec 6>&-
# Change permissions on the file so it can be executed by anyone
chmod 755 /vmfs/volumes/storage1/$NVMDIR/$NVM.vmx
#Clone existing Template VM's VMDK into current directory
cd /vmfs/volumes/storage1/$NVMDIR #change to the VM dir
vmkfstools -i /vmfs/volumes/storage1/ScriptedVM/ScriptedVM.vmdk $NVM.vmdk
#Register VM
vmware-cmd -s register /vmfs/volumes/storage1/$NVMDIR/$NVM.vmx

CreateScheduledTask on Vmware ESX

ManagedObjectReference MgdObjRef_VM =
_service.FindByInventoryPath(_sic.SearchIndex(), pathVM);
MethodActionArgument[] mActArgumnt = new MethodActionArgument();
MethodAction mAction = new MethodAction();
mActArgumnt.Value = MgdObjRef_VM;
ma.Argument = mActArgumnt;
ma.Name = "MigrateVM";
DailyTaskScheduler dtScheduler = new DailyTaskScheduler();
dtScheduler.Hour = 12;
dtScheduler.Minute = 0;
ScheduledTaskSpec tSpec = new ScheduledTaskSpec();
tSpec.Action = mAction;
tSpec.Scheduler = dtScheduler;
tSpec.Enabled = true;
tSpec.Name = "Migrate virtual machine";
tSpec.Description = "Migrate virtual machine at noon");
tSpec.Notification = "VMAdmin@syngress.com";
_service.createScheduledTask(_sic.ScheduledTaskManager,MgdObjRef_VM,tSpec);

PowerOff VM_Task Script for ESX

ManagedObjectReference MgdObjRef_VM =
_service.findByInventoryPath(_sic.SearchIndex(), pathVM);
ManagedObjectReference MgdObjRef_Host =
_service.findByInventoryPath(_sic.SearchIndex(), pathHost);
ManagedObjectReference MgdObjRef_Task =
_service.PowerOffVM(MgdObjRef_VM, MgdObjRef_Host);

C# Script for Changing the Priority of a VM on ESX

ViewContents vc = vma_.GetContents(vm);
Change change = new Change();
change.target = "hardware/cpu/controls/shares";
change.val = "high";
change.op = ChangeOp.edit;
change.valSpecified = true;
ChangeReqList changeList = new ChangeReqList();
ChangeReq changeReq = new ChangeReq();
changeReq.handle = vc.handle;
changeReq.change = new Change[] { change };
ChangeReq[] changeReqs = new ChangeReq[] { changeReq };
changeList.req = changeReqs;
UpdateList updateList = vma_.PutUpdates(changeList);