[c-nsp] downlink bgp interconnect best practices

[Gert Doering]

Hi,

On Tue, May 31, 2011 at 04:43:57PM +0400, Nikolay Shopik wrote:
> >We found it useful to have this separation - but if you don't want that,
> >there is nothing particularily wrong with "just have two boxes and
> >terminate upstream and downstream links on both of them" - for
> >redundancy, give the customers two links to both boxes, and all is
> >set...
> 
> As we lately start growing we probably go with additional box(es), per 
> customer(s), which hold full bgp for them too. Also can't we go with 
> some kind router reflector which isn't passing any traffic (changing 
> next-hop to one of border)?

In your case, I'd have the core/border routers do route-reflector functions
towards the customer-edge routers.  Saves you having to do a full mesh
between all the customer-edge routers, and saves you from having to add
two more boxes (two! one RR is going to fail one day, and then your BGP
is broken).


> btw in your scheme there is link between CR1 and CR2, what's point to 
> have such, if my customer is have bgp session with both there is no 
> chance packet could go to "worst path" and thus link between CR1 and CR2 
> redundant. Probably I miss some case scenario?

Well, it depends a bit how the connectivity between CR1 and CR2 is 
built.  If you have two independent switches there, the direct link is
not strictly needed.  Still, it has the advantage that if these switches
should fail, CR1 and CR2 always are connected - otherwise you'll run
into some weird problems.

Imagine:

upstream        upstream
   |             |
  CR1           CR2
   | \
   |  \
   |   \
  AR1  AR2

now what happens if a packet comes in from upstream 2 to CR2?  It will
have to be dropped -> black-holing.  So if you have a direct link CR1-CR2,
you ensure that your network never partitions, even if switch(es) fail.

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/20110531/47ef410f/attachment.pgp>