[c-nsp] downlink bgp interconnect best practices

Mark Tinka mtinka at globaltransit.net
Tue May 31 11:39:27 EDT 2011


On Tuesday, May 31, 2011 07:11:14 PM Nikolay Shopik wrote:

> Well in our case all customers fiber/copper terminated in
> same rack where is borders resides. So I just see no
> point to having additional router for customer except
> for additional redundancy of course. But this require
> router able to handle traffic and having bgp full-view
> for customer. If this router is NOT going to have hold
> bgp for customer its okey probably terminate both bgp
> sessions at border and connect them via L2 vlan/switch
> as we having now.

Well, I wouldn't recommend this.

Even though it's not impossible, your BGP routing policy 
could get complex trying to deal with customers and 
upstreams on the same router.

Also, there's no clear separation between your border and 
edge services. If one of your border routers were massively 
attacked that it stopped working, so would your customers, 
even though the other border router is idle, waiting for 
traffic.

In general terms, if budget is tight, it's not uncommon to 
use one router for everything (I'm sure most of us on this 
list went through that period at least once or twice in our 
careers). But if you have the budget, hierarchy will save 
your life.

> Our looks like this, where CS1 and CS2 are core switches,
> 3524XL for now, but will be replaced with 3560X. So bgp
> session goes directly to CR2 for now.

Again, if it's for now due to budget or some other issues, 
that's fine.

But if it's long-term, you prefer separation between your 
edge and core services, much as you do between your edge and 
border services, and between your border and core services.

Cheers,

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


More information about the cisco-nsp mailing list