Interesting RIP behavior
As per the attached image, i've got three routers connected in a square triangle 
.
Configs are as below, quite simple setup.
I start off without the manual summary configured on R1, everything is fine, all routing is as expected.
I add the manual summary to R1 and the following events occur.
1) R1 sends a flash update to R3, prefix 15.15.0.0/16(1), metric in brackets! R3 will update its RIB and send a flash update to R2(2), it won't send a flash update back to R1 due to split-horizon.
2) R2 receives the prefix 15.15.0.0/16(2) from R3, updates it's RIB and sends a flash update 15.15.0.0/16(3) to R1. No flash update is sent to R3 due to split-horizon.
3) When R1 receives the prefix 15.15.0.0/16(3) from R2, it updates it's RIB, and sends a poison prefix 15.15.0.0/16(16) to R3.
4) R3 will receive the poisoned route, the prefix is removed from the RIB and R3 will send a flash update with the poisoned prefix to both R1 and R2. This poisoned triggered updates will propagate throughout the network until all ribs are flushed of 15.15.0.0/16.
5) Eventually, R1 will send the summary to R3 via a standard update and this cycle will continue again.
Step 3) is the interesting part!
I found that this behaviour occurs only if a prefix received on R1 matches the interface summary. The prefix will be poisoned out the summary interface. If the poisoned route makes its way back via an alternative path to R1, the cycle will continue. If no alternate path existed, R1 would keep the RIB entry i.e. prefix received by R2 and on the next update send the summary to R3, i.e. stable network.
Looks like a summary route feedback protection mechanism i never knew about!
.Configs are as below, quite simple setup.
I start off without the manual summary configured on R1, everything is fine, all routing is as expected.
I add the manual summary to R1 and the following events occur.
1) R1 sends a flash update to R3, prefix 15.15.0.0/16(1), metric in brackets! R3 will update its RIB and send a flash update to R2(2), it won't send a flash update back to R1 due to split-horizon.
2) R2 receives the prefix 15.15.0.0/16(2) from R3, updates it's RIB and sends a flash update 15.15.0.0/16(3) to R1. No flash update is sent to R3 due to split-horizon.
3) When R1 receives the prefix 15.15.0.0/16(3) from R2, it updates it's RIB, and sends a poison prefix 15.15.0.0/16(16) to R3.
4) R3 will receive the poisoned route, the prefix is removed from the RIB and R3 will send a flash update with the poisoned prefix to both R1 and R2. This poisoned triggered updates will propagate throughout the network until all ribs are flushed of 15.15.0.0/16.
5) Eventually, R1 will send the summary to R3 via a standard update and this cycle will continue again.
Step 3) is the interesting part!
I found that this behaviour occurs only if a prefix received on R1 matches the interface summary. The prefix will be poisoned out the summary interface. If the poisoned route makes its way back via an alternative path to R1, the cycle will continue. If no alternate path existed, R1 would keep the RIB entry i.e. prefix received by R2 and on the next update send the summary to R3, i.e. stable network.
Looks like a summary route feedback protection mechanism i never knew about!
R1#sh ip int bri | ex una Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.1.9 YES manual up up FastEthernet0/1 192.168.1.1 YES manual up up Loopback0 15.15.15.15 YES manual up up R1#sh runn | sec router rip router rip version 2 passive-interface Loopback0 network 15.0.0.0 network 192.168.1.0 no auto-summary R1#sh runn int fa0/1 Building configuration... Current configuration : 144 bytes ! interface FastEthernet0/1 ip address 192.168.1.1 255.255.255.252 ip summary-address rip 15.15.0.0 255.255.0.0 duplex auto speed auto end ! R2#sh ip int bri | ex una Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.1.10 YES manual up up FastEthernet1/0 192.168.1.5 YES manual up up R2#sh runn | sec router rip router rip version 2 network 192.168.1.0 no auto-summary R3#sh ip int bri | ex una Interface IP-Address OK? Method Status Protocol FastEthernet0/1 192.168.1.2 YES manual up up FastEthernet1/0 192.168.1.6 YES manual up up R3#sh runn | sec router rip router rip version 2 network 192.168.1.0 no auto-summary R3#
Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
Comments
-
EdTheLad
Member Posts: 2,111 ■■■■□□□□□□
Split-horizon = Don't advertise a prefix out an interface it was learned on.
Split-horizon poison reverse = Advertise a route with max metric out an interface it was learned on.
R1 is sending and receiving on 2 different interfaces, this is not split-horizon.
Cisco does not implement poison reverse on RIP.Networking, sometimes i love it, mostly i hate it.Its all about the $$$$ -
AwesomeGarrett
Member Posts: 257
We'll get to the bottom of this. Obviously, it's because RIP doesn't install a Null0 route for summary routes. More reading is required. -
EdTheLad
Member Posts: 2,111 ■■■■□□□□□□
Yeah, expected behavior would be for the R1 to receive the prefix with hop count 3 , advertise it to R3 with metric 4, receive it again with metric 6, circle around again receive with metric 9 and eventually the route gets poisoned and the cycle continues when R1 sends its next update to R3 with the summary.
This poisoning to the received summary fast tracks the process. I've tested using "default-information originate" on R1 and specifying to use just f0/1 with a route-map and i get the expected behavior. This enhancement seems only applicable to a local summary route.Networking, sometimes i love it, mostly i hate it.Its all about the $$$$ -
AwesomeGarrett
Member Posts: 257
We came to the same conclusion but I have been unable to locate any documentation to back our findings. How about you?
SIDE NOTE: Freshies probably wondering why we're going the extra mile on RIP, LOL! -
fredrikjj
Member Posts: 879
AwesomeGarrett wrote: »SIDE NOTE: Freshies probably wondering why we're going the extra mile on RIP, LOL!
Nope, they all know that it's because you are huge nerds
