Routers and Routing Basics CCNA 2

Routers and Routing Basics CCNA 2 Chapter 7

Distance Vector Routing Protocols • Using Distance Vector Routing Protocols • Review of Distance Vector Operation in a Stable Network • Route Poisoning • Problem: Counting to Infinity • Loop-Prevention Features • Summarizing Loop Avoidance • Routing Information Protocol • Configuring RIP Versions 1 and 2 • RIP Verification and Troubleshooting • Choosing the Best Route Among the Possible Routes • Integrating Static Routes with RIP • Classful and Classless Routing Protocols, Routing, and Addressing • Summary

Routing Loops – the Fee for Simplicity • In 1980s a typical WAN link to a remote site might have been only 56 kbps • As a result, the designers of the first distance vector protocols had to keep them simple • The simplicity of distance vector protocols introduced the possibility of routing loops (same single packet ends up back at the same routers over and over again) • The looping packets could easily congest the network and make it unusable • Routing loops must be avoided as much as possible

Distance Vector Operation in a Stable Network Normal Steady-State RIP Operations • 1. R2 considers itself to have a 0-hop route for subnet 172.30.22.0/24, so in the routing update sent by R2, R2 advertises a metric1 (hop count 1) route. • 2. R1 receives the update, and because R1 has learned of no other possible routes to 172.30.22.0, this route must be R1’s best route to the subnet. • 3. R1 adds the subnet to its routing table, listing it as a RIP-learned route. • 4. For the learned route, R1 uses an outgoing interface of S0/0, because R1 received R2’s routing update on R1’s S0/0 interface. • 5. For the learned route, R1 uses a next-hop router of 172.30.1.2, because R1 learned the route from a RIP update whose source IP address was 172.30.1 At the end of this process, R1 has learned a new route. The rest of the RIP-learned routes in this example follow the same process.

Distance Vector Operation in a Stable Network (Continued) • Metric—RIP uses hop count for the metric. RIP routers add 1 to the metric before advertising the route. • Periodic—The hourglass icons represent the fact that the updates repeat on a regular cycle. RIP uses a 30-second update interval by default. • Full updates—The routers send full updates, every time, instead of just sending new or changed routing information. (The term partial update refers to routing updates that include only changed information.) • Full updates limited by split horizon rules—The routing protocol omits some routes from the periodic full updates due to split horizon rules.

Route Poisoning • When a route fails, distance vector routing protocols risk causing routing loops until every router in the internetwork knows and believes that the original route has failed. • As a result, distance vector protocols need to have a way to specifically identify which routes have failed. • Distance vector protocols spread the bad news about a route failure by poisoning the route. • Route poisoningrefers to the practice of advertising a route, but with a special metric value called infinity. • Simply put, routers consider routes advertised with an infinite metric to have failed. Each distance vector routing protocol uses the concept of an actual metric value that represents infinity. • RIP defines infinity as 16.

Route Poisoning (Continued) • 1. R2’s FA0/1 interface fails. • 2. R2 removes its connected route for 172.30.22.0/24 from its routing table. • 3. R2 advertises 172.30.22.0 with an infinite metric, which for RIP is metric 16. • 4. R1 keeps the route in its routing table, with an infinite metric, as part of the loop-avoidance process.

Counting to Infinity • Distance vector routing protocols risk causing routing loops between the time at which the first router realizes a route has failed until all the routers know that the route has failed. • That problem, called counting to infinity, causes two other related problems: • 1. Packets may loop around the internetwork while the routers count to infinity, with the bandwidth consumed by the looping packets crippling an internetwork. • 2. The counting-to-infinity process may take several minutes, meaning that the looping could cause users to believe that the network has failed.

Counting to Infinity (Continued) R2 Incorrectly Believes R1 has a Route to 172.16.22.0/24 • 1. R2’s FA0/1 interface fails, so R2 removes its connected route for 172.30.22.0/24 from it routing table. • 2. R2 sends a poisoned route advertisement (metric 16 for RIP) to R1, but at about the same time, R1’s periodic update timer expires, so R1 sends its regular update, including an advertisement of 172.30.22.0, metric 2. • 3. R2 hears about the metric 2 route to reach 172.30.22.0 from R1. Because R2 no longer has a route for subnet 172.30.22.0, R2 adds the two-hop route to its routing table, next-hop router R1. • 4. At about the same time as Step 3, R1 receives the update from R2, telling R1 that its former route to 172.30.22.0, through R1, has failed. As a result, R1 changes its routing table to list a metric of 16 for the route to 172.30.22.0.

Counting to Infinity (Continued) R1 and R2 Count to Infinity • 1. Both R1’s and R2’s update timers expire at about the same time. R1 advertises a poison (metric 16) route, and R2 advertises a metric 3 route. (Remember, RIP routers add 1 to the • metric before advertising the route.) • 2. R2 receives R1’s update, so R2 changes its route for 172.30.22.0 to use a metric of 16. • 3. At about the same time as Step 2, R1 receives R2’s update, so R1 changes its route for 172.30.22.0 to use a metric of 3.

Loop-Prevention Features – Split Horizon • Split horizon is defined as follows: • In routing updates sent out interface X, • do not include routing information about routes • that refer to interface X as the outgoing interface.

Loop-Prevention Features – Split Horizon (Continued) The Effects of Split Horizon Without Poison Reverse • 1. R1 sends its normal periodic full update, which, due to split horizon rules, includes only one route. • 2. R2 sends its normal periodic full update, which, due to split horizon rules, includes only two routes. • 3. R2’s FA0/1 interface fails. • 4. R2 removes its connected route for 172.30.22.0/24 from its routing table. • 5. R2 advertises 172.30.22.0 with an infinite metric, which for RIP is metric 16. • 6. R1 temporarily keeps the route for 172.30.22.0 in its routing table, later removing the route from the routing table. • 7. In its next regular update, R1, due to split horizon, still does not advertise the route for • 172.30.22.0.

Poison Reverse and Triggered Updates • Distance vector protocols can attack the counting-to-infinity • problem when reacting to failed routes by ensuring that • every router learns that the route has failed, through every • means possible, as quickly as possible: • ■ Triggered update— When a route fails, do not wait for the next periodic update. Instead, send an immediate triggered update listing the poisoned route. • ■ Poison reverse— When learning of a failed route, suspend split horizon rules for that route, and advertise a poisoned route.

Poison Reverse and Triggered Updates(Continued) R2 Sending a Triggered Update, with R1 Advertising a Poison Reverse Route • 1. R2’s FA0/1 interface fails. • 2. R2 immediately sends a triggered partial update with only the changed information—in • this case, a poison route for 172.30.22.0. • 3. R1 responds by changing its routing table and sending back an immediate (triggered) partial update, listing only 172.30.22.0 with an infinite metric (metric 16). This is a poison • reverse route. • 4. On R2’s next regular periodic update, R2 advertises all the typical routes, including the • poison route for 172.30.22.0, for a time. • 5. On R1’s next regular periodic update, R1 advertises all the typical routes, including the • poison reverse route for 172.30.22.0, for a time.

Loops in Redundant Networks • Split horizon prevents the counting-to-infinity problem from • occurring between two routers. • However, with redundant paths in an internetwork, which is true of most internetworks today, split horizon alone does not always prevent counting to infinity.

Loops in Redundant Networks (Continued) Periodic Updates in a Stable Triangle Internetwork • 1. R2 advertises a metric 1 route for 172.30.22.0 in its updates to both R1 and R3. • 2. R1 advertises a metric 2 route for 172.30.22.0 to R3, while R3 advertises a metric 2 route for 172.30.22.0 to R2. • 3. Both R1 and R3 add the metric 1 route, learned directly from R2, to their routing tables, and ignore the two-hop routes they learn from each other. For example, R1 places a route 172.30.22.0, using outgoing interface S0/0, next-hop router 172.30.1.2 (R2), in its routing table.

Loops in Redundant Networks (Continued) Counting to Infinity in a Redundant Internetwork, Part 1 • 1. R2’s FA0/1 interface fails. • 2. R2 immediately sends triggered partial updates poisoning the route for 172.30.22.0. R2 sends the updates out all still-working interfaces. • 3. R3 receives R2’s triggered update that poisons the route for 172.30.22.0, so R3 updates its routing table to list metric 16 for this route. • 4. Before the update described in • Step 2 arrives at R1, R1 sends its normal periodic update to R3, listing 172.30.22.0, metric 2, as normal. (Figure omits some of what would be in R1’s periodic update to reduce clutter.) 5. R1 receives R2’s triggered update (described at Step 2) that poisons the route for 172.30.22.0, so R1 updates it routing table to list metric 16 for this route. 6. R3 receives the periodic update sent by R1 (described at Step 4), listing a metric 2 route for 172.30.22.0. As a result, R3 updates its routing table to list a metric 2 route, through R1 as the next-hop router, with outgoing interface S0/0. At this point, R3 has an incorrect metric 2 route for 172.30.22.0, pointing back to R1.

Loops in Redundant Networks (Continued) Counting to Infinity in a Redundant Internetwork, Part 2 • 7. R1 sends its next periodic update to R3, with poisoned route 172.30.22.0, metric 16. • 8. Before the update described in Step 7 arrives at R3, R3 sends its next periodic update toR2, listing a metric 3 route for 172.30.22.0. • 9. R3 receives R1’s periodic update from R1 (as described in Step 7), and R3 changes its route for 172.30.22.0 to list an infinite metric. • 10. R2 receives R3’s periodic update (as described in Step 8), so R2 adds a metric 3 route for 172.30.22.0 to its routing table, listing R3 as the next-hop router, with outgoing interface • S0/1/

The Holddown Process and Holddown Timer • Distance vector protocols use holddown to specifically • attack the loops created by the counting-to-infinity • problems that occur in redundant internetworks • The term holddown gives a hint as to its meaning: • After the route is considered to be down, hold the route in a down state for a while to give the routers time to make sure every router knows that the route has failed. • The holddown process tells a router to ignore new information about the failed route, for a time period called the holddown time, as counted using the holddown timer.

Using Holddown to Prevent Counting to Infinity • 1. R2’s FA0/1 interface fails. • 2. R2 immediately sends triggered partial updates, poisoning the route for 172.30.22.0. R2 sends the updates out all still-working interfaces. • 3. R3 receives R2’s triggered update that poisons the route for 172.30.22.0, so R3 updates its routing table to list metric 16 for this route. R3 also puts the route for 172.30.22.0 in holddown and starts the holddown timer (180 seconds by default with RIP) for the route. • 4. Before the update described in Step 2 arrives at R1, R1 sends its normal periodic update toR3, listing 172.30.22.0, metric 2, as normal. (Note that Figure 7-10 omits some details in R1’s periodic update to reduce clutter.) • 5. R1 receives R2’s triggered update (described in Step 2) that poisons the route for • 172.30.22.0, so R1 updates its routing table to list metric 16 for this route. 6. R3 receives the update from R1 (Step 4), listing a metric 2 route for 172.30.22.0. Because R3 has placed this route in a holddown state, and this new metric 2 route was learned from a different router (R1) than the original router (R2), R3 ignores the new routing information.

Summarizing Loop Avoidance • During periods of stability, routers send periodic full updates. • The updates list all known routes except the routes omitted due to split horizon rules. • When changes occur that cause a route to fail, • routers react by sending triggered partial updates with poisoned routes. • Routers also suspend split horizon rules for that route • advertising a poison reverse route back toward the router from which the failed route was learned • All routers place a route in holddown state and start a holddown timer for that route after learning that the route has failed. • The router ignores all new information about that route until the holddown timer expires, unless that information comes from the same router that originally advertised the good route to that subnet.

Distance Vector Loop Avoidance Terminology

Routing Information Protocol • The first IP networks used RIP Version 1 (V1) because it was the first and only IP routing protocol early in the history of TCP/IP. • As time went on, routers became more affordable, with • faster CPUs, more memory, and faster links, all of which allowed the • development of more advanced routing algorithms and routing • protocols, such as OSPF and EIGRP. • Around the same time, other developers enhanced the RIP protocol standard, calling the new standard RIP Version 2 (V2). • RIP V2 does not completely change RIP V1, but rather adds some advanced features.

Comparing RIP Version 1 and 2 Features

Configuring RIP V1 • RIP V1 configuration requires two configuration commands: • - router rip • - network classful-network-number • The router rip command moves the user from global • configuration mode to RIP configuration mode, and the • network command tells the router on which interfaces to • start using RIP.

Configuring RIP V1 (Continued) • Configuring RIP on All Interfaces on R1

Configuring RIP V1 (Continued) • When a router’s RIP configuration matches an interface, • Cisco IOS starts the following process: • 1. Sends RIP updates out the interface. • 2. Listens for RIP updates coming in that interface from some other router. • 3. Advertises the subnet attached to the interface.

Configuring RIP V2 • 1. To configure RIP V2 in internetworks that use RIP V2 only, simply add the version 2 command under router rip. • 2. After they are configured, the routers send only V2 updates • And process only received V2 updates. • 3. At that point, the core features of RIP V2, such as sending • masks in routing updates occur. • 4. Optional RIP V2 features, such as authentication, this requires additional configuration.

Using Both RIP V1 and V2 • 1. In some cases, an internetwork may need to use both RIP versions. • (Partial migrating from RIP V1 to RIP V2, some business or company organizational reason to use both versions, etc.) • 2. Regardless of the reasons, to support both versions in the same internetwork, one or more routers need to use both versions at the same time.

RIP Version Migration: Speaking Both Versions • 1. Configure R1 for RIP V1 (by omitting the version command) and then configure interface S0/0 to send and receive RIP V2 updates • 2. Configure R1 for RIP V2 (by including the version 2 command) and then configure interface S0/1 to send and receive RIP V1 updates

Configuring RIP Version 2 on an Interface • R1 enables RIP V2 on interface S0/0 by using the ip rip send version 2 and ip rip receive version 2 interface subcommands. • So, R1 sends and receives only RIP V2 updates on the right of Figure and defaults to sending and receiving RIP V1 updates on the left.

Design Options Impacted by the RIP V2 • The use of RIP V2 instead of RIP V1 allows the use of two powerful network • design options. • 1. V2 allows for the use of VLSM. VLSM gives the engineer much more • flexibility when choosing which subnets to use and how many hosts to put into • each subnet. • 2. RIP V2 also allows a design choice called a discontiguous network. A • discontiguous network occurs when at least one pair of subnets of the same • classful network are separated by subnets of a different classful network. • RIP V1 does not support discontiguous networks; RIP V2 supports them if all • the routers have been configured with the RIP no auto-summary • subcommand.

Discontiguous Network 172.30.0.0

Other RIP Configuration Options • RIP has several optional configuration settings as well: • Adjust timers, such as the holddown and update timers • Enable or disable split horizon per interface • Explicitly configure RIP neighbors to support certain types of WAN connections • Disable the sending of RIP updates on an interface (using the passive-interface command), while still receiving RIP updates • Filter the contents of RIP updates

RIP Timers • RIP uses several timers: • 1. Update timer • 2. Holddown timer • RIP uses the concept of an invalid timer and a flush timer. (The flush • timer determines when a router removes a route from the routing table • after the route has been poisoned.) • All of these timers can be reset with the following command, which is • configured as a subcommand under router rip: • timers basic update invalid holddown flush • You might consider lowering the holddown timer to speed convergence.

Disabling Split Horizon • Split horizon helps prevent loops by avoiding the counting-to-infinity • problem. • Cisco IOS enables split horizon on all interfaces • (except serial interfaces that are configured with some of Frame Relay • options). However, you can disable split horizon, per interface using • interface subcommand: • no ip split-horizon • For example, to disable split horizon on interface S0/0, the engineer • would enter configuration mode, type the interface S0/0 command, • and then use the no ip split-horizon command.

Configuring Neighbors • RIP V1 sends its update messages to IP broadcast address 255.255.255.255. • RIP V2 Improves the update process by sending its update messages to the • 224.0.0.9 multicast IP address. • By using multicasts, only RIP-speaking routers should process RIP updates, • reducing the overhead on the other hosts on a LAN. • However, some WAN data links may not support the sending of data-link • broadcasts or multicasts. • In those cases, RIP must send its updates using IP and datalink unicast • addresses. • To do so, a RIP router must define the neighboring router’s unicast IP address • using the neighbor command under router rip.

Enabling the passive-interface Command • After RIP is configured, it may be useful to then stop sending RIP • updates on the interface. • To do so, the configuration must still match the interface with a • network command, and then the router must be told to stop sending • updates with the passive-interface interface subcommand under • router rip. • The passive-interface command tells RIP to stop sending RIP updates • out the listed interface.

Route Redistribution R2, which uses only OSPF, has no need to receive R1’s RIP updates. So, R1 has used the passive-interface command, meaning that R1 no longer sends RIP updates out its S0/0 interface into the OSPF part of the internetwork.

Filtering Routes • Routers can use route filtering to filter the routes sent and • received in RIP updates. • Route filtering allows an engineer to limit which routers • learn which routes. • For example, if a particular subnet should be protected for security • reasons, and only certain groups of people should be able to • communicate with the hosts in that subnet, the engineer could filter • routes.

Verifying RIP Operations Using show Commands • The following four show commands provide the most • useful information for examining how RIP is working in a • router: • - show ip protocols • - show ip route • - show ip interface brief • - show ip rip database

R1: Sample RIP show ip protocols Command

Sample RIP show Commands on R1

Troubleshooting RIP Operations Using the debug Command • Cisco IOS supports a very important troubleshooting command called • the debug command. • The debug command has many options, including options related to RIP. • Regardless of what options are added to the debug command, this • command tells the router to do the following: • - Monitor some internal process (for example, RIP updates that are sent and received) • - When something happens related to that process, generate log messages • - Keep generating log messages until someone disables the debug using the no debug command

R1: Messages Generated by the debug ip rip Command

Load Balancing over Multiple Equal-Cost Routes • When a router discovers multiple equal-cost routes to the same subnet, • using a single routing protocol, the routing protocol can add multiple of • those routes to the routing table. • All the IGPs on Cisco routers use the following (default) rules when • considering multiple equal-cost routes: • - By default, add up to four equal-cost (equal-metric) routes for the same subnet to the routing table at the same time. • - The number of concurrent equal-cost routes can be changed by using the maximum-paths number subcommand, to a value between 1 and 6.

Load Balancing over Multiple Equal-Cost Routes (Continued) • When the IP routing table lists multiple routes to the same destination, • the IP routing process then needs to choose how to load-balance the • traffic over the multiple routes. • The following two options based on the internal routing process used • by the router: • - Process switching — The slowest and highest-overhead option for how IOS forwards packets. However, with process switching, load balancing occurs per packet, with each successive packet going to the destination subnet using a different route. • - Fast switching — The next fastest option, with less overhead, for how IOS forwards packets. However, when using fast switching, the router balances traffic per destination IP address.

Equal-Cost Load Balancing R1: Messages Generated by the show ip route Command

Choosing Routes Based on Administrative Distance • In some cases, one router may need to use multiple routing protocols. • Because each routing protocol uses a different metric, a router cannot • use the metric to determine which route is the best route. • Routers determine the best route in these cases by choosing the route • with the lowest administrative distance. • The administrative distance is a number assigned to all the possible • sources of routing information — routing protocols and static routes • included.

Default Administrative Distances in Cisco IOS

Routers and Routing Basics CCNA 2