I am having a big question regarding Poison reverse concept .
Here from the picture The Link between A and T is broken .
Now A sends a Triggered update to B and E immediately , and B , E sends the route back to the A .
Here is the question , B and E will send the poison route only to A or they will send the entire database and how will be the communication between E ,D and B,C ?
If the Router C sends an update to B with metric 4 then B accepts it ?
I did a lab to test the behaviour with the same topology as yours. R1 is announcing three networks:
1.1.1.1/32
2.2.2.2/32
3.3.3.3/32
R1 is sending full updates towards R2. This is the final update before shutting down Lo0 which has the IP 1.1.1.1.
R1 then sends a triggered update:
Dec 9 10:22:37.797: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
Dec 9 10:22:37.809: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (12.12.12.1)
Dec 9 10:22:37.809: RIP: build flash update entries
Dec 9 10:22:37.809: 1.1.1.1/32 via 0.0.0.0, metric 16, tag 0
R1 is just poisoning that route.
R1 also receives the poisoned route back from R2
Dec 9 10:22:39.853: RIP: received v2 update from 12.12.12.2 on FastEthernet0/0
Dec 9 10:22:39.853: 1.1.1.1/32 via 0.0.0.0 in 16 hops (inaccessible)
R1 sends a full update later at its regular interval (30 seconds).
Dec 9 10:23:01.276: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (12.12.12.1)
Dec 9 10:23:01.276: RIP: build update entries
Dec 9 10:23:01.276: 1.1.1.1/32 via 0.0.0.0, metric 16, tag 0
Dec 9 10:23:01.280: 2.2.2.2/32 via 0.0.0.0, metric 1, tag 0
Dec 9 10:23:01.280: 3.3.3.3/32 via 0.0.0.0, metric 1, tag 0
Now to see what happens on the other routers.
R3:
Dec 9 10:22:39.857: RIP: received v2 update from 23.23.23.2 on FastEthernet0/0
Dec 9 10:22:39.861: 1.1.1.1/32 via 0.0.0.0 in 16 hops (inaccessible)
R3 then sends this towards R4 and R2:
Dec 9 10:22:41.861: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (23.23.23.3)
Dec 9 10:22:41.861: RIP: build flash update entries
Dec 9 10:22:41.861: 1.1.1.1/32 via 0.0.0.0, metric 16, tag 0
Dec 9 10:22:41.865: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (34.34.34.3)
Dec 9 10:22:41.865: RIP: build flash update entries
Dec 9 10:22:41.865: 1.1.1.1/32 via 0.0.0.0, metric 16, tag 0
R4:
Dec 9 10:22:41.916: RIP: received v2 update from 34.34.34.3 on FastEthernet0/0
Dec 9 10:22:41.920: 1.1.1.1/32 via 0.0.0.0 in 16 hops (inaccessible)
Dec 9 10:22:43.908: RIP: received v2 update from 45.45.45.5 on FastEthernet0/1
Dec 9 10:22:43.908: 1.1.1.1/32 via 0.0.0.0 in 16 hops (inaccessible)
R4 sends it towards R5 and R3.
Dec 9 10:22:43.920: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (34.34.34.4)
Dec 9 10:22:43.920: RIP: build flash update entries
Dec 9 10:22:43.920: 1.1.1.1/32 via 0.0.0.0, metric 16, tag 0
Dec 9 10:22:43.924: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (45.45.45.4)
Dec 9 10:22:43.924: RIP: build flash update entries
Dec 9 10:22:43.924: 1.1.1.1/32 via 0.0.0.0, metric 16, tag 0
R5:
Dec 9 10:22:41.888: RIP: received v2 update from 56.56.56.6 on FastEthernet0/1
Dec 9 10:22:41.888: 1.1.1.1/32 via 0.0.0.0 in 16 hops (inaccessible)
R5 sends it towards R6 and R4:
Dec 9 10:22:43.891: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (45.45.45.5)
Dec 9 10:22:43.891: RIP: build flash update entries
Dec 9 10:22:43.891: 1.1.1.1/32 via 0.0.0.0, metric 16, tag 0
Dec 9 10:22:43.895: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (56.56.56.5)
Dec 9 10:22:43.895: RIP: build flash update entries
Dec 9 10:22:43.895: 1.1.1.1/32 via 0.0.0.0, metric 16, tag 0
R6:
Dec 9 10:22:39.869: RIP: received v2 update from 26.26.26.2 on FastEthernet0/0
Dec 9 10:22:39.869: 1.1.1.1/32 via 0.0.0.0 in 16 hops (inaccessible)
R6 sends it towards R2 and R5:
Dec 9 10:22:41.873: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (26.26.26.6)
Dec 9 10:22:41.873: RIP: build flash update entries
Dec 9 10:22:41.873: 1.1.1.1/32 via 0.0.0.0, metric 16, tag 0
Dec 9 10:22:41.877: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (56.56.56.6)
Dec 9 10:22:41.877: RIP: build flash update entries
Dec 9 10:22:41.877: 1.1.1.1/32 via 0.0.0.0, metric 16, tag 0
So as can be seen, the route is poisoned and sent as a flash update. This only contains the poisoned route. Later at the regular interval a full update is sent with the route included and a metric of 16.
What happens if another router sends the 1.1.1.1/32 network with a better metric?
R4 starts advertising the 1.1.1.1/32 network:
R4(config)#int lo0
R4(config-if)#ip add 1.1.1.1 255.255.255.255
R4(config-if)#router rip
R4(config-router)#net 1.0.0.0
Dec 9 10:57:23.275: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
Dec 9 10:57:32.079: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (34.34.34.4)
Dec 9 10:57:32.079: RIP: build flash update entries
Dec 9 10:57:32.079: 1.1.1.1/32 via 0.0.0.0, metric 1, tag 0
Dec 9 10:57:32.083: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (45.45.45.4)
Dec 9 10:57:32.083: RIP: build flash update entries
Dec 9 10:57:32.083: 1.1.1.1/32 via 0.0.0.0, metric 1, tag 0
R5 installs this route:
Dec 9 10:57:16.771: RIP: received v2 update from 56.56.56.6 on FastEthernet0/1
Dec 9 10:57:16.771: 1.1.1.1/32 via 0.0.0.0 in 16 hops (inaccessible)
Dec 9 10:57:16.775: RT: del 1.1.1.1/32 via 56.56.56.6, rip metric [120/3]
Dec 9 10:57:16.775: RT: delete subnet route to 1.1.1.1/32
Dec 9 10:57:16.775: RT: NET-RED 1.1.1.1/32
Dec 9 10:57:16.779: RT: delete network route to 1.0.0.0
Dec 9 10:57:16.779: RT: NET-RED 1.0.0.0/8
Dec 9 10:57:32.079: RIP: received v2 update from 45.45.45.4 on FastEthernet0/0
Dec 9 10:57:32.083: 1.1.1.1/32 via 0.0.0.0 in 1 hops
Dec 9 10:57:32.083: RT: add 1.1.1.1/32 via 45.45.45.4, rip metric [120/1]
Dec 9 10:57:32.083: RT: NET-RED 1.1.1.1/32
Note that this behavior is dependant on if the route has gone into hold down. To catch a route in hold down there has to be a passive failure.
R2 applies an ACL towards R1 to filter out the RIP updates:
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip access-list extended NO-RIP
R2(config-ext-nacl)#deny udp any any eq 520
R2(config-ext-nacl)#permit ip any any
R2(config-ext-nacl)#int f0/0
R2(config-if)#ip access-group NO-RIP in
It should take approximately 180 seconds before the route becomes invalid and goes into holddown. This output from R2 is the last one before it becomes invalid:
R2#sh ip route 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 12.12.12.1 on FastEthernet0/0, 00:03:00 ago
Routing Descriptor Blocks:
* 12.12.12.1, from 12.12.12.1, 00:03:00 ago, via FastEthernet0/0
Route metric is 1, traffic share count is 1
Then the holddown timer goes active:
R2#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 12.12.12.1 on FastEthernet0/0, 00:03:01 ago
Hold down timer expires in 178 secs
When the holddown has expired the route can be installed:
R2#sh ip route 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 23.23.23.3 on FastEthernet0/1, 00:00:07 ago
Routing Descriptor Blocks:
* 23.23.23.3, from 23.23.23.3, 00:00:07 ago, via FastEthernet0/1
Route metric is 1, traffic share count is 1
Conclusion: When an interface goes down, a triggered flash update is sent poisoning that route with a metric of 16. This update is sent out all RIP enabled interfaces. Because the route is poisoned, the routers are free to install other routes.
If the route is not poisoned and instead relying on timers then the holddown timer of 180 seconds must expire first before other routes can be installed.
Poison reverse is an extra add-on to the split horizon rule that overrides split horizon in cases exactly like you describe. The route with the infinite metric is sent from A to B and E, and from B and E to their connected neighbors, including A. The whole point is to get the entire network into a converged understanding that T and any networks behind it are no longer reachable.
Here's a quote from the Wikipedia page for split horizon that took me less than 5 seconds to find with a Google search (still not getting the hint are we?):
Split-horizon routing with poison reverse is a variant of split-horizon route advertising in which a router actively advertises routes as unreachable over the interface over which they were learned by setting the route metric to infinite (16 for RIP). The effect of such an announcement is to immediately remove most looping routes before they can propagate through the network. The router is said to have poisoned the network by sending 'false' (infinite) metric values to other devices sharing such updates. The main disadvantage of poison reverse is that it can significantly increase the size of routing announcements in certain fairly common network topologies, but it allows for the improvement of the overall efficiency of the network in case of faults. Split horizon states that if a neighboring router sends a route to a router, the receiving router will not propagate this route back to the advertising router on the same interface. With route poisoning, when a router detects that one of its connected routes has failed, the router will poison the route by assigning an infinite metric to it and advertising it to neighbors. When a router advertises a poisoned route to its neighbors, its neighbors break the rule of split horizon and send back to the originator the same poisoned route, called a poison reverse. In order to give the router enough time to propagate the poisoned route and to ensure that no routing loops occur while propagation occurs, the routers implement a hold-down mechanism.
