RIP AD not working as expected

EdTheLad

I've configured a static route 3.3.3.0/24 on R3 and it's being redistributed into RIP. R1 is receiving this prefix via R3 hop count 1 and R2 hop count 2. I've modified the AD on the prefix received from R2 i.e. worst route. I expected that this should have no affect. It does, the worst metric rip route is now preferred. AD should only be evaluated between different routing protocols, rip should prefer the lowest hop count and ignore the AD. I tested this with eigrp and it works as expected.

Tested on ios 12.4 & 15.4 ,

*Apr 21 05:05:35.544: RIP: received v2 update from 192.168.1.10 on Ethernet0/0
*Apr 21 05:05:35.544:      3.3.3.0/24 via 0.0.0.0 in 2 hops
*Apr 21 05:05:35.544:      192.168.1.4/30 via 0.0.0.0 in 1 hops
R1#
*Apr 21 05:05:37.532: RIP: received v2 update from 192.168.1.2 on Ethernet0/1
*Apr 21 05:05:37.532:      3.3.3.0/24 via 0.0.0.0 in 1 hops
*Apr 21 05:05:37.532:      192.168.1.4/30 via 0.0.0.0 in 1 hops


R1(config)#access-list 1 permit 3.3.3.0 0.0.0.255
R1(config)#router rip
R1(config-router)#distance 50 192.168.1.10 0.0.0.0 1 
R1(config-router)#end
R1#


*Apr 21 05:10:37.645: RIP: received v2 update from 192.168.1.10 on Ethernet0/0
*Apr 21 05:10:37.645:      3.3.3.0/24 via 0.0.0.0 in 2 hops
*Apr 21 05:10:37.645:      192.168.1.4/30 via 0.0.0.0 in 1 hops
R1#
*Apr 21 05:10:49.725: RIP: received v2 update from 192.168.1.2 on Ethernet0/1
*Apr 21 05:10:49.725:      3.3.3.0/24 via 0.0.0.0 in 1 hops
*Apr 21 05:10:49.725:      192.168.1.4/30 via 0.0.0.0 in 1 hops


R1#sh ip route rip | b Gate
Gateway of last resort is not set

      3.0.0.0/24 is subnetted, 1 subnets
R        3.3.3.0 [50/2] via 192.168.1.10, 00:00:09, Ethernet0/0
      192.168.1.0/24 is variably subnetted, 5 subnets, 2 masks
R        192.168.1.4/30 [120/1] via 192.168.1.10, 00:00:09, Ethernet0/0
                        [120/1] via 192.168.1.2, 00:00:03, Ethernet0/1
R1#

R1(config)#int eth 0/0
R1(config-if)#shu        
R1(config-if)#shutdown 
R1(config-if)#do sh ip route | b Gate
Gateway of last resort is not set

      3.0.0.0/24 is subnetted, 1 subnets
R        3.3.3.0 [120/1] via 192.168.1.2, 00:00:02, Ethernet0/1
      192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks
C        192.168.1.0/30 is directly connected, Ethernet0/1
L        192.168.1.1/32 is directly connected, Ethernet0/1
R        192.168.1.4/30 [120/1] via 192.168.1.2, 00:00:02, Ethernet0/1
R        192.168.1.8/30 [120/2] via 192.168.1.2, 00:00:02, Ethernet0/1

AwesomeGarrett

EdTheLad, when was the last time you reviewed your TCP/IP Vol I notes?

EdTheLad

Whats that supposed to mean? you don't understand AD?

networker050184

Not the behavior I would expect to see either. Been quite a while since I've looked at RIP though I must admit. Maybe a generic routing table debug might show you something? I wouldn't be surprised to see weird behaviors in RIP in newer code though. Doubt it gets quite the regression testing it once did.

AwesomeGarrett

Well, this is the expected behavior from RIP. The reason you didn't see it in EIGRP is because you cannot change the AD on external routes on a per neighbor basis with EIGRP.

This is what I meant from reviewing your notes.

Don't take it the wrong way EdTheLad, I've learned quite a bit from you on the forum. But it is in the book in black and white.

EdTheLad

AwesomeGarrett wrote: »

Well, this is the expected behavior from RIP. The reason you didn't see it in EIGRP is because you cannot change the AD on external routes on a per neighbor basis with EIGRP.

Maybe you should have pointed that out in your first post!
Anyway, i've check internal eigrp and its behaving the same as rip. Maybe this is Cisco's intent, maybe their distance vector code is screwed, as per all the documentation states AD is supposed to be used between different routing protocols not comparing routes from one, that is what the metric is for. OSPF works as expected, if you configure 2 ospf processes and change the AD of one, it will prefer lowest cost path and ignore the AD.

AwesomeGarrett

LOL! We should hang out more. In fact, I'm going to post on your other thread.

_Gonzalo_

I wouldn´t say that it is an unexpected behaviour. I have never heard or read that AD should be ignored if the protocol is the same... That, for instance, would be an issue for internal and external routes when redistributing from one EIGRP AS to another.

As you mentioned that in OSPF it does happen, maybe it´s an OSPF feature... But as I said, never heard of it.

networker050184

Usually it's taught (and stated in Cisco documentation) that AD is only used to make a selection between two different routing protocols. So how OSPF behaves would match that. It's certainly possible there is a caveat in distance vector protocols, or just Cisco's implementation of them. I'm sure we could do some testing in other vendors or reading up on some RFCs to know for sure. I'm too occupied with other things at the moment to really care personally though!

_Gonzalo_

networker050184 wrote: »

Usually it's taught (and stated in Cisco documentation) that AD is only used to make a selection between two different routing protocols.

Well, I agree with that, but that´s not what I said. Certainly, AD was originally intended for that purpose, but you must agree that with EIGRP it cannot work that way... I don´t see how ignoring the AD would work for EIGRP external routes.

deth1k

Ed,
This is expected behavior. AD is locally significant. Not sure if you've gone through any of 360 labs but there are multiple CFG scenarios like this where route AD manipulation is used (under routing process), in fact they "make" you do it as the only option.
Cheers