Subnetting Made Easy And Other Cisco Tidbits

RIP - Routing Information Protocol
Monday, 8 June 2009

Whether you are taking ICND1, CCNA, CCNP, CCDA, CCIE etc you should all know about RIP. It is very rare for me to come across RIP in my day-to-day work hence I tend to forget some of the nuances behind it. I will focus on RIPv2 but will touch upon RIPv1 in terms of comparison.

Metric

RIP is a distance vector protocol which uses the notion of hop counts as its metric with any one router up to a maximum of 15 hops away from another router. What this means is that if there is a network that is 16 hops or more away from your RIP router and your entire routing domain is running RIP you won't be able to reach that network. It therefore means that RIP is not suitable for large networks. RIPv1 and v2 both use the same maximum hop count as their metric.

Classful and Classless behaviour

RIPv1 is classful and RIPv2 is classless. What this means in very simple terms is that RIPv1 does not send the subnet mask in its routing updates whereas RIPv2 does and as such RIPv2 supports Variable Length Subnet Masks. If a router running RIPv1 has a different class of address on two interfaces (e.g. a Class A address on one interface and a Class B address on another interface) an update going out of the Class B interface will automatically summarise the Class A networks in that update to the default mask of /8. For example, the router may have learned about 10.1.2.0/24 on one interface but because it is advertising that network out of an interface with a different class of address it would advertise it as 10.0.0.0/8. This doesn't happen with RIPv2 as you can issue the no auto-summary command under the routing process and the router will advertise 10.128.1.0/24. This is especially important when it comes to discontiguous networks which is a fancy name for a class of network that has another class of network in between, for example:

(Class A)R1(Class B)-->(Class B)R2(Class B)-->(Class B)R3(Class A)

Here R2 could learn a route to 10.0.0.0/8 from both R1 and R3 as both R1 and R3 would have automatically summarised the Class A address to a /8.

A point that is often overlooked with RIP is the behaviour when the same class of address is used throughout. If my router had an interface with a Class A address but with a non-Class A subnet mask (e.g. 10.1.2.0/24) and I received an update about 10.1.3.0/24 through that interface, the RIP router would assume that it should apply the mask configured on that interface (i.e. a /24) and not the default Class A mask of /8.

Basic Configuration

Always advertise the classful network so if you want to advertise 10.1.2.0 you only need to specify 10.0.0.0 in the network command.

conf t
router rip
version 2 <--RIPv2 enabled
network 10.0.0.0
no auto-summary <--turn off automatic summarisation (I do this as a matter of course)

What does the network command tell the router to do? In RIP it tells the router to do three things:

1. Advertise all networks that form part of the subnet specified
2. It tells the router to listen to RIP updates on the interfaces with IP addresses in that configured subnet.
3. It tells the router to send RIP updates out of the interfaces with IP addresses in that configured subnet.

Passive Interface

The passive-interface command tells a router's interface to stop sending updates out of that interface. Note here that the interface will still receive RIP updates because it never forms neighbour adjacencies, and just receives information from other RIP routers.

router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface FastEthernet0/0 <--stops RIP sending updates out of fa0/0

Be aware that you can make all interfaces passive by issuing the passive-interface default command. This might be desirable when you want all interfaces except one from sending updates. For example, you may only want fa0/0 sending RIP updates so you make every interface passive by default and then issue the no passive-interface [interface] command:

router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface default <--stops RIP updates from being sent out of all interfaces
no passive-interface FastEthernet0/0 <--allows RIP updates to be sent out of that interface

How do we stop updates from being received?

As we have seen the passive-interface command tells our router to not send RIP updates out of the specified interface but that same interface can still receive RIP updates. In order to prevent updates from being received you should use something called a distribute-list. A distribute-list filters out routes from entering the routing table by referencing a pre-configured access-list or prefix-list.

For example, let's create an access-list:

access-list 1 permit any

The syntax of a distribute-list when using an access-list is as follows and is configured under the routing process:

distribute-list [access-list-number_or_access-list-name] [in | out] [interface]

If there is a match with a deny statement in the access-list then that route is filtered out of the routing update. If you look at my access-list you will see that I am, in effect, matching everything in my access-list so all routes should be filtered out.

Using the earlier configuration example, I will use a distribute-list to stop updates being received on fa0/0 and passive-interface from sending updates out of fa0/0.

access-list 1 deny any

router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface FastEthernet0/0 <--stops RIP sending updates out of fa0/0
distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1

You could replace the passive-interface command with a distribute-list. To do this make sure your access-list permits everything as in my preconfigured ACL 1 and apply it outbound on the outgoing interface:

access-list 1 permit any
router rip
version 2
network 10.0.0.0
no auto-summary
distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1
distribute-list 1 out FastEthernet0/0 <--filter outgoing updates on fa0/0 as specified by ACL 1

Administrative Distance (AD)

RIP has an AD of 120. Cisco uses AD as a measure of trustworthiness about a certain route. If there are two routes to the same network learnt by different routing protocols then the AD is used as a tiebreaker. The routing protocol with the lowest AD is considered to be more trustworthy and the route learned from that routing protocol will be installed into the routing table. Below are some of the ADs of static routing and routing protocols:

Connected Interface = 0
Static route = 1
EIGRP Summary = 5
eBGP = 20
Internal EIGRP = 90
IGRP = 100
OSPF = 110
ISIS = 115
RIP = 120
EGP = 140
ODR = 160
External EIGRP = 170
iBGP = 200
Unknown = 255

Looking at those ADs, RIP is not a terribly trusted protocol and equivalent routes learned by static, eBGP, Internal EIGRP, IGRP, OSPF, and ISIS would be installed in the routing table before a RIP route. Of course you can change the AD of a routing protocol by issuing the distance command under the routing process:

router rip
version 2
distance 90

Interestingly if you set the distance to 255 no routes learned by that routing protocol will be installed in the routing table.

Sending Updates

RIPv1 broadcasts its routing updates to 255.255.255.255 whereas RIPv2 multicasts its updates to 224.0.0.9. Both use UDP Port 520 at the Transport Layer. A router's full routing table is sent every 30 seconds to the IP address above depending on whether v1 or v2 is used. There are also triggered updates which are sent when a route in a router's routing table changes.

When a router sends its update it adds 1 to the metric of each route it is advertising so that receiving routers know the metric to get to that route. For example, if a router had a route to 192.168.1.0/24 with a metric of 2 , it would advertise it with a metric of 3.

Sending and Receiving version on interfaces

By default a RIP router will send only v1 updates out of an interface but receive both v1 and v2 updates. This allows for a mix of v1 and v2 capable routers. If your router is running RIPv2 it can only send and receive v2 updates only. You can configure it yourself under an interface:

interface Fastethernet0/0
ip rip receive version [1 | 2 | 1 2]
ip rip send version [1 | 2 | 1 2]

Timers

It is worth fully understanding how the timers in RIP work and what their default values are. They are:

Update Timer = 30 seconds
Invalid Timer = 180 seconds
Holddown Timer = 180 seconds
Flush Timer = 240 seconds

When a route is learned via RIP the Invalid and Flush timers are started for that route and are reset when that route is learned again. In normal operation this should be every 30 seconds as the router that has advertised this route should be sending their update every 30 seconds as dictated by the Update Timer. If there is a failure in the network that stops updates about this route from being received from the original advertising router, the Invalid and Flush timers will count up over 30 seconds towards 180 and 240 seconds respectively. If during that time our router learns the same route but from a different source and it has a worse metric (i.e. the hop count is greater than our current route) it won't install that update in its routing table until the original route is flushed. Once the Invalid Timer reaches 180 seconds the Holddown Timer starts counting down from 180 seconds with the Flush Timer only having 60 seconds left as it has already been running for 180 seconds. The route in the routing table will now show something like this:

R 192.168.1.0/24 is possibly down

Whichever is the first out of the Holddown and Flush timers to expire will cause the route to be removed/flushed from the routing table. By default this will always be the Flush timer as it has only 60 seconds left to elapse once the Invalid Timer reaches 180 seconds. Your router can now install previously heard updates that originally had a worse metric once those updates have been received again. You can quickly see why RIP has slow convergence time and would have to wait 240 seconds for the old route to be flushed and could wait for another 30 seconds to receive an update if one exists. That's 270 seconds, or three and a half minutes, which is bloody slow and it could be longer! You can adjust your timers using the timers basic update invalid holddown flush under the routing process:

router rip
version 2
timers basic 30 90 120 120

This sets the Update Timer to 30 seconds, Invalid Timer to 90 seconds, and both the Flush and Holddown Timers to 120 seconds.

Neighbour relationship

RIP has absolutely no concept of neighbours. It simply listens to updates from other routers and it never, ever, ever, sends Hellos, ok? This is what is meant when you hear the term "routing by rumour".

Split Horizon

Split Horizon stops a network being advertised out of an interface in which it has been learned. For example, if a router learned about network 192.168.1.0/24 on fa0/0 a RIP routing update out of fa0/0 would not contain 192.168.1.0/24. This is to prevent routing loops from occurring. Split Horizon is enabled by default on all interfaces except Frame Relay interfaces where the IP address is configured on the physical interface. You can turn off Split Horizon on an interface by issuing the no ip split-horizon command under an interface:

interface FastEthernet0/0
no ip split-horizon

Interestingly there is a special case where Split Horizon is overridden and that is called Poison Reverse. This is where a router receives an update on an interface specifying that a route is down, as indicated by a hop count of 16 (known as route poisoning), and the receiving router sends that update back out of the same interface. If you run a debug on RIP (debug ip rip) you will see Poison Reverse in action with a line of:

RIP: sending v2 flash update to 224.0.0.9

These flash updates are also seen in triggered updates.

Authentication

RIPv2 allows for passwords to be exchanged between RIP routers to secure updates and stop rogue RIP routers from being deployed in a network and disrupting it.

By default, RIP passwords are sent in plain-text but you can configure it to use MD5 which I would highly recommend if your network is susceptible to eavesdropping. In fact I would do it as a matter of course. As you would expect, the passwords on both sides must match in order for the RIP updates to be successfully exchanged.

You configure the passwords in global configuration mode using key-chains which are made up of keys which in turn have the password configured on them with optional send and receive lifetimes. Let's configure a basic key-chain (more advanced configuration can be seen here):

key-chain MyKeyChain
key 1
key MyPassword

To turn RIP authentication on you must configure it under the interface which will be sending the updates:

int fa0/0
ip rip authentication key-chain [key-chain-name]

So for my example it would be:

int fa0/0
ip rip authentication key-chain MyKeyChain

If you want to send your passwords in plain-text that is all there is to it as you remember RIP defaults to using plain-text passwords. You can specifically tell RIP to send passwords as plain-text by issuing the ip rip authentication mode text command under your outgoing interface as in:

int fa0/0
ip rip authentication mode text
ip rip authentication key-chain MyKeyChain

If you want to use MD5 instead then guess what one word needs to change in the example above? Yes, you've got it, replace the word "text" with "md5" as in:

int fa0/0
ip rip authentication mode md5
ip rip authentication key-chain MyKeyChain

Remember you have to explicitly set the authentication mode to MD5 as RIP defaults to using plain-text passwords.

Changing the next-hop router

Did you know that a RIP router can send updates about a route and change the next-hop router? As you would imagine, if a router, say R1, was to learn a route from R2, R1 would use R2 as the next-hop. R2, however, could conceivably change the next-hop from itself to another router.

In RIPv2, each RIP entry includes a space where an explicit IP address can be entered as the next hop router for datagrams intended for the network in that entry. This feature can help improve efficiency of routing by eliminating unnecessary extra hops for packets sent to certain destinations.

One common use of this field is when the most efficient route to a network is through a router that is not running RIP. Such a router will not exchange RIP messages and would therefore not normally be selected by RIP routers as a next hop for any network. The explicit Next Hop field allows the router to be selected as the next hop regardless of this situation.

The Next-Hop field is changed by using route-maps.

Using Offset Lists to change RIP's metric for a particular route

You change the metric received or advertised in RIP by using an offset-list. This is very similar in configuration to distribute-lists where you reference an access-list. The access-list will be checked against sent or received updates and the specified offset added to the metric. The basic syntax is:

offset-list [access-list-number_or_access-list-name] [in | out] [specified-offset] [interface]

Let's look at an example:

R1 has a route for 192.168.1.0/24 with a hop count of 0 as it is directly connected. We want to advertise that route to R2 with a hop count of 2. Remember that a RIP router will advertise out its hop count + 1 to other RIP routers so R2 would ordinarily receive a hop count of 1 to reach 192.168.1.0/24 via R1. Let's configure our offset-list:

access-list 1 permit 192.168.1.0 0.0.0.255

router rip
offset-list 1 out 1 FastEthernet0/0

Here offset-list 1 specifies ACL 1 which will match 192.168.1.0/24. This is applied outbound as specified by out. We add 1 to the metric of all routes matched by our access-list as specified by the 1 after the out keyword. Finally we specify the interface out of which our offset-list is applied.

Clearing RIP routes from the routing table to speed up convergence

As RIP has no concept of neighbours you can simply issue the clear ip route * command from privileged mode. This will clear out all routes and cause the router to send out RIP request packets. This wouldn't work with a routing protocol that has neighbours such as EIGRP as the routes are promoted to the routing table from the topology table. In that case you would have to tear down the neighbour adjacency.

Conclusion

I've tried to be as brief as possible as I don't see the point of reinventing the wheel as there are so many quality papers on RIP. I hope I've got enough detail in here for you to understand the basic operation of RIP and some of the extras that can be configured.

As always, if you have any questions about this topic please feel free to leave a comment and/or email me using the Contact Me tab at the top of the screen.

Good luck with your studies!

Posted byChris Bloomfield at 19:07  

Labels: Cisco, RIP, RIPv1, RIPv2, Routing Information Protocol

4 comments:

BULL'S EYE said... 1 July 2009 at 10:26  

i have a question.....the AD of a routing protocol by issuing the distance command under the routing process , if two protocols have the same AD which one will be preffered??

Great article.............Cant wait for OSPF ,bgp , multicast......Please Continue the gud work ,,,,,,You Rock!!!

Chris Bloomfield said... 1 July 2009 at 15:00  

This is a great question Joel and it depends on which way you look at it.

Let's say you have RIP and EIGRP running on a network. If you was to lower the distance of RIP to 90 so that it matched EIGRP, EIGRP will still be preferred as by default it has the lowest AD and it has not been changed. However, if we was to change the distance of internal EIGRP to 120 so that it matched RIP, the EIGRP route will still be preferred as it has the lowest AD by default.

HTH and there will be an EIGRP posting soon ;-)

BULL'S EYE said... 1 July 2009 at 16:42  

yeah!! thanks for showing me both the sides of the coin.....and i just cannot wait for your eigrp article!!!

prabhu.R said... 10 July 2009 at 08:27  

good effort....keep going....very simple and concept oriented....thank....

Post a Comment