[c-nsp] delay eBGP sessions on startup?

[Mark Tinka]

On Tuesday 24 November 2009 06:25:45 am David Hughes wrote:

> So you are generating the aggregate at the border?  That
>  can certainly leave you black holing traffic under
>  several scenarios (anything that isolates that router). 
>  Have you thought about generating the aggregate within
>  your network and propagating it via iBGP.  At least the
>  border can't advertise it upstream instantaneously as it
>  won't know about it until iBGP is up.

Reading through this thread since yesterday, this is also 
one of the first things I'd recommend be done.

In our case, our route reflectors generate our aggregates. 
All other peering routers simply pass them on if they 
receive them from the route reflectors via iBGP. 
Particularly useful if you have a peering router that was 
generating your aggregate at an exchange point, but suddenly 
lost its backhaul to your core, and along with it, its iBGP 
session.

Not that I'm recommending it, but one of the unintended 
benefits we've seen of running a BGP-free core (for IPv4, 
that is) is that given how long core boxes take to boot, and 
how slow they may sometimes be in fully converging their BGP 
tables (while potentially blackholing traffic in the 
process, hence the little useful knobs in OSPF and IS-IS), 
not having to run BGP in the core means only edge routers 
are affected by a system restart. This would limit outages 
to a smaller part of the network than if a core router were 
restarting.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20091124/b98f5432/attachment.bin>