At 07:39 PM 3/11/2003 +0000, Oliver Hensel wrote: >Hi! > >Can someone point me to a document which explains >what happens with a prefix that is dampened if >it's distributed via two providers.
Hi Oliver, Here is a link to a doc from Randy Bush that covers damping in some detail. http://psg.com/~randy/021028.zmao-nanog.pdf (handily posted to NANOG today :) For technical info on damping in general, check rfc 2439, and RIPE 229 for recent best practise config settings (which are put into serious question by the above PDF) Damping was brought into existence as a means to protect routers which could be overwhelmed by a large amount of BGP updates to the extent where they would would either crash, or drop BGP sessions themselves thereby exacerbating the route churn issue. At present, newer routers and better BGP implementations are able to deal with large amounts of BGP updates without any impact to other processes in the router and thus the need to protect them via damping isn't a huge priority. Further, as Randy points out, damping may do more harm than good to route convergence in the global Internet. As a result, I think it is safe to say that the need for damping in general is in serious question. >Will only the penalized route dampened, that is >will we still have connectivity if one link is >flapping. I think so, but I'd like to have some >confirmation for that. BGP prefixes (NLRI) are damped individually, however damping really only impacts you on more remote AS's. In your case, you have a situation like the below: you / \ transit1 transit2 | \ / | remote1 - - remote2 | \ / | remote3 ------- remote4 When you advertise 10/8 to transit1 and transit2, assuming these folks are clueful and automatically pref customer routes above peer/transit, both of them will always prefer the direct route to you. This is important as implicit withdrawals are penalized in the same way as direct withdrawals. This fact, coupled with the fact that damping stats are cleared on EBGP sessions when the peer resets will tend to make damping irrelevant between neighboring AS's. However, as you get more and more remote, things get worse. To expand on this, consider remote3. Assuming you advertise 10/8 to both transits, imagine that the update from transit2 gets to remote1 first and on to remote3. In this case, remote3 hits you with an advert penalty and posts the route 10/8 via as-path "r1,t2, you" Shortly thereafter, the update from transit1 shows up in remote1 and by virtue of a better AS-PATH becomes the best path in remote1. Remote1 therefore sends an update with the new path info to remote3. This update includes an implicit withdrawal of the old path and a subsequent damping penalty applied to 10/8 in remote3. Likely these two updates appeared in remote 3 in a pretty narrow time window and thus you have a 10/8 prefix that has suffered a nice penalty without ever really flapping. Consider also that depending on AS size, router types, BGP advertisement intervals and such, remote 3 may have seen an r1,r4,r2,t2 path first, then an r1.r2,t2, then an r1,t1 path and may have penalized you once for the initial advert and two more times for the implicit withdrawals which might get you damped in remote3 right off the bat. This issue gets worse as you consider ASes more and more remote from you. For what it's worth, I may have this entirely wrong :-) But this is my understanding of the behavior. The networks I have designed used graded damping and are not tremendously aggressive. I am however considering removing damping from the configs for the few networks I have some impact in as I really don't see it serving much of a role. Pete >Thanks and best regards, > >Oliver > > >-- >Oliver Hensel >telematis Netzwerke GmbH >mailto: [EMAIL PROTECTED] > Siemensstrasse 23, D-76275 Ettlingen > Tel: +49 (0) 7243-3448-0, Fax: -498 >visit us: http://telematis.com >3 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=65302&t=65086 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
