Periodic updates means that at the end of a certain time period, updates will be transmitted. This period
typically ranges from 10 seconds for AppleTalk's RTMP to 90 seconds for Cisco's IGRP. At issue here is
the fact that if updates are sent too frequently, congestion may occur; if updates are sent too infrequently,
convergence time may be unacceptably high. 87
IT Certification CCIE,CCNP,CCIP,CCNA,CCSP,Cisco Network Optimization and Security Tips
Common Characteristics
A typical distance vector routing protocol uses a routing algorithm in which routers periodically send
routing updates to all neighbors by broadcasting their entire route tables.[3]
[3] A notable exception to this convention is Cisco's Enhanced IGRP. EIGRP is a distance vector protocol, but its updates are not periodic, are not
broadcasted, and do not contain the full route table. EIGRP is covered in Chapter 8, "Enhanced Interior Gateway Routing Protocol (EIGRP)."
The preceding statement contains a lot of information. Following sections consider it in more detail.
routing updates to all neighbors by broadcasting their entire route tables.[3]
[3] A notable exception to this convention is Cisco's Enhanced IGRP. EIGRP is a distance vector protocol, but its updates are not periodic, are not
broadcasted, and do not contain the full route table. EIGRP is covered in Chapter 8, "Enhanced Interior Gateway Routing Protocol (EIGRP)."
The preceding statement contains a lot of information. Following sections consider it in more detail.
Distance Vector Routing Protocols
Most routing protocols fall into one of two classes: distance vector or link state. The basics of distance
vector routing protocols are examined here; the next section covers link state routing protocols. Distance
vector algorithms are based on the work done of R. E. Bellman,[1] L. R. Ford, and D. R. Fulkerson[2] and
for this reason occasionally are referred to as Bellman-Ford or Ford-Fulkerson algorithms.
[1] R. E. Bellman. Dynamic Programming. Princeton, New Jersey: Princeton University Press; 1957.
[2] L. R. Ford Jr. and D. R. Fulkerson. Flows in Networks. Princeton, New Jersey: Princeton University Press; 1962.
The name distance vector is derived from the fact that routes are advertised as vectors of (distance,
direction), where distance is defined in terms of a metric and direction is defined in terms of the next-hop
router. For example, "Destination A is a distance of 5 hops away, in the direction of next-hop router X."
As that statement implies, each router learns routes from its neighboring routers' perspectives and then
advertises the routes from its own perspective. Because each router depends on its neighbors for
information, which the neighbors in turn may have learned from their neighbors, and so on, distance
vector routing is sometimes facetiously referred to as "routing by rumor."
Distance vector routing protocols include the following:
Routing Information Protocol (RIP) for IP
Xerox Networking System's XNS RIP
Novell's IPX RIP
Cisco's Internet Gateway Routing Protocol (IGRP)
DEC's DNA Phase IV
AppleTalk's Routing Table Maintenance Protocol (RTMP)
vector routing protocols are examined here; the next section covers link state routing protocols. Distance
vector algorithms are based on the work done of R. E. Bellman,[1] L. R. Ford, and D. R. Fulkerson[2] and
for this reason occasionally are referred to as Bellman-Ford or Ford-Fulkerson algorithms.
[1] R. E. Bellman. Dynamic Programming. Princeton, New Jersey: Princeton University Press; 1957.
[2] L. R. Ford Jr. and D. R. Fulkerson. Flows in Networks. Princeton, New Jersey: Princeton University Press; 1962.
The name distance vector is derived from the fact that routes are advertised as vectors of (distance,
direction), where distance is defined in terms of a metric and direction is defined in terms of the next-hop
router. For example, "Destination A is a distance of 5 hops away, in the direction of next-hop router X."
As that statement implies, each router learns routes from its neighboring routers' perspectives and then
advertises the routes from its own perspective. Because each router depends on its neighbors for
information, which the neighbors in turn may have learned from their neighbors, and so on, distance
vector routing is sometimes facetiously referred to as "routing by rumor."
Distance vector routing protocols include the following:
Routing Information Protocol (RIP) for IP
Xerox Networking System's XNS RIP
Novell's IPX RIP
Cisco's Internet Gateway Routing Protocol (IGRP)
DEC's DNA Phase IV
AppleTalk's Routing Table Maintenance Protocol (RTMP)
Load Balancing
Recall from Chapter 3, "Static Routing," that load balancing is the practice of distributing traffic among
multiple paths to the same destination in order to use bandwidth efficiently. As an example of the
usefulness of load balancing, consider Figure 4.1 again. All the networks in Figure 4.1 are reachable from
two paths. If a device on 192.168.2.0 sends a stream of packets to a device on 192.168.6.0, router A may
send them all via router B or router C. In both cases, the network is 1 hop away. However, sending all
packets on a single route probably is not the most efficient use of available bandwidth. Instead, load
balancing should be implemented to alternate traffic between the two paths. As noted in Chapter 3, load
balancing can be equal cost or unequal cost and per packet or per destination .
multiple paths to the same destination in order to use bandwidth efficiently. As an example of the
usefulness of load balancing, consider Figure 4.1 again. All the networks in Figure 4.1 are reachable from
two paths. If a device on 192.168.2.0 sends a stream of packets to a device on 192.168.6.0, router A may
send them all via router B or router C. In both cases, the network is 1 hop away. However, sending all
packets on a single route probably is not the most efficient use of available bandwidth. Instead, load
balancing should be implemented to alternate traffic between the two paths. As noted in Chapter 3, load
balancing can be equal cost or unequal cost and per packet or per destination .
Convergence
A dynamic routing protocol must include a set of procedures for a router to inform other routers about its
directly connected networks, to receive and process the same information from other routers, and to pass
along the information it receives from other routers. Further, a routing protocol must define a metric by
which best paths may be determined.
A further criteria for routing protocols is that the reachability information in the route tables of all routers
in the internetwork must be consistent. If router A in Figure 4.1 determines that the best path to network
192.168.5.0 is via router C and if router C determines that the best path to the same network is through
router A, router A will send packets destined for 192.168.5.0 to C, C will send them back to A, A will
again send them to C, and so on. This continuous circling of traffic between two or more destinations is
referred to as a routing loop.
NOTE
Convergence and convergence time
The process of bringing all route tables to a state of consistency is called convergence. The time it takes
to share information across an internetwork and for all routers to calculate best paths is the convergence
time.
Figure 4.2 shows an internetwork that was converged, but now a topology change has occurred. The link
between the two left-most routers has failed; both routers, being directly connected, know about the
failure from the data link protocol and proceed to inform their neighbors of the unavailable link. The
neighbors update their route tables accordingly and inform their neighbors, and the process continues
until all routers know about the change.
Figure 4.2. Reconvergence after a topology change takes time. While the internetwork is in an unconverged
state, routers are susceptible to bad routing information.
Notice that at time t2 the three left-most routers know about the topology change but the three right-most
routers have not yet heard the news. Those three have old information and will continue to switch packets
accordingly. It is during this intermediate time, when the internetwork is in an unconverged state, that
routing errors may occur. Therefore convergence time is an important factor in any routing protocol. The
faster a network can reconverge after a topology change, the better.
directly connected networks, to receive and process the same information from other routers, and to pass
along the information it receives from other routers. Further, a routing protocol must define a metric by
which best paths may be determined.
A further criteria for routing protocols is that the reachability information in the route tables of all routers
in the internetwork must be consistent. If router A in Figure 4.1 determines that the best path to network
192.168.5.0 is via router C and if router C determines that the best path to the same network is through
router A, router A will send packets destined for 192.168.5.0 to C, C will send them back to A, A will
again send them to C, and so on. This continuous circling of traffic between two or more destinations is
referred to as a routing loop.
NOTE
Convergence and convergence time
The process of bringing all route tables to a state of consistency is called convergence. The time it takes
to share information across an internetwork and for all routers to calculate best paths is the convergence
time.
Figure 4.2 shows an internetwork that was converged, but now a topology change has occurred. The link
between the two left-most routers has failed; both routers, being directly connected, know about the
failure from the data link protocol and proceed to inform their neighbors of the unavailable link. The
neighbors update their route tables accordingly and inform their neighbors, and the process continues
until all routers know about the change.
Figure 4.2. Reconvergence after a topology change takes time. While the internetwork is in an unconverged
state, routers are susceptible to bad routing information.
Notice that at time t2 the three left-most routers know about the topology change but the three right-most
routers have not yet heard the news. Those three have old information and will continue to switch packets
accordingly. It is during this intermediate time, when the internetwork is in an unconverged state, that
routing errors may occur. Therefore convergence time is an important factor in any routing protocol. The
faster a network can reconverge after a topology change, the better.
Cost
This metric is configured by a network administrator to reflect more- or less-preferred routes. Cost may
be defined by any policy or link characteristic or may reflect the arbitrary judgment of the network
administrator.
The term cost is often used as a generic term when speaking of route choices. For example, "RIP chooses
the lowest-cost path based on hop count." Another generic term is shortest, as in "RIP chooses the
shortest path based on hop count." When used in this context, either low est-cost (or highest-cost) and
shortest (or longest) merely refer to a routing protocol's view of paths based on its specific metrics.
be defined by any policy or link characteristic or may reflect the arbitrary judgment of the network
administrator.
The term cost is often used as a generic term when speaking of route choices. For example, "RIP chooses
the lowest-cost path based on hop count." Another generic term is shortest, as in "RIP chooses the
shortest path based on hop count." When used in this context, either low est-cost (or highest-cost) and
shortest (or longest) merely refer to a routing protocol's view of paths based on its specific metrics.
Reliability
Reliability measures the likelihood that the link will fail in some way and can be either variable or fixed.
Examples of variable-reliability metrics are the number of times a link has failed or the number of errors
it has received within a certain time period. Fixed-reliability metrics are based on known qualities of a
link as determined by the network administrator. The path with highest reliability would be selected as
best.
Examples of variable-reliability metrics are the number of times a link has failed or the number of errors
it has received within a certain time period. Fixed-reliability metrics are based on known qualities of a
link as determined by the network administrator. The path with highest reliability would be selected as
best.
Delay
Delay is a measure of the time a packet takes to traverse a route. A routing protocol using delay as a
metric would choose the path with the least delay as the best path. There may be many ways to measure
delay. Delay may take into account not only the delay of the links along the route but also such factors as
router latency and queuing delay. On the other hand, the delay of a route may be not measured at all; it
may be a sum of static quantities defined for each interface along the path. Each individual delay quantity
would be an estimate based on the type of link to which the interface is connected.
metric would choose the path with the least delay as the best path. There may be many ways to measure
delay. Delay may take into account not only the delay of the links along the route but also such factors as
router latency and queuing delay. On the other hand, the delay of a route may be not measured at all; it
may be a sum of static quantities defined for each interface along the path. Each individual delay quantity
would be an estimate based on the type of link to which the interface is connected.
Bandwidth
A bandwidth metric would choose a higher-bandwidth path over a lower-bandwidth link. However,
bandwidth by itself still may not be a good metric. What if one or both of the T1 links are heavily loaded
with other traffic and the 56K link is lightly loaded? Or what if the higher-bandwidth link also has a
higher delay?
bandwidth by itself still may not be a good metric. What if one or both of the T1 links are heavily loaded
with other traffic and the 56K link is lightly loaded? Or what if the higher-bandwidth link also has a
higher delay?
Hop Count
A hop count metric simply counts router hops. For instance, from router A it is 1 hop to network
192.168.5.0 if packets are sent out interface 192.168.3.1 (through router B) and 2 hops if packets are sent
out 192.168.1.1 (through routers C and B). Assuming hop count is the only metric being applied, the best
route is the one with the fewest hops, in this case, A-B.
But is the A-B link really the best path? If the A-B link is a DS-0 link and the A-C and C-B links are T-1
links, the 2-hop route may actually be best because bandwidth plays a role in how efficiently traffic
travels through the network.
192.168.5.0 if packets are sent out interface 192.168.3.1 (through router B) and 2 hops if packets are sent
out 192.168.1.1 (through routers C and B). Assuming hop count is the only metric being applied, the best
route is the one with the fewest hops, in this case, A-B.
But is the A-B link really the best path? If the A-B link is a DS-0 link and the A-C and C-B links are T-1
links, the 2-hop route may actually be best because bandwidth plays a role in how efficiently traffic
travels through the network.
Metrics
When there are multiple routes to the same destination, a router must have a mechanism for calculating
the best path. A metric is a variable assigned to routes as a means of ranking them from best to worst or
from most preferred to least preferred. Consider the following example of why metrics are needed.
Assuming that information sharing has properly occurred in the internetwork of Figure 4.1, router A
might have a route table that looks like Table 4.1.
Table 4.1. A rudimentary route table for router A of Figure 4.1.
Network Next-Hop Router
192.168.1.0 Directly connected
192.168.2.0 Directly connected
192.168.3.0 Directly connected
192.168.4.0 B, C
192.168.5.0 B, C
192.168.6.0 B, C
192.168.7.0 B, C
This route table says that the first three networks are directly connected and that no routing is needed
from router A to reach them, which is correct. The last four networks, according to this table, can be
reached via router B or router C. This information is also correct. But if network 192.168.7.0 can be
reached via either router B or router C, which path is the preferable path? Metrics are needed to rank the
alternatives.
NOTE
The "best" or "shortest" route is the most preferred route according to a particular protocol's metric.
Different routing protocols use different, and sometimes multiple, metrics. For example, RIP defines the
"best" route as the one with the least number of router hops; IGRP defines the "best" route based on a
combination of the lowest bandwidth along the route and the total delay of the route. The following
sections provide basic definitions of these and other commonly used metrics. Further complexities—such
as how some routing protocols use multiple metrics and deal with routes that have identical metric
values—are covered later, in the protocol-specific chapters of this book.
the best path. A metric is a variable assigned to routes as a means of ranking them from best to worst or
from most preferred to least preferred. Consider the following example of why metrics are needed.
Assuming that information sharing has properly occurred in the internetwork of Figure 4.1, router A
might have a route table that looks like Table 4.1.
Table 4.1. A rudimentary route table for router A of Figure 4.1.
Network Next-Hop Router
192.168.1.0 Directly connected
192.168.2.0 Directly connected
192.168.3.0 Directly connected
192.168.4.0 B, C
192.168.5.0 B, C
192.168.6.0 B, C
192.168.7.0 B, C
This route table says that the first three networks are directly connected and that no routing is needed
from router A to reach them, which is correct. The last four networks, according to this table, can be
reached via router B or router C. This information is also correct. But if network 192.168.7.0 can be
reached via either router B or router C, which path is the preferable path? Metrics are needed to rank the
alternatives.
NOTE
The "best" or "shortest" route is the most preferred route according to a particular protocol's metric.
Different routing protocols use different, and sometimes multiple, metrics. For example, RIP defines the
"best" route as the one with the least number of router hops; IGRP defines the "best" route based on a
combination of the lowest bandwidth along the route and the total delay of the route. The following
sections provide basic definitions of these and other commonly used metrics. Further complexities—such
as how some routing protocols use multiple metrics and deal with routes that have identical metric
values—are covered later, in the protocol-specific chapters of this book.
Path Determination
All networks within an internetwork must be connected to a router, and wherever a router has an interface
on a network that interface must have an address on the network. This address is the originating point for
reachability information.
Figure 4.1 shows a simple three-router internetwork. Router A knows about networks 192.168.1.0,
192.168.2.0, and 192.168.3.0 because it has interfaces on those networks with corresponding addresses
and appropriate address masks. Likewise, router B knows about 192.168.3.0, 192.168.4.0, 192.168.5.0,
and 192.186.6.0; router C knows about 192.168.6.0, 192.168.7.0, and 198.168.1.0. Each interface
implements the data link and physical protocols of the network to which it is attached, so the router also
knows the state of the network (up or down).
At first glance, the information-sharing procedure seems simple. Look at router A:
1. Router A examines its IP addresses and associated masks and deduces that it is attached to
networks 192.168.1.0, 192.186.2.0, and 192.168.3.0.
2. Router A enters these networks into its route table, along with some sort of flag indicating that the
networks are directly connected.
3. Router A places the information into a packet: "My directly connected networks are 192.168.1.0,
192.186.2.0, and 192.168.3.0."
4. Router A transmits copies of these route information packets, or routing updates, to routers B and
C.
5. Routers B and C, having performed the same steps, have sent updates with their directly
connected networks to A. Router A enters the received information into its route table, along with
the source address of the router that sent the update packet. Router A now knows about all the
networks, and it knows the addresses of the routers to which they are attached.
This procedure does seem quite simple. So why are routing protocols so much more complicated than
this? Look again at Figure 4.1.
What should router A do with the updates from B and C after it has recorded the information in
the route table? Should it, for instance, pass B's routing information packet to C and pass C's
packet to B?
If router A does not forward the updates, information sharing may not be complete. For instance,
if the link between B and C does not exist, those two routers would not know about each other's
networks. Router A must forward the update information, but this step opens a whole new set of
problems.
If router A hears about network 192.168.4.0 from both router B and router C, which router should
be used to reach that network? Are they both valid? Which one is the best path?
What mechanism will be used to ensure that all routers receive all routing information while
preventing update packets from circulating endlessly through the internetwork?
The routers share certain directly connected networks (192.168.1.0, 192.168.3.0, and
192.168.6.0). Should the routers still advertise these networks?
These questions are almost as simplistic as the preceding preliminary explanation of routing protocols,
but they should give you a feel for some of the issues that contribute to the complexity of the protocols.
Each routing protocol addresses these questions one way or another, as will become clear in following
sections and chapters.
on a network that interface must have an address on the network. This address is the originating point for
reachability information.
Figure 4.1 shows a simple three-router internetwork. Router A knows about networks 192.168.1.0,
192.168.2.0, and 192.168.3.0 because it has interfaces on those networks with corresponding addresses
and appropriate address masks. Likewise, router B knows about 192.168.3.0, 192.168.4.0, 192.168.5.0,
and 192.186.6.0; router C knows about 192.168.6.0, 192.168.7.0, and 198.168.1.0. Each interface
implements the data link and physical protocols of the network to which it is attached, so the router also
knows the state of the network (up or down).
At first glance, the information-sharing procedure seems simple. Look at router A:
1. Router A examines its IP addresses and associated masks and deduces that it is attached to
networks 192.168.1.0, 192.186.2.0, and 192.168.3.0.
2. Router A enters these networks into its route table, along with some sort of flag indicating that the
networks are directly connected.
3. Router A places the information into a packet: "My directly connected networks are 192.168.1.0,
192.186.2.0, and 192.168.3.0."
4. Router A transmits copies of these route information packets, or routing updates, to routers B and
C.
5. Routers B and C, having performed the same steps, have sent updates with their directly
connected networks to A. Router A enters the received information into its route table, along with
the source address of the router that sent the update packet. Router A now knows about all the
networks, and it knows the addresses of the routers to which they are attached.
This procedure does seem quite simple. So why are routing protocols so much more complicated than
this? Look again at Figure 4.1.
What should router A do with the updates from B and C after it has recorded the information in
the route table? Should it, for instance, pass B's routing information packet to C and pass C's
packet to B?
If router A does not forward the updates, information sharing may not be complete. For instance,
if the link between B and C does not exist, those two routers would not know about each other's
networks. Router A must forward the update information, but this step opens a whole new set of
problems.
If router A hears about network 192.168.4.0 from both router B and router C, which router should
be used to reach that network? Are they both valid? Which one is the best path?
What mechanism will be used to ensure that all routers receive all routing information while
preventing update packets from circulating endlessly through the internetwork?
The routers share certain directly connected networks (192.168.1.0, 192.168.3.0, and
192.168.6.0). Should the routers still advertise these networks?
These questions are almost as simplistic as the preceding preliminary explanation of routing protocols,
but they should give you a feel for some of the issues that contribute to the complexity of the protocols.
Each routing protocol addresses these questions one way or another, as will become clear in following
sections and chapters.
Routing Protocol Basics
All dynamic routing protocols are built around an algorithm. Generally, an algorithm is a step-by-step
procedure for solving a problem. A routing algorithm must, at a minimum, specify the following:
A procedure for passing reachability information about networks to other routers.
A procedure for receiving reachability information from other routers
A procedure for determining optimal routes based on the reachability information it has and for
recording this information in a route table
A procedure for reacting to, compensating for, and advertising topology changes in an
internetwork
A few issues common to any routing protocol are path determination, metrics, convergence, and load
balancing.
procedure for solving a problem. A routing algorithm must, at a minimum, specify the following:
A procedure for passing reachability information about networks to other routers.
A procedure for receiving reachability information from other routers
A procedure for determining optimal routes based on the reachability information it has and for
recording this information in a route table
A procedure for reacting to, compensating for, and advertising topology changes in an
internetwork
A few issues common to any routing protocol are path determination, metrics, convergence, and load
balancing.
Dynamic Routing Protocols
Routing Protocol Basics
Distance Vector Routing Protocols
Link State Routing Protocols
Interior and Exterior Gateway Protocols
Static or Dynamic Routing?
The last chapter explained what a router needs to know to correctly switch packets to their respective
destinations and how that information is put into the route table manually. This chapter shows how
routers can discover this information automatically and share that information with other routers via
dynamic routing protocols. A routing protocol is the language a router speaks with other routers in order
to share information about the reachability and status of networks.
Dynamic routing protocols not only perform these path determination and route table update functions but
also determine the next-best path if the best path to a destination becomes unusable. The capability to
compensate for topology changes is the most important advantage dynamic routing offers over static
routing.
Obviously, for communications to occur the communicators must speak the same language. There are
eight major IP routing protocols from which to choose; if one router speaks RIP and another speaks
OSPF, they cannot share routing information because they are not speaking the same language.
Subsequent chapters examine all the IP routing protocols in current use, and even consider how to make a
router "bilingual," but first it is necessary to explore some characteristics and issues common to all
routing protocols—IP or otherwise.
Distance Vector Routing Protocols
Link State Routing Protocols
Interior and Exterior Gateway Protocols
Static or Dynamic Routing?
The last chapter explained what a router needs to know to correctly switch packets to their respective
destinations and how that information is put into the route table manually. This chapter shows how
routers can discover this information automatically and share that information with other routers via
dynamic routing protocols. A routing protocol is the language a router speaks with other routers in order
to share information about the reachability and status of networks.
Dynamic routing protocols not only perform these path determination and route table update functions but
also determine the next-best path if the best path to a destination becomes unusable. The capability to
compensate for topology changes is the most important advantage dynamic routing offers over static
routing.
Obviously, for communications to occur the communicators must speak the same language. There are
eight major IP routing protocols from which to choose; if one router speaks RIP and another speaks
OSPF, they cannot share routing information because they are not speaking the same language.
Subsequent chapters examine all the IP routing protocols in current use, and even consider how to make a
router "bilingual," but first it is necessary to explore some characteristics and issues common to all
routing protocols—IP or otherwise.
Looking Ahead
For precise control over routing behavior in an internetwork, static routing is a powerful tool. However, if
topology changes are prevalent, the demands of manual reconfiguration may make static routing
administratively unfeasible. Dynamic routing protocols enable an internetwork to respond quickly and
automatically to topology changes. Before examining the details of specific IP routing protocols, the
general issues surrounding all dynamic protocols must be examined. The next chapter introduces dynamic
routing protocols.
topology changes are prevalent, the demands of manual reconfiguration may make static routing
administratively unfeasible. Dynamic routing protocols enable an internetwork to respond quickly and
automatically to topology changes. Before examining the details of specific IP routing protocols, the
general issues surrounding all dynamic protocols must be examined. The next chapter introduces dynamic
routing protocols.
Troubleshooting Static Routes
Followers of the assorted American political scandals of the past 30 or so years will have heard a
congressional investigator ask the question, "What did he know and when did he know it?" The same
question serves an internetworking investigator well. When troubleshooting routing problems, the first
step should almost always be to examine the route table. What does the router know? Does the router
know how to reach the destination in question? Is the information in the route table accurate? Knowing
how to trace a route is essential to successfully troubleshooting an internetwork.
congressional investigator ask the question, "What did he know and when did he know it?" The same
question serves an internetworking investigator well. When troubleshooting routing problems, the first
step should almost always be to examine the route table. What does the router know? Does the router
know how to reach the destination in question? Is the information in the route table accurate? Knowing
how to trace a route is essential to successfully troubleshooting an internetwork.
Configuring Static Routes
The route table acquires information in two ways. The information may be entered manually, by means of
a static route entry, or automatically by one of several systems of automatic information discovery and
sharing known as dynamic routing protocols. The bulk of this book concerns dynamic IP routing
protocols, but this discussion of static route configuration will prepare you to understand the subsequent
chapters.
More to the point, static routing is preferred over dynamic routing in certain circumstances. As with any
process, the more automatic it is, the less control we have over it. Although dynamic (automatic) routing
requires much less human intervention, static routing allows very precise control over the routing
behavior of an internetwork. The price to be paid for this precision is the necessity of manual
reconfiguration any time the topology of the network changes.
NOTE
Discontiguous networks
NOTE
Variable subnetting
Case Study: Simple Static Routes
Figure 3.3 shows an internetwork with four routers and six networks. Notice that the subnets of network
10.0.0.0 are discontiguous—there is a different major network subnet (192.168.1.192, in the Tigger-to-
Piglet link) separating 10.1.0.0 from the other 10.0.0.0 subnets. The subnets of 10.0.0.0 are also variably
subnetted—the subnet masks are not consistent throughout the internetwork. Finally, the subnet address
of Pooh's Ethernet link is an all-zero subnet. Later chapters demonstrate that an addressing scheme with
these characteristics causes problems for simpler, classful routing protocols such as RIP and IGRP; static
routes work fine here.
Figure 3.3. Routing protocols such as RIP and IGRP cannot easily route this discontiguous, variably
subnetted internetwork, but static routing will work.
The routing commands themselves are easily read if the reader remembers that each command describes a
route table entry. The command is ip route, followed by the address to be entered into the table, a mask
for determining the network portion of the address, and the address of the directly connected interface of
the next-hop router.
An alternative configuration command for static routes specifies the interface out of which a network is
reached instead of the address of the next-hop router. For example, the route entries for Tigger could be
as follows:
Tigger(config)# ip route 192.168.1.0 255.255.255.224 S0
Tigger(config)# ip route 10.1.0.0 255.255.0.0 E0
Tigger(config)# ip route 10.4.7.0 255.255.255.0 S1
Figure 3.4 compares the route table resulting from this configuration with the route table resulting from
entries pointing to a next-hop router. Notice that a certain inaccuracy is introduced; all networks specified
with a static route referring to an exit interface are entered into the table as if they are directly connected
to that interface. The implications for route redistribution are discussed in Chapter 11.
Figure 3.4. The top route table is the result of static route entries pointing to the next-hop router. The
bottom route table is the result of static routes that point to the interface a packet must exit to reach the
destination network.[4]
a static route entry, or automatically by one of several systems of automatic information discovery and
sharing known as dynamic routing protocols. The bulk of this book concerns dynamic IP routing
protocols, but this discussion of static route configuration will prepare you to understand the subsequent
chapters.
More to the point, static routing is preferred over dynamic routing in certain circumstances. As with any
process, the more automatic it is, the less control we have over it. Although dynamic (automatic) routing
requires much less human intervention, static routing allows very precise control over the routing
behavior of an internetwork. The price to be paid for this precision is the necessity of manual
reconfiguration any time the topology of the network changes.
NOTE
Discontiguous networks
NOTE
Variable subnetting
Case Study: Simple Static Routes
Figure 3.3 shows an internetwork with four routers and six networks. Notice that the subnets of network
10.0.0.0 are discontiguous—there is a different major network subnet (192.168.1.192, in the Tigger-to-
Piglet link) separating 10.1.0.0 from the other 10.0.0.0 subnets. The subnets of 10.0.0.0 are also variably
subnetted—the subnet masks are not consistent throughout the internetwork. Finally, the subnet address
of Pooh's Ethernet link is an all-zero subnet. Later chapters demonstrate that an addressing scheme with
these characteristics causes problems for simpler, classful routing protocols such as RIP and IGRP; static
routes work fine here.
Figure 3.3. Routing protocols such as RIP and IGRP cannot easily route this discontiguous, variably
subnetted internetwork, but static routing will work.
The routing commands themselves are easily read if the reader remembers that each command describes a
route table entry. The command is ip route, followed by the address to be entered into the table, a mask
for determining the network portion of the address, and the address of the directly connected interface of
the next-hop router.
An alternative configuration command for static routes specifies the interface out of which a network is
reached instead of the address of the next-hop router. For example, the route entries for Tigger could be
as follows:
Tigger(config)# ip route 192.168.1.0 255.255.255.224 S0
Tigger(config)# ip route 10.1.0.0 255.255.0.0 E0
Tigger(config)# ip route 10.4.7.0 255.255.255.0 S1
Figure 3.4 compares the route table resulting from this configuration with the route table resulting from
entries pointing to a next-hop router. Notice that a certain inaccuracy is introduced; all networks specified
with a static route referring to an exit interface are entered into the table as if they are directly connected
to that interface. The implications for route redistribution are discussed in Chapter 11.
Figure 3.4. The top route table is the result of static route entries pointing to the next-hop router. The
bottom route table is the result of static routes that point to the interface a packet must exit to reach the
destination network.[4]
The Route Table
To understand the kind of information that exists in the route table, it is useful to begin with an
examination of what happens when a framed packet arrives at one of a router's interfaces. The data-link
identifier in the frame's destination address field is examined. If it contains either the identifier of the
router's interface or a broadcast identifier, the router strips off the frame and passes the enclosed packet to
the network layer. At the network layer, the destination address of the packet is examined. If the
destination address is either the IP address of the router's interface or an all-hosts broadcast address, the
protocol field of the packet is examined and the enclosed data is sent to the appropriate internal process. [1]
[1] There is also the special case of a multicast address, which is destined for a group of devices, but not for all devices. An example of a multicast
address is the class D address 224.0.0.5, reserved for all OSPF-speaking routers.
Any other destination address calls for routing. The address may be for a host on another network to
which the router is attached (including the router interface attached to that network) or for a host on a
network not directly connected to the router. The address may also be a directed broadcast, in which there is a distinct network or subnet address, and the remaining host bits are all ones. These addresses are also
routable.
If the packet is to be routed, the router will do a route table lookup to acquire the correct route. At a
minimum, each route entry in the database must contain two items:
A destination address. This is the address of the network the router can reach. As this chapter
explains, the router may have more than one route to the same address and/or a group of subnets
of the same or of varying lengths grouped under the same major IP network address.
A pointer to the destination. This pointer either will indicate that the destination network is
directly connected to the router or it will indicate the address of another router on a directly
connected network. That router, which will be one router hop closer to the destination, is a nexthop
router.
The router will match the most specific address it can.[2] In descending order of specificity, the address
may be one of the following:
[2] There are two basic procedures for finding the best match, depending upon whether the router is behaving classfully or classlessly. Classful
table lookups are explained in more detail in Chapter 5, "Routing Information Protocol (RIP), and classless table lookups are explained in
Chapter 7, "Routing Information Protocol Version 2."
A host address (a host route)
A subnet
A group of subnets (a summary route)
A major network number
A group of major network numbers (a supernet)
A default address
This chapter provides examples of the first four types. Supernets are covered in Chapter 7, "Routing
Information Protocol Version 2." A default address is considered a least-specific address and is matched
only if no other match can be found. Default addressing is the topic of Chapter 12, "Default Routes and
On-Demand Routing."
If the destination address of the packet cannot be matched to any route table entry, the packet is dropped
and a Destination Unreachable ICMP message is sent to the source address.
Figure 3.1 shows a simple internetwork and the route table entries required by each router. Of primary
importance here is the "big picture," seeing how the route tables work as a whole to transport packets
correctly and efficiently. The destination addresses that the router can reach are listed in the Network
column of the route tables. The pointers to the destinations are in the Next Hop column.
Figure 3.1. The minimum information needed for each route table entry consists of the destination
networks and the pointers to those networks.
If router Carroll in Figure 3.1 receives a packet with a source address of 10.1.1.97 and a destination
address of 10.1.7.35, a route table lookup determines that the best match for the destination address is
subnet 10.1.7.0, reachable via next-hop address 10.1.2.2, on interface S0. The packet is sent to that next
router (Dahl), which does a lookup in its own table and sees that network 10.1.7.0 is reachable via nexthop
address 10.1.4.2, out interface S1. The process continues until the packet reaches router Baum. That
router, receiving the packet on its interface S0, does a lookup, and sees that the destination is on one of its
directly connected networks, out E0. Routing is completed, and the packet is delivered to host 10.1.7.35
on the Ethernet link.
The routing process, as explained, assumes that the router can match its listed next-hop addresses to its
interfaces. For example, router Dahl must know that Lewis's address 10.1.4.2 is reachable via interface
S1. Dahl will know from the IP address and subnet mask assigned to S1 that S1 is directly connected to
subnet 10.1.4.0. It then knows that 10.1.4.2, a member of the same subnet, must be connected to the same
network.
Notice that every router must have consistent and accurate information for correct packet switching to
occur. For example, in Figure 3.1 an entry for network 10.1.1.0 is missing from Dahl's route table. A
packet from 10.1.1.97 to 10.1.7.35 will be delivered, but when a reply is sent from 10.1.7.35 to 10.1.1.97,
the packet is passed from Baum to Lewis to Dahl. Dahl does a lookup and finds that it has no entry for
subnet 10.1.1.0, so the packet is dropped, and an ICMP Destination Unreachable message is sent to host
10.1.7.35.
Figure 3.2 shows the actual Cisco route table from router Lewis of Figure 3.1. The command for
examining the IP route table of a Cisco router is show ip route.
Figure 3.2. The Cisco route table for router Lewis of Figure 3.1.
Examine the contents of this database and compare it with the generic table shown for Lewis in Figure
3.1. A key at the top of the table explains the letters down the left side of the table. These letters indicate
how each route entry was learned; in Figure 3.2 all routes are tagged with either a C for "directly
connected," or an S for "static entry." The statement "gateway of last resort is not set" refers to a default
route.
At the top of the table is a statement indicating that the route table knows of seven subnets of the major
network address 10.0.0.0, subnetted with a 24-bit mask. For each of the seven route entries, the
destination subnet is shown; for the entries that are not directly connected—routes for which the packet
must be forwarded to a next-hop router—a bracketed tuple indicates [administrative distance/metric] for
that route. Administrative distances are introduced later in this chapter and are covered in detail in
Chapter 11, "Route Redistribution." Metrics, discussed in greater detail in Chapter 4, "Dynamic Routing Protocols," are a way for routes to be
rated by preference—the lower the metric, the "shorter" the path. Notice that the static routes shown in
Figure 3.2 have a metric of 0. Finally, either the address of the directly connected interface of the nexthop
router or the interface to which the destination is connected is shown.
examination of what happens when a framed packet arrives at one of a router's interfaces. The data-link
identifier in the frame's destination address field is examined. If it contains either the identifier of the
router's interface or a broadcast identifier, the router strips off the frame and passes the enclosed packet to
the network layer. At the network layer, the destination address of the packet is examined. If the
destination address is either the IP address of the router's interface or an all-hosts broadcast address, the
protocol field of the packet is examined and the enclosed data is sent to the appropriate internal process. [1]
[1] There is also the special case of a multicast address, which is destined for a group of devices, but not for all devices. An example of a multicast
address is the class D address 224.0.0.5, reserved for all OSPF-speaking routers.
Any other destination address calls for routing. The address may be for a host on another network to
which the router is attached (including the router interface attached to that network) or for a host on a
network not directly connected to the router. The address may also be a directed broadcast, in which there is a distinct network or subnet address, and the remaining host bits are all ones. These addresses are also
routable.
If the packet is to be routed, the router will do a route table lookup to acquire the correct route. At a
minimum, each route entry in the database must contain two items:
A destination address. This is the address of the network the router can reach. As this chapter
explains, the router may have more than one route to the same address and/or a group of subnets
of the same or of varying lengths grouped under the same major IP network address.
A pointer to the destination. This pointer either will indicate that the destination network is
directly connected to the router or it will indicate the address of another router on a directly
connected network. That router, which will be one router hop closer to the destination, is a nexthop
router.
The router will match the most specific address it can.[2] In descending order of specificity, the address
may be one of the following:
[2] There are two basic procedures for finding the best match, depending upon whether the router is behaving classfully or classlessly. Classful
table lookups are explained in more detail in Chapter 5, "Routing Information Protocol (RIP), and classless table lookups are explained in
Chapter 7, "Routing Information Protocol Version 2."
A host address (a host route)
A subnet
A group of subnets (a summary route)
A major network number
A group of major network numbers (a supernet)
A default address
This chapter provides examples of the first four types. Supernets are covered in Chapter 7, "Routing
Information Protocol Version 2." A default address is considered a least-specific address and is matched
only if no other match can be found. Default addressing is the topic of Chapter 12, "Default Routes and
On-Demand Routing."
If the destination address of the packet cannot be matched to any route table entry, the packet is dropped
and a Destination Unreachable ICMP message is sent to the source address.
Figure 3.1 shows a simple internetwork and the route table entries required by each router. Of primary
importance here is the "big picture," seeing how the route tables work as a whole to transport packets
correctly and efficiently. The destination addresses that the router can reach are listed in the Network
column of the route tables. The pointers to the destinations are in the Next Hop column.
Figure 3.1. The minimum information needed for each route table entry consists of the destination
networks and the pointers to those networks.
If router Carroll in Figure 3.1 receives a packet with a source address of 10.1.1.97 and a destination
address of 10.1.7.35, a route table lookup determines that the best match for the destination address is
subnet 10.1.7.0, reachable via next-hop address 10.1.2.2, on interface S0. The packet is sent to that next
router (Dahl), which does a lookup in its own table and sees that network 10.1.7.0 is reachable via nexthop
address 10.1.4.2, out interface S1. The process continues until the packet reaches router Baum. That
router, receiving the packet on its interface S0, does a lookup, and sees that the destination is on one of its
directly connected networks, out E0. Routing is completed, and the packet is delivered to host 10.1.7.35
on the Ethernet link.
The routing process, as explained, assumes that the router can match its listed next-hop addresses to its
interfaces. For example, router Dahl must know that Lewis's address 10.1.4.2 is reachable via interface
S1. Dahl will know from the IP address and subnet mask assigned to S1 that S1 is directly connected to
subnet 10.1.4.0. It then knows that 10.1.4.2, a member of the same subnet, must be connected to the same
network.
Notice that every router must have consistent and accurate information for correct packet switching to
occur. For example, in Figure 3.1 an entry for network 10.1.1.0 is missing from Dahl's route table. A
packet from 10.1.1.97 to 10.1.7.35 will be delivered, but when a reply is sent from 10.1.7.35 to 10.1.1.97,
the packet is passed from Baum to Lewis to Dahl. Dahl does a lookup and finds that it has no entry for
subnet 10.1.1.0, so the packet is dropped, and an ICMP Destination Unreachable message is sent to host
10.1.7.35.
Figure 3.2 shows the actual Cisco route table from router Lewis of Figure 3.1. The command for
examining the IP route table of a Cisco router is show ip route.
Figure 3.2. The Cisco route table for router Lewis of Figure 3.1.
Examine the contents of this database and compare it with the generic table shown for Lewis in Figure
3.1. A key at the top of the table explains the letters down the left side of the table. These letters indicate
how each route entry was learned; in Figure 3.2 all routes are tagged with either a C for "directly
connected," or an S for "static entry." The statement "gateway of last resort is not set" refers to a default
route.
At the top of the table is a statement indicating that the route table knows of seven subnets of the major
network address 10.0.0.0, subnetted with a 24-bit mask. For each of the seven route entries, the
destination subnet is shown; for the entries that are not directly connected—routes for which the packet
must be forwarded to a next-hop router—a bracketed tuple indicates [administrative distance/metric] for
that route. Administrative distances are introduced later in this chapter and are covered in detail in
Chapter 11, "Route Redistribution." Metrics, discussed in greater detail in Chapter 4, "Dynamic Routing Protocols," are a way for routes to be
rated by preference—the lower the metric, the "shorter" the path. Notice that the static routes shown in
Figure 3.2 have a metric of 0. Finally, either the address of the directly connected interface of the nexthop
router or the interface to which the destination is connected is shown.
Static Routing
The Route Table
Configuring Static Routes
Case Study: Simple Static Routes
Case Study: Summary Routes
Case Study: Alternative Routes
Case Study: Static Floating Routes
Case Study: Load Sharing
Case Study: Recursive Table Lookups
Troubleshooting Static Routes
Case Study: Tracing a Failed Route
Case Study: A Protocol Conflict
An important observation from Chapter 2, "TCP/IP Review," is that the data link/physical layers and the
transport/network layers, as defined by the OSI model, perform very similar duties: They provide the
means for conveying data from a source to a destination across some path. The difference is that the data
link/physical layers provide communications across a physical path, whereas the transport/network layers
provide communications across a logical or virtual path made up of a series of data links.
Further, Chapter 2 showed that for communications to take place across a physical path, certain
information about data link identifiers and encapsulations must be acquired and stored in a database such
as the ARP cache. Similarly, information that the transport/network layers require to do their job must
also be acquired and stored. This information is stored in the route table, also known as the forwarding
database.
This chapter examines what sort of information is required to route a packet, how that information is
stored in the route table, how to enter the information into the database, and some techniques for building
a routed internetwork by entering the proper information into the proper routers' route tables.
Configuring Static Routes
Case Study: Simple Static Routes
Case Study: Summary Routes
Case Study: Alternative Routes
Case Study: Static Floating Routes
Case Study: Load Sharing
Case Study: Recursive Table Lookups
Troubleshooting Static Routes
Case Study: Tracing a Failed Route
Case Study: A Protocol Conflict
An important observation from Chapter 2, "TCP/IP Review," is that the data link/physical layers and the
transport/network layers, as defined by the OSI model, perform very similar duties: They provide the
means for conveying data from a source to a destination across some path. The difference is that the data
link/physical layers provide communications across a physical path, whereas the transport/network layers
provide communications across a logical or virtual path made up of a series of data links.
Further, Chapter 2 showed that for communications to take place across a physical path, certain
information about data link identifiers and encapsulations must be acquired and stored in a database such
as the ARP cache. Similarly, information that the transport/network layers require to do their job must
also be acquired and stored. This information is stored in the route table, also known as the forwarding
database.
This chapter examines what sort of information is required to route a packet, how that information is
stored in the route table, how to enter the information into the database, and some techniques for building
a routed internetwork by entering the proper information into the proper routers' route tables.
UDP
User Datagram Protocol, or UDP, described in RFC 768, provides a connectionless, best-effort packet
delivery service. At first take, it may seem questionable that any application would prefer an unreliable
delivery over the connection-oriented TCP. The advantage of UDP, however, is that no time is spent
setting up a connection—the data is just sent. Applications that send short bursts of data will realize a
performance advantage by using UDP instead of TCP.
delivery service. At first take, it may seem questionable that any application would prefer an unreliable
delivery over the connection-oriented TCP. The advantage of UDP, however, is that no time is spent
setting up a connection—the data is just sent. Applications that send short bursts of data will realize a
performance advantage by using UDP instead of TCP.
TCP
The Transmission Control Protocol, or TCP, described in RFC 793, provides applications with a reliable,
connection-oriented service. In other words, TCP provides the appearance of a point-to-point connection.
Point-to-point connections have two characteristics:
They have only one path to the destination. A packet entering one end of the connection cannot
become lost, because the only place to go is the other end.
Packets arrive in the same order in which they are sent.
TCP provides the appearance of a point-to-point connection, although in reality there is no such
connection. The internet layer TCP is utilizing is a connectionless, best-effort packet delivery service. The
analog of this is the postal service. If a stack of letters is given to the mail carrier for delivery, there is no
guarantee that the letters will arrive stacked in the same order, that they will all arrive on the same day, or
indeed that they will arrive at all. The postal service merely commits to making its best effort to deliver
the letters.
Likewise, the internet layer does not guarantee that all packets will take the same route, and therefore
there is no guarantee that they will arrive in the same sequence and time intervals as they were sent, or
that they will arrive at all.
On the other hand, a telephone call is connection-oriented service. Data must arrive sequentially and
reliably, or it is useless. Like a telephone call, TCP must first establish a connection, then transfer data,
and then perform a disconnect when the data transfer is complete.
TCP uses three fundamental mechanisms to accomplish a connection-oriented service on top of a
connectionless service:
Packets are labeled with sequence numbers so that the receiving TCP service can put out-ofsequence
packets into the correct sequence before delivering them to the destination application.
TCP uses a system of acknowledgments, checksums, and timers to provide reliability. A receiver
may notify a sender when it recognizes that a packet in a sequence has failed to arrive or has
errors, or a sender may assume that a packet has not arrived if the receiver does not send an
acknowledgment within a certain amount of time after transmission. In both cases, the sender will
resend the packet in question.
TCP uses a mechanism called windowing to regulate the flow of packets; windowing decreases
the chances of packets being dropped because of full buffers in the receiver.
TCP attaches a header to the application layer data; the header contains fields for the sequence numbers
and other information necessary for these mechanisms as well as fields for addresses called port numbers,
which identify the source and destination applications of the data. The application data with its attached
TCP header is then encapsulated within an IP packet for delivery. Figure 2.32 shows the fields of the TCP
header, and Figure 2.33 shows an analyzer capture of a TCP header.
Source and Destination Port are 16-bit fields that specify the source and destination applications for the
encapsulated data. Like other numbers used by TCP/IP, RFC 1700 describes all port numbers in common
and not-so-common use. A port number for an application, when coupled with the IP address of the host
the application resides on, is called a socket. A socket uniquely identifies every application in an
internetwork.
Sequence Number is a 32-bit number that identifies where the encapsulated data fits within a data stream
from the sender. For example, if the sequence number of a segment is 1343 and the segment contains 512
octets of data, the next segment should have a sequence number of 1343 + 512 + 1 = 1856.
Acknowledgment Number is a 32-bit field that identifies the sequence number the source next expects to
receive from the destination. If a host receives an acknowledgment number that does not match the next
sequence number it intends to send (or has sent), it knows not only that packets have been lost but also
which packets have been lost.
Header Length, sometimes called Data Offset, is a four-bit field indicating the length of the header in 32-
bit words. This field is necessary to identify the beginning of the data because the length of the Options
field is variable.
The Reserved field is six bits, which are always set to zero.
Flags are six 1-bit flags that are used for data flow and connection control. The flags are Urgent (URG),
Acknowledgment (ACK), Push (PSH), Reset (RST), Synchronize (SYN), and Final (FIN).
Window Size is a 16-bit field used for flow control. It specifies the number of octets, starting with the
octet indicated by the Acknowledgment Number, that the sender of the segment will accept from its peer
at the other end of the connection before the peer must stop transmitting and wait for an acknowledgment.
Checksum is 16 bits, covering both the header and the encapsulated data, allowing error detection.
Urgent Pointer is used only when the URG flag is set. The 16-bit number is added to the Sequence
Number to indicate the end of the urgent data.
Options, as the name implies, specifies options required by the sender's TCP process. The most
commonly used option is Maximum Segment Size, which informs the receiver of the largest segment the
sender is willing to accept. The remainder of the field is padded with zeros to ensure that the header
length is a multiple of 32 octets.
connection-oriented service. In other words, TCP provides the appearance of a point-to-point connection.
Point-to-point connections have two characteristics:
They have only one path to the destination. A packet entering one end of the connection cannot
become lost, because the only place to go is the other end.
Packets arrive in the same order in which they are sent.
TCP provides the appearance of a point-to-point connection, although in reality there is no such
connection. The internet layer TCP is utilizing is a connectionless, best-effort packet delivery service. The
analog of this is the postal service. If a stack of letters is given to the mail carrier for delivery, there is no
guarantee that the letters will arrive stacked in the same order, that they will all arrive on the same day, or
indeed that they will arrive at all. The postal service merely commits to making its best effort to deliver
the letters.
Likewise, the internet layer does not guarantee that all packets will take the same route, and therefore
there is no guarantee that they will arrive in the same sequence and time intervals as they were sent, or
that they will arrive at all.
On the other hand, a telephone call is connection-oriented service. Data must arrive sequentially and
reliably, or it is useless. Like a telephone call, TCP must first establish a connection, then transfer data,
and then perform a disconnect when the data transfer is complete.
TCP uses three fundamental mechanisms to accomplish a connection-oriented service on top of a
connectionless service:
Packets are labeled with sequence numbers so that the receiving TCP service can put out-ofsequence
packets into the correct sequence before delivering them to the destination application.
TCP uses a system of acknowledgments, checksums, and timers to provide reliability. A receiver
may notify a sender when it recognizes that a packet in a sequence has failed to arrive or has
errors, or a sender may assume that a packet has not arrived if the receiver does not send an
acknowledgment within a certain amount of time after transmission. In both cases, the sender will
resend the packet in question.
TCP uses a mechanism called windowing to regulate the flow of packets; windowing decreases
the chances of packets being dropped because of full buffers in the receiver.
TCP attaches a header to the application layer data; the header contains fields for the sequence numbers
and other information necessary for these mechanisms as well as fields for addresses called port numbers,
which identify the source and destination applications of the data. The application data with its attached
TCP header is then encapsulated within an IP packet for delivery. Figure 2.32 shows the fields of the TCP
header, and Figure 2.33 shows an analyzer capture of a TCP header.
Source and Destination Port are 16-bit fields that specify the source and destination applications for the
encapsulated data. Like other numbers used by TCP/IP, RFC 1700 describes all port numbers in common
and not-so-common use. A port number for an application, when coupled with the IP address of the host
the application resides on, is called a socket. A socket uniquely identifies every application in an
internetwork.
Sequence Number is a 32-bit number that identifies where the encapsulated data fits within a data stream
from the sender. For example, if the sequence number of a segment is 1343 and the segment contains 512
octets of data, the next segment should have a sequence number of 1343 + 512 + 1 = 1856.
Acknowledgment Number is a 32-bit field that identifies the sequence number the source next expects to
receive from the destination. If a host receives an acknowledgment number that does not match the next
sequence number it intends to send (or has sent), it knows not only that packets have been lost but also
which packets have been lost.
Header Length, sometimes called Data Offset, is a four-bit field indicating the length of the header in 32-
bit words. This field is necessary to identify the beginning of the data because the length of the Options
field is variable.
The Reserved field is six bits, which are always set to zero.
Flags are six 1-bit flags that are used for data flow and connection control. The flags are Urgent (URG),
Acknowledgment (ACK), Push (PSH), Reset (RST), Synchronize (SYN), and Final (FIN).
Window Size is a 16-bit field used for flow control. It specifies the number of octets, starting with the
octet indicated by the Acknowledgment Number, that the sender of the segment will accept from its peer
at the other end of the connection before the peer must stop transmitting and wait for an acknowledgment.
Checksum is 16 bits, covering both the header and the encapsulated data, allowing error detection.
Urgent Pointer is used only when the URG flag is set. The 16-bit number is added to the Sequence
Number to indicate the end of the urgent data.
Options, as the name implies, specifies options required by the sender's TCP process. The most
commonly used option is Maximum Segment Size, which informs the receiver of the largest segment the
sender is willing to accept. The remainder of the field is padded with zeros to ensure that the header
length is a multiple of 32 octets.
ICMP
The Internet Control Message Protocol, or ICMP, described in RFC 792, specifies a variety of messages
whose common purpose is to manage the internetwork. ICMP messages may be classified as either error
messages or queries and responses. Figure 2.28 shows the general ICMP packet format. The packets are
identified by type; many of the packet types have more specific types, and these are identified by the code
field. Table 2.5 lists the various ICMP packet types and their codes, as described in RFC 1700.
whose common purpose is to manage the internetwork. ICMP messages may be classified as either error
messages or queries and responses. Figure 2.28 shows the general ICMP packet format. The packets are
identified by type; many of the packet types have more specific types, and these are identified by the code
field. Table 2.5 lists the various ICMP packet types and their codes, as described in RFC 1700.
Reverse ARP
Instead of mapping a hardwar e address to a known IP address, Reverse ARP (RARP) maps an IP address
to a known hardware address. Some devices, such as diskless workstations, may not know their IP
address at startup. RARP may be programmed into firmware on these devices, allowing them to issue an
ARP Request that has their burned-in hardware address. The reply from a RARP server will supply the
appropriate IP address.
RARP is being largely supplanted by Bootstrap Protocol (BOOTP) and its extension Dynamic Host
Configuration Protocol (DHCP), both of which can provide more information than the IP address, and
which, unlike RARP, can be routed off the local data link.
to a known hardware address. Some devices, such as diskless workstations, may not know their IP
address at startup. RARP may be programmed into firmware on these devices, allowing them to issue an
ARP Request that has their burned-in hardware address. The reply from a RARP server will supply the
appropriate IP address.
RARP is being largely supplanted by Bootstrap Protocol (BOOTP) and its extension Dynamic Host
Configuration Protocol (DHCP), both of which can provide more information than the IP address, and
which, unlike RARP, can be routed off the local data link.
Gratuitous ARP
A host may occasionally issue an ARP Request with its own IP address as the target address. These ARP
Requests, known as gratuitous ARPs, have two uses:
A gratuitous ARP may be used for duplicate address checks. A device that issues an ARP Request
with its own IP address as the target and receives an ARP Reply from another device will know
that the address is a duplicate.
A gratuitous ARP may be used to advertise a new data link identifier. This use takes advantage of
the fact that when a device receives an ARP Request for an IP address that is already in its ARP
cache, the cache will be updated with the sender's new hardware address.
Many IP implementations do not use gratuitous ARP, but you should be aware of its existence.
Requests, known as gratuitous ARPs, have two uses:
A gratuitous ARP may be used for duplicate address checks. A device that issues an ARP Request
with its own IP address as the target and receives an ARP Reply from another device will know
that the address is a duplicate.
A gratuitous ARP may be used to advertise a new data link identifier. This use takes advantage of
the fact that when a device receives an ARP Request for an IP address that is already in its ARP
cache, the cache will be updated with the sender's new hardware address.
Many IP implementations do not use gratuitous ARP, but you should be aware of its existence.
Proxy ARPProxy ARP
Sometimes called promiscuous ARP and described in RFCs 925 and 1027, proxy ARP is a method by
which routers may make themselves available to hosts. For example, a host 192.168.12.5/24 needs to
send a packet to 192.168.20.101/24, but it is not configured with default gateway information and
therefore does not know how to reach a router. It may issue an ARP Request for 192.168.20.101; the local
router, receiving the request and knowing how to reach network 192.168.20.0, will issue an ARP Reply
with its own data link identifier in the hardware address field. In effect, the router has tricked the local
host into thinking that the router's interface is the interface of 192.168.20.101. All packets destined for
that address will be sent to the router.
which routers may make themselves available to hosts. For example, a host 192.168.12.5/24 needs to
send a packet to 192.168.20.101/24, but it is not configured with default gateway information and
therefore does not know how to reach a router. It may issue an ARP Request for 192.168.20.101; the local
router, receiving the request and knowing how to reach network 192.168.20.0, will issue an ARP Reply
with its own data link identifier in the hardware address field. In effect, the router has tricked the local
host into thinking that the router's interface is the interface of 192.168.20.101. All packets destined for
that address will be sent to the router.
Breaking the Octet Boundary
In the examples given so far, the subnet spaces have fallen on octet boundaries. This arrangement is not
always the most practical or efficient choice. What if, for instance, you need to subnet a class B address
across 500 data links, each with a maximum of 100 hosts? This requirement is easily met, but only by
using nine bits in the subnet field: 29 – 2 = 510 available subnets, leaving seven bits for the host field, and
27 – 2 = 126 available hosts per subnet. No other bit combination will satisfy this requirement.
Notice, also, that there is no way to subnet a class C address on an octet boundary—doing so would use
up all of the last byte, leaving no room for host bits. The subnet bits and host bits must share the last
octet, as the following example shows.
Step 1:
Figure 2.15 shows the internetwork of Figure 2.13 but with a class C address of 192.168.100.0 assigned.
There are five data links; therefore, the address must be subnetted to provide for at least five subnet
addresses. The illustration also indicates the number of hosts (including router interfaces) that need to be
addressed on each subnet. The maximum host address requirement is 25 for the two ethernets. Therefore,
the full subnetting requirements are at least five subnets and at least 25 host addresses per subnet.
Figure 2.15. The network from Figure 2.13 but with a class C mask assigned. Subnetting an entire octet will
not work here; there would be no space left for host bits.
Step 2:
Applying the 2n – 2 formula, three subnet bits and five host bits will satisfy the requirements: 23 – 2 = 6
and 25 – 2 = 30. A class C mask with three bits of subnetting is represented as 255.255.255.224 in dotted
decimal.
Step 3:
Figure 2.16 shows the derivation of the subnet bits. The subnet mask derived in step 2 is written in binary,
and the IP address is written below it. Vertical lines are drawn as markers for the subnet space, and within
this space all possible bit combinations are written by counting up from zero in binary.
Step 4:
The last step is to calculate the host addresses available to each subnet. This step is done by choosing a
subnet and, keeping the network and subnet bits unchanged, writing all bit combinations in the host space
by counting up from zero in binary.
always the most practical or efficient choice. What if, for instance, you need to subnet a class B address
across 500 data links, each with a maximum of 100 hosts? This requirement is easily met, but only by
using nine bits in the subnet field: 29 – 2 = 510 available subnets, leaving seven bits for the host field, and
27 – 2 = 126 available hosts per subnet. No other bit combination will satisfy this requirement.
Notice, also, that there is no way to subnet a class C address on an octet boundary—doing so would use
up all of the last byte, leaving no room for host bits. The subnet bits and host bits must share the last
octet, as the following example shows.
Step 1:
Figure 2.15 shows the internetwork of Figure 2.13 but with a class C address of 192.168.100.0 assigned.
There are five data links; therefore, the address must be subnetted to provide for at least five subnet
addresses. The illustration also indicates the number of hosts (including router interfaces) that need to be
addressed on each subnet. The maximum host address requirement is 25 for the two ethernets. Therefore,
the full subnetting requirements are at least five subnets and at least 25 host addresses per subnet.
Figure 2.15. The network from Figure 2.13 but with a class C mask assigned. Subnetting an entire octet will
not work here; there would be no space left for host bits.
Step 2:
Applying the 2n – 2 formula, three subnet bits and five host bits will satisfy the requirements: 23 – 2 = 6
and 25 – 2 = 30. A class C mask with three bits of subnetting is represented as 255.255.255.224 in dotted
decimal.
Step 3:
Figure 2.16 shows the derivation of the subnet bits. The subnet mask derived in step 2 is written in binary,
and the IP address is written below it. Vertical lines are drawn as markers for the subnet space, and within
this space all possible bit combinations are written by counting up from zero in binary.
Step 4:
The last step is to calculate the host addresses available to each subnet. This step is done by choosing a
subnet and, keeping the network and subnet bits unchanged, writing all bit combinations in the host space
by counting up from zero in binary.
Subscribe to:
Posts (Atom)