|
Home > Archive > CCNA > March 2001 > Looking for more details on Poison Reverse and others
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Looking for more details on Poison Reverse and others
|
|
| Bernie 2001-03-01, 11:25 am |
| Route Poisoning, Triggered Updates, Poison Reverse....
I need more clarification on what these do, how they do it. I have read them in the Sybex book and I'm having a tough time locating a good page with detailed info on the Cisco site. Can anybody send me a link? | |
|
|
|
| Thanks Azam,
Good Luck today and relax during the test | |
|
|
|
| quote:
Originally posted by Bernie
Route Poisoning, Triggered Updates, Poison Reverse....
I need more clarification on what these do, how they do it. I have read them in the Sybex book and I'm having a tough time locating a good page with detailed info on the Cisco site. Can anybody send me a link?
Route Poisoning -- when a route drops, the router(s) send out an update for that route with an infinite metric, marking it unreachable. "Infinite" in RIP is 16 hops, for instance.
Triggered Updates -- instead of waiting for the regularly scheduled update, the routers send out a "flash update" of a topology change as soon as they know about it.
Poison reverse -- a route poisoning that is sent out ALL of a router's interfaces, even when it violates the split horizon rule.
All 3 are used together in IGRP and RIP to avoid routing loops and speed convergence.
HTH,
doctorcisco | |
|
| I hate to disagree with the Doctor, but afaik "poison reverse" is short for "split horizon with poison reverse".
Plain split horizon says "do NOT send back an update out the interface on which it was received";
(split horizon with) poison reverse says "DO send back the update, but with infinite metric".
Cheers! | |
|
| quote:
Originally posted by dmaftei
I hate to disagree with the Doctor, but afaik "poison reverse" is short for "split horizon with poison reverse".
Plain split horizon says "do NOT send back an update out the interface on which it was received";
(split horizon with) poison reverse says "DO send back the update, but with infinite metric".
Cheers!
I'll gladly accede to dmaftei's explanation of the term. In either case, unless I'm missing something, the point is much the same ... poison reverse sends route poisoning updates back toward their source, even though the routing protocol is using split horizon. Bad news goes everywhere; good news is subject to split horizon rules.
doctorcisco | |
|
| quote:
Originally posted by doctorcisco
In either case, unless I'm missing something, the point is much the same ... poison reverse sends route poisoning updates back toward their source, even though the routing protocol is using split horizon.
Not really. Poison reverse is a reaction to a received update: you get a route to X, you do some crunching and sooner or later you'll send your update containing X on the other interfaces, and you poison X on the interface on which it was received. You react because of a change that happened in another place.
On the other hand with route poisoning you're the one that causes the change. Say your administrator removes a static route (that used to be advertised). You then set the metric for that route to "infinity" (you poison the route), and send an update on all your interfaces.
Am I confusing people, rather than clarifying?!
Cheers! | |
|
| quote:
Originally posted by dmaftei
Am I confusing people, rather than clarifying?!
Cheers!
I got it, so it must not be TOO confusing.
doctorcisco | |
|
| Sorry, you confused me.
Poison Reverse is Split Horizon with Route Poisoning. Ex) ROUTERC IS THINKING...Hey, don't send packets back to RouterD, RouterD just told you it wasn't feeling good. I'd better tell RouterA and RouterB that RouterD has an infinite hop count.
By combining both it equals Poison Reverse? | |
|
| quote:
Originally posted by Bernie
Poison Reverse is Split Horizon with Route Poisoning.
Err, I wouldn't say that (or it may be that I don't understand well what you're saying. Sorry...  )... Let me try again, maybe this time I'll manage to be meaningful...
We're talking about :
- split horizon (plain).
- poison reverse. The proper name is split horizon with poison reverse, and it's a variant of split horizon (as the proper name suggests).
- route poisoning. This has nothing to do with split horizon (neither plain, nor "with poison reverse" variant).
Consider this topology (let's assume RIP, so metrics are hops, infinity is 16).
RouterA <-------> RouterB <-------> RouterC
First let's say routers A, B and C are all doing plain old split horizon. Router A just gets a route to 10.0.0.0, which it installs in its routing table with metric 1. Then it sends its routing table to B. Router B receives the update, recomputes its routing table and installs 10.0.0.0 with metric 2. Now it's the time for B send its routing table to its neighbors. When it sends it to router C it includes 10.0.0.0 with metric 2 (because that's what it has in its routing table). When it sends it to router A it does not include 10.0.0.0. This is plain, old split horizon. Router C receives the update from B, installs 10.0.0.0 with metric 3. When C sends its routing table to B, it does not include 10.0.0.0. Again, plain, old split horizon. Router A has a route to 10.0.0.0 with metric 1, B has a route to 10.0.0.0 with metric 2, C has a route to 10.0.0.0 with metric 3. Everybody's happy.
Now let's start over. This time our routers are doing split horizon with poison reverse, also known as poison reverse. Again router A gets a route to 10.0.0.0, and sends its routing table to B. Router B receives the update and installs 10.0.0.0 with metric 2 in its routing table. Now router B has to send its routing table to its neighbors. Its update to C includes 10.0.0.0 with metric 2 -- no surprise here. The update to A includes 10.0.0.0 with metric 16. This is the poison reverse. Router C receives the update and installs 10.0.0.3 with metric 3. When C sends its update to B, it includes 10.0.0.0 with metric 16. Again poison reverse. Consider router B. It has an update from A for 10.0.0.0 metric 1, and another update from C for 10.0.0.0 metric 16. Since the update from A is better than that from C, B keeps the route received from A. The same goes for A. Router A has a route to 10.0.0.0 with metric 1, B has a route to 10.0.0.0 with metric 2, C has a route to 10.0.0.0 with metric 3. Everybody's happy again.
Now let's think about route poisoning. All the routers have the route to 10.0.0.0. Router A looses the route to 10.0.0.0. Instead of just sitting on its butt and waiting for the route to 10.0.0.0 die of age, router A sends an update including 10.0.0.0, with metric 16. This is route poisoning. Router B gets the update and propagates it in its update to C. Now all routers have 10.0.0.0 with metric 16 -- that is 10.0.0.0 is unreachable. Everybody's happy!!
Did I do better now?! | |
|
| That cleared it up, thanks again guys. | |
|
| WARNING: This is long.
SYNOPSIS: Poison reverse is an exception to the usual split horizon rule, so that routers will send bad news (route poisoning) back in the direction it came from.
quote:
Originally posted by dmaftei
Consider this topology (let's assume RIP, so metrics are hops, infinity is 16).
RouterA <-------> RouterB <-------> RouterC
<snip -- no problem with the "plain vanilla split horizon" part>
Now let's start over. This time our routers are doing split horizon with poison reverse, also known as poison reverse. Again router A gets a route to 10.0.0.0, and sends its routing table to B. Router B receives the update and installs 10.0.0.0 with metric 2 in its routing table. Now router B has to send its routing table to its neighbors. Its update to C includes 10.0.0.0 with metric 2 -- no surprise here. The update to A includes 10.0.0.0 with metric 16. This is the poison reverse.
Right here is the problem, I think. "Split horizon with poison reverse" will NOT do anything different from "plain vanilla" split horizon at this point, because no link has failed. Poison reverse is an "exception to the rule" of split horizon, basically saying that good news observes the split horizon rule, but bad news (route poisoning) will be sent back toward its source. Cisco BSCN book, p. 26, from which I stole the diagram below: "[A link has failed]. Because of the split horizon rule, Router D normally will not send routing updates about network 10.2.0.0 to Router C. However, poison reverse updates override the split horizon rule."
This is not CCNA material, but consider the following adapted from Cisco's BSCN guide pp25-26. We're running RIP.
RouterA-------|
|
|
RouterB<--->RouterC<--->RouterD<--->RouterE
10.2.0.0
The artwork got garbled. RouterA is connected to both B and C. 10.2.0.0 is the network between B and C. The rest should make sense.
1. Ethernet cable cut by crazed vacuum cleaner operator; C's connection to 10.2.0.0 breaks. B's is still good.
2. C sends a triggered update to D and A, including a metric 16 update (route poisoning) for 10.2.0.0, and purges 10.2.0.0 from its routing table.
2A) Note carefully the current routing tables. C has no route to 10.2.0.0 in its table at all. D has a poisoned route to 10.2.0.0, metric 16, and started the holddown timer. A received a route poisoning from C. But A had an equal-cost route to 10.2.0.0 via B, and therefore both routes were in its table. So A still has a good route via B.
3. C requests an immediate routing update to look for an alternate path to 10.2.0.0. A responds with a route, metric 2. D responds with a poison reverse, metric 16. ***Normally, D would never send information about 10.2.0.0 to C (split horizon). However, because the route to 10.2.0.0 was poisoned, D "breaks" the split horizon rule and sends a poison reverse to C in its update.***
4. C accepts the new route from A, because it currently HAS no route to 10.2.0.0 (it was purged in #2), and is not in holddown because the original route was purged from the routing table.
5. At the next scheduled update, C tells D about its route to 10.2.0.0. D ignores it, because D has 10.2.0.0 in holddown and the metric is worse than the original.
6. Scheduled updates from D to C include poison reverses for 10.2.0.0. C ignores them.
7. When the holddown expires, D will accept the new route from C, and will stop sending poison reverses to C. Eventually, the news will get to E.
The big problem with this whole picture -- It will take E over 3 minutes to start using the new route to 10.2.0.0. Ouch!
I sure remember this stuff better when I type it up like this!
doctorcisco | |
|
| quote:
Originally posted by doctorcisco
WARNING: This is long.
<snip>
This is a great example, bur I'm afraid it was not completely understood.
I suppose the source of confusion is step 3, specifically the "because the route to 10.2.0.0 was poisoned, D breaks the split horizon rule and sends a poison reverse to C" statement. What happens in this step is that C sends a RIP request for 10.2.0.0 (the route it just lost) to all its neighbors. Since the request is for a specific entry, all neighbors must send back whatever they know about the requested entry. This is as per rfc 1058, section 3.1.4, paragraph 4:
quote:
...If the request is for specific entries, they are looked up in the host table and the information is returned. No split horizon processing is done, and subnets are returned if requested...
Since D has 10.2.0.0 in its routing table (because it's in holddown), with infinite metric (because the route was poisoned in step 2), it will send it to C. This is not split horizon with route poisoning. D sends 10.2.0.0 back to C not "because 10.2.0.0 was poisoned", but because it received a request for 10.2.0.0.
In step 4 C reacquires 10.2.0.0 from A. Step 5 should be clear; note that in this step D receives 10.2.0.0 from C, and ignores it.
In step 6 D does split horizon with poison reverse: it sends back to C an update for 10.2.0.0 with infinite metric. It does so because in step 5, D received 10.2.0.0 from C.
Here's what rfc 1058 says about split horizon (section 2.2.1, paragraph 1):
quote:
...In particular, it is never useful to claim reachability for a destination network to the neighbor(s) from which the route was learned. "Split horizon" is a scheme for avoiding problems caused by including routes in updates sent to the gateway from which they were learned. The "simple split horizon" scheme omits routes learned from one neighbor in updates sent to that neighbor. "Split horizon with poisoned reverse" includes such routes in updates, but sets their metrics to infinity.
Finally, note that rfc 1058 doesn't mention route poisoning and holddown; I suspect these are improvements introduced by Cisco. However, triggered updates are part of the RFC.
Cheers! |
|
|
|
|