On 31/05/11 14:50, Gert Doering wrote:
We try to separate "core + uplink" and "customer connection" routers,
so we can do works on core routers witout affecting customers - and
vice versa, if we have to reboot a "customer connection" router, we
know which customers are affected and that nothing else is.
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.
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), and customers are then connected
to one or both of the "access" routers.
uplink/IX uplink/IX
| |
CR1 -- CR2
| \ / |
| \/ |
| /\ |
| / \ |
AR1 AR2
| |
customers
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...
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.
uplink uplink/uplink/IX/IX
| |
CR1 -- CR2
| \ / |
| \/ |
| /\ |
| / \ |
CS1 CS2
| |
customers
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
