[c-nsp] suppress bgp updates?

Mark Kent mark at noc.mainstreet.net
Wed Nov 17 17:28:52 EST 2010


>> Hiding internal routing turmoil, as you state it, works best when you
>> are aggregating/summarizing -- which you are not doing here.  Your RIB
>> entry for 192.0.2.0 changes between static and OSPF routes.  BGP
>> sees this as a route change and does its job of notifying neighbors.

Thanks.  Your comments are on target and, I now see, align with this
statement from near the end of rfc2439:

   Aggregation provides another means of damping.  Providers should
   damp their own internal problems, however damping on IGP link state
   origination is not yet implemented by router vendors.

And these three sentences, also from rfc2439:

1) A BGP implementation cannot rely upon the sender to sufficiently
   shield it from route instabilities.

2) The mechanisms described here allow routing instability to be
   contained at an AS border router bordering the instability.

3) Route flap should be damped near the source.

all beg the question: why not give operators a way to completely
contain routing instability *IN* their networks??

Back when this was a hot topic I am pretty sure someone like Vadim
Antonov complained about not caring when a T1 circuit flaps inside
some clueless ISP.  And I am certain that there was an implication
that if only those clueless ISPs would configure their routers
correctly then the world would be spared from their stupidity.

But you are implying that even 15 years later there is nothing
the clueless (or otherwise) ISP can do to *completely* shield the
outside world from their internal events.

If so, I am surprised... and still curious about what is the
best current practice.  Here is a starting point, please enhance:

  router bgp 65535
    no synch
    network 192.0.2.0
    network 192.168.4.0 mask 255.255.252.0
    agg 192.168.4.0 255.255.252.0 summ

  <various subnets of 192.168.4.0/22 are learned from various neighbors
   via ospf, and 192.0.2.0/24 is learned via ospf from the far side of 
   an unreliable T1>

Thanks,
-mark


More information about the cisco-nsp mailing list