User Datagram Protocol (UDP)

The User Datagram Protocol (UDP) is a connectionless protocol on the Transport layer of the
OSI model. The overall structure of UDP is simpler than TCP, because UDP is connectionless
and therefore does not have overhead to maintain connection information. UDP is commonly used for real-time applications such as video and voice. In these time-sensitive applications,
when a packet is lost or corrupted there is not enough time for the applications to recognize that
a packet is missing and request that it be resent, and for this retransmitted packet to arrive.
Therefore, the overhead that comes with TCP is not warranted for this type of data transfer.
The following frame snippet was taken using EtherPeek and is of a DNS request:
UDP - User Datagram Protocol
Source Port: 1213
Destination Port: 53 domain
Length: 38
Checksum: 0xBFBA
As you can see, all of the overhead that is associated with the connection-oriented nature of
the TCP frame, such as sequence and acknowledgment number, has been removed in UDP. As
a result, the UDP packet is condensed down to four fields.
The first two of these fields, Source Port and Destination Port, are both 16 bits long. The
Destination Port field must be filled in with the destination port of the service that is being
requested; however, the Source Port field only needs a value when the sending station needs
a reply from the receiver. When the conversation is unidirectional and the source port is not
used, this field should be set to 0. When a reply is needed, the receiving station will reply to the
sender on the port indicated in the original packet’s source field.
The last two fields in a UDP header are Length and Checksum. Like the source and destination
port information, the length and checksum are both 16 bits long. The Length field shows the total
number of bytes in the UDP packet, including the UDP header and user data. Checksum, though
optional, allows the receiving station to verify the integrity of the UDP header as well as the data
that is contained in the packet. If Checksum is not used, it should be set to a value of 0.


A great deal of information is covered in this chapter, with the focus on Network and Data Link
layer protocols. It is important to understand this information in order to facilitate your troubleshooting
efforts. If you do not sufficiently understand the protocols present in layers 2 and 3 of
the OSI model, you should study them in depth. The majority of networking problems occur in
these two layers.
Many encapsulation types are available at the second layer of the OSI model. The ones
discussed in this chapter were Ethernet, PPP, SDLC, Frame Relay, and ISDN. Each has its
own strengths and weaknesses that make it better suited for a particular installation.
There are two major protocol classifications: connection-oriented and connectionless.
Connection-oriented protocols allow for sequenced data transfer, flow control, and error
control. Examples of connection-oriented protocols include ATM and TCP. Connectionless
protocols require less overhead; however, they do so at the expense of the sequenced data
transfer and the error and flow control offered by connection-oriented protocols. The connectionless
protocol discussed in this chapter is UDP.


Know the differences between connectionless and connection-oriented protocols. Connectionoriented
protocols have flow-control and error-checking methodologies that are not present in
connectionless protocols. Connectionless protocols offer better performance characteristics for
real-time voice and video applications.
Know the Data Link protocols and technologies. The major technologies covered in this
section include Ethernet, PPP, SDLC (HDLC), Frame Relay, and ISDN.
Know how to calculate subnet masks. Understand how VLSM functions, and know how to
determine an appropriate address and subnet mask combination. 1122

Transmission Control Protocol (TCP)

The Transmission Control Protocol (TCP), a connection-oriented protocol on the Transport
layer that provides reliable delivery of data, is an integral part of the IP suite. Look at the structure
of the TCP packet. The following EtherPeek frame was taken during a POP3 transaction:
TCP - Transmission Control Protocol
Source Port: 110 POP3
Destination Port: 1097
Sequence Number: 997270908
Ack Number: 7149472
Offset: 5
Reserved: 0000
Code: %010000
Ack is valid
Window: 8760
Checksum: 0x8064
Urgent Pointer: 0
No TCP Options
No More POP Command or Reply Data
Extra bytes (Padding):
UUUUUU 55 55 55 55 55 55
Frame Check Sequence: 0x04020000

This structure is similar to the IP packet structure. The TCP header is 32 bits long and has a
minimum length of five fields, but can be six fields deep when options are specified. The first layer
starts with the Source Port and Destination Port fields. Each of these fields is 16 bits long.
A Sequence Number field occupies the entire second layer, meaning that it is 32 bits long.
TCP is a connection-oriented protocol, and this field is used to keep track of the various requests
that have been sent.
The third layer is a 32-bit length field containing the acknowledgment sequence number that
is used to track responses.
The fourth layer begins with the Offset field, which is four bits and specifies the number of
32-bit words present in the header. Six bits are reserved for future use (this is called the Reserved
field). This field follows the Offset field.
The next field, called the Flag or Code field, is also a six-bit field, and it contains control
information. Look at Table 36.6 for an explanation of the six bits within the Flag field.
The Window field specifies the buffer size for incoming data. Once the buffer is filled, the
sending system must wait for a response from the receiving system. This field is 16 bits long.
Layer 5 of the TCP header begins with the Checksum parameter, which also occupies 16 bits.
It is used to verify the integrity of the transmitted data.
The Urgent Pointer field references the last byte of data, so the receiver knows how much
urgent data it will receive. This is also a 16-bit field.
Finally, there is the Option field, which must also be 32 bits long. If the options do not
occupy 32 bits, padding is added to reach the correct length.

Internet Control Message Protocol (ICMP)

The Internet Control Message Protocol (ICMP) is used throughout IP networks. ICMP was
designed to provide routing-failure information to the source system. This protocol provides
four types of feedback that are used to make the IP routing environment more efficient:
Reachability This is determined by using ICMP echo and reply messages.
Redirects These messages tell hosts to redirect traffic or choose alternative routes.
Timeouts These messages indicate that a packet’s designated TTL is expired.
Router Discovery These messages discover directly connected routers’ IP addresses. Router
discovery actually uses the ICMP Router Discovery Protocol to do this. This passive method
gathers directly connected IP addresses without having to understand specific routing protocols.
Here is a look at a couple of ICMP packets (echo request and reply):
ICMP - Internet Control Messages Protocol
ICMP Type: 8 Echo Request
Code: 0
Checksum: 0x495c
Identifier: 0x0200

Sequence Number: 512
ICMP Data Area:
abcdefghijklmnop 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
qrstuvwabcdefghi 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
Frame Check Sequence: 0x342e3235
ICMP - Internet Control Messages Protocol
ICMP Type: 0 Echo Reply
Code: 0
Checksum: 0x515c
Identifier: 0x0200
Sequence Number: 512
ICMP Data Area:
abcdefghijklmnop 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
qrstuvwabcdefghi 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
Frame Check Sequence: 0x342e3235
The ICMP structure is similar to the IP structure in that it has a type, checksum, identifier,
and sequence number. The field names differ a little but have the same functionality.

Tips for Successfully Using VLSM in a Network

As is the case with many elements of networking, planning is the key to successfully using
VLSM in a network. This is especially true of VLSM implementations being put in place on existing
networks. Without proper planning, a VLSM implementation can provoke serious support
problems. There are numerous ways to implement VLSM; here we will only focus on two.
Divide up a single /24 network. This implementation strategy is best designed for smaller
remote sites connecting to one or two central locations. A single /24 network can be divided
up and used for the remote sites. In this manner, summarization and problem tracking are
made easier. For example, assume that the standard remote location has 60 IP-enabled
devices on a single segment, two routers, one switch, and two point-to-point Frame Relay
links, and is assigned the 10.1.1.0 /24 subnet. Using the small-site VLSM strategy, you can
take this /24 and divide it up into the following:
10.1.1.0 /25 for the user segment
10.1.1.244 /30 for Frame Relay link 2

10.1.1.248 /30 for Frame Relay link 1
10.1.1.253 /32 for router 2 loopback
10.1.1.254 /32 for router 1 loopback
As you can see, /32 subnets are being used for the router loopback addresses. This does not
conform to the rules of IP addressing, but it is supported by Cisco routers. Also, though it is true
that with only 60 IP-enabled devices a /26 mask could have been used, that would leave no
room for future growth. The suggested arrangement, on the other hand, allows for effective
use of the address range and permits some future expansion. Notice also that /30 masks were
used for the Frame Relay links. In the event that these links might become point-to-multipoint
links, however, a different mask should be used.
Use one mask size per service. The second tip for implementing VLSM is to try to use the
same mask size for the same service type. For example, use a /32 mask for all loopback interfaces,
a /30 mask for all point-to point links, a /26 mask for all server segments, and a /24 mask
for all user segments. In this manner you can easily identify the general purpose of a subnet
just by looking at the mask.
As stated, there are various ways to implement VLSM successfully; it just takes some planning
up front. This planning must take into account the current IP addressing scheme. In addition,
make sure that the final implementation is consistently applied and will be scalable and adaptable
as the network requirements change. 1117

IP Addressing Review

No review of TCP/IP networking would be complete without a review of IP addressing. In
this section we will not explain the basics of IP addressing; rather, we will focus more on
the application of variable-length subnet masking (VLSM) and the calculation of networks
as it pertains to troubleshooting in an IP environment. If you need a more detailed discussion,
see CCNA: Cisco Certified Network Associate Study Guide, 4th ed., by Todd Lammle
(Sybex, 2004).

As internetworks grew and address space became more scarce, several methodologies were
devised to extend the address space availability. One of these methodologies was VLSM. In older
routing protocols, if you wanted to subnet a major network, you had to make all the subnets the
same size. This was because the routing protocols passed only network information and did not
include subnet mask information. Newer routing protocols pass subnet information along with
the individual routes, allowing for the use of VLSM. This enables better use of address space
because network administrators can size the subnets based on the need. For example, a point-topoint
connection has only two nodes on it, and as such only needs two host addresses. Without
VLSM, if your standard subnet mask was 255.255.255.0, a /24 subnet, then 256 “addresses”
would be used on this point-to-point connection (though 256 addresses are used, only 254 are
usable by hosts). With VLSM, this same connection could use a 255.255.255.252 mask, /30, using
only four addresses—two for the hosts, one for the subnet, and one for the broadcast address. For
reference, Table 36.5 shows various subnet mask information.

One drawback to VLSM is the complexity that it adds to the network. When there was only
one mask used in an environment, the network administrators could easily memorize the subnet
information. With VLSM, however, subnet information needs to be calculated based on the
individual situation. Miscalculation of the subnets can lead to communication problems if
machines are assigned outside a subnet boundary or on a subnet or broadcast address.