The Ultimate CCNA Study Package - ICND 1 And 2

Chris Bryant, CCIE #12933 http://www.thebryantadvantage.com Back To Index

Static Routing, Distance Vector Routing, And RIP

Don't miss the "Recommended Video Viewing" section at the end of this chapter! Overview
Static Routing Theory And Labs RIP Routing Theory And Labs The Importance Of "show ip protocols" "Hot Spots And Gotchas" Recommended Video Viewing!

Both the ICND 1 and ICND 2 sections of the Index page link to this chapter - you need to have these fundamentals mastered for both exams if you're taking the two-exam path to the CCNA. In the IP addressing section, you were given a "sneak peak" at static routing. In this section, we'll actually configure static routing in a network and use some new commands to test IP connectivity. I've also gotplenty ofIPconnectivity troubleshooting built into this section as well. It's important to understand static routing for your CCENT and CCNA exams, and you'll find it helpful in working with real-world networks as well. When it comes to real-world networks, though, you're going to see a lot more of dynamic routing protocols than static routes. Later in this section, you'll be introduced to your first routing protocol, the Routing Information Protocol (RIP). We'll configure, troubleshoot, and verify RIP right after we take a close look at static routes! Static Routes Here's the network we'll use for the static routing discussion:

If you don't have experience with frame relay, no problem. You certainly will by the end of your CCNA course! Frame Relay is a Layer 2 protocol, and right now we're strictly concerned with routing, and an understanding of frame relay is not required for this section of the course. This particular network is a hub-and-spoke network, with R1 serving as the hub and R2 and R3 serving as the spokes. When one spoke sends traffic to another, that traffic will go through the hub. That's a very important concept to keep in mind! I'm also introducing you to loopback interfaces in this section. Loopback interfaces are logical interfaces - they do not physically exist on the router. Trust me, you're going to be introduced to literally dozens of uses for loopback interfaces in your Cisco studies. We're going to use them for a basic IP connectivity test. For this example and all others in this course, the last octet of the IP address for any physical interface will be the router number. That's a good habit to get into for your home lab studies as well. For loopbacks, we'll use the router number for each octet. The networks used in this section:

Frame Relay (Serial interfaces, all routers): 172.12.123.x /24 R2's loopback interface: 2.2.2.2 /24 R3's loopback interface: 3.3.3.3 /24

We're going to use pings to test IP connectivity throughout this section. When you ping a remote IP address, you're sending five ICMP Echo packets to the IP address you specify. If we get five ICMP Echo Replies in return, you'llsee five exclamation points, and that means you do have IP connectivity to the specified destination. For example, right now R1 can ping the serial interfaces on R2 and R3:
R1#ping 172.12.123.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.123.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/72 ms

R1#ping 172.12.123.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms

There are no routing protocols or static routes on the routers right now, so how can R1 successfully ping those two destinations? Let's use show ip route to take a look at R1's routing table. (I'll delete most of the code table, since it's the routes we're really interested in right now.)
R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, Gateway of last resort is not set 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0

There's only one route in R1's routing table, but that's enough - it's the 172.12.123.0 /24 network, and the two destinations we pinged are on that network. Let's see if our spokes can ping the hub, and each other. Can R2 ping both 172.12.123.1 and .3?
R2#ping 172.12.123.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.123.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms R2#ping 172.12.123.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 128/138/168 ms

Yes! Remember, the ping from R2 to R3 is going through R1, since R1 is our hub.

The ping reply from R3 to R2 also comes back through R1.

 Can R3 ping 172.12.123.1 and .2?

R3#ping 172.12.123.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.123.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms R3#ping 172.12.123.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.123.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 132/134/144 ms

Yes! Both the ping from R3 to R2 and the ping reply from R2 to R3 went through R1. Since every router on the network has an entry for 172.12.123.0 /24 in its routing table, there's no problem. So right now, everything's great! Now let's see if R3 can ping R2's loopback interface, 2.2.2.2.
R3#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

Nope! When you see periods come back from a ping, that's not good that means that we do not have IP connectivity to the remote address we pinged. In this particular case, you probably already know why we don't have that connectivity, but as your network grows it's not always going to be easy to diagnose this kind of problem. Ping tells you that you don't have connectivity, but doesn't really tell you why. A command that's very helpful in diagnosing an IP connectivity issue is debug ip packet. WARNING: Do NOT practice debugs on a production network. Some

debugs,especially debug ip packet, can overwhelm a router or switch CPU and render the device unable to route or switch. It's important to know how the debug output will look when things are running correctly, because that's the only way to know what you're looking for when things aren't running correctly. If you have a home lab, make sure to run plenty of debugs as you work - but never practice them at work. Let's run that debug on R3 and then send a ping to 172.12.123.2, which we already know we can ping successfully. That will allow us to see what the debug ip packet output looks like when all is well.
R3#debug ip packet IP packet debugging is on R3# R3#ping 172.12.123.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.123.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 136/139/152 ms R3# IP: s=172.12.123.3 (local), d=172.12.123.2 (Serial0), len 100, sending IP: s=172.12.123.1 (Serial0), d=172.12.123.3 (Serial0), len 56, rcvd 3 IP: s=172.12.123.2 (Serial0), d=172.12.123.3 (Serial0), len 100, rcvd 3 IP: s=172.12.123.3 (local), d=172.12.123.2 (Serial0), len 100, sending IP: s=172.12.123.2 (Serial0), d=172.12.123.3 (Serial0), len 100, rcvd 3 IP: s=172.12.123.3 (local), d=172.12.123.2 (Serial0), len 100, sending IP: s=172.12.123.2 (Serial0), d=172.12.123.3 (Serial0), len 100, rcvd 3 IP: s=172.12.123.3 (local), d=172.12.123.2 (Serial0), len 100, sending IP: s=172.12.123.2 (Serial0), d=172.12.123.3 (Serial0), len 100, rcvd 3 IP: s=172.12.123.3 (local), d=172.12.123.2 (Serial0), len 100, sending IP: s=172.12.123.2 (Serial0), d=172.12.123.3 (Serial0), len 100, rcvd 3

The key words there are "sending" and "rcvd" (short for received). That's what we want to see! Now let's see what we don't want to see by keeping that debug on and pinging 2.2.2.2, an address we know we do not have connectivity to.
R3#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, ..... Success rate is 0 percent (0/5) R3# IP: s=172.12.123.3 (local), d=2.2.2.2, len IP: s=172.12.123.3 (local), d=2.2.2.2, len IP: s=172.12.123.3 (local), d=2.2.2.2, len IP: s=172.12.123.3 (local), d=2.2.2.2, len IP: s=172.12.123.3 (local), d=2.2.2.2, len timeout is 2 seconds:

100, 100, 100, 100, 100,

unroutable unroutable unroutable unroutable unroutable

The key word here is "unroutable". Here's the reason for that message....
R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP Gateway of last resort is not set 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0

There's no entry for the2.2.2.0 network in R3's routing table, so the

packets destined for a host on that network cannot be routed. Before we proceed, we'll turn the debug off with undebug all, which (naturally) turns off all debugs. If you want to specify the debug to turn off, use the no debug command followed by the name of the debug itself.
R3#undebug all All possible debugging has been turned off

We've got two choices to get a route to 2.2.2.0 into that table:

Configure a static route Configure a dynamic routing protocol throughout the network

Since we're in the static routing section of the course, let's choose a static route! We use the ip route command to create static routes, and we actually have two choices when it comes to static routes. We can create...

A static route to a given host or destination network A default static route, which will be used when there is no other match in the routing table for a destination network

We'll use both in this section, starting with a "regular" static route. We'll also use IOS Help to illustrate the choices with this command, and many others throughout the course. Get plenty of practice with IOS Help during your exam prep! To use IOS Help, you simply usea question mark. IOS Help shows the options we have at any particular point in a command.
R3(config)#ip route ? A.B.C.D Destination prefix profile Enable IP routing table profile static Allow static routes vrf Configure static route for a VPN Routing/Forwarding instance

We're going to configure the destination IP prefix2.2.2.0 here for our static route (theloopback network we want to ping).
R3(config)#ip route2.2.2.0 ? A.B.C.D Destination prefix mask

Now we must specify the network mask, 255.255.255.0. Do not panic when you see the number of choices here !
R3(config)#ip route 172.12.23.0 255.255.255.0 ? A.B.C.DForwarding router's address Async Async interface BRI ISDN Basic Rate Interface BVI Bridge-Group Virtual Interface CTunnel CTunnel interface Dialer Dialer interface Ethernet IEEE 802.3 Lex Lex interface Loopback Loopback interface Multilink Multilink-group interface Null Null interface Serial Serial Tunnel Tunnel interface Vif PGM Multicast Host interface Virtual-TokenRing Virtual TokenRing

At this point in the ip route command, you must specify one of these two

values:

The local router's exit interface (NOT the IP address) The remote router's IP address that we want to send that packet to

I personally like to use the remote router's IP address, but there's nothing wrong with using the local router's exit interface. Besides, you better know them both for your CCENT and CCNA exams! We'll use the nexthop IP address 172.12.123.1, R1's serial interface, since we already have IP connectivity to that address as verified earlier.
R3(config)#ip route2.2.2.0 255.255.255.0 172.12.123.1 <1-255> Distance metric for this route name Specify name of the next hop permanent permanent route tag Set tag for this route <cr>

When you see < cr > at the bottom of IOS Help output, that means the command is acceptable to enter as it is.We'll take a look at a few of those options later in the course. Let's press the ENTER keyto have the route entered into the routing table, use <ctrl-z> to go back to the enable prompt, and then verify the route entry withshow ip route. Always use a show command to verify your latest configuration!
R3(config)#ip route 172.12.23.0 255.255.255.0 172.12.123.3 R3(config)#^Z R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP 2.0.0.0/24 is subnetted, 1 subnets S 2.2.2.0 [1/0] via 172.12.123.1 3.0.0.0/24 is subnetted, 1 subnets C 3.3.3.0 is directly connected, Loopback0 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0

And there's our static route, as indicated by the "S"! Nothing to it! Now we'll send a ping to 2.2.2.2, and let's see what happens. I've turned debug ip packet back on as well (not shown)...
R3#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) R3# IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending IP: s=172.12.123.1 (Serial0), d=172.12.123.3 (Serial0), len 56, rcvd 3 IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending IP: s=172.12.123.1 (Serial0), d=172.12.123.3 (Serial0), len 56, rcvd 3 IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending R3# IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending IP: s=172.12.123.1 (Serial0), d=172.12.123.3 (Serial0), len 56, rcvd 3

.. and we get a really strange readout. Three "U"s and two periods. No exclamation points, so something's definitely wrong. Interestingly, the packets are being sent - you can see the word "sending" five times. So the pings are leaving R3, but aren't getting to 2.2.2.2. Obviously something is wrong, and I showed you this to illustrate a basic principle of pings and IP connectivity that many network admins forget: When you send pings, it's not enough for the local router to have connectivity to the remote network - the downstream routers need connectivity to that remote network as well! Sorry for the mass use of italics, but this is a really important concept, and an often-forgotten one. Let's walk through the ping process, which is really just two steps. The pings leave R3, and where do they go? Let's revisit R3's routing table for that answer:
R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP 2.0.0.0/24 is subnetted, 1 subnets S 2.2.2.0 [1/0] via 172.12.123.1 3.0.0.0/24 is subnetted, 1 subnets C 3.3.3.0 is directly connected, Loopback0 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0

The next hop for those pings is R1's serial0 interface, 172.12.123.1. Does R1 have a route to 2.2.2.2? Let's check R1's routing table for the answer...
R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP Gateway of last resort is not set 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0

R1 has noentry in its routing table that will allow it to forward packets to 2.2.2.2.Therefore, R1 is simply dropping thepackets that R3 is sendingto 2.2.2.2.

We need to get a route into R1's routing table to allow it to route packets to 2.2.2.2. We'll use this opportunity to configure a default static route on R1. A router only uses a default route if there is no other matching entry in the routing table for a given network destination. The syntax for a default static route looks a bit odd, so be ready to identify it on the exam:
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ip route 0.0.0.0 0.0.0.0 172.12.123.2

Both the destination network and the mask are all zeroes in a default static route. As with a "regular" static route, we have the option of configuring a next-hop IP address or the local router's exit interface. Here I've configured a default static route with the next-hop address of 172.12.123.2 (R2's serial interface), so R1 is basically saying this: "Any packets that need routing and don't have a matching entry inmy routing table, send them to 172.12.123.2 and hopefully the router at that address knows what to do with those packets."

Let's verify the default static route with show ip route on R1:
R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP * - candidate default

Gateway of last resort is 172.12.123.2 to network 0.0.0.0 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0 S* 0.0.0.0/0 [1/0] via 172.12.123.2

There's an asterisk next to the "S", which indicates that this route is a default static route. Also note that the gateway of last resort lists the nexthop address of the static route. Will this allow R3 to successfully ping R2's loopback interface?
R3#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 136/141/164 ms R3# IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending IP: s=172.12.123.1 (Serial0), d=172.12.123.3 (Serial0), len 56, rcvd 3 IP: s=2.2.2.2 (Serial0), d=172.12.123.3 (Serial0), len 100, rcvd 3 IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending IP: s=2.2.2.2 (Serial0), d=172.12.123.3 (Serial0), len 100, rcvd 3 IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending IP: s=2.2.2.2 (Serial0), d=172.12.123.3 (Serial0), len 100, rcvd 3 IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending IP: s=2.2.2.2 (Serial0), d=172.12.123.3 (Serial0), len 100, rcvd 3 IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending IP: s=2.2.2.2 (Serial0), d=172.12.123.3 (Serial0), len 100, rcvd 3

Yes! Default static routes serve two major purposes, one of which we've just seen - we can send data to networks that have no specific entry in the routing table. This also helps to keep routing tables concise and complete, and as you advance in your Cisco studies, you'll learn that it's important to control the size of the routing table while keeping it complete. Static routes have their place, but they're not terribly scalable. Scalability refers to a network feature or protocol's ability to remain useful without a great deal of manual intervention as the network grows, and it's a term you'll hear often in your Cisco studies and your real-world job. Static routes do not dynamically adapt to network changes, and they can be a pain to keep up withas your network grows. That's why they're not considered very scalable. However, I've run into the following topology more than once where the spoke routers weren't exactly top-of-the-line, and static default routes worked beautifully without the additional overhead of a routing protocol.

Anytime you have a situation where there's only one possible next-hop address for all traffic, static default routes may well fit the bill. Here, a static route on each spoke that points to the hub may be all you need! Using static routes in this situation does cut down on routing protocol overhead - actually, the overhead is eliminated if you don't use a routing protocol. Watch your hub configuration, though. The hub is likely the company's connection to the Internet, plus you've got multiple spokes, so you don't want to use a default static route. You'll need individual static routes, some pointing to the spokes and others to the ISP router.

"Why Does My Static Route Say 'Directly Connected'"? Earlier in this section, I told you that we've got two options for the end of the ip route command:

the local router's exit interface the remote router's next-hop IP address

We used the next-hop IP address in the previous lab, so let me show you an oddity you'll note in your routing table when you configure ip route using the local router's exit interface. I'll configure a static host route on R1 (a host route being a route to one and only one destination): R1(config)#ip route 172.12.123.2 255.255.255.255 serial0 Now let's look at the routing table:

R1#show ip route Codes: C - connected, S - static 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks S 172.12.123.2/32 is directly connected, Serial0

Everything looks good, but notice that the route mentions "directly connected"? This is a static route, not a directly connected on, as indicated by the letter "S" in the left-hand column. You'll see this when you configure a static route using the local router's exit interface. Don't let it throw you, it's just one of those things. Changing The Administrative Distance OfA Static Route The default AD of a static route is 1; the only route type considered more trustworthy is a directly connected route, which has an AD of zero. There may be times when you want to change the AD of a static route, and we can do that with the distance option. First, we're going to examine the theory of and configure RIP, and after the RIP section we'll take a look at this kind of route - a floating static route. Distance Vector Routing The main distance vector protocol in use in today's networks is the Routing Information Protocol (RIP). A less popular distance vector protocol is the Interior Gateway Routing Protocol (IGRP). IGRP is still in some production networks, but it's no longer on the CCNA exams and it's not even supported by recent IOS versions. Therefore, we'll spend all of our time here studying RIP. Before we head into a detailed discussion of RIP, there are two distance vector routing loop prevention behaviors you should know about - split horizon and route poisoning. A routing loop occurs when an overall path to a destination in the packet enters a loop where the packet is routed in an unending circle. Loops generally occur due to router misconfiguration or poor network design. Split Horizon And Route Poisoning Split Horizon is a simple yet powerful routing loop avoidance feature. The rule of split horizon is that a route cannot be advertised out the same interface upon which the advertisement for that same network was originally received. That's simple enough, and so is the concept of route poisoning. Route Poisoning occurs when a route becomes unavailable. You'd think that a distance vector routing protocol would simply stop advertising a route when it becomes unavailable, but that's not quite what happens. With route poisoning, the router with the failed route continues to advertise the route, but with a metric indicating the route is unreachable. With RIP, that means advertising the route with a metric of 16, which RIP considers an unreachable route.

Upon receipt of the advertisement containing the metric of "unreachable", the downstream routers remove the network from their routing tables, and will no longer advertise that route. If a distance vector protocol simply stopped sending advertisements for the lost route, other routers in the network would continue to advertise the now-unavailable route. This is because distance vector protocols converge slowly. Convergence occurs when routers have agreed that a network change has taken place, and this can take a while in distance vector networks. Too long, as the following example illustrates.

In this full-mesh network, R3 is advertising the network of its directly attached Ethernet interface to both R1 and R2. R1 is receiving updates for that network from both R2 and R3. R1 will accept the routing update from R3, and accept and then discard the update from R2 since the metric is higher than the update received from R3. If the Ethernet network on R3 becomes unavailable, why doesnt R3 simply stop advertising the route, rather than advertising it with an unreachable metric? Consider what would happen if R2 sent a routing update to R1 while R3 simply stopped advertising the route.

Distance vector protocols do not converge quickly. If R3 simply stops advertising network 3.0.0.0, R2 will still have the route in its routing table and will continue to advertise it to R1. From R1s perspective, the more direct route will time out while it continues to get an advertisement for the route from R2. Eventually, R1 will install theroute it's getting from R2 into its routing table, resulting in continued transmission of data to an unavailable network. Neither R1 nor R2 has any way of knowing that 3.0.0.0 is down. Worse, R1 will then begin to advertise the 3.0.0.0 network to R3! It's a bad situation that will just get worse - but what I've described here does not happen, thanks to route poisoning.

When network 3.0.0.0 becomes unavailable, R3 continues to advertise it, but with a metric indicating that it is unavailable. (In RIP, that metric is 16, as shown below.) R1 and R2 will receive that route, see that the network is unavailable, and will no longer advertise it. The result is that R1 will not receive any route to the downed network from either R2 or R3. I know we haven't gotten to RIP yet, but you'll see the following command quite a few times in this section. When you see a metric of 16 in a RIP update, that route has been poisoned as RIP considers a route with a metric of 16 to be unreachable.
R3#deb ip rip RIP: sending v2 update to 224.0.0.9 via Serial0 (172.12.123.3) 172.12.123.0/24 -> 0.0.0.0, metric 1, tag 0 1.1.1.1/32 -> 172.12.123.1, metric 2, tag 0 2.2.2.2/32 -> 172.12.123.2, metric 3, tag 0 3.3.3.3/32 -> 0.0.0.0, metric 16, tag 0

And speaking of RIP.... The Routing Information Protocol There are two versions of RIP, and while you're almost always going to run the more recent of the two, you need to know about them both for the exams and just in case you do run into the original version in the field. We're going touse almostthe same network we used in the static route

discussion here in our RIP discussion, with the only difference being an additional loopback address, 1.1.1.1, added to R1.

The static routes from the previous discussion have been removed, and here's how we do that:
R3#conf t Enter configuration commands, one per line. End with CNTL/Z. R3(config)#no ip route 2.2.2.0 255.255.255.0 172.12.123.1 R1#conf t Enter configuration commands, one per line. End with CNTL/Z R1(config)#no ip route 0.0.0.0 0.0.0.0 172.12.123.2

If you're ever in doubt of how to remove a command from a Cisco router or switch, putting "no" in front of the original command will do it 99% of the time. Additionally, all of the masks on the loopbacks are now 255.255.255.255, a typical mask for a loopback. This is a host mask. We verify the routes are indeed gone with show ip route. Always trust, but always verify.
R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, area Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0 R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP Gateway of last resort is not set 3.0.0.0/32 is subnetted, 1 subnets C 3.3.3.3 is directly connected, Loopback0 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0

The static routes are gone and we're ready for our next lab! When a router is configured to run the dynamic routing protocol RIP, the router will send routing updates out the interfaces that are RIP-enabled. To illustrate, we'll configure RIP on R1 with the router rip command, and then enable RIP for the 1.0.0.0 and 172.12.123.0 networks. We're also going to turn off RIP's autosummarization feature -there's a detailedexplanation of what this does in the EIGRP section, andit is a common command for real-world RIP deployments.
R1(config)#router rip R1(config-router)#no auto-summary R1(config-router)#network 172.12.123.0 R1(config-router)#network 1.0.0.0

We're going to continually come back to the show ip protocols command throughout the course, and you should be very familiar with this command and its output before taking the CCENT and CCNA exams.
R1#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: rip Default version control: send version 1, receive any version Interface Send Recv Triggered RIP Key-chain Loopback0 1 1 2 Serial0 1 1 2 Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 1.0.0.0 172.12.0.0 Routing Information Sources: Gateway Distance Last Update Distance: (default is 120)

Going through the output from top to bottom, we see that...

RIP is running ("Routing Protocol is 'rip'") Updates are being sent every 30 seconds (the default) Version 1 updates are being sent, with either version accepted ("default version control") The loopback0 and serial0 interfaces are RIP-enabled Autosummarization has been disabled successfully with no autosummary ("Automatic network summarization is not in effect") The networks being advertised are 1.0.0.0 and 172.12.0.0

The other information is important, but these are the basics we need to master first. The first thing we're going to do is change the version default (but you should have that default in mind on exam day!). Why change the default? Version 1 is quite limited in that it is a classful protocol, while Version 2 is a classless protocol. This is one time when it's good to be classless! Later in the course,you'll be introduced to manual route summarization and variable-length subnet masking (VLSM). I won't show you those

advanced skills now because we need to concentrate on the basics, but I do want you to know that RIPv1 does not support either of those, while RIPv2 supports both.

RIPv1: classful, no VLSM, no manual route summarization RIPv2: classless, VLSM support, manual route summarization support

To force RIP to send and receive only v2 updates, use the version 2 command under the RIP process.
R1(config)#router rip R1(config-router)#version 2

Verify with show ip protocols.

R1#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 5 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: rip Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain Loopback0 2 2 Serial0 2 2 Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 1.0.0.0 172.12.0.0 Routing Information Sources: Gateway Distance Last Update Distance: (default is 120)

Let's go to both R2 and R3 and enable RIP on the loopback and serial interfaces. We'll hardcode both RIP configs to run V2 only and disable auto-summarization as well.
R2(config)#router rip R2(config-router)#version 2 R2(config-router)#no auto-summary R2(config-router)#network 172.12.123.0 R2(config-router)#network 2.0.0.0 R3(config)#router rip R3(config-router)#version 2 R3(config-router)#no auto-summary R3(config-router)#network 172.12.123.0 R3(config-router)#network 3.0.0.0

Let's look at R1's routing table to see if R1 sees the loopback networks on the other routers.
R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP Gateway of last resort is not set 1.0.0.0/32 C 1.1.1.1 2.0.0.0/32 R 2.2.2.2 is subnetted, 1 subnets is directly connected, Loopback0 is subnetted, 1 subnets [120/1] via 172.12.123.2, 00:00:03, Serial0

 3.0.0.0/32 is subnetted, 1 subnets R 3.3.3.3 [120/1] via 172.12.123.3, 00:00:07, Serial0 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0

There they are! The letter "R" indicates a route discovered via RIP. Here's a handy little trick for you that does make examining routes a little easier - to see only RIP-discovered routes, use the command show ip route rip.
R1#show ip route rip 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:04, Serial0 3.0.0.0/32 is subnetted, 1 subnets R 3.3.3.3 [120/1] via 172.12.123.3, 00:00:09, Serial0

Going from left to right, let's examine that information:

The "R" indicates a route discovered by RIP The next values are the network number and the network mask, respectively The numbers in the brackets are the administrative distance and the metric of the route - more about the metric later in this section. Administrative distance is discussed in the Troubleshooting section. The IP address following the word "via" is the next-hop IP address for the route The time shown is the amount of time since the last update concerning that particular route was received Finally, the interface name is the interface that received the update

Can R1 ping the loopbacks of the other two interfaces?

R1#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms R1#ping 3.3.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms

Yes! And the following outputs show that each of the spoke routers can ping the two remote loopbacks as well.
R2#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms R2#ping 3.3.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 132/134/144 ms R3#ping 1.1.1.1

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms R3#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 132/135/148 ms

The reason we call RIP a dynamic routing protocol is that it can dynamically discover newly added networks- a major improvement over static routes. Sure, we could add a few static routes to all three of our routers and get the same result that we have now, but what happens when the network grows? What if three other networks are added to R3? Let's configure three more loopbacks on R3 with three different network numbers and find out.

The IP addresses on the new loopbacks:

L1 - 33.3.3.3 L2 - 44.4.4.4 L3 - 55.5.5.5

If we relied on static routes, we'd have to go to both R1 and R2 and configure static routes to each of those networks. With a dynamic routing protocol, we just add the new networks to the routing process on R3 and we're all set! Before we add the new networks, though, let's run the command debug ip rip on R3 and watch the RIP updates being sent. I'll turn the debug off once we see an update sent and received.
R3#deb ip rip RIP: sending v2 update to 224.0.0.9 via Serial0 (172.12.123.3) 172.12.123.0/24 -> 0.0.0.0, metric 1, tag 0 1.1.1.1/32 -> 172.12.123.1, metric 2, tag 0 2.2.2.2/32 -> 172.12.123.2, metric 3, tag 0 3.3.3.3/32 -> 0.0.0.0, metric 1, tag 0 RIP: received v2 update from 172.12.123.1 on Serial0 1.1.1.1/32 -> 0.0.0.0 in 1 hops 2.2.2.2/32 -> 172.12.123.2 in 2 hops

 172.12.123.0/24 -> 0.0.0.0 in 1 hops R3#undebug all All possible debugging has been turned off

The great thing about a RIP debug is that you can actually see the routes contained in the routing update. (Not all protocols are so kind.) The first update is sent to 224.0.0.9,the multicast address reserved for RIPv2 updates. The incoming update from R1's serial0 interfacementions "hops" several times, where the outgoing update mentions a "metric". They're actually the same thing.Both versions of RIP use hop count for their metric, a measurement of how far it is to a remote destination. That's a serious limitation for RIP when it comes to Wide Area Networks (WANs), because RIP will consider bothpaths in the following example tohave the same metric:

R1 has two possible paths to get to R2,one via R3and anotherthroughR4. The path through R3 is over three times faster than the one through R4, but RIP would consider both paths to have the same number of hops, and would consider them to be equally fast. Not good. That's why you see RIPv2 on plenty of Local Area Networks (LANs), but not many WANs. Now back to our network! We'll use the network command under the RIP process to add the new networks to the RIP process.
R3(config)#router rip R3(config-router)#network 33.0.0.0 R3(config-router)#network 44.0.0.0 R3(config-router)#network 55.0.0.0

On R1, we'll see those three new networks appear in the routing table...
R1#show ip route rip 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:01, Serial0 33.0.0.0/32 is subnetted, 1 subnets R 33.3.3.3 [120/1] via 172.12.123.3, 00:00:04, Serial0 3.0.0.0/32 is subnetted, 1 subnets R 3.3.3.3 [120/1] via 172.12.123.3, 00:00:04, Serial0 55.0.0.0/32 is subnetted, 1 subnets R 55.5.5.5 [120/1] via 172.12.123.3, 00:00:04, Serial0 44.0.0.0/32 is subnetted, 1 subnets

R 44.4.4.4 [120/1] via 172.12.123.3, 00:00:04, Serial0

... and R1can ping all three of the new loopbacks, with no manual configuration needed on R1 at all. That's a scalable solution! You'll learn all about other routing protocols during your CCNA studies, including EIGRP and OSPF. In the meantime, make sure you have both static routing and RIP mastered before taking the CCENT and moving on to advanced studies. Configuring and troubleshooting routing is all about knowing the fundamentals. Viewing And Changing RIP Timers You've probably noticed the RIP timers in the output of show ip protocols:
R1#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds Invalid after 180 seconds, hold down 180, flushed after 240

It's rare you'll have cause to change these, but after a quick discussion of what these timers mean, I'll show you how to change them. updates - easy enough, that's how often RIP sends full routing updates invalid - If the router doesn't get an update for a route for this amount of time, the route is marked unreachable (hop count of 16) and it's advertised as such. The route is still used to forward packets, though, until one of the other timers expires. Default is 180 seconds. holddown - Routes go into holddown when they get a packet indicating that the route has a metric of 16 and is unreachable. The router will not accept an advertisement for that same route from another source until the holddown timer expires. Default is 180 seconds. flush - Overall amount of time between the last update received for a route and the point where the route is finally removed from the routing table. Default is 240 seconds. Note that this is an overall time; once the invalid timer expires at the default of 180 seconds, it's another 60 seconds until the route finally gets flushed from the table (240 - 180 = 60). It's rare that you have cause to change these timers, but you can do so with the timers basic command. You do have to specify the value of each timer, not just the one you want to change. You should also observe these rules when doing so, as per Cisco recommendations:

invalid timer should be at least three times the update timer holddown timer should be at least three times the update timer flush timer should be larger than both of the individual invalid and holddown timers

Floating Static Routes Just before we began our RIP studies, I mentioned that we can change

the default AD of a static route. Now that we know the basics of RIP, I want to show you a scenario where we just might want to do that. To illustrate , we'll use the following network topology and addressing scheme. All IP addresses end with the router's number. For example, R1's Serial0 interface on the 172.12.123.0 /24 networkhas an IP address of 172.12.123.1. Note that RIP is not running over the entire network -- it's not running over the serial link connecting R1 and R3's serial1 interfaces.

R1/R2/R3 Frame Network: 172.12.123.0 /24 R1 / R3 Serial Connection: 210.1.1.0 /24 R2 / R3 Ethernet Network: 172.12.23.0 /27

R1 has two next-hop addresses for the 172.12.23.0 /27 network:

R1#show ip route rip 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:04, Serial0 [120/1] via 172.12.123.3, 00:00:04, Serial0

If these routes are removed from the table, you want the next-hop IP address to be 210.1.1.3, whichis not running RIP but is connected to R3. A floating static route using that address as the next hop will look like this:
R1(config)#ip route 172.12.23.0 255.255.255.224 210.1.1.3 ? <1-255> Distance metric for this route name Specify name of the next hop permanent permanent route tag Set tag for this route <cr> R1(config)#ip route 172.12.23.0 255.255.255.224210.1.1.3 200

Using the option to change the static route's administrative distance (that's what "distance metric for this route" refers to) creates the static route, but it will not appear in the routing table unless the matching RIP routes leave

the table. Right now, the static route is not in the table:
R1#show ip route < code table removed for clarity > 172.12.0.0/16 is variably subnetted, 3 subnets, 2 masks C 172.12.13.0/24 is directly connected, Serial1 R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:21, Serial0 [120/1] via 172.12.123.3, 00:00:05, Serial0 C 172.12.123.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0

Serial0 will now be closed, so R1 will no longer be receiving RIP updates from R2 or R3. The floating static route is now in the table. Note the administrative distance in the brackets is now 200.
R1#show ip route < code table removed for clarity > 172.12.0.0/27 is subnetted, 1 subnets S 172.12.23.0 [200/0] via 210.1.1.3 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0 C 210.1.1.0/24 is directly connected, Serial1 R1#ping 172.12.23.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.23.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

When we reopen R1's S0 interface, the RIP updates will again be received by R1 and the floating static route will be removed from the table due to its higher AD.
R1(config)#int s0 R1(config-if)#no shutdown R1#show ip route < code table removed for clarity > 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:17, Serial0 [120/1] via 172.12.123.3, 00:00:00, Serial0 C 172.12.123.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0 C 210.1.1.0/24 is directly connected, Serial1

In most networks, you will be running RIP over that entire network, but take it from me - sooner or later you're going to run into a situation just like this. A floating static route is the perfect solution! There's another option there you should be aware of:
R1(config)#ip route 3.3.3.3 255.255.255.255 serial0 ? <1-255> Distance metric for this route A.B.C.D Forwarding router's address name Specify name of the next hop permanent permanent route tag Set tag for this route <cr>

By configuring the permanent option, theoretically the route should remain in the routing table when the interface used to reach that destination is shut. That's the theory. In the real world, I've seen this command work and I've seen it fail. I personally don't use it a great deal. For the exam, you should know the theory of the permanent option (as well as everything else about the ip route command!), but in the real world, I wouldn't depend on it. "Hot Spots And Gotchas" Static Routing: Create static route commands with the ip route command. If you do not specify an administrative distance at the end of the command, the default of 1 is used. Static routes can come in handy when you need to conserve bandwidth and/or router resources. Particularly in hub-and-spoke networks, static routes may be all you need. Default static routes in particular can help to keep a routing table smaller than it would be with routes from a dynamic routing protocol, but still allow the router to reach all necessary remote networks. Most static routing errors are due to a simple misconfiguration. Watch your typing. :) To have a static route remain in the routing table even when the exit interface is shut, use the permanent option at the end of the ip route command. Floating static routes are simply static routes that are assigned a higher AD than that of the routing protocol(s) running on the router. That way, these routes only enter the routing table if the matching route put there by the dynamic routing protocol is no longer present. RIP and Distance Vector routing: The rule of split horizon states that a router cannot advertise a route back out the same interface upon which the route was originally learned. Route poisoning is the process of marking a route with a metric of "unreachable". For RIP, "unreachable" is a hop count of 16. Split horizon, route poisoning, and the RIP timers holddown, invalid, and flush are all used to prevent routing loops. RIP can be run in multivendor environments. To see the version(s) of RIP running on a router, run show ip protocols and/or debug ip rip.

An advantage of running RIP over OSPF is that it is less complex to configure, and it is easier on the router's resources (CPU and memory). After that, the scales tip heavily in OSPF's favor for reasons you'll read about in the OSPF section. RIP uses the Bellman-Ford algorithm, as opposed to EIGRP (DUAL) and OSPF (SPF, Dijkstra). The major drawback to RIP is it use of hop count as its sole metric. RIP route brackets show the administrative distance first and the metric second. RIP version differences: RIPv2 supports VLSM, RIPv1 does not. RIPv2 includes subnet mask information in updates, RIPv1 does not. RIPv2 multicasts updates to 224.0.0.9, RIPv1 broadcasts updates to 255.255.255.255. RIPv2 supports update packet authentication, RIPv1 does not. They do both recognize a metric of 16 as "unreachable". Recommended Video Viewing: CCNA Video Boot Camp on OSPF (Hosted By Udemy.com - free course) http://www.udemy.com/ccna-boot-camp/

My Full CCNA Video Boot Camp - Over 22 Hours Of Video - And A Secret Discount Link! See the course here, and watch an hour of the OSPF section for free! http://www.udemy.com/ccna-on-demand-video-boot-camp/

Get a $10 discount by enrolling at the following link - it's like getting this ebook for free! http://www.thebryantadvantage.com/CCNAStudyPackageUpgrade.htm Floating static route lab - three parts, listed in order. Do NOT miss this series!

http://www.youtube.com/watch?v=jNN4Xt59pJ8 http://www.youtube.com/watch?v=w0nIswQePm0 http://www.youtube.com/watch?v=zjJSnCDCMFg 3:00 Video Boot Camp on static routing: http://www.youtube.com/watch?v=F-Z7VMCUP98 5:00 Video Boot Camp on static routes and distances: http://www.youtube.com/watch?v=Jf0dwZ9XucA Main YouTube Channel page - subscribe today and never miss a new video! http://www.youtube.com/user/ccie12933
Back To Index

Copyright 2012 The Bryant Advantage. All Rights Reserved.