Now, each of the routers advertise their connected networks using RIP.
Here is the configuration for R1’s RIP process. You can see we’ve enabled version 2 and disabled auto-summary but it doesn’t matter for the purpose of this demonstration. TIP: the sh run | s rip’ command is us asking the IOS parser to look for the RIP section (s rip) in the configuration.
R1, R2 and R3 each have a copy of the RIP database containing all of the routers. Crucially however none of the routers advertise learnt networks back out of their networks connected to the switch , they only send their directly connected networks. This is because, as the split horizon rule dictates, we are learning the other networks via a broadcast interface so it is un-necessary to send that same learned route back out. If we did that then we would be advertising routers to neighbors which we didn’t have connectivity to.
For example, what if we disabled split horizon on R2. It would advertise connectivity to R3 and R1’s loopback interfaces. Of course those RIP adverts would have a metric (hop count) of one more than the best route but what if the best route was lost? In this case the route advertised from R2 would be the new ‘best route’ and since R2 doesn’t actually have any connectivity to the R1 or R3 loopback interfaces the traffic would get to R2 and be dropped. All of this is possible because of the painfully slow convergence timers in distance vector protocols like RIP. Indeed the dead interval is 3 minutes and the flush timer 4 minutes! Now then, it’s not all bad news. RIP does also have another very clever way of telling all connected RIP hosts on the same broadcast network that something bad has happened and you must flush your RIP tabels immediately (usually because an interface has gone down). This type of ‘triggered update’ is called ‘Poison Reverse’. This ‘poisoning’ of a lost route basically advertises an immediate route update for the lost network with a metric (hop count) of 16 which means ‘inaccessible’ - job done.
Lets see the poison reverse in action here We’ll shut down the loopback0 interface on R1. Our debugs are running on R2. Watch as R1 sends out the update for the lost route to 22.214.171.124/24.
First;y here is a normal update from R1 - notice it learned it from 126.96.36.199 which is R1’s interface closest to R2.
Now we’ve just shutdown the lo0 interface on R1. It immediately sends out an update telling us that route is dead (hop count 16).
Now we (R2) send an update ourselves, basically passing on the bad news to all other RIPv2 (we send it to 188.8.131.52 which is the multicast address used by RIPv2)
We also ‘hear’ the bad news from R3 who also, like us, passed it on...hey bad news does travel fast even in RIP.
Right, this is all good fun, but what about split-horizon? Well, you know, the best place to see split horizon NOT working well for us is on a frame relay network...so lets do that instead.
We’ll begin by configuring a basic RIP setup on R1 and R5. The RIP default will be sourced from R1 and sent to R5.
Here is the basic configuration to enable the RIP process and enable it on the network segment between R1 and R5. Notice the new (ish) pipe command ’s’ this is short for section. We’ve put the loopback0 interfaces for R1 and R5 into RIP - notice the network masks both both of these? The loopback interfaces are 184.108.40.206/24 and 220.127.116.11/24 for R1 and R5 respectively and yet in the RIP process the network statements are 18.104.22.168 and 22.214.171.124. There is no netmask statement to support the 24 bits of network so how does RIP know what to advertise? Well in fact version 1 of RIP would not be able to help here but version 2 (which we have enabled) does support VLSM and can send the netmask of associated with the ‘network’ of the interface configuration along with the advertisement of the route...phew. RIP is CLASSFUL, it’s not something you want to run in a modern network necessarily. We’ve also disabled summarisation to stop RIP sending the classful route...it will do it automatically so we need to do this if we have shared networks advertised (for this example it is unnecessary)
Right, lets have a look at the routing table on R1 and then on R5
See how RIP, because of the CLASSFUL network issue has advertised the networks between R1 and R2, R1 and R4 and R5 and R4? On a production network you can see how it might get out of control sending more routes than you actually wanted to? To stop this happening we’d normally apply the ‘passive-interface’ command to stop the router sending router updates to it’s neighbors on that shared interface. If you wanted to stop the router receiving the routes you would use a distribute-list or access-list denying UDP port 520 inbound.
Right do we want a defaultroute sending from R1 to R5 (and other neighbors). First we need R1 to have a defaultroute in it’s routing table, without it RIP will not send a defaut route it HAS to already be in the routing table.
Firstly lets send the default using static routing. We’re going to put a static defaultroute into R1’s routing table and point it at the null0 interface - you wouldn’t want to do this unless you wished to blackhole traffic to networks which were not in your routing table. Remember packets trying to get to unknown networks are dropped...this may be desirable...up to you.
Lets take a look at R1’s routing table
Lets take a look at R5’s RIP routes in the routing table to show you that static routes don’t just jump into the RIP process - we have to redistribute between routing protocols don’t we ;-)
Right so lets do that redistribute step now. We want to take that static route to null and pop it into RIP. Remember RIP routes are sent as full updates every 30 seconds so we’ll just wait...OK here is the ‘debug ip rip’ output.
Great news - lets take a look at the routing table and see if the default route is in there now.
OK so I just thought of something we can do here. The redistribution line allows us to do things like add hop count (metric) into the updates...lets take a quick look at that. Remember the metric right now is 1 (we’re one hop away).
Here is the debug on R5
Excellent - you know what though...I told you RIP full updates are sent every 30 secs but this arrived a second after I told R1 that the redistribution should have a metric of 5. Well this is a great feature of later versions of RIP called ‘triggered updates’. This type of update is sent immediately when there is a change rather than waiting.
NOTE: there is a cisco proprietary version of triggered updates which can be used between peers across point-to-point interfaces. This type of update differs in that no updates are ever sent unless their has been a change at which point only the routes which have changed are sent. It reduces update traffic across what could be a slow circuit.
Right so the metric is reflected in the routing table? Yes indeed [120/5] shows administrative distance 120 (default) and a metric of 5.
So that was redistribution but there is another way to get the default sent and thats using ‘default-information originate’. Using this method we get a little more control using route-maps and conditional advertising. Lets move on with this.
First we’ll tear down the static redistribution and check the route is gone from R5:
Trust me - the route is gone from R5 - screenshot overload ;-)
Right lets configure the default originate - make a note - we still need the default route to be alive on the router, no default in table = no advertising default
Here is the debug on R5...see the 0.0.0.0/0 coming in
Lets do a show ip rip database on R1 to see it is redistributing the default route (default originate is still a redistribution)
So we have the route in the table but before we close down here lets have a think back to what I was saying earlier about blackholing the traffic. Remember, if we don’t have a route with a shorter prefix than the default then we’re going to drop those packets right here. Now that may be what you want but it’s more likely that you’re advertising a default route because you want traffic to come to R1 because R1 is a gateway for your network e.g. a router before the internet. So lets think about it, if R1 is connected to the internet and we are advertising a default route to our internal routers so they send their packets to us...thats great. What if R1 loses connectivity to the internet though? All of that internal traffic is still going to be racing to R1 which is wasting bandwidth and ultimately unnecessary.
RIP default-information originate can help us out here with a technique called conditional advertising. To do this we use a route-map.
The route-map will ‘look’ for the existence of a route and if that route drops out then we’ll stop advertising the default...sound right to you? Well in our example we are going to say that the interface connected between R1 and R2 is the uplink to the internet. I’ve configured a basic OSPF neighbour relationship between R1 and R2 and R2 is sending it’s loopback0 network (126.96.36.199/32) to R1. Sp, if we see the OSPF router for 188.8.131.52/32 go away then we will suggest that our link to the internet has gone away and we will want to stop advertising the default route. OK lets get on with it then. Here is the OSPF route in R1’s routing table
First we setup the route-map. We want to match the route for the OSPF route learned from R2 - 184.108.40.206/32. A standard access-list will match the IP address for the network. The route-map matches existence of that route.
Lets add that route-map to the conditional default-route advertisement.
Right - lets check...is the default route in R5’s routing table?
Ok, lets shutdown the interface to R2. We see the OSPF go down, the route is gone.
The route has gone from R5...job done
Ok, that wraps it up for this tech article. We’re doing these all the time, be sure to keep checking back.
Thanks for reading