weird BGP cisco-ism? [problem resolved]

Danny McPherson danny at genuity.net
Fri Jul 11 23:10:36 UTC 1997


> > Try it w/o the summary-only stuff.
> 
> Didn't help at all.
> 
> > 
> > I don't use summary-only, or aggregate-address, or network XXX at
> > all.  I redis my connected & static routes into bgp and arrange
> > for my global routes to make it beyond my AS.  I also use pull up
> > static routes to null0 for all of my blocks.
> 
> I redistribute in a similar way, and have the statics to null0 as well.
> 
> Still insisted on flapping at least twice every time it got the brief
> hit on the /24 subnet coming from the outside world.
> 
> At this point what needs to happen is for this to be recreated in
> a lab somewhere and some config changes tried... I can't blow away
> my customers one more time just to play with it. 
> 
> Some day we'll have routers that can tell you what they're doing, right?

Because you're redistributing the route into BGP, when the "true" route 
becomes unavailable and the "nailed up" route kicks in, the route will flap.  
As Ravi mentioned:

[snip]
To avoid readvertising the same prefix, you might want to check if
there is any other dynamic protocol that is installing that prefix in
the routing table and removing it (could be a OSPF subnet...)
-------

You could do a couple of things.

1.) Stop redistributing the more specifics into BGP and allow the "nailed up" 
routes to source the "aggregate" BGP advertisements.  Something like I 
mentioned previously should suffice.  Besides, there's really no need to 
inject the more specifics into BGP if you don't plan to advertise them to 
external peers .. per they're probably already being redistributed into your 
IGP.

2.) Configure a Loopback interface addressed out of the /20 network on the 
router which the summary-only statement exists so that a more specific of the 
network will always be available.

I prefer sourcing advertisments via "Null 0" and "network" statments and don't 
like redistrbuting anything into BGP.


-danny

 






More information about the NANOG mailing list