Effect of redistributed connected on RIP metrics
Comments(0)
Came across an interesting post on Groupstudy awhile back (sorry I don’t have the link to it)
==========================================================
RIP speakers tell their neighbors what metric to install in their routing tables. So, for example, if a RIP speaker advertises some directly connected interface, it doesn’t advertise a metric of zero – it advertises a metric of one. And since on the router on which you’re configuring the redistribution already has the redistributed routes via whatever it is you’re redistributing from, the metric value you use in the ‘redistribute’ command has no local significance. So the value that you configure is the value you want to tell your RIP “neighbors” to install in their routing
tables.
—–Original Message—–
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of ccie preparation
Sent: Saturday, February 14, 2009 12:28 PM
To: Cisco certification
Subject: RIP metric
Folks,
I have 4 lookbacks that i created on one router. I redistribute the loopbacks in the rip process with a metric of 3. When I go to the adjoinging router which is also running RIP, I see that the metric is still 3. Shouldn’t the router redistributing the loopbacks into RIP increment the metric by 1 before forwarding the updates to the adjoining router?
Any help would be appreciated?
Thanks
Blogs and organic groups at http://www.ccie.net
=========================================================
Now this is interesting because as we know, a router running RIP normally will increment the metric of a route by 1 before sending it to a neighbor.
However when a router is redistributing a connected route into RIP, as mentioned above, the metric specified in the redistribute command does look to be what is advertised to a neighboring RIP router.
Let’s refer back to my original simple topology:
Now for R1, instead of having a RIP network statement for Lo0 (1.1.1.1), let§s remove it and instead redistribute it into RIP with a metric of 3.
- R1(config-router)#no net 1.0.0.0
R1(config-router)#redistribute connected metric 3
- R1#sh ip rip d 1.1.1.1 255.255.255.255
1.1.1.1/32 redistributed
[3] via 0.0.0.0,
Now lets see what metric R1 advertises to R2:
- R1#
*Mar 1 01:45:17.031: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.12.1)
*Mar 1 01:45:17.031: RIP: build update entries
*Mar 1 01:45:17.031: 1.1.1.1/32 via 0.0.0.0, metric 3, tag 0
Cool.
Now we can have R2 request a full routing table (RIP routes) from its neighbors by issuing clear ip route *.
This is a very useful command whenever you want to quicken the receipt of updated RIP routing info, rather than waiting 
- R2#clear ip route *
R2#sh ip ro 1.1.1.1
Routing entry for 1.1.1.1/32
Known via “rip”, distance 120, metric 3
Redistributing via rip
Last update from 10.0.12.1 on FastEthernet0/0, 00:00:08 ago
Routing Descriptor Blocks:
* 10.0.12.1, from 10.0.12.1, 00:00:08 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1
Sure enough, R2 has a metric of 3 for 1.1.1.1/32.
Normal rules apply when R3 then advertises 1.1.1.1/32 to R3:
- R3#sh ip ro 1.1.1.1
Routing entry for 1.1.1.1/32
Known via “rip”, distance 120, metric 4
Redistributing via rip
Last update from 10.0.23.2 on FastEthernet0/0, 00:00:09 ago
Routing Descriptor Blocks:
* 10.0.23.2, from 10.0.23.2, 00:00:09 ago, via FastEthernet0/0
Route metric is 4, traffic share count is 1
Naturally, if we also apply an offset-list to R1 to increase the metric of all routes R1 advertises to R2 by 7, then R2 will have the route to 1.1.1.1/32 with metric 10:
- R1(config-router)#offset-list 0 out 7 f0/0
R1(config-router)#^Z - R2#clear ip route *
R2#sh ip ro 1.1.1.1
Routing entry for 1.1.1.1/32
Known via “rip”, distance 120, metric 10
Redistributing via rip
Last update from 10.0.12.1 on FastEthernet0/0, 00:00:04 ago
Routing Descriptor Blocks:
* 10.0.12.1, from 10.0.12.1, 00:00:04 ago, via FastEthernet0/0
Route metric is 10, traffic share count is 1
Now you may ask: what if NO metric is specified in the redistribute connected statement? What metric does R1 advertise to R2 then?
The answer is 1
- R1(config)#router rip
R1(config-router)#no offset-list 0 out 7 f0/0
R1(config-router)#no redistribute connected metric 3
R1(config-router)#redistribute connected
R1(config-router)#^Z - R2#sh ip ro 1.1.1.1
Routing entry for 1.1.1.1/32
Known via “rip”, distance 120, metric 1
Redistributing via rip
Last update from 10.0.12.1 on FastEthernet0/0, 00:00:27 ago
Routing Descriptor Blocks:
* 10.0.12.1, from 10.0.12.1, 00:00:27 ago, via FastEthernet0/0
Route metric is 1, traffic share count is 1
Thats it
The above behaviour is important to bear in mind if you are ever asked in a lab task to ensure that R2 eg, receives a route from R1 with a specific RIP metric, and the route in question is one that R1 redistributed into RIP.
Hope this helps.
