 |
|
|
|
|
|
The lecture is to be used only in conjunction with the required text for this course: "Cisco CCNA Exam #640-607 Certification Guide", by Wendell Odom, Cisco Press. The copyright of the material and illustrations is held by Wendell Odom.
Lesson 1:
Routing Protocols and the
Configuration of RIP and IGRP
Distance Vector Routing Protocols
Terminology relating to routing protocols is often misunderstood; the first term that needs to be defined is routing protocol. This term can be contrasted with routed protocol. Three definitions follow:
• A routing protocol fills the routing table with routing information. Examples include RIP and IGRP.
• A routed protocol is a protocol that has an OSI Layer 3 equivalent specification, which defines logical addressing and routing. The packets defined by the network layer (Layer 3) portion of these protocols can be routed. Examples of protocols include IP and IPX.
• The term routing type might appear and refers to the type of routing protocol—for instance, link-state. IP routing protocols fill the IP routing table with valid, (hopefully) loop-free routes. (As you will see later, distance vector routing protocols have many features that prevent loops, none of which guarantees to prevent loops.) Each route includes a subnet number, the interface out which to forward packets so that they are delivered to that subnet, and the IP address of the next router that should receive packets destined for that subnet (if needed). An analogy to routing is the process a stubborn man might use when taking a trip to somewhere he has never been. He might look for a road sign referring to the destination town and pointing him to the next turn.
By repeating the process at each intersection, he should eventually make it to the correct town, at last. Of course, if a routing loop occurs (in other words, he’s lost!) and he stubbornly never asks for directions, he could loop forever—or at least until he’s out of gas!
Before discussing the underlying logic, the goals of a routing protocol should be considered. The goals documented in the following list are common for any IP routing protocol, regardless of its underlying logic type:
• To dynamically learn and fill the routing table with a route to all subnets in the network.
• If more than one route to a subnet is available, to place the best route in the routing table.
• To notice when routes in the table are no longer valid, and to remove those routes from the routing table.
• If a route is removed from the routing table and another route through another neighboring router is available, to add the route to the routing table. (Many people view this goal and the previous one as a single goal.)
• To add new routes, or to replace lost routes with the best currently available route, as quickly as possible. The time between losing the route and finding a working replacement route is called convergence time.
• To prevent routing loops.
Comparing Routing Protocols
Several routing protocols for TCP/IP exist. IP’s long history and continued popularity have called for the specification and creation of several different competing options. So, classifying IP routing protocols based on their differences is useful—and also is a fair topic for exam questions.
One major classification of IP routing protocols is whether they are optimized for creating routes inside one organization or routes between two or more interconnected organizations.
Exterior routing protocols are optimized for use between routers from different organizations. Border Gateway Protocol (BGP) and Exterior Gateway Protocol (EGP) are the two options for exterior routing protocols; BGP is the most popular and the more recently developed of the two. (EGP is not technically a routing protocol but is a "reachability" protocol; it is obsolete.) The CCNA exam focuses on interior routing protocols. If you are interested in pursuing CCIE-ISP, CCIE-R/S, or CCNP certification, understanding exterior routing protocols is very important. An excellent learning tool and reference to IP routing and routing protocols is the Cisco Press book Routing TCP/IP, Volume I, by Jeff Doyle. Routing protocol is the term used to describe the programs and processes used to exchange and learn routing information. Other documents call these same programs and processes routing algorithms. Personally, I prefer the term type of routing protocol, yet a third term for the same concept. Terminology counts; for the CCNA exam, remember all three terms.
One type of routing protocol is the link-state protocol. Link-state protocols use a topological database that is created on each router; entries describing each router, each router’s attached links, and each router’s neighboring routers are included in the database. Each router builds a complete map of the network. The topology database is processed by an algorithm called the Dijkstra shortest path first (SPF) algorithm for choosing the best routes to add to the routing table. This detailed topology information along with the Dijkstra algorithm helps link-state protocols avoid loops and converge quickly.
A second type of routing protocol is the balanced hybrid protocol. Balanced hybrid is a term created by Cisco to describe the inner workings of EIGRP, which uses the Diffusing Update Algorithm (DUAL) for calculating routes. A balanced hybrid protocol exchanges more topology information than does a distance vector routing protocol, but it does not require full topology and does not require the computationally intensive Dijkstra algorithm for computing loop-free routes.
Distance vector is the other type of routing protocol and will be discussed in much detail in the next subsection. Several different implementations of distance vector and link-state routing protocols could be covered on the CCNA exam; only RIP Version 1 (RIP-1) and IGRP should be covered in-depth.
RIP-1 and IGRP are similar in most details, with the big exception being that IGRP uses a much more robust metric. Both RIP-1 and IGRP are covered in more detail later in this chapter. Some routing protocols are less likely to be covered on the CCNA exam, including RIP Version 2 (RIP-2). RIP-2 includes many improvements over RIP-1. Most notably, the subnet mask associated with each advertised route is included in the routing update. The mask allows routers to use features such as variable-length subnet masks (VLSMs) and route summarization, both features sure to be covered on the CCNP exams.
Enhanced IGRP (EIGRP) is another balanced hybrid routing protocol, but it uses more advanced features to avoid loops and speed convergence. (EIGRP is also unlikely to be covered on the CCNA exam but is fair game for the CCNP.) The underlying algorithm is called the Diffusing Update Algorithm (DUAL). DUAL defines a method for each router to not only calculate the best current route to each subnet, but to also calculate alternative routes that could be used if the current route fails. An alternate route, using what DUAL defines as a neighboring feasible successor route, is guaranteed to be loop-free, so convergence can happen quickly.
EIGRP also transmits the subnet mask for each routing entry. Therefore, features such as VLSM and route summarization are easily supported. Open Shortest Path First (OSPF) is a link-state routing protocol used for IP. Link-state protocols avoid routing loops by transmitting and keeping more detailed topology information, which allows the protocol to use calculations that prevent loops. With OSPF, the subnet mask information is also transmitted, allowing features such as VLSM and route summarization.
Table 6-2 lists interior IP routing protocols and their types. A column referring to whether the routing protocol includes subnet mask information in the routing updates is listed for future reference.
Table 6-2 Interior IP Routing Protocols and Types
Distance Vector Routing
CCNAs deal with routing problems on a daily basis; some of these problems are a result of the logic behind distance vector routing protocols. To understand what distance vector routing means is to understand how a routing protocol accomplishes the following goals:
• Learning routing information
• Noticing failed routes
• Adding the current best route after one has failed
• Preventing loops
The following list summarizes the behavior of a router that uses the RIP-1 or IGRP distance vector routing protocols:
• Directly connected subnets are already known by the router; these routes are advertised to neighboring routers.
• Routing updates are broadcast (or multicast, in many cases). This is so that all neighboring routers can learn routes via the single broadcast or multicast update.
• Routing updates are listened for so that this router can learn new routes.
• A metric describes each route in the update. The metric describes how good the route is; if multiple routes to the same subnet are learned, the lower metric route is used.
• Topology information in routing updates includes, at a minimum, the subnet and metric information.
• Periodic updates are expected to be received from neighboring routers at a specified interval. Failure to receive updates from a neighbor in a timely manner results in the removal of the routes previously learned from that neighbor.
• A route learned from a neighboring router is assumed to be through that router.
• A failed route is advertised for a time, with a metric that implies that the network is "infinite" distance. This route is considered unusable. Infinity is defined by each routing protocol to be some very large metric value. For instance, RIP’s infinite metric is 16 because RIP’s maximum valid hop count is 15.
Figure 6-2 demonstrates how Router A’s directly connected subnets are advertised to Router B. In this case, Router A advertises two directly connected routes.
Figure 6-2 Router A Advertising Directly Connected Routes
Table 6-3 shows the resulting routing table on Router B.
Table 6-3 Router B Routing Table, After Receiving Update in Figure 6-2
The two directly connected routes on Router B do not have a Next Router field because packets to those subnets can be sent directly to hosts in those subnets. The Next Router field for the routes learned from Router A show Router A’s IP address as the next router, as described previously. (A route learned from a neighboring router is assumed to be through that router.)
Router B typically learns Router A’s IP address for these routes by simply looking at the source IP address of the routing update. Metric values are cumulative. A subnet learned via an update from a neighbor is advertised, but with a higher metric. For example, an update received on serial 1 lists a subnet with metric 5. Before advertising that subnet in an update sent out some other interface, the router adds to the metric, based on a value associated with serial 1. With RIP, because hop count is the metric, the advertised metric would be 6, in this case. Figure 6-3 and Table 6-4 illustrate the concept.
Figure 6-3 Router A Advertising Routes Learned from Router C
Table 6-4 Router B Routing Table, After Receiving Update in Figure 6-3
Figure 6-3 demonstrates the seven distance vector routing protocol behaviors previously listed, with the exception of periodic updates and failed routes. The metric describing subnet 162.11.10.0, received from Router C, was incremented by 1 before advertising about that subnet to Router B. This metric value represents hop count, which is used by RIP. (IGRP uses a different metric, which will be discussed later.) The route to 162.11.10.0 that Router B adds to its routing table refers to Router A as the next router because Router B learned the route from Router A; Router B knows nothing about the network topology on the "other side" of Router A.
Distance vector routing protocols doubt the validity of routing information that they learned from a neighboring router if that neighboring router quits sending routing updates. Periodic routing updates are sent by each router. A routing update timer determines how often the updates are sent. The timer should be equal on all routers, although the timers can be configured for different values, causing unpredictable (and bad) results. The absence of routing updates for a preset number of routing timer intervals results in the removal of the routes previously learned from the router that has become silent.
Several issues exist related to loops and convergence required when using distance vector routing protocols. Most of the issues with distance vector routing protocols arise when working with networks with multiple paths because loops are very difficult when there is only one path possible to get to a subnet. Table 6-5 summarizes these issues and lists the names of the solutions, which are explained in the upcoming text.
Table 6-5 Issues Relating to Distance Vector Routing Protocols in Networks with Multiple Paths
Issues When Multiple Routes to the Same Subnet Exist
The first issue is straightforward and is described more easily with the example in Figure 6-4 and Tables 6-6 and 6-7.
Figure 6-4 Routers A and C Advertising to Router B
NOTE The routing updates in Figure 6-4 show only the information needed for the point being made in this example; other routes that would normally be in the routing update are omitted.
Table 6-6 Router B Routing Table, with Two Routes to Same Subnet While Router B Serial 1 Is Down
Table 6-7 Router B Routing Table, with Two Routes to Same Subnet After Router B Serial 1 Is Up
Table 6-6 shows B’s routing table before B’s S1 interface came up; Table 6-7 shows B’s routing table after S1 is up. One route was changed, one route was added, and one route that could have been changed was not. The route to 162.11.10.0 was changed because the metric for the route through Router C (metric 1) is smaller than the one from Router A (metric 2). The route to directly connected subnet 162.11.6.0 was added, but not because of this distance vector routing protocol; it was added by Router B because it is a directly connected subnet and because that interface is now up. Finally, the route to subnet 162.11.9.0 is advertised with metric 1 by both Routers A and C. In this case, the route that was already in the table is left in the table, which is a reasonable choice. The choice of just placing one of the two equal metric routes in the table is an implementation decision. Cisco routers can include up to six equal-cost routes in the routing table instead of the choice shown in this example.
Split Horizon, Holddown, and Route Poisoning
Routing loops can occur when using distance vector routing protocols because bad routing information can be propagated. Split horizon is the popular solution to the problem and works very well in most topologies. Figure 6-5 shows an example of this problem.
NOTE The routing updates in Figure 6-5 show only the information needed for the point being made in this example; other routes that would normally be in the routing update are omitted.
Figure 6-5 Advertisements Passing on Serial Link for Subnet 162.11.7.0
In Figure 6-5, the routing updates are sent periodically. There is no requirement to make the updates flow from C and B at the same time; however, in this case, B and C are sending updates at the same instant in time. This is not a problem until B advertises an infinite-distance (metric) route to 162.11.7.0 because the subnet just failed. However, the update from C passes the update from B on the serial link. Table 6-8 and Table 6-9 show the resulting routing table entries, with a reference to the metric values.Table 6-8 Router B Routing Table, After Subnet 162.11.7.0 Failed and Update from Router C Is Received
Table 6-9 Router C Routing Table, After Subnet 162.11.7.0 Failed and Update from Router B Is Received
NOTE In this chapter, the value 16 is used to represent an infinite metric. RIP uses 16 to represent infinite; IGRP uses a delay value of more than 4 billion to imply an infinite distance route. Now Router C has an infinite distance route, but Router B will send packets to 162.11.7.0 through Router C. Router C claimed to have a metric 2 route to 162.11.7.0 at the same time that Router C was receiving the update that the route to 162.11.7.0 was no longer valid. (Note: Infinity is shown as the value 16 in Table 6-9, which is RIP’s value for infinity.) So, Router B thinks 162.11.7.0 is reachable through Router C, and Router C thinks 162.11.7.0 is unreachable. The process repeats itself with the next routing update, except Router B advertises metric 3 and Router C advertises an infinite (bad) metric for subnet 162.11.7.0. This will continue until both numbers reach infinity.For those less patient, each distance vector routing protocol implementation sets a metric value for which the number is considered to be infinite. For example, 16 is infinite for RIP, and 4,294,967,295 is infinite for IGRP.
Split horizon is the solution to the counting to infinity problem, in this case. Split horizon includes two related concepts that affect what routes are included in a routing update:
• An update does not include the subnet of the interface out which the update is sent.
• All routes with outgoing interface of interface x are not included in updates sent out that same interface x.
For instance, in Figure 6-6, B’s route to subnet 162.11.10.0 points out Serial1, so its update sent out Serial1 does not advertise that subnet. B’s update also does not include subnet 162.11.9.0, presumably because B’s route to that subnet also points out Serial1. However, because B’s route to 162.11.5.0 points out Serial0 to Router A, B advertises about that subnet out Serial1. The term split horizon with poison reverse, or simply poison reverse, is a similar feature to split horizon. Instead of not advertising a route out the same interface in which the route was learned, poison reverse means that the routes are advertised but with a poison (infinite) metric. In other words, in Figure 6-6, Router B would also advertise routes to 162.11.6.0, 162.11.9.0, and 162.11.10.0, all with infinite metric.
Split horizon defeats the counting to infinity problem over a single link. However, counting to infinity can occur in redundant networks (networks with multiple paths) even with split horizon enabled. The holddown timer is part of a solution to the counting to infinity problem when networks have multiple paths to many subnets. Split horizon does not defeat the counting to infinity problem in all topologies. An additional solution is required, which includes a holddown timer and a routing update feature called route poisoning. Figure 6-7 shows an example topology showing counting to infinity.
Figure 6-6 Split Horizon Enabled, with Poison Reverse
Figure 6-7 Counting to Infinity
For the scenario in Figure 6-7, subnet 162.11.10.0 fails; Router C sends updates to Router B and Router A, as shown in Step 1 of Figure 6-7. Router A happens to send its next update out its S1 interface to Router B just before it hears the bad news about 162.11.10.0 from Router C, as denoted as Step 2 in Figure 6-7. Table 6-10 shows the result of these two updates entering Router B.Table 6-10 Router B Routing Table After Updates in Figure 6-7 Are Received
Router B now thinks it has a valid route to 162.11.10.0, pointing back to Router A. On B’s next update, the router does not advertise subnet 162.11.10.0 out S0 due to split horizon rules, but Router B advertises 162.11.10.0 to Router C out Serial1. Router C incorrectly believes that the route to 162.11.10.0 exists through Router B; Router C also tells Router A that it has a route to 162.11.10.0. So, counting to infinity occurs.The solution is to enable a holddown timer. In the example in Figure 6-7, Router B’s original route to 162.11.10.0 pointed to Router C. It was then changed to point to Router A. Holddown would require Router B to wait for a period to learn new routes after an old one has failed, in this case ignoring the metric 2 route learned from Router A.
NOTE Holddown is defined as follows: When learning about a failed route, ignore any new information about that subnet for a time equal to the holddown timer.
With holddown enabled, Router B would not believe the metric 2 route learned in Step 1 of Figure 6-7. During the same time, Routers C and A both would be advertising infinite metric routes to 162.11.10.0 to Router B, which also would quickly be receiving only routing updates for 162.11.10.0 with an infinite metric. (Infinite is a term used to signify the concept, not the actual value. Each routing protocol can—and typically does—define a maximum usable metric value, with any number over that being considered infinite.)
Route poisoning is another method to help avoid loops and speed convergence. Route poisoning is different than poison reverse—unfortunately, some well-known TCP/IP references have used these terms in different ways, making things quite a mess. (The typical description in the Cisco context follows.) When a distance vector routing protocol notices that a particular route is no longer valid, it has two choices. One is simply to quit advertising about that subnet; the other is to advertise that route, but with an infinite metric, signifying that the route is bad. Route poisoning calls for the second of these options, which removes any ambiguity about whether the route is still valid. For example, in Figure 6-7 again, a metric of 16 is used to signify infinity.
Router C is using route poisoning to ensure that Router A and Router B do not point routes for 162.11.10.0 back through Router C. (The examples in this chapter all used route poisoning— in other words, the bad routes were advertised with an infinite metric.)
One final loop prevention mechanism that also speeds convergence is called flash updates, also known as triggered updates. When a router notices that a directly connected subnet has changed state, it immediately sends another routing update on its other interfaces rather than waiting on the routing update timer to expire. This causes the information about the route whose status has changed to be forwarded more quickly and starts the holddown timers more quickly as well on the neighboring routers, as seen in Figure 6-8.
Figure 6-8 Flash Updates
NOTE The updates are full updates, as is required by distance vector logic. The other routes are not important to the description, so these other routes in the update are not listed. Router C sends its update immediately after 162.11.10.0 fails. Routers A and B also react immediately, sending updates to their neighbors. Because all the routers will ignore any new information about this subnet for holddown time, fast propagation of the fact that the route failed is not harmful. This mechanism quickly prevents packets from being unnecessarily routed.Table 6-11 contains a summary of the terms and concepts used by distance vector routing protocols to help avoid loops and speed convergence.
RIP and IGRP
To pass the CCNA exam, you will need to know the particulars of how RIP and IGRP implement distance vector logic. RIP and IGRP both use distance vector logic, so they are very similar in many respects. A couple of major differences exist, however, and will be explained in the upcoming text. Table 6-11 outlines the features of RIP and IGRP.
Table 6-11 RIP and IGRP Feature Comparison
The metric with IGRP is more robust than RIP’s metric. The metric is calculated using the bandwidth and delay settings on the interface on which the update was received. By using bandwidth and delay, the metric is more meaningful; longer hop routes over faster links can be considered better routes.The metric used by IP RIP is hop count. When an update is received, the metric for each subnet in the update signifies the number of routers between the router receiving the update and each subnet. Before sending an update, a router increments its metric for routes to each subnet by 1. In other words, a routing update includes metric values that tell the receiving router what its metrics should be.
Finally, the issue of whether the mask is sent is particularly important if VLSMs in the same network are desired. This topic is discussed in the upcoming section "Configuration of RIP and IGRP."
Distance Vector Routing Protocol Summary
Distance vector routing protocols learn and advertise routes. The routes placed in the routing table should be loop-free and should be the best known working route. Metrics are used to choose the best route. Mechanisms such as split horizon and holddown timers are used to prevent routing loops.
Configuration of RIP and IGRP
The CCNA exam requires you to understand RIP and IGRP configuration details. RIP and IGRP configuration requires an understanding of two subtle nuances—namely, what the network command really implies and how the router interprets the network command. Other than these two details, configuration is relatively easy.
Hands-on experience is the best way to fully learn the details of configuration. In lieu of that, this section lists commands, provides examples, and points out any tricky features. Table 6-12 and Table 6-13 summarize the more popular commands used for RIP and IGRP configuration and verification. Two configuration samples follow. The Cisco IOS documentation is an excellent reference for additional IP commands, and the Cisco Press book Interconnecting Cisco Network Devices is an excellent reference, particularly if you are not able to attend the instructor-led version of the class.
Table 6-12 IP RIP and IGRP Configuration Commands
Table 6-13 IP RIP and IGRP EXEC
The network Command
Each network command enables RIP or IGRP on a set of interfaces. However, as a CCNA, you must understand the subtleties to what that really means (as explained in the next several paragraphs.) However, what "enables" really means in this case is not obvious from Cisco IOS documentation. Also, the parameters for the network command are not intuitive to many people new to Cisco IOS configuration commands; therefore, routing protocol configuration, including the network command, is a likely topic for tricky questions on the exam. The network command causes implementation of the following three functions:
• Routing updates are broadcast or multicast out an interface.
• Routing updates are processed if they enter that same interface.
• The subnet directly connected to that interface is advertised.
The network command matches some of the interfaces on a router. The interfaces matched by the network command have the three functions previously mentioned performed on them. Examples provide a much easier understanding of the network command, as demonstrated in Figure 6-9 and Example 6-1.
Figure 6-9 Sample Router with Five Interfaces
Example 6-1 Sample Router Configuration with RIP Partially Enabled
The router matches interfaces with the network command by asking this simple question: Which of my interfaces have IP addresses in the same network number referenced in this network subcommand?For any interfaces that have IP addresses in the same network number referenced in this network subcommand, routing updates are broadcast and listened for, and the connected subnet is advertised. For instance, in the first of the two highlighted network commands of Example 6-1, network 10.0.0.0 is configured. Interfaces Ethernet0 and tokenring 0 will be matched. A single network command probably will match more than one interface because the parameter to the network command is always a Class A, B, or C network number, not a subnet number or IP address. Furthermore, most routers will be attached to multiple subnets of that same Class A, B, or C network. In many smaller networks, subnets of only a single network are used, so a single network command could match all interfaces.
In Example 6-1, RIP broadcasts are sent out serial 0, ethernet 0, and tokenring 0. Likewise, RIP updates entering those three interfaces alone are processed. Finally, each RIP update created by this router advertises only directly connected subnets 10.1.2.0, 199.1.1.0, and 10.1.3.0, in addition to any routes learned from other routers using RIP.
A common oversight is to forget to configure a network command to match interfaces serial 1 and ethernet 1. Seemingly, if no other routers are attached to that same Ethernet interface, then there is no need to broadcast RIP/IGRP or listen for RIP/IGRP on the interface. However, three functions are enabled by matching an interface with the network command, as discussed earlier. With the current configuration in Example 6-1, because no network command matches the ethernet 1 and serial 1 interfaces, none of the RIP/IGRP updates from this router will advertise about subnet 172.16.1.0 or network 199.1.2.0.
The passive-interface Command
The passive-interface command can be used to cause the router to listen for RIP/IGRP and advertise about the connected subnet, but not to send RIP/IGRP updates on the interface. In Example 6-2, a sample IGRP configuration causes the router to advertise about all connected subnets, to listen on all interfaces for IGRP updates, and to advertise on all interfaces except ethernet 1.
Example 6-2 Sample IGRP Configuration and show ip route Output
Notice that the four network commands match all five interfaces on the router (refer to Figure 6-9). The passive-interface router subcommand causes the router to not send IGRP updates on interface E1. Also, notice the 1 on the router igrp command—all other routers using IGRP must use this same process-id, assuming that all routers want to exchange routing information using IGRP.IGRP Metrics
IGRP uses a composite metric. This metric is calculated as a function of bandwidth, delay, load, and reliability. By default, only the bandwidth and delay are considered; the other parameters are considered only if enabled via configuration. Delay and bandwidth are not measured values but are set via the delay and bandwidth interface subcommands. (The same formula is used for calculating the metric for EIGRP, but with a scaling factor so that the actual metric values are larger, allowing more granularity in the metric.)
The show ip route command in Example 6-2 shows the IGRP metric values in brackets. For example, the route to 10.1.4.0 shows the value [100/8539] beside the subnet number. The metric 8539 is a single value, as calculated based on bandwidth and delay. The metric is calculated (by default) as the sum of the inverse of the minimum bandwidth, plus the cumulative delay on all links in the route. In other words, the higher the bandwidth, the lower the metric; the lower the cumulative delay, the lower the metric.
Split Horizon and Infinity
Split horizon and route poisoning were covered in the section "Distance Vector Routing Protocols." RIP and IGRP are distance vector routing protocols that implement split horizon and route poisoning; these can be better understood by examining debug messages. Figure 6-10 and Example 6-3 show a stable network with split horizon rules that affect the RIP updates. Then Ethernet 0 on Yosemite is shut down, and Yosemite advertises an infinite distance route to 10.1.2.0, as seen in Example 6-4.
Figure 6-10 Split Horizon and Infinite Distance Routes
Example 6-3 RIP Configuration and Debugs on Albuquerque
Example 6-3 RIP Configuration and Debugs on Albuquerque (Continued)
Example 6-4 RIP Configuration on Yosemite
You can see several interesting items in the configuration and debugs as highlighted in Example 6-3 and Example 6-4. RIP is enabled on all interfaces and on all routers in this example.The RIP update sent out Albuquerque’s Ethernet0 interface advertises five routes but does not advertise the route to 10.1.1.0 because that is the subnet of that attached Ethernet. Albuquerque’s update sent on its Serial1 interface advertises only three routes due to split horizon rules. Finally, notice the update received on Albuquerque, entering Serial0 (from Yosemite) after Yosemite’s Ethernet0 interface has failed. Yosemite has described subnet 10.1.2.0 with a metric 16 route, which is considered infinite by RIP.
Example 6-5 shows the configuration added to each of the three routers in Figure 6-10 to migrate to IGRP. The logic of the network commands works just like with RIP. The output of the show and debug commands provides some insights into the differences between RIP and IGRP.
Example 6-5 Migration to IGRP with Sample show and debug Commands
Example 6-5 Migration to IGRP with Sample show and debug Commands (Continued)
Example 6-5 Migration to IGRP with Sample show and debug Commands (Continued)
The configuration at the beginning of Example 6-5 is used to migrate from RIP to IGRP. As highlighted in Example 6-5, the no router rip command removes all RIP configuration on the router. The three routers each must use the same IGRP process-id (5, in this case), and because all interfaces on each of the routers are in network 10.0.0.0, only a single network subcommand is needed.The output of the show ip route command lists six subnets, just as was the case when RIP was used. The metrics, the second number inside the brackets, are different. In fact, notice the two routes to 10.1.5.0/24—one through Yosemite and one through Seville. Both routes are included because the default setting for ip maximum-paths is 4 and because the routes have an equal metric. Looking further into the output of the debug ip igrp transaction command, you can see the equal cost routes being advertised. One route is seen in the update received on serial 1; the other route in the update is received on serial 0.
The output of the debug ip igrp transaction shows the details of the routing updates, whereas the debug ip igrp event command simply mentions that routing updates have been received. Finally, the show ip protocol command lists several important details about the routing protocol. The time remaining until the next routing update is to be sent is mentioned in one of the first messages. Also, the time since an update was received from each neighboring router is listed at the end of the output. Each of the neighbors from which routing information has been received is listed as well. If you are in doubt as to whether updates have been received during the recent past and from what routers, the show ip protocol command is the place to find out.
RIP-1 and IGRP—No Subnet Masks
RIP-1 and IGRP do not transmit the subnet mask in the routing updates, as seen in the debug output examples in this section. As a CCNA, Cisco expects you to be able to articulate the implications of the missing mask to the function of the routing protocol. Several subtle actions are taken in light of the lack of mask information in the update:
• Updates sent out an interface in network X, when containing routes about subnets of network X, contain the subnet numbers of the subnets of network X but not the corresponding masks.
• Updates sent out an interface in network X, when containing routes about subnets of network Y, are summarized into one route about the entire network Y.
• When receiving a routing update containing routes referencing subnets of network X, the receiving router assumes that the mask in use is the same mask it uses on an interface with an address in network X.
• When receiving an update about network X, if the receiving router has no interfaces in network X, it treats the route as a route to the entire Class A, B, or C network X. Example 6-6, Example 6-7, and Example 6-8 contain show and debug command output on Albuquerque, Yosemite, and Seville with the effects described in the preceding list. The network of Figure 6-10 is still in use, but the subnet on Seville’s Ethernet has been changed from 10.1.3.0/24 to 10.1.3.192/26. Because RIP-1 does not send the mask in the update, Seville chooses not to address 10.1.3.192/26 onto its serial links (which use mask 255.255.255.0), because the update would be ambiguous.
Example 6-6 Configuration and Debug IP RIP on Albuquerque
Example 6-6 Configuration and Debug IP RIP on Albuquerque (Continued)
Example 6-7 Configuration on Yosemite
Example 6-8 Configuration on Seville
As seen in the highlighted portions of Example 6-6, subnet 10.1.3.192/26 is not advertised by Seville, as seen in its update received into Albuquerque’s serial 1 interface. In fact, the debug output looks exactly like it would have earlier, when subnet 10.1.3.0/24 was used on Seville’s Ethernet, if that Ethernet was down. However, in this case, the Ethernet is up, as shown in the show ip route output from Seville at the end of Example 6-6. Essentially, RIP will not advertise the route with a mask of 255.255.255.192 out an interface that is in the same network but that has a different mask. If RIP on Seville had advertised the route to 10.1.3.192, Albuquerque and Yosemite would have believed there was a problem because the subnet number is 10.1.3.192, which is not a subnet number with the mask that Albuquerque and Yosemite think is in use (255.255.255.0). So, RIP and IGRP simply do not advertise the route into the same network on an interface that uses a different mask. The use of different masks in parts of the same network is called variable-length subnet masking (VLSM). As seen in this example, VLSM is not supported by RIP (Version 1) or IGRP.RIP Version 2
RIP Version 2, defined by RFC 1723, is simply an improved version of RIP Version 1. Many features are the same: Hop count is still used for the metric, it is still a distance vector protocol, and it still uses holddown timers and route poisoning. Several features have been added, as listed in Table 6-14.
Table 6-14 RIP Version 2 Features
Although all features of RIP-2 are important, certainly the one that allows RIP to continue to be a valid option in modern networks is the support of VLSM by including the subnet mask. For instance, the problem with RIP-1 and IGRP shown in Examples 6-6, 6-7, and 6-8 was caused by the lack of this feature. With RIP-2, the problem is removed. The same network diagram (Figure 6-10) is used in this case. Example 6-9 shows the RIP-2 configuration on each of the three routers, and Example 6-10 shows a sample RIP debug on Albuquerque.Example 6-9 RIP-2 Sample Configuration for Routers in Figure 6-10
Example 6-10 RIP-2 Routing Updates, No Auto Summary, on Albuquerque
Example 6-10 RIP-2 Routing Updates, No Auto Summary, on Albuquerque (Continued)
A couple of important items should be noted in the debug output of Example 6-10. (As always, the specific portions of the examples referred to in the text after the example are highlighted.) The updates sent by Albuquerque are sent to multicast IP address 224.0.0.9, as opposed to a broadcast address; this allows the devices that are not using RIP-2 to ignore the updates and not waste processing cycles. The show ip route output on Albuquerque lists the previously missing subnet, 10.1.3.192/26; this is expected as highlighted in the debug ip rip messages received by Albuquerque from Seville (10.1.6.253). The subnet masks are shown in the prefix style, with /26 representing mask 255.255.255.192. Also, note the debug output designating tag 0—this means that all the external route tags have value 0, which is the default.Migration from RIP-1 to RIP-2 requires some planning. RIP-1 sends updates to the broadcast address, whereas RIP-2 uses a multicast. A RIP-1 only router and a RIP-2 only router will not succeed in exchanging routing information. To migrate to RIP-2, one option is to migrate all routers at the same time. This might not be a reasonable political or administrative option, however. If not, then some coexistence between RIP-1 and RIP-2 is required. The ip rip send version command can be used to overcome the problem. Essentially, the configuration tells the router whether to send RIP-1 style updates, RIP-2 style updates, or both for each interface. Consider the familiar Figure 6-10 network, with RIP-1 still configured on all three routers. If two of the routers are migrated—for instance, Albuquerque and Seville—then they can communicate with RIP-2 easily. However, by default these two routers will now send only RIP-2 updates, which Yosemite cannot understand because it is still running RIP-1. The configurations in Examples 6-11, 6-12, and 6-13 overcome the problem by having Albuquerque and Seville send only RIP-1 updates to Yosemite.
Example 6-11 Configuration on Albuquerque
Example 6-12 Configuration on Yosemite
Example 6-13 Configuration on Seville
As seen in the highlighted lines of the example, with RIP-2 configured, RIP-2 updates are sent and received on each interface that is matched by a network command. Because Yosemite will send and receive only RIP-1 updates, the other two routers need the appropriate interface subcommands to tell the router to send and receive RIP-1 updates to and from Yosemite. Both Albuquerque and Seville will continue to send and (hope to) receive RIP-2 updates on all interfaces.Auto Summary and Route Aggregation
The IOS is optimized to perform routing as fast as possible. Most of the Layer 3 routing performance improvement in the brief history of routers has been through improved algorithms; many times those improved algorithms later have been implemented in hardware to provide additional latency improvements. Although these improvements have been a great benefit, it is typically true that any algorithm that searches a list will run more quickly if the list is short, compared to searching a similar list that is long. Auto summary and route aggregation (also known as route summarization) are two IOS features that reduce the size of the IP routing table. Auto summarization is a routing protocol feature that operates by this rule: When advertised on an interface whose IP address is not in network X, routes about subnets in network X will be summarized and advertised as one route. That route will be for the entire Class A, B, or C network X.
Auto summary is a feature of RIP-1 and IGRP that cannot be disabled. For RIP-2 and EIGRP, auto summary can be enabled or disabled. As usual, an example makes the concept much clearer. Consider Figure 6-11, which shows two networks in use: 10.0.0.0 and 172.16.0.0. Seville has four (connected) routes to subnets of network 10.0.0.0. Example 6-14 lists the output of a show ip route command on Albuquerque, as well as RIP-2 debug ip rip output.
Figure 6-11 Auto Summarization
Example 6-14 Albuquerque’s Routing Table When Seville Is Summarizing
Notice as highlighted in Example 6-14 that Albuquerque’s received update on Serial0.2 from Seville advertises only about the entire Class A network 10.0.0.0/8 because auto summary is enabled on Seville (by default). The IP routing table lists just one route to network 10.0.0.0. This works fine, as long as network 10.0.0.0 is contiguous. Consider Figure 6-12, where Yosemite also has subnets of network 10.0.0.0 but has no connectivity to Seville other than through Albuquerque.Figure 6-12 Auto Summarization Pitfalls
IP subnet design traditionally has not allowed discontiguous networks. A contiguous network is a single Class A, B, or C network for which all routes to subnets of that network pass through only other subnets of that same single network. Discontiguous networks refer to the concept that, in a single Class A, B, or C network, there is at least one case in which the only routes to one subnet pass through subnets of a different network. An easy analogy for residents in the United States is the familiar term contiguous 48, referring to the 48 states besides Alaska and Hawaii. To drive to Alaska from the contiguous 48, for example, you must drive through another country (Canada, for the geographically impaired!), so Alaska is not contiguous with the 48 states—in other words, it is discontiguous.Figure 6-12 breaks that rule. In this figure, there could be a PVC between Yosemite and Seville that uses a subnet of network 10.0.0.0, but that PVC may be down, causing the discontiguous network. The temporarily discontiguous network can be overcome with the use of a routing protocol that transmits masks because the rule of discontiguous subnets can be ignored when using a routing protocol that transmits masks. Consider the routing updates and routing table on Albuquerque in Example 6-15, where auto summarization is disabled on all routers.
Example 6-15 Albuquerque’s Routing Table When Seville is Not Summarizing
Example 6-15 Albuquerque’s Routing Table When Seville is Not Summarizing (Continued)
Notice as highlighted in Example 6-15 that the routing updates include the individual subnets. Therefore, Albuquerque can see routes to all subnets of network 10 and can route packets to the correct destinations in Seville and Yosemite. With auto summary enabled, Albuquerque would think that both Seville and Yosemite had an equal-metric route to network 10.0.0.0; some packets would be routed incorrectly.Route summarization (also called route aggregation) works like auto summarization, except that there is no requirement to summarize into a Class A, B, or C network. Consider the same network in Figure 6-12. Albuquerque has eight routes to subnets of network 10.0.0.0; four of those routes are learned from Seville. Consider the subnet, broadcast, and assignable addresses in each of the subnets, as shown in Table 6-15.
Table 6-15 Route Aggregation Comparison of Subnet Numbers
Now consider the concept of a subnet 10.1.4.0, with mask 255.255.252.0. In this case, 10.1.4.0/22 (same subnet, written differently) would have a subnet broadcast address of 10.1.7.255 and assignable addresses of 10.1.4.1 to 10.1.7.254. Because 10.1.4.0/22 happens to include all the assignable addresses of the original four subnets, a single route to 10.1.4.0/22 would be just as good as the four separate routes, assuming that the next-hop information would be the same for each of the original four routes.Route aggregation is simply a tool used to tell a routing protocol to advertise a single, larger subnet rather than the individual smaller subnets. In this case, the routing protocol would advertise 10.1.4.0/22 rather than the four individual subnets. Albuquerque’s routing table will then be smaller. EIGRP and OSPF are the only interior IP routing protocols to support route aggregation.
Route summarization of the subnets off Seville is shown in Example 6-16. Still using the network of Figure 6-12, the routers are all migrated to EIGRP. Example 6-16 shows the EIGRP configuration on Albuquerque, EIGRP configuration on Seville, and the resulting IP routing table on Albuquerque. (Yosemite is migrated to EIGRP as well; the configuration is not shown because the example shows only aggregation by Seville.)
Example 6-16 Route Aggregation Example Using EIGRP
Example 6-16 Route Aggregation Example Using EIGRP (Continued)
The ip summary-address interface subcommand on Seville’s serial 0.1 interface is used to define the superset of the subnets that should be advertised. Notice the route in Albuquerque’s routing table, which indeed shows 10.1.4.0/22, rather than the four individual subnets.When summarizing, the superset of the original subnets could actually be smaller than the Class A, B, or C network; larger than the network; or exactly matched to a network. For instance, 192.168.4.0, 192.168.5.0, 192.168.6.0, and 192.168.7.0 could be summarized into 192.168.4.0/22, which represents four consecutive Class C networks. Summarization when the summarized group is a set of networks is sometimes called supernetting.
Table 6-16 lists the features for summarization of the interior IP routing protocols.
Table 6-16 Route Aggregation Comparison of Subnet Numbers
Table 6-16 Route Aggregation Comparison of Subnet Numbers (Continued)
Multiple Routes to the Same Subnet
By default, the IOS supports four equal-cost routes to the same IP subnet in the routing table at the same time. This number can be changed to between 1 and 6 using the ip maximum-paths x router configuration subcommand, where x is the maximum number of routes to any subnet. As mentioned earlier, the packets are balanced on a per-destination address basis by default; packets also can be balanced on a packet-by-packet basis, but at a performance penalty.
The metric formula used for IGRP (and EIGRP) poses an interesting problem when considering equal-metric routes. IGRP can learn more than one route to the same subnet, with different metrics; however, the metrics are very likely to never be exactly equal. The variance router subcommand is used to define how variable the metrics can be for routes to be considered to have equal metrics. The parameter to the command (the multiplier) is multiplied by the lowest of the received metrics for a particular subnet. Any routes with a metric less than the product of "best metric" times the multiplier are considered to be equal.
Some rather interesting twists in logic must be considered when deciding whether to use one or multiple equal-cost routes with IGRP. If maximum-paths is set to 1, then the first of these equal-cost routes learned to each subnet is placed into the routing table. However, these could be the routes with the largest metric. To avoid that, maximum-paths could be defaulted to 4 or could be coded as some other number; in addition, the variance command can be used to define how close the metrics must be in value to be considered equal. However, in that case, some of the traffic will flow over the routes with the best metric, and some will flow over the route with the worst metric. Neither situation seems to be optimal.
A different—and possibly better—alternative is to use the traffic-share min router IGRP subcommand in conjunction with maximum-paths and variance. This command tells the router to add the multiple routes to the routing table, but to send only traffic using the route with the smallest metric. This allows all routes to each subnet to be in the routing table, which is an advantage for faster convergence. However, all traffic goes across the lowest-metric route that is currently in the routing table. The traffic-share balanced command, which is the default, tells the router to use all the routes proportionally based on the metrics for each route.
