[c-nsp] downlink bgp interconnect best practices

[Mark Tinka]

On Tuesday, May 31, 2011 06:50:39 PM Gert Doering wrote:

> So a "text book" scenario would have two "core/uplink"
> routers here, fully meshed with two "customer access"
> boxes (so there's no single switch in between that could
> break),...

Well, in our large PoP's, we aggregate core and edge routers 
into core switches. If you're going to do this, you 
obviously need two switches for redundancy.

We do this because in our large PoP's, it's easy to end up 
with several edge routers. It would be uneconomical to 
aggregate all those edge routers into the core.

But you're right - if you don't have two switches, save 
yourself the hassle and connect to the core directly. If you 
can have two switches and need port density that the core 
router can't provide cheaply, go that route too.

> Now, reality doesn't always work like this for smaller
> shops - if the customer connects with a bigger pipe than
> what we have to the access routers (like "2 Gbit ether
> channel uplink"), they get connected to the "core" box -
> because it's sometimes not very economic to roll out
> 10Gig everywhere, just for a single 2G customer...

This is when I'd upgrade the edge router to something like 
an MX or ASR9000, and connect the customer to Gig-E or 10-
Gig-E ports there. But this is if the customer is connecting 
within a PoP where an edge router has gotten full and needs 
to be upgraded anyway. Not always an option, financially.

If the customer is connecting to a Metro-E ring, and they 
need more bandwidth, one could run them to the PE 
Aggregation routers that serve the Metro-E Access rings. 
That's what we do, mostly if customers want anything larger 
than 4Gbps.

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/acc2f33c/attachment.pgp>