RIP AD not working as expected

EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
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


Networking, sometimes i love it, mostly i hate it.Its all about the $$$$

Comments

  • AwesomeGarrettAwesomeGarrett Member Posts: 257
    EdTheLad, when was the last time you reviewed your TCP/IP Vol I notes?
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    Whats that supposed to mean? you don't understand AD?
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • networker050184networker050184 Mod Posts: 11,962 Mod
    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.
    An expert is a man who has made all the mistakes which can be made.
  • AwesomeGarrettAwesomeGarrett Member Posts: 257
    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.
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    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.
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • AwesomeGarrettAwesomeGarrett Member Posts: 257
    LOL! We should hang out more. In fact, I'm going to post on your other thread.
  • _Gonzalo__Gonzalo_ Member Posts: 113
    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.
  • networker050184networker050184 Mod Posts: 11,962 Mod
    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!
    An expert is a man who has made all the mistakes which can be made.
  • _Gonzalo__Gonzalo_ Member Posts: 113
    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.
  • deth1kdeth1k Member Posts: 312
    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
Sign In or Register to comment.