BUY THIS BOOK
Add to Cart

Print Book $39.99


Safari Books Online

What is this?

Add to UK Cart

Print Book £28.50

What is this?

Looking to Reprint this content?


IP Routing
IP Routing By Ravi Malhotra
January 2002
Pages: 238

Cover | Table of Contents | Colophon


Table of Contents

Chapter 1: Starting Simple
A young woman boards a commuter train in a small town in Quebec, changes trains a couple of times, and, a day later, arrives in New York City. She walks up the stairs from the platform into Grand Central Terminal, looks up above her head, and, for the first time, sees the constellations, hundreds of feet above on the ceiling.
A high school student in New Zealand downloads maps of Sri Lanka from a local (Sri Lankan) web site. The maps show the natural features, the political boundaries, the flora and fauna, rainfall, ancient kingdoms, languages, and religions. The download takes thousands of IP packets that find their way from Sri Lanka to the student's PC in New Zealand.
Just as our Canadian friend changed trains at several stations along the way, the IP packets from the Sri Lankan web site may have bounced through dozens of routers before arriving at the student's machine.
The routing of IP packets in an IP network is the set of tasks required to move an IP packet from router to router to its destination, as specified in the IP header field. This book is about the set of tasks that accomplish IP routing.
There are similarities in routing concepts between IP networks, transportation systems, and mail delivery operations. Throughout this text, we will often illustrate IP routing concepts by comparison with these other systems.
When our Canadian visitor finally picks up her bags and is ready to head out of Grand Central Terminal, she looks around for the exit signs. On one end, below a row of immense windows, is a sign saying "Vanderbilt Avenue." Below the opposite row of tall windows is a sign saying "Lexington Avenue." Under the large stone arches is a sign reading "42nd Street" (Figure 1-1).
Figure 1-1: Grand Central Terminal and the adjoining streets
Just as the streets around Grand Central Terminal are immediately accessible to any traveler, a router has directly attached networks that are immediately accessible (in other words, that do not require any specific routing mechanism to discover). Consider router
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
What Is IP Routing?
A young woman boards a commuter train in a small town in Quebec, changes trains a couple of times, and, a day later, arrives in New York City. She walks up the stairs from the platform into Grand Central Terminal, looks up above her head, and, for the first time, sees the constellations, hundreds of feet above on the ceiling.
A high school student in New Zealand downloads maps of Sri Lanka from a local (Sri Lankan) web site. The maps show the natural features, the political boundaries, the flora and fauna, rainfall, ancient kingdoms, languages, and religions. The download takes thousands of IP packets that find their way from Sri Lanka to the student's PC in New Zealand.
Just as our Canadian friend changed trains at several stations along the way, the IP packets from the Sri Lankan web site may have bounced through dozens of routers before arriving at the student's machine.
The routing of IP packets in an IP network is the set of tasks required to move an IP packet from router to router to its destination, as specified in the IP header field. This book is about the set of tasks that accomplish IP routing.
There are similarities in routing concepts between IP networks, transportation systems, and mail delivery operations. Throughout this text, we will often illustrate IP routing concepts by comparison with these other systems.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Directly Connected Networks
When our Canadian visitor finally picks up her bags and is ready to head out of Grand Central Terminal, she looks around for the exit signs. On one end, below a row of immense windows, is a sign saying "Vanderbilt Avenue." Below the opposite row of tall windows is a sign saying "Lexington Avenue." Under the large stone arches is a sign reading "42nd Street" (Figure 1-1).
Figure 1-1: Grand Central Terminal and the adjoining streets
Just as the streets around Grand Central Terminal are immediately accessible to any traveler, a router has directly attached networks that are immediately accessible (in other words, that do not require any specific routing mechanism to discover). Consider router R, in the following example. Networks 1.0.0.0, 10.1.1.0, and 10.1.2.0 are directly connected to the router:
hostname R
!
interface Ethernet0
ip address 1.1.1.1 255.0.0.0
!
interface Ethernet1
ip address 10.1.1.4 255.255.255.0
!
interface Ethernet2
ip address 10.1.2.4 255.255.255.0
...
In fact, the moment these networks are connected to the router they are visible in R's routing table. Note in the following output that the command to display the routing table is show ip route (in EXEC mode). Also note the "C" that is prepended to the entries in the routing table, indicating that the routes were discovered as directly connected to the router:
R#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

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

C    1.0.0.0/8 is directly connected, Ethernet0
     10.0.0.0/8 is subnetted, 2 subnets
C       10.1.1.0/24 is directly connected, Ethernet1
C       10.1.2.0/24 is directly connected, Ethernet2
Directly connected networks are automatically installed in the routing table if the interface to the network is up. Figure 1-2 shows router
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Static Routing
Our Canadian friend has always wanted to see the New York Public Library. She gets directions at the information booth: "Make a right on 42nd Street; walk three blocks; look for the lions in front of the library." The information-booth attendant may have no idea that the library is closed that day, or that the sidewalk on 42nd Street is blocked just then because of fire trucks and 41st Street may be the preferable route. The information booth has given the same directions to the library for the last hundred years and hopefully will for hundreds more -- the route from Grand Central Station to the library, in other words, is static.
In a similar vein, a network administrator can create a static route. So, to reach network 146.1.0.0, we may add the command:
ip route 146.1.0.0 255.255.0.0 1.1.1.2
which says to get to network 146.1.0.0/16, go to the next hop of 1.1.1.2. This specifies a fixed path to 146.1.0.0/16, as shown here, where the contents of the routing table are displayed using the EXEC command show ip route:
  R#sh ip route
  ...

1 S    146.1.0.0/16 [1/0] via 1.1.1.2
         
Even if 1.1.1.2 goes down, an alternate path -- shown via R2 in Figure 1-3 -- cannot be used until a second static route is specified:
ip route 146.1.0.0 255.255.0.0 1.1.1.3  
Figure 1-3: Router R's connectivity to 146.1.0.0
The syntax of the static route command is:
ip route network [mask] {address | interface} [distance]
where network and mask specify the IP address and mask of the destination. The next hop may be specified by its IP address or by the interface on which to send the packet. To point a static route to an interface (Ethernet0 in this case), use:
ip route 146.1.0.0 255.255.0.0 interface Ethernet0
Static routes are smart to the extent that if the next hop (interface or IP address) specified goes down, the router will remove the static route entry from the routing table.
In line 1, the static route in the routing table is accompanied by "[1/0]". This specifies the administrative distance and the metric associated with the route. We'll discuss distance and metrics in the next section.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Dynamic Routing
After the public library, our Canadian visitor jumps into a taxi to go crash at a friend's place in Brooklyn. "Go over the Brooklyn Bridge," she tells the driver. They head downtown. Suddenly, the driver slams on his brakes and makes an abrupt turn. Cars all around jam on their brakes, and pedestrians run hither and thither. "The radio said it is an hour to go over the bridge! We will take the tunnel!" the driver shouts to the back seat. This is an example of dynamic routing in a transportation system. What is dynamic routing in IP networks? Dynamic routing protocols allow each router to automatically discover one or more paths to each destination in the network. When the network topology changes, such as when new paths are added or when paths go out of service, dynamic routing protocols automatically adjust the contents of the routing table to reflect the new network topology.
Dynamic routing relies on (frequent!) updates to discover changes in network topology. In the example in Figure 1-3, when the path R3 R4 is added to the network it can be automatically discovered by a routing protocol, such as RIP, EIGRP, or OSPF.
The routing protocols in use today are based on one of two algorithms: Distance Vector or Link State. Distance Vector (DV) algorithms broadcast routing information to all neighboring routers. In other words, each router tells all of its neighbors the routes it knows. When a router receives a route (from a neighbor) that is not in its routing table, it adds the route to its table; if the router receives a route that is already in its routing table, it keeps the shorter route in its table. DV algorithms are sometimes also described as routing by rumor: bad routing information propagates just as quickly as good information. Link State algorithms operate on a different paradigm. First, each router constructs its own topological map of the entire network, based on updates from neighbors. Next, each router uses Dijkstra's algorithm to compute the shortest path to each destination in this graph. Both DV and Link State algorithms are described in further detail in the chapters that follow.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
The Routing Table
At Grand Central Terminal, a big wall lists all the destinations and their corresponding track numbers (see Figure 1-4). Passengers find their destination on this wall and then proceed to the indicated platforms. Similarly, a routing table must contain at least two pieces of information: the destination network and the next hop toward that destination. This reflects a fundamental paradigm of IP routing: hop-by-hop routing. In other words, a router does not know the full path to a destination, but only the next hop to reach the destination.
Figure 1-4: Destinations and track numbers at Grand Central Terminal
Routes are installed in the routing table as they are learned through the mechanisms we have been discussing: directly connected networks, static routes, and dynamic routing protocols. A typical routing table in a Cisco router looks like this:
   Router>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

   Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     

2       177.130.0.0/30 is subnetted, 2 subnets

   C       177.130.17.152 is directly connected, Serial1
   C       177.130.17.148 is directly connected, Serial0

3       10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
4  S       10.0.0.0/8 [1/0] via 160.4.115.74
5  S       10.254.101.0/24 [1/0] via 160.4.101.4
6       162.162.0.0/24 is subnetted, 2 subnets

   O IA    162.162.101.0 [110/3137] via 11.175.238.4, 02:16:02, Ethernet0
                       [110/3137] via 11.175.238.3, 02:16:02, Ethernet0
   O IA    162.162.253.0 [110/3127] via 11.175.238.4, 02:25:43, Ethernet0
                       [110/3127] via 11.175.238.3, 02:25:43, Ethernet0

7  O E2 192.188.106.0/24 [110/20] via 11.175.238.33, 20:49:59, Ethernet0

    ...
Note that the first few lines of the output attach a code to the source of the routing information: "C" and "S" denote "connected" and "static", respectively, as we saw earlier, "I" denotes IGRP, etc. This code is prepended to each routing entry in the routing table, signifying the source of that route.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Underlying Processes
Behind the scenes, there are three key sets of processes running on each router that make up IP routing. I have already discussed examples from each of these three sets in the preceding sections. These processes may be organized into three categories:
  1. Processes associated with the discovery of paths to various destinations in the network. These processes include dynamic routing protocols, such as RIP and IGRP, as well as static route entries. This text describes these processes in detail.
  2. Processes that maintain the IP routing table. These processes receive updates from all dynamic routing protocols running on the router as well as from static route entries. By attaching administrative distance values to each routing information source, these processes break ties when multiple sources (e.g., OSPF and static route entries) report paths to the same destination. I discussed the use of administrative distance values in the previous section. Other examples from this group of processes will be discussed in Chapter 8.
  3. Processes involved with the forwarding of IP packets. These processes are invoked when a router receives a packet to forward. The result of the match between the destination IP address in the packet and the contents of the IP routing table may be a match with one entry in the routing table, a match with more than one entry in the routing table, a match with a default route, etc. One general rule here is the rule of longest prefix match -- if there is more than one match, the match with the longest subnet mask (or prefix) wins. Further, the outcome of these processes depends on whether the router is configured for classful or classless route lookups.
Several concepts that have not yet been discussed were thrown into the preceding discussion. For instance, we have not yet talked about classful versus classless route lookups or about default routes. These concepts will be addressed in later chapters. However, this early lesson in the division of processes should help you to understand and classify concepts more quickly.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Summing Up
Dynamic routing protocols are the mainstay of IP routing. Thus, without ado, I will begin with RIP and then, moving on in order of complexity, will discuss IGRP, EIGRP, OSPF, and BGP-4.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Chapter 2: Routing Information Protocol (RIP)
RIP is the first in a family of dynamic routing protocols that we will look at closely. Dynamic routing protocols automatically compute routing tables, freeing the network administrator from the task of specifying routes to every network using static routes. Indeed, given the complexity of and number of routes in most networks, static routing usually is not even an option.
In addition to computing the "shortest" paths to all destination networks, dynamic routing protocols discover alternative (second-best) paths when a primary path fails and balance traffic over multiple paths ( load balancing).
Most dynamic routing protocols are based on one of two distributed algorithms: Distance Vector or Link State. RIP, upon which Cisco's IGRP was based, is a classic example of a DV protocol. Link State protocols include OSPF, which we will look at in a later chapter. The following section gets us started with configuring RIP.
Throughout this book, we'll be using a fictional network called TraderMary to illustrate the concepts with which we're working. TraderMary is a distributed network with nodes in New York, Chicago, and Ames, Iowa, as shown in Figure 2-1.
Figure 2-1: TraderMary's network
As a distributed process, RIP needs to be configured on every router in the network:
hostname NewYork
...
interface Ethernet0
ip address 172.16.1.1 255.255.255.0
!
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
!
interface Serial0
ip address 172.16.250.1 255.255.255.0
!
interface Serial1
ip address 172.16.251.1 255.255.255.0
...
router rip
network 172.16.0.0


hostname Chicago
...
interface Ethernet0
ip address 172.16.50.1 255.255.255.0
!
interface Serial0
ip address 172.16.250.2 255.255.255.0
!
interface Serial1
ip address 172.16.252.1 255.255.255.0
...

router rip
network 172.16.0.0


hostname Ames
...
interface Ethernet0
ip address 172.16.100.1 255.255.255.0
!
interface Serial0
ip address 172.16.252.2 255.255.255.0
!
interface Serial1
ip address 172.16.251.2 255.255.255.0
...

router rip
network 172.16.0.0
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Getting RIP Running
Throughout this book, we'll be using a fictional network called TraderMary to illustrate the concepts with which we're working. TraderMary is a distributed network with nodes in New York, Chicago, and Ames, Iowa, as shown in Figure 2-1.
Figure 2-1: TraderMary's network
As a distributed process, RIP needs to be configured on every router in the network:
hostname NewYork
...
interface Ethernet0
ip address 172.16.1.1 255.255.255.0
!
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
!
interface Serial0
ip address 172.16.250.1 255.255.255.0
!
interface Serial1
ip address 172.16.251.1 255.255.255.0
...
router rip
network 172.16.0.0


hostname Chicago
...
interface Ethernet0
ip address 172.16.50.1 255.255.255.0
!
interface Serial0
ip address 172.16.250.2 255.255.255.0
!
interface Serial1
ip address 172.16.252.1 255.255.255.0
...

router rip
network 172.16.0.0


hostname Ames
...
interface Ethernet0
ip address 172.16.100.1 255.255.255.0
!
interface Serial0
ip address 172.16.252.2 255.255.255.0
!
interface Serial1
ip address 172.16.251.2 255.255.255.0
...

router rip
network 172.16.0.0
Notice that all that is required of a network administrator to start RIP on a router is to issue the following command:
router rip
in global configuration mode and to list the networks that will be participating in the RIP process:
network 172.16.0.0
What does it mean to list the network numbers participating in RIP?
  1. Router NewYork will include directly connected 172.16.0.0 subnets in its updates to neighboring routers. For example, 172.16.1.0 will now be included in updates to the routers Chicago and Ames.
  2. NewYork will receive and process RIP updates on its 172.16.0.0 interfaces from other routers running RIP. For example, NewYork will receive RIP updates from Chicago and Ames.
  3. By exclusion, network 192.168.1.0, connected to NewYork, will not be advertised to Chicago or Ames, and NewYork will not process any RIP updates received on Ethernet0 (if there is another router on that segment).
Next, let's verify that all the routers are seeing all the
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
How RIP Finds Shortest Paths
All DV protocols essentially operate the same way: routers exchange routing updates with neighboring (directly connected) routers; the routing updates contain a list of network numbers along with the distance (metric, in routing terminology) to the networks. Each router chooses the shortest path to a destination network by comparing the distance (or metric) information it receives from its various neighbors. Let's look at this in more detail in the context of RIP.
Let's imagine that the network is cold-started -- i.e., all three routers are powered up at the same time. The first thing that happens after IOS has finished loading is that the router checks for its connected interfaces and determines which ones are up. Next, these directly connected networks are installed in each router's routing table. So, right after IOS has been loaded and before any routing updates have been exchanged, the routing table would look like this:
NewYork>sh 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

Gateway of last resort is not set

C       171.16.1.0 is directly connected, Ethernet0
C       171.16.250.0 is directly connected, Serial0
C       171.16.251.0 is directly connected, Serial1


Chicago>sh 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

Gateway of last resort is not set

C       171.16.50.0 is directly connected, Ethernet0
C       171.16.250.0 is directly connected, Serial0
C       171.16.252.0 is directly connected, Serial1


Ames>sh 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

Gateway of last resort is not set

C       171.16.100.0 is directly connected, Ethernet0
C       171.16.250.0 is directly connected, Serial0
C       171.16.252.0 is directly connected, Serial1
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Convergence
Changes -- planned and unplanned -- are normal in any network:
  • A serial link breaks
  • A new serial link is added to a network
  • A router or hub loses power or malfunctions
  • A new LAN segment is added to a network
All routers in the routing domain will not reflect these changes right away. This is because RIP routers rely on their direct neighbors for routing updates, which in turn rely on another set of neighbors. The routing process that is set into motion from the time of a network change (such as the failure of a link) until all routers correctly reflect the change is referred to as convergence. During convergence, routing connectivity between some parts of the network may be lost and, hence, an important question that is frequently asked is "How long will the network take to converge after such-and-such failure in the network?" The answer depends on a number of factors, including the network topology and the timers that have been defined for the routing protocol.
The following list defines the four timers that are key to the operation of any DV protocol, including RIP:
Update timer (default value: 30 seconds)
After sending a routing update, RIP sets the update timer to 0. When the timer expires, RIP issues another routing update. Thus, RIP updates are sent every 30 seconds.
Invalid timer (default value: 180 seconds)
Every time a router receives an update for a route, it sets the invalid timer to 0. The expiration of the invalid timer indicates that six consecutive updates were missed -- at this time, the source of the routing information is considered suspect. Even though the route is declared invalid, packets are still forwarded to the next hop specified in the routing table. Note that prior to the expiration of the invalid timer RIP would process any updates received by updating the route's timers.
Hold-down timer (default value: 180 seconds)
When the invalid timer expires, the route automatically enters the hold-down phase. During hold-down, all updates regarding the route are disregarded -- it is assumed that the network may not have converged and that there may be bad routing information circulating in the network. The hold-down timer is started when the invalid timer expires. Thus, a route goes into hold-down state when the invalid timer expires. A route may also go into hold-down state when an update is received indicating that the route has become unreachable -- this is discussed further later in this section.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Subnet Masks
Looking closely at Figure 2-2, we see that there is no field for subnet masks in RIP. Let's say that router SantaFe received an update with the following routes in the IP address field:
192.100.1.48
192.100.1.64
192.100.2.0
10.0.0.0
And let's say that SantaFe has the following configuration:
hostname SantaFe
!
interface Ethernet 0
ip address 192.100.1.17 255.255.255.240
!
interface Ethernet 1
ip address 192.100.1.33 255.255.255.240
!
router rip
network 192.100.1.0
network 192.100.2.0
How would the router associate subnet masks with these routes?
  • If the router has an interface on a network number received in an update, it would associate the same mask with the update as it does with its own interface. Consequently, RIP does not permit Variable Length Subnet Masks (VLSM).
  • If the router does not have an interface on the network number received in an update, it would assume a natural mask for the network number.
SantaFe's routing table would look like this:
SantaFe>sh ip route
...
Gateway of last resort is not set

R       10.0.0.0 [120/1] via 192.100.1.18, 0:00:11, Ethernet0
R       192.100.2.0 [120/1] via 192.100.1.18, 0:00:11, Ethernet0
     192.100.1.0/16 is subnetted, 4 subnets
C       192.100.1.16 is directly connected, Ethernet0
C       192.100.1.32 is directly connected, Ethernet1
R       192.100.1.48 [120/1] via 192.100.1.18, 0:00:11, Ethernet0
R       192.100.1.64 [120/1] via 192.100.1.18, 0:00:11, Ethernet0
SantaFe represents 192.100.1.48 and 192.100.1.64 with a 28-bit mask even though the subnet mask was not conveyed in the RIP update. SantaFe was able to deduce the 28-bit mask because it has direct interfaces on 192.100.1.0 networks. This assumption is key to why RIP does not support VLSM.
SantaFe represents 192.100.2.0 and 10.0.0.0 with their natural 24-bit and 8-bit masks, respectively, because it has no interfaces on those networks. Chapter 5 covers RIP-2, an extension of RIP that supports VLSM.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Route Summarization
Consider the router Phoenix, which connects to SantaFe and sends the RIP updates shown earlier:
192.100.1.48
192.100.1.64
192.100.2.0
10.0.0.0
Phoenix may have been configured as follows (see Figure 2-8, later in Chapter 2):
hostname Phoenix
ip subnet-zero
!
interface Ethernet 0
ip address 192.100.1.18 255.255.255.240
!
interface Ethernet 1
ip address 192.100.1.49 255.255.255.240
!
interface Ethernet 2
ip address 192.100.1.65 255.255.255.240
!
interface Ethernet 3
ip address 192.100.2.1 255.255.255.240
!
interface Ethernet 4
ip address 192.100.2.17 255.255.255.240
!
interface Ethernet 5
ip address 10.1.0.1 255.255.0.0
!
interface Ethernet 6
ip address 10.2.0.1 255.255.0.0
!
router rip
network 192.100.1.0
network 192.100.2.0
network 10.0.0.0
Phoenix did not send detailed routes for 192.100.2.0 or 10.0.0.0 when advertising to SantaFe because Phoenix summarized those routes. As I stated earlier, since Phoenix did not have interfaces on those networks, it couldn't have made sense of those routes anyway.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Default Route
A routing table need not contain all routes in the network to reach all destinations. This simplification is arrived at through the use of a default route . When a router does not have an explicit route to a destination IP address, it looks to see if it has a default route in its routing table and, if so, forwards packets for this destination via the default route.
In RIP, the default route is represented as the IP address 0.0.0.0. This is convenient because 0.0.0.0 cannot be confused with any Class A, B, or C IP address.
One situation in which default routes can be employed in an intranet is in a core network that has branch offices hanging off it (Figure 2-7).
Figure 2-7: Branch offices only need a default route
Consider the topology of this figure. Since the branch offices have only one connection (to the core), all routes to the core network and to other branches can be replaced with a single default route pointing toward the core network. This implies that the size of the routing table in the branch offices is just the number of directly connected networks plus the default route.
So, router Portland may be configured as follows:
hostname Portland
...
interface Ethernet 0
ip address 192.100.1.17 255.255.255.240
!
interface Serial 0
ip address 192.100.1.33 255.255.255.240
!
router rip
network 192.100.1.0
An examination of Portland's routing table would show the following:
Portland>sh ip route
...
Gateway of last resort is not set

     192.100.1.0/28 is subnetted, 2 subnets
C       192.100.1.16 is directly connected, Ethernet0
C       192.100.1.32 is directly connected, Serial0
R    0.0.0.0 [120/1] via 192.199.1.34, 0:00:21, Serial0
The default route may be sourced from router core1 as follows:
hostname core1
...
interface Serial 0
ip address 192.100.1.34 255.255.255.240
!
router rip
network 192.100.1.0
!
ip route 0.0.0.0 0.0.0.0 null0
Note that the default route 0.0.0.0 is automatically carried by RIP -- it is not listed in a network number statement under router rip.
The advantage of using a default in place of hundreds or thousands of more specific routes is obvious -- network bandwidth and router CPU are not tied up in routing updates. The disadvantage of using a default is that packets for destinations that are down or not even defined in the network are still forwarded to the core network.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Fine-Tuning RIP
We saw in the section on RIP metrics that the preferred path between NewYork and Ames would be the two-hop path via Chicago rather than the one-hop 56-kbps path that RIP selects. The RIP metrics can be manipulated to disfavor the one-hop path through the use of offset lists:
hostname NewYork
...
router rip
network 172.16.0.0
offset-list 10 in 2 serial1
...
access-list 10 permit 172.16.100.0 0.0.0.0

hostname Chicago
...
router rip
network 172.16.0.0

Ames#config terminal
router rip
network 172.16.0.0
offset-list 20 in 2 serial1
...
access-list 20 permit 172.16.1.0 0.0.0.0
NewYork adds 2 to the metric for the routes specified in access list 10 when learned via serial1, and Ames adds 2 to the metric for the routes specified in access list 20 when learned via serial1. The direct route over the 56-kbps link thus has a metric of 3, and the route via Chicago has a metric of 2. The new routing tables look like this:
NewYork>sh ip route
...
Gateway of last resort is not set

C       192.168.1.0 is directly connected, Ethernet1
     172.16.0.0/16 is subnetted, 6 subnets
C       172.16.1.0 is directly connected, Ethernet0
C       172.16.250.0 is directly connected, Serial0
C       172.16.251.0 is directly connected, Serial1
R       172.16.50.0 [120/1] via 172.16.250.2, 0:00:11, Serial0
R       172.16.100.0 [120/2] via 172.16.250.2, 0:00:19, Serial0
R       172.16.252.0 [120/1] via 172.16.250.2, 0:00:11, Serial0
                     [120/1] via 172.16.251.2, 0:00:19, Serial1

Ames>sh ip route
...
Gateway of last resort is not set

     172.16.0.0/16 is subnetted, 6 subnets
C       172.16.100.0 is directly connected, Ethernet0
C       172.16.252.0 is directly connected, Serial0
C       172.16.251.0 is directly connected, Serial1
R       172.16.50.0 [120/1] via 172.16.252.1, 0:00:21, Serial0
R       172.16.1.0 [120/2] via 172.16.251.1, 0:00:09, Serial1
R       172.16.250.0 [120/1] via 172.16.252.1, 0:00:21, Serial0
                     [120/1] via 172.16.251.1, 0:00:09, Serial1
The syntax for offset lists is as follows:
offset-list {access-list} {in | out}
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Summing Up
RIP is a relatively simple protocol, easy to configure and very reliable. The robustness of RIP is evident from the fact that various implementations of RIP differ in details and yet work well together. A standard for RIP wasn't put forth until 1988 (by Charles Hedrick, in RFC 1058). Small, homogeneous networks are a good match for RIP. However, as networks grow, other routing protocols may look more attractive for several reasons:
  • The RIP metric does not account for link bandwidth or delay.
  • The exchange of full routing updates every 30 seconds does not scale for large networks -- the overhead of generating and processing all routes can be high.
  • RIP convergence times can be too long.
  • Subnet mask information is not exchanged in RIP updates, so Variable Length Subnet Masks are not supported.
  • The RIP metric restricts the network diameter to 15 hops.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Chapter 3: Interior Gateway Routing Protocol (IGRP)
The second Distance Vector protocol that we will examine is the Interior Gateway Routing Protocol, or IGRP. IGRP and RIP are close cousins: both are based on the Bellman-Ford Distance Vector (DV) algorithms. DV algorithms propagate routing information from neighbor to neighbor; if a router receives the same route from multiple neighbors, it chooses the route with the lowest metric. All DV protocols need robust strategies to cope with bad routing information. Bad routes can linger in a network when information about the loss of a route does not reach some router (for instance, because of the loss of a route update packet), which then inserts the bad route back into the network. IGRP uses the same convergence strategies as RIP: triggered updates, route hold-downs, split horizon, and poison reverse.
IGRP has been widely deployed in small to mid-sized networks because it can be configured with the same ease as RIP, but its metric represents bandwidth and delay, in addition to hop count. The ability to discriminate between paths based on bandwidth and delay is a major improvement over RIP.
IGRP is a Cisco proprietary protocol; other router vendors do not support IGRP. Keep this in mind if you are planning a multivendor router environment.
The following section gets us started with configuring IGRP.
TraderMary's network, shown in Figure 3-1, can be configured to run IGRP as follows.
Figure 3-1: TraderMary's network
Like RIP, IGRP is a distributed protocol that needs to be configured on every router in the network:
hostname NewYork
...
interface Ethernet0
ip address 172.16.1.1 255.255.255.0
!
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
!
interface Serial0
description New York to Chicago link
ip address 172.16.250.1 255.255.255.0
!
interface Serial1
description New York to Ames link
ip address 172.16.251.1 255.255.255.0
...
router igrp 10
network 172.16.0.0


hostname Chicago
...
interface Ethernet0
ip address 172.16.50.1 255.255.255.0
!
interface Serial0
ip address 172.16.250.2 255.255.255.0
!
interface Serial1
ip address 172.16.252.1 255.255.255.0
...
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Getting IGRP Running
TraderMary's network, shown in Figure 3-1, can be configured to run IGRP as follows.
Figure 3-1: TraderMary's network
Like RIP, IGRP is a distributed protocol that needs to be configured on every router in the network:
hostname NewYork
...
interface Ethernet0
ip address 172.16.1.1 255.255.255.0
!
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
!
interface Serial0
description New York to Chicago link
ip address 172.16.250.1 255.255.255.0
!
interface Serial1
description New York to Ames link
ip address 172.16.251.1 255.255.255.0
...
router igrp 10
network 172.16.0.0


hostname Chicago
...
interface Ethernet0
ip address 172.16.50.1 255.255.255.0
!
interface Serial0
ip address 172.16.250.2 255.255.255.0
!
interface Serial1
ip address 172.16.252.1 255.255.255.0
...

router igrp 10
network 172.16.0.0


hostname Ames
...
interface Ethernet0
ip address 172.16.100.1 255.255.255.0
!
interface Serial0
ip address 172.16.252.2 255.255.255.0
!
interface Serial1
ip address 172.16.251.2 255.255.255.0
...

router igrp 10
network 172.16.0.0
         
The syntax of the IGRP command is:
router igrp {process-id | autonomous-system-number}
in global configuration mode. The networks that will be participating in the IGRP process are then listed:
network 172.16.0.0
What does it mean to list the network numbers participating in IGRP?
  1. NewYork will include directly connected 172.16.0.0 subnets in its updates to neighboring routers. For example, 172.16.1.0 will now be included in updates to the routers Chicago and Ames.
  2. NewYork will receive and process IGRP updates on its 172.16.0.0 interfaces from other routers running IGRP 10. For example, NewYork will receive IGRP updates from Chicago and Ames.
  3. By exclusion, network 192.168.1.0, connected to NewYork, will not be advertised to Chicago or Ames, and NewYork will not process any IGRP updates received on Ethernet0 (if there is another router on that segment).
Next, let's verify that all the routers are seeing all the 172.16.0.0 subnets. Here is NewYork
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
How IGRP Works
Since IGRP is such a close cousin of RIP, we will not repeat the details of how DV algorithms work, how updates are sent, and how route convergence is achieved. However, because IGRP employs a much more comprehensive metric, I'll discuss the IGRP metric in detail. I'll begin this discussion with AS numbers.
Each IGRP process requires an autonomous system number:
router igrp autonomous-system-number
            
The AS number allows the network administrator to define routing domains; routers within a domain exchange IGRP routing updates with each other but not with routers in different domains. Note that in the context of IGRP the terms "autonomous system number" and "process ID" are often used interchangeably. Since the IGRP autonomous system number is not advertised to other domains, network engineers often cook up arbitrary process IDs for their IGRP domains.
Let's say that TraderMary created a subsidiary in Africa and that the new topology is as shown in Figure 3-2.
Figure 3-2: TraderMary's U.S. and African networks
Note that IGRP is running in the U.S. and Africa with AS numbers of 10 and 20, respectively. The U.S. routers now exchange IGRP routes with each other, as before, and the routers Nairobi and Casablanca exchange IGRP updates with each other. IGRP updates are processed only between routers running the same AS number, so NewYork and Nairobi do not exchange IGRP updates with each other. We will see this in more detail later, when we look at the format of an IGRP update.
The advantage of creating small domains with unique AS numbers is that a routing problem in one domain is not likely to ripple into another domain running a different AS number. So, for example, let's say that a network engineer in Africa configured network 172.16.50.0 on Casablanca (172.16.50.0 already exists on Chicago). The U.S. network would not be disrupted because of this duplicate address. In another situation, an IGRP bug in IOS on Chicago could disrupt routing in the U.S., but Nairobi and Casablanca would not be affected by this problem in the AS 10.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Speeding Up Convergence
Like RIP, IGRP implements hold-downs, split horizon, triggered updates, and poison reverse (see Chapter 2 for details on these convergence methods). Like RIP, IGRP also maintains an update timer, an invalid timer, a hold-down timer, and a flush timer for every route in the routing table:
Update timer (default value: 90 seconds)
After sending a routing update, IGRP sets the update timer to 0. When the timer expires, IGRP issues another routing update.
Invalid timer (default value: 270 seconds)
Every time a router receives an update for a route, it sets the invalid timer to 0. The expiration of the invalid timer indicates that the source of the routing information is suspect. Even though the route is declared invalid, packets are still forwarded to the next hop specified in the routing table. Note that prior to the expiration of the invalid timer, IGRP would process any updates received by updating the route's timers.
Hold-down timer (default value: 280 seconds)
When the invalid timer expires, the route automatically enters the hold-down phase. During hold-down all updates regarding the route are disregarded -- it is assumed that the network may not have converged and that there may be bad routing information circulating in the network. The hold-down timer is started when the invalid timer expires.
Flush timer (default value: 630 seconds)
Every time a router receives an update for a route, it sets the flush timer to 0. When the flush timer expires, the route is removed from the routing table and the router is ready to receive a new route update. Note that the flush timer overrides the hold-down timer.
IGRP timers can be modified to allow faster convergence. The configuration:
router igrp 10
timers basic 30 90 90 180
would generate IGRP updates every 30 seconds, mark a route invalid in 90 seconds, keep the route in hold-down for 90 seconds, and flush the route in 180 seconds.
However, IGRP timers should not be modified without a detailed understanding of route convergence in Distance Vector protocols (see Chapter 2). Selecting too short a hold-down period, for example, may cause bad routing information to persist in a network. Selecting too long a hold-down period would increase the time it takes to learn a route via a different path after a failure.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Route Summarization
IGRP summarizes network numbers when crossing a major network-number boundary, just like RIP does. Route summarization reduces the number of routes that need to be exchanged, processed, and stored.
However, route summarization does not work well in discontiguous networks. Consider the discontiguous network in Figure 3-5. Router X will receive advertisements for 10.0.0.0 from both routers A and B. If X sent packets with the destination 10.1.1.1 to B, the packet would be lost -- B would have to drop the packet because it would not have a route for 10.1.1.1 in its table. Likewise, if X sent packets with the destination 10.2.1.1 to A, the packet would be lost -- A would have to drop the packet because it would not have a route for 10.2.1.1.
Figure 3-5: Contiguous and discontiguous networks
Both IGRP and RIP networks must be designed in contiguous blocks of major network numbers.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Default Routes
IGRP tracks default routes in the exterior section of its routing updates. A router receiving 10.0.0.0 in the exterior section of a routing update would mark 10.0.0.0 as a default route and install its next hop to 10.0.0.0 as the gateway of last resort . Consider the network in Figure 3-6 as an example in which a core router connects to several branch routers in remote sites.
Figure 3-6: Branch offices only need a default route
The core router is configured as follows:
   hostname core1
   !
   interface Ethernet0
    ip address 192.168.1.1 255.255.255.0
   ...
   interface Serial0
   ip address 172.16.245.1 255.255.255.0
   ...
   router igrp 10
3   redistribute static                             
    network 172.16.0.0
4   default-metric 10000 100 255 1 1500             
   !
   no ip classless
5  ip default-network 10.0.0.0
6  ip route 10.0.0.0 255.0.0.0 Null0
         
The branch router is configured as follows:
hostname branch1
...
interface Serial0
ip address 172.16.245.2 255.255.255.0
...
router igrp 10
redistribute static
network 172.16.0.0
!
no ip classless
An examination of branch1's routing table would show:
branch1#sh 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

Gateway of last resort is 172.16.245.1 to network 10.0.0.0

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.245.0 is directly connected, Serial0
I*   10.0.0.0/8 [100/8576] via 172.16.245.1, 00:00:26, Serial0
         
Note that network 10.0.0.0 has been flagged as a default route (*). To ensure that the default route works, let's do a test to see if branch1 can ping 192.168.1.1, even though 192.168.1.0 is not in branch1's routing table:
branch1#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/50/80 ms
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Classful Route Lookups
Router branch1 is configured to perform classful route lookups (see line 7 in the previous code block). A classful route lookup works as follows:
  1. Upon receiving a packet, the router first determines the major network number for the destination. If the destination IP address is 172.16.1.1, the major network number is 172.16.0.0. If the destination IP address is 192.168.1.1, the major network number is 192.168.1.0.
  2. Next, the router checks to see if this major network number exists in the routing table. If the major network number exists in the routing table (172.16.0.0 does), the router checks for the destination's subnet. In our example, branch1 would look for the subnet 172.16.1.0. If this subnet exists in the table, the packet will be forwarded to the next hop specified in the table. If the subnet does not exist in the table, the packet will be dropped.
  3. If the major network number does not exist in the routing table, the router looks for a default route. If a default route exists, the packet will be forwarded as specified by the default route. If there is no default route in the routing table, the packet will be dropped.
Router branch1 is able to ping 192.168.1.1 as a consequence of rule 3:
branch1#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/50/80 ms
However, let's define a new subnet of 172.16.0.0 on core1 (and then block the advertisement of this subnet with an access list on lines 8 and 9) and see if branch1 can reach it using a default route:
   hostname core1
   !
   interface Ethernet0
    ip address 192.168.1.1 255.255.255.0
   !
   interface Ethernet1
   ip address 172.16.10.1 255.255.255.0
   ...
   interface Serial0
   ip address 172.16.245.1 255.255.255.0
   ...
   router igrp 10
    redistribute static
    network 172.16.0.0
    default-metric 10000 100 255 1 1500
    distribute-list 1 out serial0
   !
   no ip classless
   ip default-network 10.0.0.0
   ip route 10.0.0.0 255.0.0.0 Null0
   !
8  
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Summing Up
IGRP has the robustness of RIP but adds a major new feature -- route metrics based on bandwidth and delay. This feature -- along with the ease with which it can be configured and deployed -- has made IGRP tremendously popular for small to mid-sized networks. However, IGRP does not address several problems that also affect RIP:
  • The exchange of full routing updates does not scale for large networks -- the overhead of generating and processing all routes in the AS can be high.
  • IGRP convergence times can be too long.
  • Subnet mask information is not exchanged in IGRP updates, so Variable Length Subnet Masks (VLSM) and discontiguous address spaces are not supported.
These issues may be too significant to overlook in large IP networks in which address-space conservation may necessitate VLSM, full route updates would be so large that they would consume significant network resources (serial links to branches tend to saturate quickly, and smaller routers may consume a lot of CPU power just to process all the routes at every update interval), and the convergence times may be too long because of the network diameter. Even small to mid-sized networks may choose not to implement IGRP if convergence time is an issue.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Chapter 4: Enhanced Interior Gateway Routing Protocol (EIGRP)
The Enhanced Interior Gateway Routing Protocol (EIGRP), referred to as an advanced Distance Vector protocol, offers radical improvements over IGRP. Traditional DV protocols such as RIP and IGRP exchange periodic routing updates with all their neighbors, saving the best distance (or metric) and the vector (or next hop) for each destination. EIGRP differs in that it saves not only the best (least-cost) route but all routes, allowing convergence to be much quicker. Further, EIGRP updates are sent only upon a network topology change; updates are not periodic.
Getting EIGRP running is not much more difficult than getting IGRP running, as we will see in Section 4.1.
Even though EIGRP offers radical improvements over IGRP, there are similarities between the protocols. Like IGRP, EIGRP bases its metric on bandwidth, delay, reliability, load, and MTU (see Section 4.2).
The fast convergence feature in EIGRP is due to the Diffusing Update Algorithm (DUAL), discussed in Section 4.3.
EIGRP updates carry subnet mask information. This allows EIGRP to summarize routes on arbitrary bit boundaries, support classless route lookups, and allow the support of Variable Length Subnet Masks (VLSM). This is discussed in Section 4.4 and Section 4.5.
Setting up default routes in EIGRP is discussed in Section 4.6.
Troubleshooting EIGRP can be tricky. This chapter ends with some troubleshooting tips in Section 4.7.
EIGRP is a Cisco proprietary protocol; other router vendors do not support EIGRP. Keep this in mind if you are planning a multivendor router environment.
This chapter focuses on EIGRP's enhancements over IGRP: the use of DUAL; and the use of subnet masks in updates, which in turn allow VLSM and route summarization at arbitrary bit boundaries. This chapter does not cover router metrics in detail or the concept of parallel paths. Those concepts have not changed much in EIGRP. I assume that the reader is familiar with IGRP.
TraderMary's network, shown in Figure 4-1, can be configured to run EIGRP as follows.
Figure 4-1: TraderMary's network
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Getting EIGRP Running
TraderMary's network, shown in Figure 4-1, can be configured to run EIGRP as follows.
Figure 4-1: TraderMary's network
Just like RIP and IGRP, EIGRP is a distributed protocol that needs to be configured on every router in the network:
hostname NewYork
...
interface Ethernet0
ip address 172.16.1.1 255.255.255.0
!
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
!
interface Serial0
description New York to Chicago link
ip address 172.16.250.1 255.255.255.0
!
interface Serial1
description New York to Ames link
bandwidth 56
ip address 172.16.251.1 255.255.255.0
...
router eigrp 10
network 172.16.0.0


hostname Chicago
...
interface Ethernet0
ip address 172.16.50.1 255.255.255.0
!
interface Serial0
description Chicago to New York link
ip address 172.16.250.2 255.255.255.0
!
interface Serial1
description Chicago to Ames link
ip address 172.16.252.1 255.255.255.0
...

router eigrp 10
network 172.16.0.0


hostname Ames
...
interface Ethernet0
ip address 172.16.100.1 255.255.255.0
!
interface Serial0
description Ames to Chicago link
ip address 172.16.252.2 255.255.255.0
!
interface Serial1
description Ames to New York link
bandwidth 56
ip address 172.16.251.2 255.255.255.0
...

router eigrp 10
network 172.16.0.0
         
The syntax of the EIGRP command is:
router eigrp autonomous-system-number
         
in global configuration mode. The networks that will be participating in the EIGRP process are then listed:
network 172.16.0.0
What does it mean to list the network numbers participating in EIGRP?
  1. Router NewYork will include directly connected 172.16.0.0 subnets in its updates to neighboring routers. For example, 172.16.1.0 will now be included in updates to the routers Chicago and Ames.
  2. NewYork will receive and process EIGRP updates on its 172.16.0.0 interfaces from other routers running EIGRP 10. For example, NewYork will receive EIGRP updates from Chicago and Ames.
  3. By exclusion, network 192.168.1.0, connected to NewYork, will not be advertised to Chicago or Ames, and NewYork will not process any EIGRP updates received on
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
EIGRP Metric
The EIGRP composite metric is computed exactly as the IGRP metric is and then multiplied by 256. Thus, the default expression for the EIGRP composite metric is:
Metric = [BandW +Delay]x 256
where BandW and Delay are computed exactly as for IGRP (see Section 3.2.2 in Chapter 3). In summary, BandW is computed by taking the smallest bandwidth (expressed in kbits/s) from all outgoing interfaces to the destination (including the destination) and dividing 10,000,000 by this number (the smallest bandwidth), and Delay is the sum of all the delay values to the destination network (expressed in tens of microseconds).
Further, note that the total delay (line 6), minimum bandwidth (line 6), reliability (line 7), minimum MTU (line 7), and load (line 8) for a path, which are used to compute the composite metric (line 5), are shown as output of the show ip route destination-network-number command:
   NewYork#sh ip route 172.16.50.0
   Routing entry for 172.16.50.0 255.255.255.0
     Known via "eigrp 10", distance 90, metric 2195456, type internal
     Redistributing via eigrp 10
     Last update from 172.16.250.2 on Serial0, 00:00:21 ago