Solved: RIP poison reverse benefit

CARLO CIANFARANI · ‎08-31-2012

Hi,

I've a question related to "poison-reverse" when used in conjuction with split-horizon (for instance in RIP protocol implementation)

Just to recap: split-horizon with poison reverse will advertise back with metric infinity (16 for RIP) a route out the interface from which it has been received with a metric of infinity (via a triggered/flash update).

Consider the following scenario:

R2-----serial--------R1---fast0/0 (10.10.1.1/24)

Suppose now R1 fa0/0 fail. R1 will remove the connected network (10.10.1.0/24) from IP routing table and, in turn, will send a triggered/flash update about 10.10.1.0 with metric 16 (inaccessible) to the serial i/f connected to R2. R2 following split-horizon w/ poison reverse rule will advertise back 10.10.1.0 with metric 16 to R1.

Now the question is: What is the purpose of the poison reverse route update from the point of view of the receiving router (R1 in the example) ? Which kind of action the receiving router (R1) will take upon the receiving of the poison-reverse route update ?

Thanks

Peter Paluch · ‎09-04-2012

Dear friends,

My understanding is that there are two different and distinct mechanisms: split horizon with poisoned reverse, and route poisoning.

The split horizon with poisoned reverse is a mechanism supposed to break tight routing loops between a pair of interconnected routers. Instead of one router learning a route from another router and not telling it back, a router does advertise the route back where it came from but using an infinite metric, thereby explicitly claiming: "even if you for some reason thought you could use me to reach this network, forget about it". Doing this prevents stale and possibly worse-case backup routes via us to be removed from our next-hop router towards the destination network.

The route poisoning is a method to rapidly advertise a network as unreachable, thereby allowing an alternative route to be installed into routing tables. In my opinion, the route poisoning is not that much of a loop prevention technique, rather it is a mechanism to speed up convergence.

To by best knowledge, RIPv1 and RIPv2 in Cisco's implementation implements only a split horizon technique, not a split horizon with poisoned reverse. This is an implementor's choice, I believe - the RFC 1058 (RIPv1) talk both about simple split horizon and about a split horizon with poisoned reverse, so either could have been implemented by Cisco. However, Cisco chose to go with simple split horizon only (it should be noted that EIGRP implements split horizon with poisoned reverse).

The debug shown by Carlo proves that - when the network is disconnected, both routers perform the route poisoning process and do a "mass advertising" of the disconnected network as unreachable. However, when the network is connected back, only a simple split horizon is invoked.

Best regards,

Peter

View solution in original post

Richard Burts · ‎09-01-2012

Carlo

I think that you do not have a correct understanding of split horizon with poison reverse. In the scenario that you describe R1 will send the update that removes the routing table entry for 10.10.1.0/ R2 receives the update and removes the entry from its routing table. There is no reason for R2 to send the poison reverse to R1.

A router sends the poison reverse when its has learned a route but there is no reason to do this when it removes a route.

Perhaps it will help you to understand it better if we think about the other side of your scenario. Think what happens when fa0/0 comes up. R1 will send an update announcing the route to R2. R2 has learned the route, inserts the route into its routing table, and then R2 sends a poison reverse to R1 to ensure that R1 will not attempt to route packets to 10.10.1.0 via R2.

HTH

Rick

HTH

Rick

CARLO CIANFARANI · ‎09-03-2012

I've done a test w/ IOS 12.4(21a) turning on debug ip rip and debug ip routing

R1-------s0/0--------R2-----fa0/0

R1#sh ip route

10.0.0.0/24 is subnetted, 2 subnets

C 10.10.1.0 is directly connected, FastEthernet0/0

C 10.10.4.0 is directly connected, Serial0/0

R2#sh ip route

10.0.0.0/24 is subnetted, 2 subnets

R 10.10.1.0 [120/1] via 10.10.4.1, 00:00:22, Serial0/0

C 10.10.4.0 is directly connected, Serial0/0

R2#

R2#sh ip int s0/0

Serial0/0 is up, line protocol is up

Internet address is 10.10.4.2/24

Broadcast address is 255.255.255.255

Address determined by setup command

MTU is 1500 bytes

Helper address is not set

Directed broadcast forwarding is disabled

Multicast reserved groups joined: 224.0.0.9

Outgoing access list is not set

Inbound access list is not set

Proxy ARP is enabled

Local Proxy ARP is disabled

Security level is default

Split horizon is enabled <-------------

when R1 fa0/0 is shutted down debug show:

R1(config-if)#sh

R1(config-if)#

*Mar 1 00:23:09.423: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: True

*Mar 1 00:23:09.431: RT: interface FastEthernet0/0 removed from routing table

*Mar 1 00:23:09.431: RT: del 10.10.1.0/24 via 0.0.0.0, connected metric [0/0]

*Mar 1 00:23:09.435: RT: delete subnet route to 10.10.1.0/24

*Mar 1 00:23:09.439: RT: NET-RED 10.10.1.0/24

R1(config-if)#

*Mar 1 00:23:11.415: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down

R1(config-if)#

*Mar 1 00:23:11.419: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: False

*Mar 1 00:23:11.427: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.10.4.1)

*Mar 1 00:23:11.431: RIP: build flash update entries

*Mar 1 00:23:11.431: 10.10.1.0/24 via 0.0.0.0, metric 16, tag 0

*Mar 1 00:23:12.415: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

R1(config-if)#

*Mar 1 00:23:12.423: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: False

R1(config-if)#

*Mar 1 00:23:13.503: RIP: received v2 update from 10.10.4.2 on Serial0/0

*Mar 1 00:23:13.507: 10.10.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)

R1(config-if)#

*Mar 1 00:23:21.351: RIP: received v2 update from 10.10.4.2 on Serial0/0

*Mar 1 00:23:21.355: 10.10.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)

R1(config-if)#

R1(config-if)#do sh ip rip da

10.0.0.0/8 auto-summary

10.10.1.0/24 is possibly down

10.10.4.0/24 directly connected, Serial0/0

R1(config-if)#

*Mar 1 00:23:30.651: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.10.4.1)

*Mar 1 00:23:30.655: RIP: build update entries

*Mar 1 00:23:30.655: 10.10.1.0/24 via 0.0.0.0, metric 16, tag 0

R1(config-if)#

R1(config-if)#do sh ip rip da

10.0.0.0/8 auto-summary

10.10.1.0/24 is possibly down

10.10.4.0/24 directly connected, Serial0/0

R1(config-if)#

*Mar 1 00:23:48.899: RIP: received v2 update from 10.10.4.2 on Serial0/0

*Mar 1 00:23:48.903: 10.10.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)

R1(config-if)#

R1(config-if)#do sh ip rip da

10.0.0.0/8 auto-summary

10.10.1.0/24 is possibly down

10.10.4.0/24 directly connected, Serial0/0

R1(config-if)#

*Mar 1 00:23:57.847: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.10.4.1)

*Mar 1 00:23:57.851: RIP: build update entries

*Mar 1 00:23:57.851: 10.10.1.0/24 via 0.0.0.0, metric 16, tag 0

R1(config-if)#

R1(config-if)#do sh ip rip da

10.0.0.0/8 auto-summary

10.10.4.0/24 directly connected, Serial0/0

R1(config-if)#

*Mar 1 00:24:24.019: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.10.4.1)

*Mar 1 00:24:24.023: RIP: build update entries - suppressing null update

R1(config-if)#

R2#

*Mar 1 00:23:07.903: RIP: received v2 update from 10.10.4.1 on Serial0/0

*Mar 1 00:23:07.907: 10.10.1.0/24 via 0.0.0.0 in 1 hops

R2#

*Mar 1 00:23:16.575: RIP: received v2 update from 10.10.4.1 on Serial0/0

*Mar 1 00:23:16.575: 10.10.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)

*Mar 1 00:23:16.579: RT: del 10.10.1.0/24 via 10.10.4.1, rip metric [120/1]

*Mar 1 00:23:16.583: RT: delete subnet route to 10.10.1.0/24

*Mar 1 00:23:16.583: RT: NET-RED 10.10.1.0/24

R2#

*Mar 1 00:23:18.587: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.10.4.2)

*Mar 1 00:23:18.591: RIP: build flash update entries

*Mar 1 00:23:18.591: 10.10.1.0/24 via 0.0.0.0, metric 16, tag 0

R2#

R2#sh ip rip data

*Mar 1 00:23:26.399: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.10.4.2)

*Mar 1 00:23:26.403: RIP: build update entries

*Mar 1 00:23:26.403: 10.10.1.0/24 via 0.0.0.0, metric 16, tag 0

R2#sh ip rip da

10.0.0.0/8 auto-summary

10.10.1.0/24 is possibly down

10.10.4.0/24 directly connected, Serial0/0

R2#

*Mar 1 00:23:35.775: RIP: received v2 update from 10.10.4.1 on Serial0/0

*Mar 1 00:23:35.779: 10.10.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)

R2#

R2#sh ip rip data

10.0.0.0/8 auto-summary

10.10.1.0/24 is possibly down

10.10.4.0/24 directly connected, Serial0/0

R2#

*Mar 1 00:23:53.975: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.10.4.2)

*Mar 1 00:23:53.979: RIP: build update entries

*Mar 1 00:23:53.979: 10.10.1.0/24 via 0.0.0.0, metric 16, tag 0

R2#

*Mar 1 00:24:03.003: RIP: received v2 update from 10.10.4.1 on Serial0/0

*Mar 1 00:24:03.003: 10.10.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)

R2#

R2#sh ip rip data

10.0.0.0/8 auto-summary

10.10.1.0/24 is possibly down

10.10.4.0/24 directly connected, Serial0/0

R2#

*Mar 1 00:24:20.643: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.10.4.2)

*Mar 1 00:24:20.647: RIP: build update entries - suppressing null update

Here you can see R2 advertise back 10.10.1.0/24 with metric 16 on s0/0 (I think this is the poison reverse update) while the entry in R1 RIP database enter in "possibly down" state

After, when finally the entry is removed form RIP database on R1 and R2 no more updates are sent by routers (RIP: build update entries - suppressing null update)

Whenever fa0/0 comes up I can not see any poisoned route advertised back by R2 to R1:

R1(config-if)#no sh

R1(config-if)#

*Mar 1 00:33:20.023: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 has_route: False

*Mar 1 00:33:20.027: RT: SET_LAST_RDB for 10.10.1.0/24

NEW rdb: is directly connected

*Mar 1 00:33:20.031: RT: add 10.10.1.0/24 via 0.0.0.0, connected metric [0/0]

*Mar 1 00:33:20.035: RT: NET-RED 10.10.1.0/24

*Mar 1 00:33:20.039: RT: interface FastEthernet0/0 added to routing table

*Mar 1 00:33:20.043: RIP: sending request on FastEthernet0/0 to 224.0.0.9

R1(config-if)#

*Mar 1 00:33:21.999: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up

R1(config-if)#

*Mar 1 00:33:22.007: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 has_route: True

*Mar 1 00:33:22.039: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.10.1.1)

*Mar 1 00:33:22.039: RIP: build flash update entries - suppressing null update

*Mar 1 00:33:22.043: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.10.4.1)

*Mar 1 00:33:22.047: RIP: build flash update entries

*Mar 1 00:33:22.047: 10.10.1.0/24 via 0.0.0.0, metric 1, tag 0

*Mar 1 00:33:22.999: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

R1(config-if)#

*Mar 1 00:33:23.003: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 has_route: True

R1(config-if)#

*Mar 1 00:33:36.371: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.10.4.1)

*Mar 1 00:33:36.375: RIP: build update entries

*Mar 1 00:33:36.375: 10.10.1.0/24 via 0.0.0.0, metric 1, tag 0

R1(config-if)#

*Mar 1 00:33:48.179: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.10.1.1)

*Mar 1 00:33:48.183: RIP: build update entries

*Mar 1 00:33:48.183: 10.10.4.0/24 via 0.0.0.0, metric 1, tag 0

R1(config-if)#

R2#

*Mar 1 00:33:27.167: RIP: received v2 update from 10.10.4.1 on Serial0/0

*Mar 1 00:33:27.171: 10.10.1.0/24 via 0.0.0.0 in 1 hops

*Mar 1 00:33:27.175: RT: SET_LAST_RDB for 10.10.1.0/24

NEW rdb: via 10.10.4.1

*Mar 1 00:33:27.179: RT: add 10.10.1.0/24 via 10.10.4.1, rip metric [120/1]

*Mar 1 00:33:27.179: RT: NET-RED 10.10.1.0/24

R2#

*Mar 1 00:33:29.183: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.10.4.2)

*Mar 1 00:33:29.187: RIP: build flash update entries - suppressing null update

*Mar 1 00:33:29.891: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.10.4.2)

*Mar 1 00:33:29.895: RIP: build update entries - suppressing null update

R2#

*Mar 1 00:33:41.523: RIP: received v2 update from 10.10.4.1 on Serial0/0

*Mar 1 00:33:41.527: 10.10.1.0/24 via 0.0.0.0 in 1 hops

R2#

*Mar 1 00:33:58.875: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.10.4.2)

*Mar 1 00:33:58.879: RIP: build update entries - suppressing null update

R2#

Richard Burts · ‎09-04-2012

Carlo

These are very interesting test results and are certainly different from my understanding of how RIP is supposed to work.

HTH

Rick

HTH

Rick

paul.capusneanu · ‎09-04-2012

Hi Carlo,

The answer is "nothing". R1 will do nothing when it receives the infinity metric. Poison reverse is a method used to quickly break a routing loop and not wait for a time out. Split horizon is much safer when used in conjuction with Poison Reverse.

Take care,

PaulC

CARLO CIANFARANI · ‎09-04-2012

Thanks for the answers...

Searching for "poison reverse" seem to point to advertise back a "poisoned route" to the router it has learned the route to ensure that "neighbor" will not attempt to route packets to it

So it could seem "poison reverse" is not operational in this lab. By the way, I've done a test in the same topology with RIPng (IPv6) and if poison reverse is configured at RIPng process level, actually the router follows the rule (i.e. advertise back a "poisoned route" to the router it has learned a route)

Peter Paluch · ‎09-04-2012

Dear friends,

My understanding is that there are two different and distinct mechanisms: split horizon with poisoned reverse, and route poisoning.

The split horizon with poisoned reverse is a mechanism supposed to break tight routing loops between a pair of interconnected routers. Instead of one router learning a route from another router and not telling it back, a router does advertise the route back where it came from but using an infinite metric, thereby explicitly claiming: "even if you for some reason thought you could use me to reach this network, forget about it". Doing this prevents stale and possibly worse-case backup routes via us to be removed from our next-hop router towards the destination network.

The route poisoning is a method to rapidly advertise a network as unreachable, thereby allowing an alternative route to be installed into routing tables. In my opinion, the route poisoning is not that much of a loop prevention technique, rather it is a mechanism to speed up convergence.

To by best knowledge, RIPv1 and RIPv2 in Cisco's implementation implements only a split horizon technique, not a split horizon with poisoned reverse. This is an implementor's choice, I believe - the RFC 1058 (RIPv1) talk both about simple split horizon and about a split horizon with poisoned reverse, so either could have been implemented by Cisco. However, Cisco chose to go with simple split horizon only (it should be noted that EIGRP implements split horizon with poisoned reverse).

The debug shown by Carlo proves that - when the network is disconnected, both routers perform the route poisoning process and do a "mass advertising" of the disconnected network as unreachable. However, when the network is connected back, only a simple split horizon is invoked.

Best regards,

Peter

CARLO CIANFARANI · ‎09-05-2012

Peter, thinking about it I have reached same result !

Thanks all