As established in the previous section, subnet bits cannot be all zeros or all ones in classful environments.
Likewise, an IP host address cannot have all its host bits set to zero— this setting is reserved for the
address router's use to represent the network or subnet itself. And the host bits cannot be set to all ones, as
this setting is the broadcast address. These restrictions apply to the host bits with no exceptions and are
starting points for designing subnets. Beyond these starting points, network designers need to choose the
most appropriate subnetting scheme in terms of matching the address space to the particulars of an
internetwork.
When designing subnets and their masks, the number of available subnets under a major network address
and the number of available hosts on each subnet are both calculated with the same formula: 2 n – 2,
where n is the number of bits in the subnet or host space and 2 is subtracted to account for the unavailable
all-zeros and all-ones addresses. For example, given a class A address of 10.0.0.0, a subnet mask of
10.0.0.0/16 (255.255.0.0) means that the 8-bit subnet space will yield 28 – 2 = 254 available subnets and
216 – 2 = 65,534 host addresses available on each of those subnets. On the other hand, a mask of
10.0.0.0/24 (255.255.255.0) means that a 16-bit subnet space is yielding 65,534 subnets and an 8-bit host
space is yielding 254 host addresses for each subnet.
The following steps are used to subnet an IP address:
NOTE
A stepwise method for designing subnets
1. Determine how many subnets are required and how many hosts per subnet are required.
2. Use the 2 n – 2 formula to determine the number of subnet bits and the number of host bits that will
satisfy the requirements established in step 1. If multiple subnet masks can satisfy the
requirements, choose the one that will best scale to future needs. For example, if the internetwork
is most likely to grow by adding subnets, choose more subnet bits; if the internetwork is most
likely to grow by adding hosts to existing subnets, choose more host bits. Avoid choosing a
scheme in which either all subnets or all host addresses within the subnets will be used up
immediately, leaving no room for future growth.
3. Working in binary, determine all available bit combinations in the subnet space; in each instance,
set all the host bits to zero. Convert the resulting subnet addresses to dotted decimal. These are the
subnet addresses.
4. For each subnet address, again working in binary, write all possible bit combinations for the host
space without changing the subnet bits. Convert the results to dotted decimal; these are the host
addresses available for each subnet.
NOTE
When configuring subnets, always work in binary instead of dotted decimal.
The importance of doing the last two steps in binary cannot be overemphasized. The single greatest
source of mistakes when working with subnets is trying to work with them in dotted deci mal without
under standing what is happening at the binary level. Again, dotted decimal is for convenience in reading
and writing IP addresses. Routers and hosts see the addresses as 32-bit binary strings; to successfully
work with IP addresses, they must be seen the way the routers and hosts see them.
The last paragraph may seem a bit overzealous in light of the examples given so far; the patterns of subnet
and host addresses have been quite apparent without having to see the addresses and masks in binary. The
next section uses the four design steps to derive a subnet design in which the dotted-decimal
representations are not so obvious. 37
IT Certification CCIE,CCNP,CCIP,CCNA,CCSP,Cisco Network Optimization and Security Tips
Subnets and Subnet Masks
NOTE
The need for network-level addressing
Never lose sight of why network-level addresses are necessary in the first place. For routing to be
accomplished, each and every data link (network) must have a unique address; in addition, each and every
host on that data link must have an address that both identifies it as a member of the network and
distinguishes it from any other host on that network.
As defined so far, a single class A, B, or C address can be used only on a single data link. To build an
internetwork, separate addresses must be used for each data link so that those networks are uniquely
identifiable. If a separate class A, B, or C address were assigned to each data link, less than 17 million
data links could be addressed before all IP addresses were depleted. This approach is obviously
impractical, [7] as is the fact that to make full use of the host address space in the previous example, more
than 65,000 devices would have to reside on data link 172.21.0.0!
[7] Seventeen million data links may seem like a lot until you consider that even a single moderate-size business may have dozens or hundreds of
data links.
The only way to make class A, B, or C addresses practical is by dividing each major address, such as
172.21.0.0, into subnetwork addresses. Recall two facts:
1. The host portion of an address can be used as desired.
2. The network portion of an IP address is determined by the address mask assigned to that interface.
Figure 2.13 shows an internetwork to which the major class B address 172.21.0.0 has been assigned. Five
data links are interconnecting the routers, each one of which requires a network address. As it stands,
172.21.0.0 would have to be assigned to a single data link, and then four more addresses would have to be
requested for the other four data links.
Notice what was done in Figure 2.13. The address mask is not a standard 16-bit mask for class B
addresses; the mask has been extended another eight bits so that the first 24 bits of the IP address are
interpreted as network bits. In other words, the routers and hosts have been given a mask that causes them
to read the first eight host bits as part of the network address. The result is that the major network address
applies to the entire internetwork, and each data link has become a subnetwork, or subnet. A subnet is a
subset of a major class A, B, or C address space.
NOTE
Subnet
NOTE
Subnet mask
The IP address now has three parts: the network part, the subnet part, and the host part. The address mask
is now a subnet mask, or a mask that is longer than the standard address mask. The first two octets of the
address will always be 172.21, but the third octet—whose bits are now subnet bits instead of host bits—
may range from 0 to 255. The internetwork in Figure 2.12 has subnets 1, 2, 3, 4, and 5 (172.21.1.0
through 172.21.5.0). Up to 256 subnets may be assigned under the single class B address, using the mask
shown.
Two words of caution are in order. First, not all routing protocols can support subnet addresses in which
the subnet bits are all zeros or all ones. The reason is that these protocols, called classful protocols, cannot
differentiate between an all-zero subnet and the major network number. For instance, subnet 0 in Figure
2.13 would be 172.21.0.0; the major IP address is also 172.21.0.0. The two cannot be distinguished
without further information.
NOTE
Classful protocols
Likewise, classful routing protocols cannot differentiate a broadcast on the all-ones subnet from an allsubnets
broadcast address.[8] For example, the all-ones subnet in Figure 2.13 would be 172.21.255.0. For
that subnet, the all-hosts broadcast address would be 172.21.255.255, but that is also the broadcast for all
hosts on all subnets of major network 172.21.0.0. Again, the two addresses cannot be distinguished
without further information. RIP version 1 and IGRP are both classful routing protocols; Chapter 7
introduces classless routing protocols, which can indeed use the all-zeros and all-ones subnets.
[8] The all-hosts IP broadcast address is all ones: 255.255.255.255. An all-hosts broadcast for a particular subnet would set all host bits to one; for
instance, an all hosts broadcast for subnet 172.21.1.0 would be 172.21.1.255. Finally, a broadcast for all hosts on all subnets sets the subnet bits
and the host bits to all ones: 172.21.255.255.
The second caution has to do with the verbal description of subnets and their masks. Subnetting the third
octet of a class B address, as is done is Figure 2.13, is very common; also common is hearing people
describe such a subnet design as "using a class C mask with a class B address," or "subnetting a class B
address into a class C." Both descriptions are wrong! Such descriptions frequently lead to
misunderstandings about the subnet design or to a poor understanding of subnetting itself. The proper
way to describe the subnetting scheme of Figure 2.12 is either as "a class B address with 8 bits of
subnetting," or as "a class B address with a 24-bit mask."
The subnet mask may be represented in any of three formats—dotted decimal, bitcount, and
hexadecimal—as shown in Figure 2.14. Dotted decimal is still the most common format, although the
bitcount format is becoming increasingly popular. Compared to dotted decimal, the bitcount format is
easier to write (the address is followed by a forward slash and the number of bits that are masked for the
network part). In addition, the bitcount format is more descriptive of what the mask is really doing and
therefore avoids the type of semantic misunderstandings described in the previous paragraph. Many
UNIX systems use the hexadecimal format.
Figure 2.14. The subnet mask in Figure 2.13 may be represented in three different formats.
Although the address mask must be specified to Cisco routers in dotted decimal, using the command
shown previously, the mask may be displayed by various show commands in any of the three formats by
using the command ip netmask-format [dec|hex|bit] in line configuration mode. For example, to
configure a router to display its masks in bitcount format, use:
Gladys(config)# line vty 0 4
Gladys(config-line)# ip netmask-format bit
The need for network-level addressing
Never lose sight of why network-level addresses are necessary in the first place. For routing to be
accomplished, each and every data link (network) must have a unique address; in addition, each and every
host on that data link must have an address that both identifies it as a member of the network and
distinguishes it from any other host on that network.
As defined so far, a single class A, B, or C address can be used only on a single data link. To build an
internetwork, separate addresses must be used for each data link so that those networks are uniquely
identifiable. If a separate class A, B, or C address were assigned to each data link, less than 17 million
data links could be addressed before all IP addresses were depleted. This approach is obviously
impractical, [7] as is the fact that to make full use of the host address space in the previous example, more
than 65,000 devices would have to reside on data link 172.21.0.0!
[7] Seventeen million data links may seem like a lot until you consider that even a single moderate-size business may have dozens or hundreds of
data links.
The only way to make class A, B, or C addresses practical is by dividing each major address, such as
172.21.0.0, into subnetwork addresses. Recall two facts:
1. The host portion of an address can be used as desired.
2. The network portion of an IP address is determined by the address mask assigned to that interface.
Figure 2.13 shows an internetwork to which the major class B address 172.21.0.0 has been assigned. Five
data links are interconnecting the routers, each one of which requires a network address. As it stands,
172.21.0.0 would have to be assigned to a single data link, and then four more addresses would have to be
requested for the other four data links.
Notice what was done in Figure 2.13. The address mask is not a standard 16-bit mask for class B
addresses; the mask has been extended another eight bits so that the first 24 bits of the IP address are
interpreted as network bits. In other words, the routers and hosts have been given a mask that causes them
to read the first eight host bits as part of the network address. The result is that the major network address
applies to the entire internetwork, and each data link has become a subnetwork, or subnet. A subnet is a
subset of a major class A, B, or C address space.
NOTE
Subnet
NOTE
Subnet mask
The IP address now has three parts: the network part, the subnet part, and the host part. The address mask
is now a subnet mask, or a mask that is longer than the standard address mask. The first two octets of the
address will always be 172.21, but the third octet—whose bits are now subnet bits instead of host bits—
may range from 0 to 255. The internetwork in Figure 2.12 has subnets 1, 2, 3, 4, and 5 (172.21.1.0
through 172.21.5.0). Up to 256 subnets may be assigned under the single class B address, using the mask
shown.
Two words of caution are in order. First, not all routing protocols can support subnet addresses in which
the subnet bits are all zeros or all ones. The reason is that these protocols, called classful protocols, cannot
differentiate between an all-zero subnet and the major network number. For instance, subnet 0 in Figure
2.13 would be 172.21.0.0; the major IP address is also 172.21.0.0. The two cannot be distinguished
without further information.
NOTE
Classful protocols
Likewise, classful routing protocols cannot differentiate a broadcast on the all-ones subnet from an allsubnets
broadcast address.[8] For example, the all-ones subnet in Figure 2.13 would be 172.21.255.0. For
that subnet, the all-hosts broadcast address would be 172.21.255.255, but that is also the broadcast for all
hosts on all subnets of major network 172.21.0.0. Again, the two addresses cannot be distinguished
without further information. RIP version 1 and IGRP are both classful routing protocols; Chapter 7
introduces classless routing protocols, which can indeed use the all-zeros and all-ones subnets.
[8] The all-hosts IP broadcast address is all ones: 255.255.255.255. An all-hosts broadcast for a particular subnet would set all host bits to one; for
instance, an all hosts broadcast for subnet 172.21.1.0 would be 172.21.1.255. Finally, a broadcast for all hosts on all subnets sets the subnet bits
and the host bits to all ones: 172.21.255.255.
The second caution has to do with the verbal description of subnets and their masks. Subnetting the third
octet of a class B address, as is done is Figure 2.13, is very common; also common is hearing people
describe such a subnet design as "using a class C mask with a class B address," or "subnetting a class B
address into a class C." Both descriptions are wrong! Such descriptions frequently lead to
misunderstandings about the subnet design or to a poor understanding of subnetting itself. The proper
way to describe the subnetting scheme of Figure 2.12 is either as "a class B address with 8 bits of
subnetting," or as "a class B address with a 24-bit mask."
The subnet mask may be represented in any of three formats—dotted decimal, bitcount, and
hexadecimal—as shown in Figure 2.14. Dotted decimal is still the most common format, although the
bitcount format is becoming increasingly popular. Compared to dotted decimal, the bitcount format is
easier to write (the address is followed by a forward slash and the number of bits that are masked for the
network part). In addition, the bitcount format is more descriptive of what the mask is really doing and
therefore avoids the type of semantic misunderstandings described in the previous paragraph. Many
UNIX systems use the hexadecimal format.
Figure 2.14. The subnet mask in Figure 2.13 may be represented in three different formats.
Although the address mask must be specified to Cisco routers in dotted decimal, using the command
shown previously, the mask may be displayed by various show commands in any of the three formats by
using the command ip netmask-format [dec|hex|bit] in line configuration mode. For example, to
configure a router to display its masks in bitcount format, use:
Gladys(config)# line vty 0 4
Gladys(config-line)# ip netmask-format bit
Address Masksz
The address for an entire data link—a non-host-specific network address— is represented by the network
portion of an IP address, with all host bits set to zero. For instance, the InterNIC, the body that
administers IP addresses, might assign to an applicant an address of 172.21.0.0.[6] This address is a class B
address because 172 is between 128 and 191, so the last two octets make up the host bits. Notice that they
are all set to zero. The first 16 bits (172.21.) are assigned, but address owners are free to do whatever they
please with the host bits.
[6] Actually, this address would never be assigned. It is from a group of addresses reserved for private use; most of the addresses used in this book
are from this reserved pool, described in RFC 1918. Reserved addresses are: 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, and
192.168.0.0-192.168.255.255.
Each device or interface will be assigned a unique, host-specific address such as 172.21.35.17. The
device, whether a host or a router, obviously needs to know its own address, but it also needs to be able to
determine the network to which it belongs— in this case, 172.21.0.0.
This task is accomplished by means of an address mask. The address mask is a 32-bit string, one bit for
each bit of the IP address. As a 32-bit string, the mask can be represented in dotted-decimal format just
like an IP address. This representation tends to be a stumbling block for some beginners: Although the
address mask can be written in dotted decimal, it is not an address. Table 2.3 shows the standard address
masks for the three classes of IP address.
Table 2.3. Address masks for class A, B, and C network addresses.
Class Mask Dotted Decimal
A 11111111000000000000000000000000 255.0.0.0
B 11111111111111110000000000000000 255.255.0.0
C 11111111111111111111111100000000 255.255.255.0
For each bit of the IP address, the device performs a Boolean (logical) AND function with the
corresponding bit of the address mask. The AND function can be stated as follows:
Compare two bits and derive a result. The result will be one if and only if both bits are one. If either or
both bits are zero, the result will be zero.
Figure 2.12 shows how, for a given IP address, the address mask is used to determine the network
address. The mask has a one in every bit position corresponding to a network bit of the address and a zero
in every bit position corresponding to a host bit. Because 172.21.35.17 is a class B address , the mask
must have the first two octets set to all ones and the last two octets, the host part, set to all zeros. As Table
2.3 shows, this mask can be represented in dotted decimal as 255.255.0.0.
Figure 2.12. Each bit of this class B address is ANDed with the corresponding bit of the address mask to
derive the network address.
A logical AND is performed on the IP address and its mask for every bit position; the result is shown in
Figure 2.12. In the result, every network bit is repeated, and all the host bits become zeros. So by
assigning an address of 172.21.35.17 and a mask of 255.255.0.0 to an interface, the device will know that
the interface belongs to network 172.21.0.0. Applying the AND operator to an IP address and its address
mask always reveals the network address.
An address and mask are assigned to an interface of a Cisco router (in this example, the E0 interface) by
means of the following commands:
Smokey(config)# interface ethernet 0
Smokey(config-if)# ip address 172.21.35.17 255.255.0.0
But why use address masks at all? So far, using the first octet rule seems much simpler.
portion of an IP address, with all host bits set to zero. For instance, the InterNIC, the body that
administers IP addresses, might assign to an applicant an address of 172.21.0.0.[6] This address is a class B
address because 172 is between 128 and 191, so the last two octets make up the host bits. Notice that they
are all set to zero. The first 16 bits (172.21.) are assigned, but address owners are free to do whatever they
please with the host bits.
[6] Actually, this address would never be assigned. It is from a group of addresses reserved for private use; most of the addresses used in this book
are from this reserved pool, described in RFC 1918. Reserved addresses are: 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, and
192.168.0.0-192.168.255.255.
Each device or interface will be assigned a unique, host-specific address such as 172.21.35.17. The
device, whether a host or a router, obviously needs to know its own address, but it also needs to be able to
determine the network to which it belongs— in this case, 172.21.0.0.
This task is accomplished by means of an address mask. The address mask is a 32-bit string, one bit for
each bit of the IP address. As a 32-bit string, the mask can be represented in dotted-decimal format just
like an IP address. This representation tends to be a stumbling block for some beginners: Although the
address mask can be written in dotted decimal, it is not an address. Table 2.3 shows the standard address
masks for the three classes of IP address.
Table 2.3. Address masks for class A, B, and C network addresses.
Class Mask Dotted Decimal
A 11111111000000000000000000000000 255.0.0.0
B 11111111111111110000000000000000 255.255.0.0
C 11111111111111111111111100000000 255.255.255.0
For each bit of the IP address, the device performs a Boolean (logical) AND function with the
corresponding bit of the address mask. The AND function can be stated as follows:
Compare two bits and derive a result. The result will be one if and only if both bits are one. If either or
both bits are zero, the result will be zero.
Figure 2.12 shows how, for a given IP address, the address mask is used to determine the network
address. The mask has a one in every bit position corresponding to a network bit of the address and a zero
in every bit position corresponding to a host bit. Because 172.21.35.17 is a class B address , the mask
must have the first two octets set to all ones and the last two octets, the host part, set to all zeros. As Table
2.3 shows, this mask can be represented in dotted decimal as 255.255.0.0.
Figure 2.12. Each bit of this class B address is ANDed with the corresponding bit of the address mask to
derive the network address.
A logical AND is performed on the IP address and its mask for every bit position; the result is shown in
Figure 2.12. In the result, every network bit is repeated, and all the host bits become zeros. So by
assigning an address of 172.21.35.17 and a mask of 255.255.0.0 to an interface, the device will know that
the interface belongs to network 172.21.0.0. Applying the AND operator to an IP address and its address
mask always reveals the network address.
An address and mask are assigned to an interface of a Cisco router (in this example, the E0 interface) by
means of the following commands:
Smokey(config)# interface ethernet 0
Smokey(config-if)# ip address 172.21.35.17 255.255.0.0
But why use address masks at all? So far, using the first octet rule seems much simpler.
The First Octet Rule
Without putting too fine a point on it, it can be said that there are three sizes of internetworks as measured
by the number of hosts: big, medium, and small.
Big internetworks, by definition, have a huge number of hosts. Relatively few big internetworks
exist.
Small internetworks are just the opposite. Each one is small because it has a small number of
hosts; a huge number of small internetworks exist.
Medium internetworks are just that: a medium number of them (in relation to big and small ones)
and a medium number of hosts in each one.
This high level of addressing focus requires three types—classes—of network address for the three sizes
of internetworks. Addresses for big internetworks need to be capable of addressing many hosts, but
because so few big internetworks exist, only a few big-network addresses are required.
The situation is reversed for small internetworks. Because there are many small internetworks, a large
number of small-network addresses are needed. But because a small internetwork has a small number of
hosts, each of the many network addresses only requires a few host addresses.
For medium-sized internetworks, a medium number of network addresses and a medium number of host
addresses will be available for each network address.
Figure 2.10 shows how the network and host portions of IP addresses are divvied up for these three
classes.
Figure 2.10. Class A, B, and C IP address formats.
The big, medium, and small networks described thus far map to address classes as follows:
Class A IP addresses are for big internetworks. The first octet is the network portion, and the last
three octets are the host portion. Only 256 numbers are available in the eight-bit network part, but
224 or 16,777,216 numbers are available in the host part of each of those network addresses.
Class B addresses are for medium-size internetworks. The first two octets are the network portion
, and the last two octets are the host portion. There are 216 or 65,536 available numbers in the
network part and an equal number in the host part.
Class C addresses are just the opposite of class A. The first three octets are the network portion,
and the last octet is the host portion.
Because all IP addresses are 32-bit binary strings, a way of distinguishing the class to which a particular
address belongs is necessary. The first octet rule, illustrated in Figure 2.11, provides the means to make
such a distinction and can be described as follows:
Figure 2.11. The first octet rule.
For class A addresses, the first bit of the first octet— that is, the left-most bit of the entire 32-bit
string— is always set to zero. Therefore, we can find the minimum and maximum numbers in the
class A range by setting all the remaining bits in the first octet to zero (for the minimum) and one
(for the maximum). This action results in the decimal numbers 0 and 127 with a few exceptions: 0
is reserved as part of the default address (Chapter 12, "Default Routes and On-Demand Routing"
), and 127 is reserved for internal loopback addresses.[4] That leaves 1 through 126; any IP address
whose first octet is between 1 and 126 inclusive is a class A address.
[4] UNIX machines use an internal loopback address (typically 127.0.0.1) to send traffic to themselves. Data may be sent to this
address and returned to the transmitting process without ever leaving the device.
Class B addresses always have their left-most bit set to one and the second bit set to zero. Again
finding the minimum and maximum number of the first octet by setting all remaining bits to zero
and then to one, we see in Figure 2.9 that any address whose first octet is in the decimal range 128
through 191 is a class B address.
In class C addresses, the first two bits are set to one, and the third bit is set to zero. The result is a
first octet range of 192 through 223.[5]
[5] Notice that 223 does not exhaust all available numbers in the first octet. See Configuration Excerise 1 at the end of this chapter.
So far IP addressing doesn't seem so difficult. A router or host could easily determine the network part of
an IP address by using the first octet rule. If the first bit is 0, then read the first eight bits to find the
network address. If the first two bits are 10, then read the first 16 bits; and if the first three bits are 110,
then read 24 bits in to get the network address. Unfortunately, things are not that easy.
by the number of hosts: big, medium, and small.
Big internetworks, by definition, have a huge number of hosts. Relatively few big internetworks
exist.
Small internetworks are just the opposite. Each one is small because it has a small number of
hosts; a huge number of small internetworks exist.
Medium internetworks are just that: a medium number of them (in relation to big and small ones)
and a medium number of hosts in each one.
This high level of addressing focus requires three types—classes—of network address for the three sizes
of internetworks. Addresses for big internetworks need to be capable of addressing many hosts, but
because so few big internetworks exist, only a few big-network addresses are required.
The situation is reversed for small internetworks. Because there are many small internetworks, a large
number of small-network addresses are needed. But because a small internetwork has a small number of
hosts, each of the many network addresses only requires a few host addresses.
For medium-sized internetworks, a medium number of network addresses and a medium number of host
addresses will be available for each network address.
Figure 2.10 shows how the network and host portions of IP addresses are divvied up for these three
classes.
Figure 2.10. Class A, B, and C IP address formats.
The big, medium, and small networks described thus far map to address classes as follows:
Class A IP addresses are for big internetworks. The first octet is the network portion, and the last
three octets are the host portion. Only 256 numbers are available in the eight-bit network part, but
224 or 16,777,216 numbers are available in the host part of each of those network addresses.
Class B addresses are for medium-size internetworks. The first two octets are the network portion
, and the last two octets are the host portion. There are 216 or 65,536 available numbers in the
network part and an equal number in the host part.
Class C addresses are just the opposite of class A. The first three octets are the network portion,
and the last octet is the host portion.
Because all IP addresses are 32-bit binary strings, a way of distinguishing the class to which a particular
address belongs is necessary. The first octet rule, illustrated in Figure 2.11, provides the means to make
such a distinction and can be described as follows:
Figure 2.11. The first octet rule.
For class A addresses, the first bit of the first octet— that is, the left-most bit of the entire 32-bit
string— is always set to zero. Therefore, we can find the minimum and maximum numbers in the
class A range by setting all the remaining bits in the first octet to zero (for the minimum) and one
(for the maximum). This action results in the decimal numbers 0 and 127 with a few exceptions: 0
is reserved as part of the default address (Chapter 12, "Default Routes and On-Demand Routing"
), and 127 is reserved for internal loopback addresses.[4] That leaves 1 through 126; any IP address
whose first octet is between 1 and 126 inclusive is a class A address.
[4] UNIX machines use an internal loopback address (typically 127.0.0.1) to send traffic to themselves. Data may be sent to this
address and returned to the transmitting process without ever leaving the device.
Class B addresses always have their left-most bit set to one and the second bit set to zero. Again
finding the minimum and maximum number of the first octet by setting all remaining bits to zero
and then to one, we see in Figure 2.9 that any address whose first octet is in the decimal range 128
through 191 is a class B address.
In class C addresses, the first two bits are set to one, and the third bit is set to zero. The result is a
first octet range of 192 through 223.[5]
[5] Notice that 223 does not exhaust all available numbers in the first octet. See Configuration Excerise 1 at the end of this chapter.
So far IP addressing doesn't seem so difficult. A router or host could easily determine the network part of
an IP address by using the first octet rule. If the first bit is 0, then read the first eight bits to find the
network address. If the first two bits are 10, then read the first 16 bits; and if the first three bits are 110,
then read 24 bits in to get the network address. Unfortunately, things are not that easy.
The TCP/IP Protocol Layers
The TCP/IP Protocol Layers
Figure 2.1 shows the TCP/IP protocol suite in relationship to the OSI reference model. The network
interface layer, which corresponds to the OSI physical and data link layers, is not really part of the
specification. However, it has become a de facto layer either as shown in Figure 2.1 or as separate
physical and data link layers. It is described in this section in terms of the OSI physical and data link
layers.
The physical layer contains the protocols relating to the physical medium on which TCP/IP will be
communicating. Officially, the protocols of this layer fall within four categories that together describe all
aspects of physical media:
Electrical/optical protocols describe signal characteristics such as voltage or photonic levels, bit
timing, encoding, and signal shape.
Mechanical protocols are specifications such as the dimensions of a connector or the metallic
makeup of a wire.
Functional protocols describe what something does. For example, "Request to Send" is the
functional description of pin 4 of an EIA-232-D connector.
Procedural protocols describe how something is done. For example, a binary 1 is represented on
an EIA-232-D lead as a voltage more negative than –3 volts.
The data link layer was described in Chapter 1, "Basic Concepts: Internetworks, Routers, and Addresses."
This layer contains the protocols that control the physical layer: how the medium is accessed and shared,
how devices on the medium are identified, and how data is framed before being transmitted on the
medium. Examples of data link protocols are IEEE 802.3/Ethernet, IEEE 802.5/Token Ring, and FDDI.
The internet layer, corresponding to the OSI network layer, is primarily responsible for enabling the
routing of data across logical internetwork paths, such as in Figure 1.9, by defining a packet format and
an addressing format. This layer is, of course, the one with which this book is most concerned.
The host-to-host layer, corresponding to the OSI transport layer, specifies the protocols that control the
internet layer, much as the data link layer controls the physical layer. Both the host-to-host and data link
layers can define such mechanisms as flow and error control. The difference is that while data link
protocols control traffic on the data link— the physical medium connecting two devices— the transport
layer controls traffic on the logical link— the end-to-end connection of two devices whose logical
connection traverses a series of data links.
The application layer corresponds to the OSI session, presentation, and application layers. Although
some routing protocols such as BGP and RIP reside at this layer, the most common services of the
application layer provide the interfaces by which user applications access the network.
A function common to the protocol suite of Figure 2.1 and any other protocol suites is multiplexing
between layers. Many applications may use a service at the host-to-host layer, and many services at the
host-to-host layer may use the internet layer. Multiple protocol suites (IP, IPX, AppleTalk, for example)
may share a physical link via common data link protocols.
The IP Packet Header
Figure 2.2 shows the format of the IP packet header, specified in RFC 791. Most fields in this packet have
some importance to routing.
Version identifies the I P version to which the packet belongs. This four-bit field is usually set to binary
0100; version 4 (IPv4) is in current, common use. A newer version of the protocol, not yet in widespread
deployment, is version 6 (IPv6), sometimes referred to as" next-generation IP"(IPng). All currently
assigned version numbers can be seen in Table 2.1, along with a few of the relevant RFCs. All versions
other than 4 and 6 (built on an earlier proposal called Simple Internet Protocol, or SIP, which also carried
a version number of 6) now exist only as "culture," and it will be left to the curious to read their cited
RFCs.
Header Length is a four-bit field that tells, as the name implies, the length of the IP header. The reason
this field is included is that the Options field (described later in this section) can vary in size. The
minimum length of the IP header is 20 octets, and the options may increase this size up to a maximum of
24 octets. This field describes the length of the header in terms of 32-bit words— five for the minimum
160-bit size and six for the maximum.
Table 2.1. IP version numbers.
Number Version RFC
0 Reserved
1–3 Unassigned
4 Internet Protocol (IP) 791
5 ST Datagram Mode 1190
6 Simple Internet Protocol (SIP)
6 IPng 1883
7 TP/IX 1475
8 P Internet Protocol (PIP) 1621
9 TCP and UDP over Bigger Addresses (TUBA) 1347
10–14 Unassigned
15 Reserved
Type of Service (TOS) is an eight-bit field that can be used for specifying special handling of the packet.
This field actually can be broken down into two subfields: Precedence and TOS. Precedence sets a
priority for the packet, the way a package might be sent overnight, 2-day delivery, or general post. TOS
allows the selection of a delivery service in terms of throughput, delay, reliability, and monetary cost.
Although this field is not commonly used (all the bits will usually be set to zero), early specifications of
the Open Shortest Path First (OSPF) protocol called for TOS routing. Also, the Precedence bits are occasionally used in Quality of Service (QoS) applications. Figure 2.3 summarizes the eight TOS bits; for
more information , see RFC 1340 and RFC 1349.
Figure 2.3. The Type of Service field.
Total Length is a 16-bit field specifying the total length of the packet, including the header, in octets. By
subtracting the header length, a receiver may determine the size of the packet's data payload. Because the
largest decimal number that can be described with 16 bits is 65,535, the maximum possible size of an IP
packet is 65,535 octets.
Identifier is a 16-bit field used in conjunction with the Flags and Fragment Offset fields for fragmentation
of a packet. Packets must be fragmented into smaller packets if the original length exceeds the Maximum
Transmission Unit (MTU) of a data link through which they pass. For example, consider a 5,000-byte
packet traveling through an internetwork. It encounters a data link whose MTU is 1,500 bytes— that is,
the frame can contain a maximum packet size of 1,500 bytes. The router that places the packet onto this
data link must first fragment the packet into chunks of no more than 1,500 octets each. The router then
marks each fragment with the same number in the Identifier field so that a receiving device can identify
the fragments that go together.[1]
[1] A fragmented packet is not reassembled at the other end of the data link; the packet stays fragmented until it reaches its final destination.
NOTE
The DF bit can be used in troubleshooting to determine a path's MTU.
Flags is a three-bit field in which the first bit is unused. The second is the Don't Fragment (DF) bit. When
the DF bit is set to one, a router cannot fragment the packet. If the packet cannot be forwarded without
fragmenting, the router drops the packet and sends an error message to the source. This function enables
the testing of MTUs in an internetwork. The DF bit can be set using the Extended Ping utility on Cisco
routers, as shown in Figure 2.4.
30
Figure 2.1 shows the TCP/IP protocol suite in relationship to the OSI reference model. The network
interface layer, which corresponds to the OSI physical and data link layers, is not really part of the
specification. However, it has become a de facto layer either as shown in Figure 2.1 or as separate
physical and data link layers. It is described in this section in terms of the OSI physical and data link
layers.
The physical layer contains the protocols relating to the physical medium on which TCP/IP will be
communicating. Officially, the protocols of this layer fall within four categories that together describe all
aspects of physical media:
Electrical/optical protocols describe signal characteristics such as voltage or photonic levels, bit
timing, encoding, and signal shape.
Mechanical protocols are specifications such as the dimensions of a connector or the metallic
makeup of a wire.
Functional protocols describe what something does. For example, "Request to Send" is the
functional description of pin 4 of an EIA-232-D connector.
Procedural protocols describe how something is done. For example, a binary 1 is represented on
an EIA-232-D lead as a voltage more negative than –3 volts.
The data link layer was described in Chapter 1, "Basic Concepts: Internetworks, Routers, and Addresses."
This layer contains the protocols that control the physical layer: how the medium is accessed and shared,
how devices on the medium are identified, and how data is framed before being transmitted on the
medium. Examples of data link protocols are IEEE 802.3/Ethernet, IEEE 802.5/Token Ring, and FDDI.
The internet layer, corresponding to the OSI network layer, is primarily responsible for enabling the
routing of data across logical internetwork paths, such as in Figure 1.9, by defining a packet format and
an addressing format. This layer is, of course, the one with which this book is most concerned.
The host-to-host layer, corresponding to the OSI transport layer, specifies the protocols that control the
internet layer, much as the data link layer controls the physical layer. Both the host-to-host and data link
layers can define such mechanisms as flow and error control. The difference is that while data link
protocols control traffic on the data link— the physical medium connecting two devices— the transport
layer controls traffic on the logical link— the end-to-end connection of two devices whose logical
connection traverses a series of data links.
The application layer corresponds to the OSI session, presentation, and application layers. Although
some routing protocols such as BGP and RIP reside at this layer, the most common services of the
application layer provide the interfaces by which user applications access the network.
A function common to the protocol suite of Figure 2.1 and any other protocol suites is multiplexing
between layers. Many applications may use a service at the host-to-host layer, and many services at the
host-to-host layer may use the internet layer. Multiple protocol suites (IP, IPX, AppleTalk, for example)
may share a physical link via common data link protocols.
The IP Packet Header
Figure 2.2 shows the format of the IP packet header, specified in RFC 791. Most fields in this packet have
some importance to routing.
Version identifies the I P version to which the packet belongs. This four-bit field is usually set to binary
0100; version 4 (IPv4) is in current, common use. A newer version of the protocol, not yet in widespread
deployment, is version 6 (IPv6), sometimes referred to as" next-generation IP"(IPng). All currently
assigned version numbers can be seen in Table 2.1, along with a few of the relevant RFCs. All versions
other than 4 and 6 (built on an earlier proposal called Simple Internet Protocol, or SIP, which also carried
a version number of 6) now exist only as "culture," and it will be left to the curious to read their cited
RFCs.
Header Length is a four-bit field that tells, as the name implies, the length of the IP header. The reason
this field is included is that the Options field (described later in this section) can vary in size. The
minimum length of the IP header is 20 octets, and the options may increase this size up to a maximum of
24 octets. This field describes the length of the header in terms of 32-bit words— five for the minimum
160-bit size and six for the maximum.
Table 2.1. IP version numbers.
Number Version RFC
0 Reserved
1–3 Unassigned
4 Internet Protocol (IP) 791
5 ST Datagram Mode 1190
6 Simple Internet Protocol (SIP)
6 IPng 1883
7 TP/IX 1475
8 P Internet Protocol (PIP) 1621
9 TCP and UDP over Bigger Addresses (TUBA) 1347
10–14 Unassigned
15 Reserved
Type of Service (TOS) is an eight-bit field that can be used for specifying special handling of the packet.
This field actually can be broken down into two subfields: Precedence and TOS. Precedence sets a
priority for the packet, the way a package might be sent overnight, 2-day delivery, or general post. TOS
allows the selection of a delivery service in terms of throughput, delay, reliability, and monetary cost.
Although this field is not commonly used (all the bits will usually be set to zero), early specifications of
the Open Shortest Path First (OSPF) protocol called for TOS routing. Also, the Precedence bits are occasionally used in Quality of Service (QoS) applications. Figure 2.3 summarizes the eight TOS bits; for
more information , see RFC 1340 and RFC 1349.
Figure 2.3. The Type of Service field.
Total Length is a 16-bit field specifying the total length of the packet, including the header, in octets. By
subtracting the header length, a receiver may determine the size of the packet's data payload. Because the
largest decimal number that can be described with 16 bits is 65,535, the maximum possible size of an IP
packet is 65,535 octets.
Identifier is a 16-bit field used in conjunction with the Flags and Fragment Offset fields for fragmentation
of a packet. Packets must be fragmented into smaller packets if the original length exceeds the Maximum
Transmission Unit (MTU) of a data link through which they pass. For example, consider a 5,000-byte
packet traveling through an internetwork. It encounters a data link whose MTU is 1,500 bytes— that is,
the frame can contain a maximum packet size of 1,500 bytes. The router that places the packet onto this
data link must first fragment the packet into chunks of no more than 1,500 octets each. The router then
marks each fragment with the same number in the Identifier field so that a receiving device can identify
the fragments that go together.[1]
[1] A fragmented packet is not reassembled at the other end of the data link; the packet stays fragmented until it reaches its final destination.
NOTE
The DF bit can be used in troubleshooting to determine a path's MTU.
Flags is a three-bit field in which the first bit is unused. The second is the Don't Fragment (DF) bit. When
the DF bit is set to one, a router cannot fragment the packet. If the packet cannot be forwarded without
fragmenting, the router drops the packet and sends an error message to the source. This function enables
the testing of MTUs in an internetwork. The DF bit can be set using the Extended Ping utility on Cisco
routers, as shown in Figure 2.4.
30
TCP/IP Review
The TCP/IP Protocol Layers
The IP Packet Header
IP Addresses
ARP
ICMP
The Host-to-Host Layer
The purpose of this chapter is to examine the details of the protocols that enable, control, or contribute to
the routing of TCP/IP, not to do an in-depth study of the TCP/IP protocol suite. Several books on the
recommended reading list at the end of the chapter cover the subject in depth. Read at least one.
Conceived in the early 1970s by Vint Cerf and Bob Kahn, TCP/IP and its layered protocol architecture
predates the ISO's OSI reference model. A brief review of TCP/IP's layers will be useful in understanding
how the various functions and services examined in this chapter interrelate.
The IP Packet Header
IP Addresses
ARP
ICMP
The Host-to-Host Layer
The purpose of this chapter is to examine the details of the protocols that enable, control, or contribute to
the routing of TCP/IP, not to do an in-depth study of the TCP/IP protocol suite. Several books on the
recommended reading list at the end of the chapter cover the subject in depth. Read at least one.
Conceived in the early 1970s by Vint Cerf and Bob Kahn, TCP/IP and its layered protocol architecture
predates the ISO's OSI reference model. A brief review of TCP/IP's layers will be useful in understanding
how the various functions and services examined in this chapter interrelate.
Repeaters and Bridges
The information presented so far may be distilled into a few brief statements:
A data communication network is a group of two or more devices connected by a common, shared
medium.
These devices have an agreed-upon set of rules, usually called the Media Access Control, or
MAC, that govern how the media is shared.
Each and every device has an identifier, and each identifier is unique to only one device.
Using these identifiers, the devices communicate by encapsulating the data they need to send
within a virtual envelope called a frame.
So here's this wonderful resource-sharing tool called a LAN. It's so wonderful, in fact, that everyone
wants to be connected to it. And herein is the rub. As a LAN grows, new problems present themselves.
The first problem is one of physical distance. Figure 1.4 shows that three factors can influence an
electrical signal. These factors may decrease or eliminate any intelligence the signal represents:
Figure 1.4. Attenuation, interference, and distortion prevent a signal from arriving in the same shape it was
in when it left. Attenuation (a) is a function of the resistance of the wire. A certain amount of signal energy
must be spent "pushing past" the resistance. Interference (b) is a function of outside influences—noise—
which adds characteristics to the signal that should not be there. Distortion (c) is a function of the wire
impeding different frequency components of the signal in different ways.
Attenuation
Interference
Distortion
As the distance the signal must travel down the wire increases, so do the degrading effects of these three
factors. Photonic pulses traveling along an optical fiber are much less susceptible to interference but will
still succumb to attenuation and distortion.
Repeaters are added to the wire at certain intervals to alleviate the difficulties associated with excessive
distance. A repeater is placed on the media some distance from the signal source but still near enough to
be able to correctly interpret the signal (see Figure 1.5). It then repeats the signal by producing a new,
clean copy of the old degraded signal. Hence, the name repeater.
Figure 1.5. By placing a repeater in the link at a distance where the original signal can still be recognized,
despite the effects of attenuation, interference, and distortion, a fresh signal can be generated and the
length of the wire extended.
A repeater may be thought of as part of the physical medium. It has no real intelligence, but merely
regenerates a signal; a digital repeater is sometimes facetiously called a "bit spitter" for this reason.
The second problem associated with growing LANs is congestion. Repeaters are added to extend the
distance of the wire and to add devices; however, the fundamental reason for having a LAN is to share
resources. When a too-large population tries to share limited resources, the rules of polite behavior begin
to be violated and conflicts erupt. Among humans, poverty, crime, and warfare may result. On Ethernet
networks, collisions deplete the available bandwidth. On Token Ring and FDDI networks, the token
rotation time and timing jitter may become prohibitively high.
Drawing boundaries between populations of LAN devices is a solution to overcrowding. This task is
accomplished by the use of bridges.[6]
[6] If you cut through the marketing hype surrounding modern Ethernet and Token Ring switches, you'll find that these very useful tools are
merely high-performance bridges.
Figure 1.6 shows the most common type of bridge: a transparent bridge. It performs three simple
functions: learning, forwarding, and filtering. It is transparent in that end stations have no knowledge of
the bridge.
Figure 1.6. The transparent bridge segments network devices into manageable populations. A bridging
table tracks the members of each population and manages communication between the populations.
The bridge learns by listening promiscuously on all its ports. That is, every time a station transmits a
frame, the bridge examines the source identifier of the frame. It then records the identifier in a bridging
table, along with the port on which it was heard. The bridge therefore learns which stations are out port 1,
which are out port 2, and so on.
In Figure 1.6, the bridge uses the information in its bridging table to forward frames when a member of
one population—say, a station out port 1—wants to send a frame to a member of another population: a
station out port 2.
A bridge that only learns and forwards would have no use. The real utility of a bridge is in the third
function, filtering. Figure 1.6 shows that if a station out port 2 sends a frame to another station out port 2,
the bridge will examine the frame. The bridge consults its bridging table and sees that the destination
device is out the same port on which the frame was received and will not forward the frame. The frame is
filtered.
Bridges enable the addition of far more devices to a network than would be possible if all the devices
were in a single population, contending for the same bandwidth. Filtering means that only frames that 20
A data communication network is a group of two or more devices connected by a common, shared
medium.
These devices have an agreed-upon set of rules, usually called the Media Access Control, or
MAC, that govern how the media is shared.
Each and every device has an identifier, and each identifier is unique to only one device.
Using these identifiers, the devices communicate by encapsulating the data they need to send
within a virtual envelope called a frame.
So here's this wonderful resource-sharing tool called a LAN. It's so wonderful, in fact, that everyone
wants to be connected to it. And herein is the rub. As a LAN grows, new problems present themselves.
The first problem is one of physical distance. Figure 1.4 shows that three factors can influence an
electrical signal. These factors may decrease or eliminate any intelligence the signal represents:
Figure 1.4. Attenuation, interference, and distortion prevent a signal from arriving in the same shape it was
in when it left. Attenuation (a) is a function of the resistance of the wire. A certain amount of signal energy
must be spent "pushing past" the resistance. Interference (b) is a function of outside influences—noise—
which adds characteristics to the signal that should not be there. Distortion (c) is a function of the wire
impeding different frequency components of the signal in different ways.
Attenuation
Interference
Distortion
As the distance the signal must travel down the wire increases, so do the degrading effects of these three
factors. Photonic pulses traveling along an optical fiber are much less susceptible to interference but will
still succumb to attenuation and distortion.
Repeaters are added to the wire at certain intervals to alleviate the difficulties associated with excessive
distance. A repeater is placed on the media some distance from the signal source but still near enough to
be able to correctly interpret the signal (see Figure 1.5). It then repeats the signal by producing a new,
clean copy of the old degraded signal. Hence, the name repeater.
Figure 1.5. By placing a repeater in the link at a distance where the original signal can still be recognized,
despite the effects of attenuation, interference, and distortion, a fresh signal can be generated and the
length of the wire extended.
A repeater may be thought of as part of the physical medium. It has no real intelligence, but merely
regenerates a signal; a digital repeater is sometimes facetiously called a "bit spitter" for this reason.
The second problem associated with growing LANs is congestion. Repeaters are added to extend the
distance of the wire and to add devices; however, the fundamental reason for having a LAN is to share
resources. When a too-large population tries to share limited resources, the rules of polite behavior begin
to be violated and conflicts erupt. Among humans, poverty, crime, and warfare may result. On Ethernet
networks, collisions deplete the available bandwidth. On Token Ring and FDDI networks, the token
rotation time and timing jitter may become prohibitively high.
Drawing boundaries between populations of LAN devices is a solution to overcrowding. This task is
accomplished by the use of bridges.[6]
[6] If you cut through the marketing hype surrounding modern Ethernet and Token Ring switches, you'll find that these very useful tools are
merely high-performance bridges.
Figure 1.6 shows the most common type of bridge: a transparent bridge. It performs three simple
functions: learning, forwarding, and filtering. It is transparent in that end stations have no knowledge of
the bridge.
Figure 1.6. The transparent bridge segments network devices into manageable populations. A bridging
table tracks the members of each population and manages communication between the populations.
The bridge learns by listening promiscuously on all its ports. That is, every time a station transmits a
frame, the bridge examines the source identifier of the frame. It then records the identifier in a bridging
table, along with the port on which it was heard. The bridge therefore learns which stations are out port 1,
which are out port 2, and so on.
In Figure 1.6, the bridge uses the information in its bridging table to forward frames when a member of
one population—say, a station out port 1—wants to send a frame to a member of another population: a
station out port 2.
A bridge that only learns and forwards would have no use. The real utility of a bridge is in the third
function, filtering. Figure 1.6 shows that if a station out port 2 sends a frame to another station out port 2,
the bridge will examine the frame. The bridge consults its bridging table and sees that the destination
device is out the same port on which the frame was received and will not forward the frame. The frame is
filtered.
Bridges enable the addition of far more devices to a network than would be possible if all the devices
were in a single population, contending for the same bandwidth. Filtering means that only frames that 20
Data Link Addresses
In a certain community in Colorado, two individuals are named Jeff Doyle. One Jeff Doyle frequently
receives telephone calls for the person with whom he shares a name—so much so that his clever wife has
posted the correct number next to the phone to redirect errant callers to their desired destination. In other
words, because two individuals cannot be uniquely identified, data is occasionally delivered incorrectly
and a process must be implemented to correct the error.
Among family, friends, and associates, a given name is usually sufficient for accurately distinguishing
individuals. However, as this example shows, most names become inaccurate over a larger population. A
more unique identifier, such as a United States Social Security number, is needed to distinguish one
person from every other.
NOTE
Frame
Devices on a LAN must also be uniquely and individually identified or they, like humans sharing the
same name, will receive data not intended for them. When data is to be delivered on aLAN , it is
encapsulated within an entity called a frame, a kind of binary envelope. Think of data encapsulation as
being the digital equivalent of placing a letter inside an envelope, as in Figure 1.1[1] . A destination address
and a return (source) address are written on the outside of the envelope. Without a destination address, the
postal service would have no idea where to deliver the letter. Likewise, when a frame is placed on a data
link, all devices attached to the link "see" the frame; therefore, some mechanism must indicate which
device should pick up the frame and read the enclosed data.
receives telephone calls for the person with whom he shares a name—so much so that his clever wife has
posted the correct number next to the phone to redirect errant callers to their desired destination. In other
words, because two individuals cannot be uniquely identified, data is occasionally delivered incorrectly
and a process must be implemented to correct the error.
Among family, friends, and associates, a given name is usually sufficient for accurately distinguishing
individuals. However, as this example shows, most names become inaccurate over a larger population. A
more unique identifier, such as a United States Social Security number, is needed to distinguish one
person from every other.
NOTE
Frame
Devices on a LAN must also be uniquely and individually identified or they, like humans sharing the
same name, will receive data not intended for them. When data is to be delivered on aLAN , it is
encapsulated within an entity called a frame, a kind of binary envelope. Think of data encapsulation as
being the digital equivalent of placing a letter inside an envelope, as in Figure 1.1[1] . A destination address
and a return (source) address are written on the outside of the envelope. Without a destination address, the
postal service would have no idea where to deliver the letter. Likewise, when a frame is placed on a data
link, all devices attached to the link "see" the frame; therefore, some mechanism must indicate which
device should pick up the frame and read the enclosed data.
Bicycles with Motors
One of the difficulties of decentralized computing is that it isolates users from one another and from the
data and applications they may need to use in common. When a file is created, how is it shared with Tom,
Dick, and Harriet down the hall? The early solution to this was the storied SneakerNet: Put the file on
floppy disks and hand carry them to the necessary destinations. But what happens when Tom, Dick, and
Harriet modify their copies of the file? How does one ensure that all information in all versions are
synchronized? What if those three coworkers are on different floors or in different buildings or cities?
What if the file needs to be updated several times a day? What if there are not three coworkers, but 300
people? What if all 300 people occasionally need to print a hard copy of some modification they have
made to the file?
The local-area network, or LAN, is a small step back to centralization. LANs are a means of pooling and
sharing resources. Servers enable everyone to access a common copy of a file or a common database; no
more "walkabouts" with floppies, no more worries about inconsistent information. E-mail furnishes a
compromise between phone calls, which require the presence of the recipient, and physical mail service,
which is called snail mail for a good reason. The sharing of printers and modem pools eliminates the need
for expensive, periodically used services on every desk.
Of course, in their infancy, LANs met with more than a little derision from the mainframe manufacturers.
A commonly heard jibe during the early years was, "A LAN is like a bike with a motor, and we don't
make Mopeds!" What a difference a few years and a few billion dollars would make.
Physically, a LAN accomplishes resource pooling among a group of devices by connecting them to a
common, shared medium, or datalink. This medium may be twisted-pair wires (shielded or unshielded),
coaxial cable, optical fiber, infrared light, or whatever. What matters is that all devices attach commonly
to the data link through some sort of network interface.
A shared physical medium is not enough. Rules must govern how the data link is shared. As in any
community, a set of rules is necessary to keep life orderly, to ensure that all parties behave themselves,
and to guarantee that everyone gets a fair share of the available resources. For a local-area network, this
set of rules, or protocol, is generally called a Media Access Control (MAC). The MAC, as the name
implies, dictates how each machine will access and share a given medium.
So far, a LAN has been defined as being a community of devices such as PCs, printers, and servers
coexisting on a common communications medium and following a common protocol that regulates how
they access the medium. But there is one last requirement: As in any community, each individual must be
uniquely identifiable.
data and applications they may need to use in common. When a file is created, how is it shared with Tom,
Dick, and Harriet down the hall? The early solution to this was the storied SneakerNet: Put the file on
floppy disks and hand carry them to the necessary destinations. But what happens when Tom, Dick, and
Harriet modify their copies of the file? How does one ensure that all information in all versions are
synchronized? What if those three coworkers are on different floors or in different buildings or cities?
What if the file needs to be updated several times a day? What if there are not three coworkers, but 300
people? What if all 300 people occasionally need to print a hard copy of some modification they have
made to the file?
The local-area network, or LAN, is a small step back to centralization. LANs are a means of pooling and
sharing resources. Servers enable everyone to access a common copy of a file or a common database; no
more "walkabouts" with floppies, no more worries about inconsistent information. E-mail furnishes a
compromise between phone calls, which require the presence of the recipient, and physical mail service,
which is called snail mail for a good reason. The sharing of printers and modem pools eliminates the need
for expensive, periodically used services on every desk.
Of course, in their infancy, LANs met with more than a little derision from the mainframe manufacturers.
A commonly heard jibe during the early years was, "A LAN is like a bike with a motor, and we don't
make Mopeds!" What a difference a few years and a few billion dollars would make.
Physically, a LAN accomplishes resource pooling among a group of devices by connecting them to a
common, shared medium, or datalink. This medium may be twisted-pair wires (shielded or unshielded),
coaxial cable, optical fiber, infrared light, or whatever. What matters is that all devices attach commonly
to the data link through some sort of network interface.
A shared physical medium is not enough. Rules must govern how the data link is shared. As in any
community, a set of rules is necessary to keep life orderly, to ensure that all parties behave themselves,
and to guarantee that everyone gets a fair share of the available resources. For a local-area network, this
set of rules, or protocol, is generally called a Media Access Control (MAC). The MAC, as the name
implies, dictates how each machine will access and share a given medium.
So far, a LAN has been defined as being a community of devices such as PCs, printers, and servers
coexisting on a common communications medium and following a common protocol that regulates how
they access the medium. But there is one last requirement: As in any community, each individual must be
uniquely identifiable.
Internetworks, Routers, and Addresses
Basic Concepts: Internetworks, Routers, and
Addresses
Bicycles with Motors
Data Link Addresses
Repeaters and Bridges
Routers
Network Addresses
Once upon a time, computing power and data storage were centralized. Mainframes were locked away in
climate-controlled, highly secure rooms, watched over by a priesthood of IS administrators. Contact with
a computer was typically accomplished by bringing a stack of Hollerith cards to the priests, who
interceded on our behalf with the Big Kahuna.
The advent of the minicomputer took the computers out of the IS temple of corporations and universities
and brought them to the departmental level. For a mere $100K or two, engineering and accounting and
any other department with a need for data processing could have their own machines.
Following on the heels of the minicomputers were microcomputers, bringing data processing right to the
desktop. Affordability and accessibility dropped from the departmental level to the individual level,
making the phrase personal computer part of everyone's vocabulary.
Desktop computing has evolved at a mind-boggling pace, but it was certainly not an immediate
alternative to centralized, mainframe-based computing. There was a ramping-up period in which both
software and hardware had to be developed to a level where personal computers could be taken seriously.
Addresses
Bicycles with Motors
Data Link Addresses
Repeaters and Bridges
Routers
Network Addresses
Once upon a time, computing power and data storage were centralized. Mainframes were locked away in
climate-controlled, highly secure rooms, watched over by a priesthood of IS administrators. Contact with
a computer was typically accomplished by bringing a stack of Hollerith cards to the priests, who
interceded on our behalf with the Big Kahuna.
The advent of the minicomputer took the computers out of the IS temple of corporations and universities
and brought them to the departmental level. For a mere $100K or two, engineering and accounting and
any other department with a need for data processing could have their own machines.
Following on the heels of the minicomputers were microcomputers, bringing data processing right to the
desktop. Affordability and accessibility dropped from the departmental level to the individual level,
making the phrase personal computer part of everyone's vocabulary.
Desktop computing has evolved at a mind-boggling pace, but it was certainly not an immediate
alternative to centralized, mainframe-based computing. There was a ramping-up period in which both
software and hardware had to be developed to a level where personal computers could be taken seriously.
Cisco Diagnostic Commands and TCP/IP Troubleshooting
The next two chapters are focused primarily on essential TCP/IP
troubleshooting skills and tools. Here in this chapter, we will
explain
show
and
debug
commands. In addition, generic commands
such as
ping
and
traceroute
will be applied to network problems. Problem isolation
techniques that are used in troubleshooting LANs will be outlined and implemented. Finally,
the use and kinds of access lists will be examined.
The next chapter, Chapter 38, “TCP/IP Routing Protocol Troubleshooting,” focuses on the
IP routing protocols, including RIP, IGRP, EIGRP, OSPF, and BGP. In addition to an explanation
of these routing protocols, the
show
and
debug
commands used specifically for them will
be examined. The final part of Chapter 38 explores redistribution issues and solutions.
Many of the
show
and
debug
commands are not protocol-specific. Though these commands do
not deal exclusively with the TCP/IP protocol, they are used in troubleshooting many TCP/IP problems
and therefore are included in this chapter for completeness. As is the case with the
show
and
debug
commands, logging and core dumps are not limited to the TCP/IP but can be used to contribute
to troubleshooting TCP/IP problems and are also included in this chapter for completeness.
In addition to all the detailed problem-solving techniques presented in these two chapters,
quick reference summary charts are located at the end of Chapter 38. These tables help to
quickly associate a cause to many TCP/IP symptoms.
Troubleshooting Commands
We will cover several troubleshooting tools in this chapter, each of which is part of the Cisco IOS.
There are many
show
commands that are supported by the router. In addition to
show
commands,
a tool called debug is used to see specific information regarding packet transfer and exchange.
Part of effectively using these tools is using them without adversely affecting the router and its
many processes. Here you will learn the specifics of several troubleshooting commands, along with
the information needed in order to use them without causing additional problems on your network.
We start with non-intrusive, Cisco-specific
show
commands. After discussing the
show
commands, we move on to the debug tool. To finalize this section, we discuss some non-
Cisco-specific troubleshooting tools:
ping
and
traceroute
.
show
Commands
A large number of
show
commands are supported by Cisco IOS. Explaining them all is beyond the
scope of this book. The most effective and useful
show
commands are described in the following
sections, and Table 37.1 lists the ones most frequently used. To get an idea of all of the
show
commands,
execute the
show ?
command from the router prompt.
show version
This command is used to display the system hardware and software versions. It also provides
information about how long the router was running and the reason it was last restarted. Review
the following output of the show version command:
Router_B>show version
Cisco Internetwork Operating System Software
IOS (tm) RSP Software (RSP-JSV-M), Version 12.1(16), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Tue 09-Jul-02 07:36 by kellythw
Image text-base: 0x60010958, data-base: 0x614C4000
ROM: System Bootstrap, Version 11.1(8)CA1, EARLY DEPLOYMENT RELEASE
SOFTWARE (fc1)
BOOTLDR: RSP Software (RSP-BOOT-M), Version 12.1(16), RELEASE SOFTWARE (fc1)
Router_B uptime is 35 weeks, 1 day, 6 hours, 18 minutes
System returned to ROM by reload at 00:12:02 EST Tue Oct 8 2002
System restarted at 23:52:37 EST Mon Oct 7 2002
System image file is "slot0:rsp-jsv-mz.121-16.bin"
cisco RSP4 (R5000) processor with 131072K/2072K bytes of memory.
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
Last reset from power-on
G.703/E1 software, Version 1.0.
G.703/JT2 software, Version 1.0.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
Bridging software.
TN3270 Emulation software.
Chassis Interface.
5 VIP2 controllers (2 FastEthernet)(6 HSSI)(1 ATM).
1 VIP2 R5K controller (8 Serial).
2 FastEthernet/IEEE 802.3 interface(s)
8 Serial network interface(s)
6 HSSI network interface(s)
1 ATM network interface(s)
123K bytes of non-volatile configuration memory.
20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
No slave installed in slot 7.
Configuration register is 0x102
Router_B>
As you can see, the output contains a great deal of information. We’ll move through it
field by field.
The first field indicates the revision of software that is actively running on the router. In this
case, it is Cisco IOS 12.1(16).
The next field is the bootstrap version, which indicates the Cisco IOS that is used in case
the IOS isn’t found. This IOS is stored on the PROMs or flash memory of the router. The
router boots by using 11.1(8)CA. This allows the router to actually boot so that you can fix
software problems.
Current router status information is located in the field following the bootstrap information.
This output tells you the length of time the router has been up and the last date it was reloaded.
If an error caused the router to reload, the error message is included in this field. Finally, the file
that was used while booting is listed.
Directly after this section is a line that tells the type of processor used and the amount of
DRAM present. The DRAM is displayed in the format value1/value2 bytes of memory.
value1 is the amount of local memory present; value2 is the amount of I/O memory present.
The total DRAM in the router is the sum of these two values.
The final section describes the route processor and amount of RAM. At the end of the
section, all interface processors are listed, followed by the number of interfaces. The last
three lines indicate the different amounts and types of memory.
show startup-config and running-config
These two commands are used to view the syntax of the router’s configuration. The show
startup-config command displays the contents of the configuration that was written to
NVRAM. The show running-config, show config, and write term commands are all
equivalent. The results of these commands display the configuration that was loaded into
memory and is running on the router.
Although you should already be familiar with these two commands, here is a very good troubleshooting
tip: Compare the two configurations when working on network problems. It is always
possible that configuration changes were made to the running configuration but not copied to the
startup configuration. There may be extra or missing commands in the configuration versions. You
may be able to solve the problem of missing commands in the running configuration quickly by
copying the startup-config to the running-config.
These commands provide you with global, protocol, and interface information. You can
analyze them for proper configuration and then make changes, if needed. Many problems
can be isolated by viewing the configuration. What usually happens is that you will see something
that wasn’t there before, see something that shouldn’t be there, or notice that something
is missing that needs to be there. For this technique to work, you must be familiar with the
router and its configuration. If backups are made of the configurations, you can compare
them to the running-config to look for differences.
show buffers
The buffers come configured with default settings. They can be modified, if necessary, but if you
do this it’s usually a good idea to have a Cisco TAC engineer look at the memory allocation and
suggest the new buffer settings. Following is an example of the buffer settings:
Router_B>show buffers
Buffer elements:
999 in free list (500 max allowed)
2594679003 hits, 0 misses, 500 created
Public buffer pools:
Small buffers, 104 bytes (total 480, permanent 480):
455 in free list (20 min, 1000 max allowed)
243410950 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Middle buffers, 600 bytes (total 360, permanent 360):
357 in free list (20 min, 800 max allowed)
374760214 hits, 8298 misses, 5776 trims, 5776 created
2275 failures (0 no memory)
Big buffers, 1524 bytes (total 360, permanent 360):
358 in free list (10 min, 1200 max allowed)
274949626 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 40, permanent 40):
40 in free list (5 min, 1200 max allowed)
12900991 hits, 173 misses, 519 trims, 519 created
0 failures (0 no memory)
Large buffers, 5024 bytes (total 40, permanent 40):
40 in free list (3 min, 120 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Huge buffers, 18024 bytes (total 4, permanent 0):
3 in free list (3 min, 52 max allowed)
2459 hits, 2 misses, 8716 trims, 8720 created
0 failures (0 no memory)
Interface buffer pools:
IPC buffers, 4096 bytes (total 312, permanent 312):
312 in free list (104 min, 1040 max allowed)
696006349 hits, 0 fallbacks, 0 trims, 0 created
0 failures (0 no memory)
Header pools:
You can view six buffer distinctions in this output: small, middle, big, very big, large, and
huge. Each division is allocated a particular amount of buffer space. These allocations are
determined at router bootup and vary by interface type. The show buffers output details
the buffer name and size, with the buffer size following immediately after its name. The
(total 120, permanent 120) for the small pool specifies that there are a total of 120
spaces allocated to the small pool. The permanent means that the 120 buffer spaces are permanently
assigned to the small buffer pool. When a buffer’s space is permanent, it cannot
be deallocated and given back to the system memory for other uses.
In the next field, you can see the number of free buffer spaces that are open to accepting a packet.
Each pool maintains a minimum and maximum threshold, which the pool uses to decide whether
more buffer space needs to be allocated to it. This is seen in the min and max allowed indicators.
The last two lines of information given for each pool describe the activity happening there.
This information, which includes all hits, misses, trims, created spaces, and failures, is described
in the following list:
Hits The number of times the pool was used successfully.
Misses The number of times a packet tried to find a space within a pool but found no available
spaces. In this case, the packet is not discarded; rather, a space is created for it.
Trims The number of spaces removed from the pool because the amount exceeded the number
of allowed buffer spaces. This value is only meaningful on dynamically allocated buffer pools;
static pools cannot be trimmed.
Created The number of spaces created to accommodate requests for space when there wasn’t
enough at the time the request was made or if there were fewer than the min of a certain type
of buffer available. Once the space is no longer needed, it will be trimmed.
Failures The number of times a buffer pool tried unsuccessfully to create space. When a failure
occurs, the requesting packet is dropped.
The last field is the no memory field, which records the number of failures that occurred due
to the lack of sufficient system memory required to create additional buffer space.
If you observe a significant increase in the number of misses while monitoring buffers with the
show buffers command, the pool can be tuned by assigning different values to the max-free, minfree,
and permanent parameters. Increasing the values for these parameters overrides the system
defaults—instead of having to create additional spaces on demand within a pool, the spaces can be
statically allocated and assigned. This helps you avoid racking up missed and failed packet statuses.
You can adjust these parameters with the following command:
buffers {small | middle | big | verybig | large | huge | type number}
{permanent | max-free | min-free | initial} number
The type represents interface type, and number is the number to be assigned to the specified
parameter.
Table 37.3 depicts the sizes of the buffer space within a pool. When a packet needs to be stored
in a buffer, it requests space from the pool in proportion to its size requirement. For example, a
full-size Ethernet packet at a 1500MTU requires one buffer space from the big buffer pool.
show stack
The show stack command is not very useful to you, but it is invaluable information for the
Cisco TAC. An example of output from the command appears in this section. As you can see,
it won’t make a lot of sense to the user. The information is sent to Cisco, and Cisco runs it
through a stack decode that provides the information relevant to system problems.
Stacks are used to provide information on the router’s processes and processor utilization.
The output displayed is from a healthy router. If the router were to crash, the latest
stack information is saved so it can be captured once the router comes back up. The data contains information regarding the reason for the reload and any errors that are attributed
to the crash.
Router_A#show stack
Minimum process stacks:
Free/Size Name
10288/12000 Init
5196/6000 Router Init
9672/12000 Virtual Exec
Interrupt level stacks:
Level Called Unused/Size Name
1 49917 8200/9000 Network Interrupt
2 2 8372/9000 Network Status Interrupt
3 0 9000/9000 OIR interrupt
4 0 9000/9000 PCMCIA Interrupt
5 2561 8652/9000 Console Uart
6 0 9000/9000 Error Interrupt
7 27140712 8608/9000 NMI Interrupt Handler
Router_A#
show tech-support
The show tech-support command is a compilation of several show commands (version,
running-config, controllers, stacks, interfaces, diagbus, buffers, process
memory, process cpu, context, boot, flash bootflash, ip traffic, and controllers
cbus). It should be noted that, although these are the typical commands issued by show
tech-support, the commands can vary depending on hardware and software levels. You
can get most of the information you need by issuing the show tech-support command,
instead of issuing all of the commands separately.
The show tech-support command does not allow you to scroll through its output on the router
because of the enormous amount of information that is displayed. To capture the output, you need
a terminal with a large line-buffer setting, or you can log the output directly to a terminal.
show access-lists
The show access-lists command is useful to view the access list configuration without sorting
through the running or start-up configuration. In addition to displaying the line entries of the
access list, the command uses the access list number to define what type of access list is being displayed.
The output from the show access-lists command follows:
Router_B#show access-lists
Extended IP access-list 105
permit ip 172.16.0.0 0.0.255.255 any (97160 matches)
permit ip 10.0.0.0 0.255.255.255 any
deny ip any any (102463 matches)
Novell access-list 801
permit 606E3000 (3245 matches)
permit 506E3074
permit B06F2E00 (655 matches)
permit D06F2EFE
permit 717B012C
permit E06F2E67
permit F9BE0714 (5038 matches)
permit A054AB00
permit 617B07C4
permit 017B1900
This information gives you a summary of each access list on the router. The access list type
is defined, and the number assigned to it is shown. Each line of the list is displayed individually.
The list also specifies matchups between networks and wildcard masks.
show memory
The show memory command is helpful for diagnosing memory problems such as allocation failures,
low amounts of free memory, and so on. In the following output, you can see that the first
field has the memory divided between processor memory and fast memory. The fields are selfexplanatory;
they describe the total, used, and free amounts of memory. As you will see in the
“Process Commands” section later, the output here is very similar to the show processes
memory command.
Router_C>show memory
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
Proc 60DC38E0 52676384 34896328 17780056 15823612 14764584
Fast 60DA38E0 131072 128344 2728 27282684
Processor memory
Address Bytes Prev. Next Ref PrevF NextF Alloc PC What
60DC38E0 1056 0 60DC3D2C 1 601342A4 List Elements
60DC3D2C 2656 60DC38E0 60DC47B8 1 601342A4 List Headers
60DC47B8 9000 60DC3D2C 60DC6B0C 1 60135498 Interrupt Stack
60DC6B0C 9000 60DC47B8 60DC8E60 1 60135498 Interrupt Stack
Interface Commands
Interface commands deal with detailed interface settings and configurations. Because each
type of interface uses particular protocols and technologies, the show interface command
is capable of displaying all data related to a specified interface. Table 37.4 lists the useful
interface-related show commands. Here in this section, we will focus on the show interface
and show ip interface commands.
show queueing and show queue
To verify the configuration and operation of the queuing system, you can issue the following
two commands:
show queueing [fair | priority | custom]
show queue [interface-type interface-number]
Following are the results from these commands on Router C. Because weighted fair queuing
is the only type of queuing that has been enabled on this router, it wasn’t necessary to issue the
optional command options fair, custom, or priority.
Router_C#show queueing
Current fair queue configuration:
Interface Discard Dynamic Reserved
threshold queue count queue count
Serial0 96 256 0
Serial1 64 256 0
Current priority queue configuration:
Current custom queue configuration:
Current RED queue configuration:
Router_C#
This command output shows that weighted fair queuing is enabled on both serial interfaces,
and that the discard threshold for Serial 0 was changed from 64 to 96. There’s a maximum
of 256 dynamic queues for both interfaces—the default value. The lines following the
interface information are empty because their corresponding queuing algorithms aren’t configured
yet.
The next command, show queue, displays more detailed information pertaining to the
specified interface:
Router_C#show queue serial0
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
TABLE 3 7 . 4 show interface Commands
show interface Command Information Produced
queuing/queue Queuing configuration and contents
interface interface-type interface-number Interface status and configuration
ip interface Information specifically related to IP
interfaces
Troubleshooting Commands 1093
Output queue: 0/1000/96/0 (size/max total/threshold/ drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Router_C#
show interface
As mentioned, the show interface command has many derivatives. Table 37.5 lists many of
the options that are available with this command.
It is important to recognize that the interface processors listed are there
because they are present on the router. For example, you won’t see a Token
Ring interface listed unless there is a Token Ring interface on the router.
Now look at sample outputs from an Ethernet and a serial interface. After each sample, we
will go through a detailed explanation:
Router_A#show interface Ethernet 5/4
Ethernet5/4 is up, line protocol is up
Hardware is cxBus Ethernet, address is 009a.822e.51b6 (bia 90.323f.acdb)
Description: Connection to Router_B
Internet address is 172.16.1.1/24
TABLE 3 7 . 5 show interface Command Options
show interface Command Option Information Produced
atm interface-type ATM interface
ethernet interface-type IEEE 802.3
serial interface-type Serial
hssi interface-type High-Speed Serial Interface (HSSI)
accounting Interface accounting
fair-queue Interface Weighted Fair Queueing (WFQ) info
rate-limit Interface rate-limit info
mac-accounting Interface MAC accounting info
1094 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/
255, load 33/255
Encapsulation ARPA, loopback not set, keepalive set (10
sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 101553 drops; input queue 0/75, 1327
drops
5 minute input rate 247000 bits/sec, 196 packets/sec
5 minute output rate 1329000 bits/sec, 333 packets/sec
421895792 packets input, 2524672293 bytes, 1 no
buffer
Received 453382 broadcasts, 0 runts, 0 giants
6 input errors, 1 CRC, 5 frame, 0 overrun, 494
ignored, 0 abort
0 input packets with dribble condition detected
618578101 packets output, 977287695 bytes, 0
underruns
0 output errors, 30979588 collisions, 1 interface
resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffers copied, 0 interrupts, 0 failures
Router_A#
This output starts with the most pertinent information—the physical interface and line protocol
status. In this case, both are up. There is much argument as to what constitutes an “up”
interface. It is very simple—the controller sends a signal that there are electrons flowing through
the physical interface. So, just doing a no shut on an interface brings it into an “up” status,
even if nothing is plugged into the interface. Line protocol is up means that the interface
is able to send itself a frame and receive it back.
The next fields contain the layer 2 MAC address, the interface description, and the layer 3
IP address. Below the interface address information, you’ll find the line settings for the interface;
MTU, bandwidth, delay, reliability, and load are listed. These values are used to calculate
a distance-vector protocol route metric.
Default Ethernet encapsulation for Cisco is ARPA. You can see that this is true and that the
keep-alive is the default at 10 seconds. This line is very important when troubleshooting Ethernet
problems. If the encapsulation type is not compatible with other machines on the network,
you will have communication problems. In order to better demonstrate this, let’s examine the
example given in the following paragraph.
Troubleshooting Commands 1095
When the router broadcasts from an interface, it uses the encapsulation that is configured.
Look at Figure 37.1. In this case, an ARPA frame (#1) is sent. If the hosts on the network do not
understand ARPA, they do not respond to the broadcast. On the other hand, if a host broadcast
uses a SNAP frame (#2), the router is designed to understand any incoming frame encapsulation
and can respond to the broadcast. Another bit of useful information that the router adds to the
ARP table is the encapsulation type of that host. Then, the next time that the router wants to speak
with the given host, it uses the documented frame type instead of the type configured on the interface.
Here’s a look at the ARP table (notice that the Type field is SNAP):
Router_C>show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.16.1.1 - 0010.296a.a820 ARPA Ethernet5/0
Internet 172.16.1.22 62 0010.29d1.68a0 SNAP Ethernet5/0
Router_C>
Continuing on with the output from the show interface command, you can see a great deal
of statistical information. The counters for the interface have not been cleared since the router
booted. Queuing type for the interface is first in, first out (FIFO). You should be familiar with
the next few fields, because the input and output queue were previously discussed in the sections
describing the show queueing and show queue commands. Here, you have statistical information
that displays the number of drops. The interface traffic statistics follow.
FIGURE 3 7 . 1 Ethernet frame encapsulation compatibility
Workstation 172.16.1.2
Workstation
172.16.1.1
Ethernet
ARPA
frame
(#1)
SNAP
encapsulation
(#2)
1096 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
Statistical information includes the number of packets that travel across the interface and
the bandwidth utilization. The following fields are dedicated to Ethernet troubleshooting.
The cyclic redundancy check field counts the number of frames that were received that
do not pass the CRC test. Next are frame errors and overruns. Overruns occur when the
receiver on the interface receives frames faster than it can move them to the hardware buffer
on the interface. The ignore signal is sent if there are buffer problems.
Output errors consist of underruns and collisions. The other fields are counters for the
physical interface: resets, lost carrier, and no carrier. These are followed by more
buffer error counters.
Now let’s review the output from a serial interface:
Router_D#sho int s1/0
Serial1/0 is up, line protocol is up
Hardware is cxBus Serial
Description: Connection to frame-relay cloud
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/
255, load 1/255
Encapsulation FRAME-RELAY, loopback not set, keepalive
set (10 sec)
LMI enq sent 195167, LMI stat recvd 195165, LMI upd
recvd 10, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 0/0,
interface broadcasts 908350
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/4 (size/max/drops); Total output
drops: 22795
Queueing strategy: weighted fair
Output queue: 0/64/22795 (size/threshold/drops)
Conversations 0/59 (active/max active)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 7000 bits/sec, 9 packets/sec
5 minute output rate 9000 bits/sec, 8 packets/sec
55695166 packets input, 3680326698 bytes, 1 no buffer
Received 0 broadcasts, 0 runts, 0 giants
1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored,
1 abort
56424159 packets output, 569801054 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
8656902 output buffers copied, 0 interrupts, 0
Troubleshooting Commands 1097
failures
3 carrier transitions
RTS up, CTS up, DTR up, DCD up, DSR up
Router_D#
This output has a lot of Frame Relay information that we will discuss in Chapter 39, “Troubleshooting
Serial Line and Frame Relay Connectivity.” For now, we’ll just review the fields of information
that are available by using this command. You can see that the first line is the interface status
line. The metric values are also listed. Following the Frame Relay information, you see the interface
traffic statistics. At the bottom of the output are the buffer error fields, as well as the physical interface
counters. A carrier transition is counted any time the carrier status change occurs. (We will
explore this output in Chapter 39.)
show ip interface
The show ip interface command provides information specific to the TCP/IP configuration
of the specified interface. Information regarding the interface status, IP address, subnet mask,
broadcast address, and applied access lists is all contained in the show ip interface command
output. In addition, the command also provides information on proxy ARP, which will be
explained in further detail later in this chapter; helper addresses, which are used for DHCP configurations;
the status of Network Address Translation (NAT); and many other items. The
amount of output from the show ip interface command for a particular interface is second
only to that of the show interface command. Here is an example:
Router_B#show ip interface serial 0
Serial0 is up, line protocol is up
Internet address is 172.16.30.6/30
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is enabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is enabled
IP multicast fast switching is enabled
1098 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
Probe proxy name replies are disabled
Gateway Discovery is disabled
Policy routing is disabled
Network address translation is disabled
Router_B#
Process Commands
Process commands deal directly with the processes running on the router. If the standard show
processes command is issued, you get a result similar to a ps –ef executed on a Unix box. The
output details each process, including process ID number (PID), time running, and stack information.
This output is too general to be used effectively while troubleshooting, but there are
two very important process command options that can be executed to refine this output.
The two options available with the show processes command are cpu and memory, as
described in Table 37.6. Each of these options refines the processes’ output and makes it more
useful and user-friendly.
show processes cpu
The output from this command, shown later in this section, relates the router’s processes and CPU
utilization. The first line of the output displays the router’s CPU utilization over three periods. In
addition, you will notice that the CPU utilization for the five-second interval has two percentages:
15 percent and 6 percent. The first number is the average CPU utilization for all processes on
the router over the last five seconds. The second number is the percentage of the CPU spent on
interrupt-driven processes. In general, interrupt-driven tasks are core to the router’s ability to
route packets. Examples of these tasks include fast- or process-switched packets, input from the
console or auxiliary ports, and corrections of memory-alignment issues. Items such as maintaining
VTY sessions and responding to SNMP queries are non-interrupt-driven processes that would
only show up in the first percentage.
Underneath the CPU utilization line, you can see the processes running on the router. Starting
from the left, you can see the PID, followed by the runtime and other data. The three columns that
TABLE 3 7 . 6 show processes Commands
show processes Command Information Produced
cpu Amount of CPU time being spent on each process
memory Memory statistics
Troubleshooting Commands 1099
deal with CPU utilization detail the percentage of CPU cycles used by the specified process. The
process description is found in the far-right column:
Router_C>show processes cpu
CPU utilization for five seconds: 15%/6%; one minute: 7%; five minutes: 7%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 76 1564143 0 0.00% 0.00% 0.00% 0 Load Meter
2 0 1 0 0.00% 0.00% 0.00% 0 LAPF Input
3 3638844 872510 4170 0.00% 0.04% 0.00% 0 Check heaps
4 4 28 142 0.00% 0.00% 0.00% 0 Pool Manager
5 0 2 0 0.00% 0.00% 0.00% 0 Timers
. . . [output removed] . . .
When the overall CPU utilization gets high, you can identify which process is using the most
CPU cycles, and then focus your attention on that process. For example, if the IP-EIGRP CPU
utilization runs high, you can determine that there is a problem within EIGRP, perhaps a routing
loop or some other instability.
show processes memory
The second helpful option for the show processes command is memory, which is used to associate
memory utilization with the router’s processes. Here is a sample output:
Router_D>show processes memory
Total: 52503792, Used: 45141524, Free: 7362268
PID TTY Allocated Freed Holding Getbufs Retbufs Process
0 0 54400 304 8898364 0 0 *Init*
0 0 632 3906083084 632 0 0 *Sched*
0 0 700723436 729437084 472484 1091352 0 *Dead*
1 0 96 0 6876 0 0 SSCOP Input
2 0 0 0 6780 0 0 Check heaps
3 0 17262036 152680 6916 12351248 260336 Pool Manager
. . . [output removed] . . .
The first line details the total, used, and free amounts of system memory. Following that, you
see the PID, allocated, freed, and holding memory. This means that the processor has allocated
a given amount of memory to the process; if the process does not need all of that memory, it
frees some of it and retains the rest.
TCP/IP Protocol Commands
We will discuss the major TCP/IP protocol commands in this section. In addition to the
TCP/IP-related commands listed here, other protocol-related commands are covered later in
this book. These cover protocols including HDLC, Frame Relay, X.25, and ISDN.
1100 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
Table 37.7 lists the frequently used IP options for the show command.
show ip access-list
This command provides information regarding a specified access list, or all access lists that
fall within the 1–199 range. When various access lists are configured on the router, the show
ip access-list command shows named IP access lists only. (Named access lists are explained
later in this chapter.) From the following sample output, you can see that it lists both standard
and extended lists:
Standard IP access list 5
permit 172.16.14.2
permit 172.16.91.140
permit 172.16.10.51
permit 172.16.1.7
permit 172.16.155.0, wildcard bits 0.0.0.255
Extended IP access list 152
deny ip any 172.16.91.0 0.0.0.63 log (268436 matches)
deny ip any host 172.16.91.66 log (81058 matches)
permit tcp any any established (8809 matches)
permit ip host 172.16.2.55 any
permit ip host 172.60.22.10 any (2194226 matches)
permit ip host 172.140.64.8 any (7930443 matches)
permit ip 172.16.10.0 0.0.255.255 any (9076 matches)
TABLE 3 7 . 7 Frequently Used show IP Command Options
show ip Command Option Information Produced
access-lists IP access lists
accounting The active IP accounting database
arp Information regarding the IP ARP entries in the ARP cache
interface IP interface status and configuration
protocols Information regarding the IP routing protocols running on
a router
route IP routing table
traffic IP protocol statistics
Troubleshooting Commands 1101
show ip arp
This command provides information contained in the router’s ARP cache, including the IP
address, MAC address, encapsulation type, and interface from which the MAC was learned.
Here is a sample:
Router_C#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.16.60.1 - 0010.7bd9.2881 ARPA Ethernet0/1
Internet 172.16.50.2 - 0010.7bd9.2880 ARPA Ethernet0/0
Internet 172.16.50.1 6 0000.0c09.99cc ARPA Ethernet0/0
Router_C#
show ip protocols
This command provides information about the IP routing protocols that run on the router. The
sample output shown here includes only EIGRP information, because that is all that is being run
on the router. As you can see, global filters are not applied. Metric values are displayed for each
individual routing protocol. Route redistribution information is also provided:
Router_B#show ip protocols
Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not
set
Incoming update filter list for all interfaces is not
set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
Automatic network summarization is not in effect
Routing for Networks:
172.16.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170
Router_B#
show ip route
This command returns information stored in the IP route table. The command can be issued as
a general command, and all IP routes and corresponding information will be displayed. Additionally,
you can specify a given network, and the command will return information regarding
that network only.
1102 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
This section contains two examples of the show ip route command. Notice that the two
outputs are different. The general command provides summary information for every IP route
in the route table. However, when a network is specified, the results are much more detailed.
Items such as the exact routing protocol responsible for learning the route, the source interface,
and the next-hop router’s IP address are all included:
Router_A>show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF
inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2,
E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, *
- candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.50.0/24 [90/2195456] via 172.16.30.6, 00:00:19, Serial1
C 172.16.30.4/30 is directly connected, Serial1
Router_A>
Router_A>show ip route 172.16.50.0
Routing entry for 172.16.50.0/24
Known via "eigrp 100", distance 90, metric 2195456, type internal
Redistributing via eigrp 100
Last update from 172.16.30.6 on Serial1, 00:02:03 ago
Routing Descriptor Blocks:
* 172.16.30.6, from 172.16.30.6, 00:02:03 ago, via
Serial1
Route metric is 2195456, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth
is 1544 Kbit
Reliability 128/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Router_A>
Troubleshooting Commands 1103
show ip traffic
This command returns information pertaining to IP traffic statistics. When the command is
issued, the output is organized according to the IP protocol. Here is a sample:
Router_B#show ip traffic
IP statistics:
Rcvd: 400 total, 400 local destination
0 format errors, 0 checksum errors,
0 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options,
0 with options
Opts: 0 end, 0 nop, 0 basic security,
0 loose source route
0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 0 alert,
0 cipso
0 other
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
0 fragmented, 0 couldn't fragment
Bcast: 0 received, 0 sent
Mcast: 398 received, 401 sent
Sent: 404 generated, 0 forwarded
0 encapsulation failed, 0 no route
ICMP statistics:
Rcvd: 0 format errors, 0 checksum errors, 0 redirects, 0
unreachable
0 echo, 0 echo reply, 0 mask requests, 0 mask
replies, 0 quench
0 parameter, 0 timestamp, 0 info request, 0 other
0 irdp solicitations, 0 irdp advertisements
Sent: 0 redirects, 0 unreachable, 0 echo, 0 echo reply
0 mask requests, 0 mask replies, 0 quench, 0
timestamp
0 info reply, 0 time exceeded, 0 parameter problem
0 irdp solicitations, 0 irdp advertisements
UDP statistics:
Rcvd: 0 total, 0 checksum errors, 0 no port
Sent: 0 total, 0 forwarded broadcasts
1104 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
TCP statistics:
Rcvd: 0 total, 0 checksum errors, 0 no port
Sent: 0 total
Probe statistics:
Rcvd: 0 address requests, 0 address replies
0 proxy name requests, 0 where-is requests, 0
other
Sent: 0 address requests, 0 address replies (0 proxy)
0 proxy name replies, 0 where-is replies
EGP statistics:
Rcvd: 0 total, 0 format errors, 0 checksum errors, 0 no
listener
Sent: 0 total
IGRP statistics:
Rcvd: 0 total, 0 checksum errors
Sent: 0 total
OSPF statistics:
Rcvd: 0 total, 0 checksum errors
0 Hello, 0 database desc, 0 link state req
0 link state updates, 0 link state acks
Sent: 0 total
IP-IGRP2 statistics:
Rcvd: 402 total
Sent: 406 total
PIMv2 statistics: Sent/Received
Total: 0/0, 0 checksum errors, 0 format errors
Registers: 0/0, Register Stops: 0/0
IGMP statistics: Sent/Received
Total: 0/0, Format errors: 0/0, Checksum errors: 0/0
Host Queries: 0/0, Host Reports: 0/0, Host Leaves: 00
DVMRP: 0/0, PIM: 0/0
Troubleshooting Commands 1105
ARP statistics:
Rcvd: 0 requests, 0 replies, 0 reverse, 0 other
Sent: 1 requests, 5 replies (0 proxy), 0 reverse
Router_B#
debug Commands
The debug commands and options are very powerful tools. The messages produced by the
debugging process give detailed information and provide insight into what is happening on a
very low level.
This power does not come free of charge. In most cases, debugging requires every packet to
be process-switched, meaning that the route processor has to look at every packet entering the
router in order for valid information to be obtained. In addition, the router must run and manage
many other processes. Debugging can cause a great deal of additional overhead on a router.
Therefore, it is important to use the tool with discretion. Use it to provide additional information
on an existing problem, not to monitor a router. As a rule of thumb, debug commands
should not be run on a router that already has a CPU utilization greater than 50 percent.
Because most problems are reported while a network is in production, the last thing you
want to do is crash a router or cause unnecessary overhead by using the debug tool. By focusing
the application of the debug command by using various command options and access lists, you
can effectively troubleshoot problems without causing additional ones.
Always remember to turn the debugging function off after you obtain the
necessary data. If left on, it can cause another network problem.
There are two tricks to successfully using the debug tool. First, make sure that your router
is configured to apply timestamps to all messages. This is done with the following commands:
Router_A(config)#service timestamps debug datetime msec localtime
Router_A(config)#service timestamps log datetime msec localtime
Next, make sure that you see these messages. By default, error and debug messages are sent
only to the console. If you are telnetted to the router, you will not see the debug or log messages
unless you issue the following command:
Router_A#terminal monitor
You can turn the messages off again by issuing the no form of the command:
Router_A#terminal no monitor
If the output messages from the debug become excessive, it becomes difficult, if not impossible,
to enter commands. Should this happen, there are two commands that you can issue to stop the
messages. The first one was already mentioned (terminal no monitor, or term no mon for
1106 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
short). In this case, you type, but you don’t see anything echo back. It can get confusing. Remember
that the text messages that echo to the screen are not entered on the command line of the
router. You can safely type term no mon and press Enter, even with hundreds of messages scrolling
past you on the screen. The router eventually recognizes and processes the command. That
stops the messages from scrolling down the screen, but it does not stop the processor from looking
at every packet.
To stop the debug process altogether, the easiest way is to type the shorthand form of
undebug all, like this:
Router_A#un all
It is short and sweet, yet effective. It works especially well when the router seems to be having
a runaway. This command stops all debug processes and all associated messages. It can be
entered safely while messages are scrolling wildly down the screen. It may take the router a few
CPU cycles to accept the command and actually stop the debug process, so don’t panic.
As an alternative, you can also have the un all command ready to go if you allow multiple
telnet sessions to the same router. In this instance, you would telnet to the router twice. In one
of the telnet sessions, set up the terminal monitor command so that you would receive the
debug output. In the other window, type in the undebug all command but do not press Enter.
Then return to your first telnet session and execute the debug command you need. If the output
is overwhelming, go back to your other telnet session and hit Enter. As was the case before, it
may take several seconds for the router to process the command and the messages to stop
appearing on the screen.
Limiting Debug Output
Because of the potential impact to the router, you should take precautions whenever you use
debug commands. Be as specific as possible when entering the debug commands so that you look
only at information relevant to your issue. In addition to the commands themselves, you can apply
access lists to the debug commands to further limit the information you are examining.
For example, if you wanted to see ping (ICMP) packets going between stations with IP
addresses of 10.20.20.20 and 10.30.30.30, you could create an access list like this:
access-list 100 permit icmp host 10.20.20.20 host 10.30.30.30
Then apply this access list to the debug command as shown here:
Router_C#debug ip packet detail 100
IP packet debugging is on (detailed) for access list 100
Router_C#
IP: s=10.20.20.20 (Serial0), d=10.30.30.30 (Serial1), g=10.5.30.30, len
100, forward ICMP type=8, code=0
In this manner, only ICMP packets going from 10.20.20.20 to 10.30.30.30 are shown in the
debug output, rather than all of the packets going through the router.
Troubleshooting Commands 1107
As with the show commands, there are global-, interface-, and protocol-related debugging
options. Because these tools and commands are used and discussed often in upcoming chapters,
they are only summarized here according to usage.
troubleshooting skills and tools. Here in this chapter, we will
explain
show
and
debug
commands. In addition, generic commands
such as
ping
and
traceroute
will be applied to network problems. Problem isolation
techniques that are used in troubleshooting LANs will be outlined and implemented. Finally,
the use and kinds of access lists will be examined.
The next chapter, Chapter 38, “TCP/IP Routing Protocol Troubleshooting,” focuses on the
IP routing protocols, including RIP, IGRP, EIGRP, OSPF, and BGP. In addition to an explanation
of these routing protocols, the
show
and
debug
commands used specifically for them will
be examined. The final part of Chapter 38 explores redistribution issues and solutions.
Many of the
show
and
debug
commands are not protocol-specific. Though these commands do
not deal exclusively with the TCP/IP protocol, they are used in troubleshooting many TCP/IP problems
and therefore are included in this chapter for completeness. As is the case with the
show
and
debug
commands, logging and core dumps are not limited to the TCP/IP but can be used to contribute
to troubleshooting TCP/IP problems and are also included in this chapter for completeness.
In addition to all the detailed problem-solving techniques presented in these two chapters,
quick reference summary charts are located at the end of Chapter 38. These tables help to
quickly associate a cause to many TCP/IP symptoms.
Troubleshooting Commands
We will cover several troubleshooting tools in this chapter, each of which is part of the Cisco IOS.
There are many
show
commands that are supported by the router. In addition to
show
commands,
a tool called debug is used to see specific information regarding packet transfer and exchange.
Part of effectively using these tools is using them without adversely affecting the router and its
many processes. Here you will learn the specifics of several troubleshooting commands, along with
the information needed in order to use them without causing additional problems on your network.
We start with non-intrusive, Cisco-specific
show
commands. After discussing the
show
commands, we move on to the debug tool. To finalize this section, we discuss some non-
Cisco-specific troubleshooting tools:
ping
and
traceroute
.
show
Commands
A large number of
show
commands are supported by Cisco IOS. Explaining them all is beyond the
scope of this book. The most effective and useful
show
commands are described in the following
sections, and Table 37.1 lists the ones most frequently used. To get an idea of all of the
show
commands,
execute the
show ?
command from the router prompt.
show version
This command is used to display the system hardware and software versions. It also provides
information about how long the router was running and the reason it was last restarted. Review
the following output of the show version command:
Router_B>show version
Cisco Internetwork Operating System Software
IOS (tm) RSP Software (RSP-JSV-M), Version 12.1(16), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Tue 09-Jul-02 07:36 by kellythw
Image text-base: 0x60010958, data-base: 0x614C4000
ROM: System Bootstrap, Version 11.1(8)CA1, EARLY DEPLOYMENT RELEASE
SOFTWARE (fc1)
BOOTLDR: RSP Software (RSP-BOOT-M), Version 12.1(16), RELEASE SOFTWARE (fc1)
Router_B uptime is 35 weeks, 1 day, 6 hours, 18 minutes
System returned to ROM by reload at 00:12:02 EST Tue Oct 8 2002
System restarted at 23:52:37 EST Mon Oct 7 2002
System image file is "slot0:rsp-jsv-mz.121-16.bin"
cisco RSP4 (R5000) processor with 131072K/2072K bytes of memory.
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
Last reset from power-on
G.703/E1 software, Version 1.0.
G.703/JT2 software, Version 1.0.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
Bridging software.
TN3270 Emulation software.
Chassis Interface.
5 VIP2 controllers (2 FastEthernet)(6 HSSI)(1 ATM).
1 VIP2 R5K controller (8 Serial).
2 FastEthernet/IEEE 802.3 interface(s)
8 Serial network interface(s)
6 HSSI network interface(s)
1 ATM network interface(s)
123K bytes of non-volatile configuration memory.
20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
No slave installed in slot 7.
Configuration register is 0x102
Router_B>
As you can see, the output contains a great deal of information. We’ll move through it
field by field.
The first field indicates the revision of software that is actively running on the router. In this
case, it is Cisco IOS 12.1(16).
The next field is the bootstrap version, which indicates the Cisco IOS that is used in case
the IOS isn’t found. This IOS is stored on the PROMs or flash memory of the router. The
router boots by using 11.1(8)CA. This allows the router to actually boot so that you can fix
software problems.
Current router status information is located in the field following the bootstrap information.
This output tells you the length of time the router has been up and the last date it was reloaded.
If an error caused the router to reload, the error message is included in this field. Finally, the file
that was used while booting is listed.
Directly after this section is a line that tells the type of processor used and the amount of
DRAM present. The DRAM is displayed in the format value1/value2 bytes of memory.
value1 is the amount of local memory present; value2 is the amount of I/O memory present.
The total DRAM in the router is the sum of these two values.
The final section describes the route processor and amount of RAM. At the end of the
section, all interface processors are listed, followed by the number of interfaces. The last
three lines indicate the different amounts and types of memory.
show startup-config and running-config
These two commands are used to view the syntax of the router’s configuration. The show
startup-config command displays the contents of the configuration that was written to
NVRAM. The show running-config, show config, and write term commands are all
equivalent. The results of these commands display the configuration that was loaded into
memory and is running on the router.
Although you should already be familiar with these two commands, here is a very good troubleshooting
tip: Compare the two configurations when working on network problems. It is always
possible that configuration changes were made to the running configuration but not copied to the
startup configuration. There may be extra or missing commands in the configuration versions. You
may be able to solve the problem of missing commands in the running configuration quickly by
copying the startup-config to the running-config.
These commands provide you with global, protocol, and interface information. You can
analyze them for proper configuration and then make changes, if needed. Many problems
can be isolated by viewing the configuration. What usually happens is that you will see something
that wasn’t there before, see something that shouldn’t be there, or notice that something
is missing that needs to be there. For this technique to work, you must be familiar with the
router and its configuration. If backups are made of the configurations, you can compare
them to the running-config to look for differences.
show buffers
The buffers come configured with default settings. They can be modified, if necessary, but if you
do this it’s usually a good idea to have a Cisco TAC engineer look at the memory allocation and
suggest the new buffer settings. Following is an example of the buffer settings:
Router_B>show buffers
Buffer elements:
999 in free list (500 max allowed)
2594679003 hits, 0 misses, 500 created
Public buffer pools:
Small buffers, 104 bytes (total 480, permanent 480):
455 in free list (20 min, 1000 max allowed)
243410950 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Middle buffers, 600 bytes (total 360, permanent 360):
357 in free list (20 min, 800 max allowed)
374760214 hits, 8298 misses, 5776 trims, 5776 created
2275 failures (0 no memory)
Big buffers, 1524 bytes (total 360, permanent 360):
358 in free list (10 min, 1200 max allowed)
274949626 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 40, permanent 40):
40 in free list (5 min, 1200 max allowed)
12900991 hits, 173 misses, 519 trims, 519 created
0 failures (0 no memory)
Large buffers, 5024 bytes (total 40, permanent 40):
40 in free list (3 min, 120 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Huge buffers, 18024 bytes (total 4, permanent 0):
3 in free list (3 min, 52 max allowed)
2459 hits, 2 misses, 8716 trims, 8720 created
0 failures (0 no memory)
Interface buffer pools:
IPC buffers, 4096 bytes (total 312, permanent 312):
312 in free list (104 min, 1040 max allowed)
696006349 hits, 0 fallbacks, 0 trims, 0 created
0 failures (0 no memory)
Header pools:
You can view six buffer distinctions in this output: small, middle, big, very big, large, and
huge. Each division is allocated a particular amount of buffer space. These allocations are
determined at router bootup and vary by interface type. The show buffers output details
the buffer name and size, with the buffer size following immediately after its name. The
(total 120, permanent 120) for the small pool specifies that there are a total of 120
spaces allocated to the small pool. The permanent means that the 120 buffer spaces are permanently
assigned to the small buffer pool. When a buffer’s space is permanent, it cannot
be deallocated and given back to the system memory for other uses.
In the next field, you can see the number of free buffer spaces that are open to accepting a packet.
Each pool maintains a minimum and maximum threshold, which the pool uses to decide whether
more buffer space needs to be allocated to it. This is seen in the min and max allowed indicators.
The last two lines of information given for each pool describe the activity happening there.
This information, which includes all hits, misses, trims, created spaces, and failures, is described
in the following list:
Hits The number of times the pool was used successfully.
Misses The number of times a packet tried to find a space within a pool but found no available
spaces. In this case, the packet is not discarded; rather, a space is created for it.
Trims The number of spaces removed from the pool because the amount exceeded the number
of allowed buffer spaces. This value is only meaningful on dynamically allocated buffer pools;
static pools cannot be trimmed.
Created The number of spaces created to accommodate requests for space when there wasn’t
enough at the time the request was made or if there were fewer than the min of a certain type
of buffer available. Once the space is no longer needed, it will be trimmed.
Failures The number of times a buffer pool tried unsuccessfully to create space. When a failure
occurs, the requesting packet is dropped.
The last field is the no memory field, which records the number of failures that occurred due
to the lack of sufficient system memory required to create additional buffer space.
If you observe a significant increase in the number of misses while monitoring buffers with the
show buffers command, the pool can be tuned by assigning different values to the max-free, minfree,
and permanent parameters. Increasing the values for these parameters overrides the system
defaults—instead of having to create additional spaces on demand within a pool, the spaces can be
statically allocated and assigned. This helps you avoid racking up missed and failed packet statuses.
You can adjust these parameters with the following command:
buffers {small | middle | big | verybig | large | huge | type number}
{permanent | max-free | min-free | initial} number
The type represents interface type, and number is the number to be assigned to the specified
parameter.
Table 37.3 depicts the sizes of the buffer space within a pool. When a packet needs to be stored
in a buffer, it requests space from the pool in proportion to its size requirement. For example, a
full-size Ethernet packet at a 1500MTU requires one buffer space from the big buffer pool.
show stack
The show stack command is not very useful to you, but it is invaluable information for the
Cisco TAC. An example of output from the command appears in this section. As you can see,
it won’t make a lot of sense to the user. The information is sent to Cisco, and Cisco runs it
through a stack decode that provides the information relevant to system problems.
Stacks are used to provide information on the router’s processes and processor utilization.
The output displayed is from a healthy router. If the router were to crash, the latest
stack information is saved so it can be captured once the router comes back up. The data contains information regarding the reason for the reload and any errors that are attributed
to the crash.
Router_A#show stack
Minimum process stacks:
Free/Size Name
10288/12000 Init
5196/6000 Router Init
9672/12000 Virtual Exec
Interrupt level stacks:
Level Called Unused/Size Name
1 49917 8200/9000 Network Interrupt
2 2 8372/9000 Network Status Interrupt
3 0 9000/9000 OIR interrupt
4 0 9000/9000 PCMCIA Interrupt
5 2561 8652/9000 Console Uart
6 0 9000/9000 Error Interrupt
7 27140712 8608/9000 NMI Interrupt Handler
Router_A#
show tech-support
The show tech-support command is a compilation of several show commands (version,
running-config, controllers, stacks, interfaces, diagbus, buffers, process
memory, process cpu, context, boot, flash bootflash, ip traffic, and controllers
cbus). It should be noted that, although these are the typical commands issued by show
tech-support, the commands can vary depending on hardware and software levels. You
can get most of the information you need by issuing the show tech-support command,
instead of issuing all of the commands separately.
The show tech-support command does not allow you to scroll through its output on the router
because of the enormous amount of information that is displayed. To capture the output, you need
a terminal with a large line-buffer setting, or you can log the output directly to a terminal.
show access-lists
The show access-lists command is useful to view the access list configuration without sorting
through the running or start-up configuration. In addition to displaying the line entries of the
access list, the command uses the access list number to define what type of access list is being displayed.
The output from the show access-lists command follows:
Router_B#show access-lists
Extended IP access-list 105
permit ip 172.16.0.0 0.0.255.255 any (97160 matches)
permit ip 10.0.0.0 0.255.255.255 any
deny ip any any (102463 matches)
Novell access-list 801
permit 606E3000 (3245 matches)
permit 506E3074
permit B06F2E00 (655 matches)
permit D06F2EFE
permit 717B012C
permit E06F2E67
permit F9BE0714 (5038 matches)
permit A054AB00
permit 617B07C4
permit 017B1900
This information gives you a summary of each access list on the router. The access list type
is defined, and the number assigned to it is shown. Each line of the list is displayed individually.
The list also specifies matchups between networks and wildcard masks.
show memory
The show memory command is helpful for diagnosing memory problems such as allocation failures,
low amounts of free memory, and so on. In the following output, you can see that the first
field has the memory divided between processor memory and fast memory. The fields are selfexplanatory;
they describe the total, used, and free amounts of memory. As you will see in the
“Process Commands” section later, the output here is very similar to the show processes
memory command.
Router_C>show memory
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
Proc 60DC38E0 52676384 34896328 17780056 15823612 14764584
Fast 60DA38E0 131072 128344 2728 27282684
Processor memory
Address Bytes Prev. Next Ref PrevF NextF Alloc PC What
60DC38E0 1056 0 60DC3D2C 1 601342A4 List Elements
60DC3D2C 2656 60DC38E0 60DC47B8 1 601342A4 List Headers
60DC47B8 9000 60DC3D2C 60DC6B0C 1 60135498 Interrupt Stack
60DC6B0C 9000 60DC47B8 60DC8E60 1 60135498 Interrupt Stack
Interface Commands
Interface commands deal with detailed interface settings and configurations. Because each
type of interface uses particular protocols and technologies, the show interface command
is capable of displaying all data related to a specified interface. Table 37.4 lists the useful
interface-related show commands. Here in this section, we will focus on the show interface
and show ip interface commands.
show queueing and show queue
To verify the configuration and operation of the queuing system, you can issue the following
two commands:
show queueing [fair | priority | custom]
show queue [interface-type interface-number]
Following are the results from these commands on Router C. Because weighted fair queuing
is the only type of queuing that has been enabled on this router, it wasn’t necessary to issue the
optional command options fair, custom, or priority.
Router_C#show queueing
Current fair queue configuration:
Interface Discard Dynamic Reserved
threshold queue count queue count
Serial0 96 256 0
Serial1 64 256 0
Current priority queue configuration:
Current custom queue configuration:
Current RED queue configuration:
Router_C#
This command output shows that weighted fair queuing is enabled on both serial interfaces,
and that the discard threshold for Serial 0 was changed from 64 to 96. There’s a maximum
of 256 dynamic queues for both interfaces—the default value. The lines following the
interface information are empty because their corresponding queuing algorithms aren’t configured
yet.
The next command, show queue, displays more detailed information pertaining to the
specified interface:
Router_C#show queue serial0
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
TABLE 3 7 . 4 show interface Commands
show interface Command Information Produced
queuing/queue Queuing configuration and contents
interface interface-type interface-number Interface status and configuration
ip interface Information specifically related to IP
interfaces
Troubleshooting Commands 1093
Output queue: 0/1000/96/0 (size/max total/threshold/ drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Router_C#
show interface
As mentioned, the show interface command has many derivatives. Table 37.5 lists many of
the options that are available with this command.
It is important to recognize that the interface processors listed are there
because they are present on the router. For example, you won’t see a Token
Ring interface listed unless there is a Token Ring interface on the router.
Now look at sample outputs from an Ethernet and a serial interface. After each sample, we
will go through a detailed explanation:
Router_A#show interface Ethernet 5/4
Ethernet5/4 is up, line protocol is up
Hardware is cxBus Ethernet, address is 009a.822e.51b6 (bia 90.323f.acdb)
Description: Connection to Router_B
Internet address is 172.16.1.1/24
TABLE 3 7 . 5 show interface Command Options
show interface Command Option Information Produced
atm interface-type ATM interface
ethernet interface-type IEEE 802.3
serial interface-type Serial
hssi interface-type High-Speed Serial Interface (HSSI)
accounting Interface accounting
fair-queue Interface Weighted Fair Queueing (WFQ) info
rate-limit Interface rate-limit info
mac-accounting Interface MAC accounting info
1094 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/
255, load 33/255
Encapsulation ARPA, loopback not set, keepalive set (10
sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 101553 drops; input queue 0/75, 1327
drops
5 minute input rate 247000 bits/sec, 196 packets/sec
5 minute output rate 1329000 bits/sec, 333 packets/sec
421895792 packets input, 2524672293 bytes, 1 no
buffer
Received 453382 broadcasts, 0 runts, 0 giants
6 input errors, 1 CRC, 5 frame, 0 overrun, 494
ignored, 0 abort
0 input packets with dribble condition detected
618578101 packets output, 977287695 bytes, 0
underruns
0 output errors, 30979588 collisions, 1 interface
resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffers copied, 0 interrupts, 0 failures
Router_A#
This output starts with the most pertinent information—the physical interface and line protocol
status. In this case, both are up. There is much argument as to what constitutes an “up”
interface. It is very simple—the controller sends a signal that there are electrons flowing through
the physical interface. So, just doing a no shut on an interface brings it into an “up” status,
even if nothing is plugged into the interface. Line protocol is up means that the interface
is able to send itself a frame and receive it back.
The next fields contain the layer 2 MAC address, the interface description, and the layer 3
IP address. Below the interface address information, you’ll find the line settings for the interface;
MTU, bandwidth, delay, reliability, and load are listed. These values are used to calculate
a distance-vector protocol route metric.
Default Ethernet encapsulation for Cisco is ARPA. You can see that this is true and that the
keep-alive is the default at 10 seconds. This line is very important when troubleshooting Ethernet
problems. If the encapsulation type is not compatible with other machines on the network,
you will have communication problems. In order to better demonstrate this, let’s examine the
example given in the following paragraph.
Troubleshooting Commands 1095
When the router broadcasts from an interface, it uses the encapsulation that is configured.
Look at Figure 37.1. In this case, an ARPA frame (#1) is sent. If the hosts on the network do not
understand ARPA, they do not respond to the broadcast. On the other hand, if a host broadcast
uses a SNAP frame (#2), the router is designed to understand any incoming frame encapsulation
and can respond to the broadcast. Another bit of useful information that the router adds to the
ARP table is the encapsulation type of that host. Then, the next time that the router wants to speak
with the given host, it uses the documented frame type instead of the type configured on the interface.
Here’s a look at the ARP table (notice that the Type field is SNAP):
Router_C>show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.16.1.1 - 0010.296a.a820 ARPA Ethernet5/0
Internet 172.16.1.22 62 0010.29d1.68a0 SNAP Ethernet5/0
Router_C>
Continuing on with the output from the show interface command, you can see a great deal
of statistical information. The counters for the interface have not been cleared since the router
booted. Queuing type for the interface is first in, first out (FIFO). You should be familiar with
the next few fields, because the input and output queue were previously discussed in the sections
describing the show queueing and show queue commands. Here, you have statistical information
that displays the number of drops. The interface traffic statistics follow.
FIGURE 3 7 . 1 Ethernet frame encapsulation compatibility
Workstation 172.16.1.2
Workstation
172.16.1.1
Ethernet
ARPA
frame
(#1)
SNAP
encapsulation
(#2)
1096 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
Statistical information includes the number of packets that travel across the interface and
the bandwidth utilization. The following fields are dedicated to Ethernet troubleshooting.
The cyclic redundancy check field counts the number of frames that were received that
do not pass the CRC test. Next are frame errors and overruns. Overruns occur when the
receiver on the interface receives frames faster than it can move them to the hardware buffer
on the interface. The ignore signal is sent if there are buffer problems.
Output errors consist of underruns and collisions. The other fields are counters for the
physical interface: resets, lost carrier, and no carrier. These are followed by more
buffer error counters.
Now let’s review the output from a serial interface:
Router_D#sho int s1/0
Serial1/0 is up, line protocol is up
Hardware is cxBus Serial
Description: Connection to frame-relay cloud
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/
255, load 1/255
Encapsulation FRAME-RELAY, loopback not set, keepalive
set (10 sec)
LMI enq sent 195167, LMI stat recvd 195165, LMI upd
recvd 10, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 0/0,
interface broadcasts 908350
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/4 (size/max/drops); Total output
drops: 22795
Queueing strategy: weighted fair
Output queue: 0/64/22795 (size/threshold/drops)
Conversations 0/59 (active/max active)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 7000 bits/sec, 9 packets/sec
5 minute output rate 9000 bits/sec, 8 packets/sec
55695166 packets input, 3680326698 bytes, 1 no buffer
Received 0 broadcasts, 0 runts, 0 giants
1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored,
1 abort
56424159 packets output, 569801054 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
8656902 output buffers copied, 0 interrupts, 0
Troubleshooting Commands 1097
failures
3 carrier transitions
RTS up, CTS up, DTR up, DCD up, DSR up
Router_D#
This output has a lot of Frame Relay information that we will discuss in Chapter 39, “Troubleshooting
Serial Line and Frame Relay Connectivity.” For now, we’ll just review the fields of information
that are available by using this command. You can see that the first line is the interface status
line. The metric values are also listed. Following the Frame Relay information, you see the interface
traffic statistics. At the bottom of the output are the buffer error fields, as well as the physical interface
counters. A carrier transition is counted any time the carrier status change occurs. (We will
explore this output in Chapter 39.)
show ip interface
The show ip interface command provides information specific to the TCP/IP configuration
of the specified interface. Information regarding the interface status, IP address, subnet mask,
broadcast address, and applied access lists is all contained in the show ip interface command
output. In addition, the command also provides information on proxy ARP, which will be
explained in further detail later in this chapter; helper addresses, which are used for DHCP configurations;
the status of Network Address Translation (NAT); and many other items. The
amount of output from the show ip interface command for a particular interface is second
only to that of the show interface command. Here is an example:
Router_B#show ip interface serial 0
Serial0 is up, line protocol is up
Internet address is 172.16.30.6/30
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is enabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is enabled
IP multicast fast switching is enabled
1098 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
Probe proxy name replies are disabled
Gateway Discovery is disabled
Policy routing is disabled
Network address translation is disabled
Router_B#
Process Commands
Process commands deal directly with the processes running on the router. If the standard show
processes command is issued, you get a result similar to a ps –ef executed on a Unix box. The
output details each process, including process ID number (PID), time running, and stack information.
This output is too general to be used effectively while troubleshooting, but there are
two very important process command options that can be executed to refine this output.
The two options available with the show processes command are cpu and memory, as
described in Table 37.6. Each of these options refines the processes’ output and makes it more
useful and user-friendly.
show processes cpu
The output from this command, shown later in this section, relates the router’s processes and CPU
utilization. The first line of the output displays the router’s CPU utilization over three periods. In
addition, you will notice that the CPU utilization for the five-second interval has two percentages:
15 percent and 6 percent. The first number is the average CPU utilization for all processes on
the router over the last five seconds. The second number is the percentage of the CPU spent on
interrupt-driven processes. In general, interrupt-driven tasks are core to the router’s ability to
route packets. Examples of these tasks include fast- or process-switched packets, input from the
console or auxiliary ports, and corrections of memory-alignment issues. Items such as maintaining
VTY sessions and responding to SNMP queries are non-interrupt-driven processes that would
only show up in the first percentage.
Underneath the CPU utilization line, you can see the processes running on the router. Starting
from the left, you can see the PID, followed by the runtime and other data. The three columns that
TABLE 3 7 . 6 show processes Commands
show processes Command Information Produced
cpu Amount of CPU time being spent on each process
memory Memory statistics
Troubleshooting Commands 1099
deal with CPU utilization detail the percentage of CPU cycles used by the specified process. The
process description is found in the far-right column:
Router_C>show processes cpu
CPU utilization for five seconds: 15%/6%; one minute: 7%; five minutes: 7%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 76 1564143 0 0.00% 0.00% 0.00% 0 Load Meter
2 0 1 0 0.00% 0.00% 0.00% 0 LAPF Input
3 3638844 872510 4170 0.00% 0.04% 0.00% 0 Check heaps
4 4 28 142 0.00% 0.00% 0.00% 0 Pool Manager
5 0 2 0 0.00% 0.00% 0.00% 0 Timers
. . . [output removed] . . .
When the overall CPU utilization gets high, you can identify which process is using the most
CPU cycles, and then focus your attention on that process. For example, if the IP-EIGRP CPU
utilization runs high, you can determine that there is a problem within EIGRP, perhaps a routing
loop or some other instability.
show processes memory
The second helpful option for the show processes command is memory, which is used to associate
memory utilization with the router’s processes. Here is a sample output:
Router_D>show processes memory
Total: 52503792, Used: 45141524, Free: 7362268
PID TTY Allocated Freed Holding Getbufs Retbufs Process
0 0 54400 304 8898364 0 0 *Init*
0 0 632 3906083084 632 0 0 *Sched*
0 0 700723436 729437084 472484 1091352 0 *Dead*
1 0 96 0 6876 0 0 SSCOP Input
2 0 0 0 6780 0 0 Check heaps
3 0 17262036 152680 6916 12351248 260336 Pool Manager
. . . [output removed] . . .
The first line details the total, used, and free amounts of system memory. Following that, you
see the PID, allocated, freed, and holding memory. This means that the processor has allocated
a given amount of memory to the process; if the process does not need all of that memory, it
frees some of it and retains the rest.
TCP/IP Protocol Commands
We will discuss the major TCP/IP protocol commands in this section. In addition to the
TCP/IP-related commands listed here, other protocol-related commands are covered later in
this book. These cover protocols including HDLC, Frame Relay, X.25, and ISDN.
1100 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
Table 37.7 lists the frequently used IP options for the show command.
show ip access-list
This command provides information regarding a specified access list, or all access lists that
fall within the 1–199 range. When various access lists are configured on the router, the show
ip access-list command shows named IP access lists only. (Named access lists are explained
later in this chapter.) From the following sample output, you can see that it lists both standard
and extended lists:
Standard IP access list 5
permit 172.16.14.2
permit 172.16.91.140
permit 172.16.10.51
permit 172.16.1.7
permit 172.16.155.0, wildcard bits 0.0.0.255
Extended IP access list 152
deny ip any 172.16.91.0 0.0.0.63 log (268436 matches)
deny ip any host 172.16.91.66 log (81058 matches)
permit tcp any any established (8809 matches)
permit ip host 172.16.2.55 any
permit ip host 172.60.22.10 any (2194226 matches)
permit ip host 172.140.64.8 any (7930443 matches)
permit ip 172.16.10.0 0.0.255.255 any (9076 matches)
TABLE 3 7 . 7 Frequently Used show IP Command Options
show ip Command Option Information Produced
access-lists IP access lists
accounting The active IP accounting database
arp Information regarding the IP ARP entries in the ARP cache
interface IP interface status and configuration
protocols Information regarding the IP routing protocols running on
a router
route IP routing table
traffic IP protocol statistics
Troubleshooting Commands 1101
show ip arp
This command provides information contained in the router’s ARP cache, including the IP
address, MAC address, encapsulation type, and interface from which the MAC was learned.
Here is a sample:
Router_C#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.16.60.1 - 0010.7bd9.2881 ARPA Ethernet0/1
Internet 172.16.50.2 - 0010.7bd9.2880 ARPA Ethernet0/0
Internet 172.16.50.1 6 0000.0c09.99cc ARPA Ethernet0/0
Router_C#
show ip protocols
This command provides information about the IP routing protocols that run on the router. The
sample output shown here includes only EIGRP information, because that is all that is being run
on the router. As you can see, global filters are not applied. Metric values are displayed for each
individual routing protocol. Route redistribution information is also provided:
Router_B#show ip protocols
Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not
set
Incoming update filter list for all interfaces is not
set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
Automatic network summarization is not in effect
Routing for Networks:
172.16.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170
Router_B#
show ip route
This command returns information stored in the IP route table. The command can be issued as
a general command, and all IP routes and corresponding information will be displayed. Additionally,
you can specify a given network, and the command will return information regarding
that network only.
1102 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
This section contains two examples of the show ip route command. Notice that the two
outputs are different. The general command provides summary information for every IP route
in the route table. However, when a network is specified, the results are much more detailed.
Items such as the exact routing protocol responsible for learning the route, the source interface,
and the next-hop router’s IP address are all included:
Router_A>show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF
inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2,
E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, *
- candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.50.0/24 [90/2195456] via 172.16.30.6, 00:00:19, Serial1
C 172.16.30.4/30 is directly connected, Serial1
Router_A>
Router_A>show ip route 172.16.50.0
Routing entry for 172.16.50.0/24
Known via "eigrp 100", distance 90, metric 2195456, type internal
Redistributing via eigrp 100
Last update from 172.16.30.6 on Serial1, 00:02:03 ago
Routing Descriptor Blocks:
* 172.16.30.6, from 172.16.30.6, 00:02:03 ago, via
Serial1
Route metric is 2195456, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth
is 1544 Kbit
Reliability 128/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Router_A>
Troubleshooting Commands 1103
show ip traffic
This command returns information pertaining to IP traffic statistics. When the command is
issued, the output is organized according to the IP protocol. Here is a sample:
Router_B#show ip traffic
IP statistics:
Rcvd: 400 total, 400 local destination
0 format errors, 0 checksum errors,
0 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options,
0 with options
Opts: 0 end, 0 nop, 0 basic security,
0 loose source route
0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 0 alert,
0 cipso
0 other
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
0 fragmented, 0 couldn't fragment
Bcast: 0 received, 0 sent
Mcast: 398 received, 401 sent
Sent: 404 generated, 0 forwarded
0 encapsulation failed, 0 no route
ICMP statistics:
Rcvd: 0 format errors, 0 checksum errors, 0 redirects, 0
unreachable
0 echo, 0 echo reply, 0 mask requests, 0 mask
replies, 0 quench
0 parameter, 0 timestamp, 0 info request, 0 other
0 irdp solicitations, 0 irdp advertisements
Sent: 0 redirects, 0 unreachable, 0 echo, 0 echo reply
0 mask requests, 0 mask replies, 0 quench, 0
timestamp
0 info reply, 0 time exceeded, 0 parameter problem
0 irdp solicitations, 0 irdp advertisements
UDP statistics:
Rcvd: 0 total, 0 checksum errors, 0 no port
Sent: 0 total, 0 forwarded broadcasts
1104 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
TCP statistics:
Rcvd: 0 total, 0 checksum errors, 0 no port
Sent: 0 total
Probe statistics:
Rcvd: 0 address requests, 0 address replies
0 proxy name requests, 0 where-is requests, 0
other
Sent: 0 address requests, 0 address replies (0 proxy)
0 proxy name replies, 0 where-is replies
EGP statistics:
Rcvd: 0 total, 0 format errors, 0 checksum errors, 0 no
listener
Sent: 0 total
IGRP statistics:
Rcvd: 0 total, 0 checksum errors
Sent: 0 total
OSPF statistics:
Rcvd: 0 total, 0 checksum errors
0 Hello, 0 database desc, 0 link state req
0 link state updates, 0 link state acks
Sent: 0 total
IP-IGRP2 statistics:
Rcvd: 402 total
Sent: 406 total
PIMv2 statistics: Sent/Received
Total: 0/0, 0 checksum errors, 0 format errors
Registers: 0/0, Register Stops: 0/0
IGMP statistics: Sent/Received
Total: 0/0, Format errors: 0/0, Checksum errors: 0/0
Host Queries: 0/0, Host Reports: 0/0, Host Leaves: 00
DVMRP: 0/0, PIM: 0/0
Troubleshooting Commands 1105
ARP statistics:
Rcvd: 0 requests, 0 replies, 0 reverse, 0 other
Sent: 1 requests, 5 replies (0 proxy), 0 reverse
Router_B#
debug Commands
The debug commands and options are very powerful tools. The messages produced by the
debugging process give detailed information and provide insight into what is happening on a
very low level.
This power does not come free of charge. In most cases, debugging requires every packet to
be process-switched, meaning that the route processor has to look at every packet entering the
router in order for valid information to be obtained. In addition, the router must run and manage
many other processes. Debugging can cause a great deal of additional overhead on a router.
Therefore, it is important to use the tool with discretion. Use it to provide additional information
on an existing problem, not to monitor a router. As a rule of thumb, debug commands
should not be run on a router that already has a CPU utilization greater than 50 percent.
Because most problems are reported while a network is in production, the last thing you
want to do is crash a router or cause unnecessary overhead by using the debug tool. By focusing
the application of the debug command by using various command options and access lists, you
can effectively troubleshoot problems without causing additional ones.
Always remember to turn the debugging function off after you obtain the
necessary data. If left on, it can cause another network problem.
There are two tricks to successfully using the debug tool. First, make sure that your router
is configured to apply timestamps to all messages. This is done with the following commands:
Router_A(config)#service timestamps debug datetime msec localtime
Router_A(config)#service timestamps log datetime msec localtime
Next, make sure that you see these messages. By default, error and debug messages are sent
only to the console. If you are telnetted to the router, you will not see the debug or log messages
unless you issue the following command:
Router_A#terminal monitor
You can turn the messages off again by issuing the no form of the command:
Router_A#terminal no monitor
If the output messages from the debug become excessive, it becomes difficult, if not impossible,
to enter commands. Should this happen, there are two commands that you can issue to stop the
messages. The first one was already mentioned (terminal no monitor, or term no mon for
1106 Chapter 37 Cisco Diagnostic Commands and TCP/IP Troubleshooting
short). In this case, you type, but you don’t see anything echo back. It can get confusing. Remember
that the text messages that echo to the screen are not entered on the command line of the
router. You can safely type term no mon and press Enter, even with hundreds of messages scrolling
past you on the screen. The router eventually recognizes and processes the command. That
stops the messages from scrolling down the screen, but it does not stop the processor from looking
at every packet.
To stop the debug process altogether, the easiest way is to type the shorthand form of
undebug all, like this:
Router_A#un all
It is short and sweet, yet effective. It works especially well when the router seems to be having
a runaway. This command stops all debug processes and all associated messages. It can be
entered safely while messages are scrolling wildly down the screen. It may take the router a few
CPU cycles to accept the command and actually stop the debug process, so don’t panic.
As an alternative, you can also have the un all command ready to go if you allow multiple
telnet sessions to the same router. In this instance, you would telnet to the router twice. In one
of the telnet sessions, set up the terminal monitor command so that you would receive the
debug output. In the other window, type in the undebug all command but do not press Enter.
Then return to your first telnet session and execute the debug command you need. If the output
is overwhelming, go back to your other telnet session and hit Enter. As was the case before, it
may take several seconds for the router to process the command and the messages to stop
appearing on the screen.
Limiting Debug Output
Because of the potential impact to the router, you should take precautions whenever you use
debug commands. Be as specific as possible when entering the debug commands so that you look
only at information relevant to your issue. In addition to the commands themselves, you can apply
access lists to the debug commands to further limit the information you are examining.
For example, if you wanted to see ping (ICMP) packets going between stations with IP
addresses of 10.20.20.20 and 10.30.30.30, you could create an access list like this:
access-list 100 permit icmp host 10.20.20.20 host 10.30.30.30
Then apply this access list to the debug command as shown here:
Router_C#debug ip packet detail 100
IP packet debugging is on (detailed) for access list 100
Router_C#
IP: s=10.20.20.20 (Serial0), d=10.30.30.30 (Serial1), g=10.5.30.30, len
100, forward ICMP type=8, code=0
In this manner, only ICMP packets going from 10.20.20.20 to 10.30.30.30 are shown in the
debug output, rather than all of the packets going through the router.
Troubleshooting Commands 1107
As with the show commands, there are global-, interface-, and protocol-related debugging
options. Because these tools and commands are used and discussed often in upcoming chapters,
they are only summarized here according to usage.
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
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.
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.
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
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.
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.
Subscribe to:
Posts (Atom)