[c-nsp] delay eBGP sessions on startup?

[Gert Doering]

Hi,

On Tue, Nov 24, 2009 at 08:25:45AM +1000, David Hughes wrote:
> > both ISP-Routers announce the ISP's aggregate (let's call it 200.1.0.0/16) 
> > to their respective upstream providers (static route to null0, "network"
> > statement).  This needs to be done, to make sure that the aggregate is
> > always visible, even if one of the routers is down.
> 
> So you are generating the aggregate at the border?  

Yes.

> That can certainly leave you black holing traffic under several scenarios 
> (anything that isolates that router).  

I'm aware of that - and in this specific network scenario, this is considered
"highly unlikely".  Basically, the network really consists of two routers,
which are directly interconnected (direct fiber to the next rack), and
both of them are connected via 2 2xGE etherchannels to two L2 switches.

So there's 5 different links between those routers - and if someone 
manages to break *all* of these at the same time, well, blackholing is
the least of my worries.

(The network is a bit more complex, but the details really don't change
this statement)

> 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.

There are no other routers that are considered "reliable enough" in
this setup - everything else is stuff like "firewalls" or "3640s used
as console server".

> So either a static to NULL0 on a pair of core box somewhere or even 
> an aggregate address statement on the border could help you here.  

Well, the "two routers" mentioned above are "the core" and "the border 
routers".  There *is* only these two :-)

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20091124/7a32b2b9/attachment.bin>