cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1590
Views
0
Helpful
5
Replies

Choose the Right devices for SP

Zinedine
Level 1
Level 1

Hi All,

please i need a help to choose the right devices for the attached Design, we will deliver the below services over this Backbone.

 

- Internet access

- EOMPLS

- H-VPLS

the condidate devices are :

  1. Asr 9006 for Core/GW internet
  2. Catalyst 6880-x for PE by region ( will help also to connect the LAN)
  3. ME 3600X for Metro L2

Any other idea please  ?

 

thanks

1 Accepted Solution

Accepted Solutions

Adam Vitkovsky
Level 3
Level 3

I’m gonna give you pro bono architectural review,

 

If you are not planning on terminating anything directly on PEs in a region1,2,..13 then convert those to P routers and you can use ncs5500 for those then and do all your PE edge stuff on metro devices

In this case I’d suggest you get two of these ncs5500 per region –having links from pre-aggregation/metro devices to local and remote region P might end up being very expensive (if you’d have redundant core devices in each region/POP you’d be dealing with just patch cables to your pre-aggregation/metro devices.

Doing all your PE edge stuff on metro devices - then you need to be mindful of the scaling and performance limitations of these small boxes ~120k prefixes max

 

If you need to terminate services on the PEs or need a place to terminate 10GE customer circuits in each region/POP then 6880-x is not a good choice it’s not an SP box and you should stick with ASR9k here as well.

Again ideally you’d have two of these in each POP maybe smaller ones 9904 or even 9901

 

In any case for the metro aggregation I suggest you go with the successor of me3600 which is asr920.

 

Regarding the drawing,

I strongly recommend you to build the whole backbone as a single ospf area 0  or isis level 2 you don’t need to worry about any scaling limits at all and a single domain will save you tons of problems down the road.

 

If you can don’t mix PE and RR functionality on the same box –it will make your life much easier trust me on this one.

You don’t need to buy expensive router HW to get RRs you can use virtual routers on commodity hw instead to minimize cost of your BGP infrastructure.

 

You mentioned Internet services + L2VPN services if you are going to distribute internet prefixes onto your PEs you need to do that from dedicated RRs (cluster) –in other words don’t mix internet prefixes with vpn prefixes –as malformed bgp updates from the Internet can bring BGP process or the whole router down –so minimize the impact of that.

 

Same applies to mixing VPN and Internet customers on the same PEs, if you are going to do that then you need a platform that can withstand DDoS attacks and still prefer VPN traffic over internet traffic in case of ASIC overload or congestion I know ASR9k can do that but I’m not sure about 6880-x.

 

adam

 

netconsultings.com

::carrier-class solutions for the telecommunications industry::

 

adam

View solution in original post

5 Replies 5

Adam Vitkovsky
Level 3
Level 3

I’m gonna give you pro bono architectural review,

 

If you are not planning on terminating anything directly on PEs in a region1,2,..13 then convert those to P routers and you can use ncs5500 for those then and do all your PE edge stuff on metro devices

In this case I’d suggest you get two of these ncs5500 per region –having links from pre-aggregation/metro devices to local and remote region P might end up being very expensive (if you’d have redundant core devices in each region/POP you’d be dealing with just patch cables to your pre-aggregation/metro devices.

Doing all your PE edge stuff on metro devices - then you need to be mindful of the scaling and performance limitations of these small boxes ~120k prefixes max

 

If you need to terminate services on the PEs or need a place to terminate 10GE customer circuits in each region/POP then 6880-x is not a good choice it’s not an SP box and you should stick with ASR9k here as well.

Again ideally you’d have two of these in each POP maybe smaller ones 9904 or even 9901

 

In any case for the metro aggregation I suggest you go with the successor of me3600 which is asr920.

 

Regarding the drawing,

I strongly recommend you to build the whole backbone as a single ospf area 0  or isis level 2 you don’t need to worry about any scaling limits at all and a single domain will save you tons of problems down the road.

 

If you can don’t mix PE and RR functionality on the same box –it will make your life much easier trust me on this one.

You don’t need to buy expensive router HW to get RRs you can use virtual routers on commodity hw instead to minimize cost of your BGP infrastructure.

 

You mentioned Internet services + L2VPN services if you are going to distribute internet prefixes onto your PEs you need to do that from dedicated RRs (cluster) –in other words don’t mix internet prefixes with vpn prefixes –as malformed bgp updates from the Internet can bring BGP process or the whole router down –so minimize the impact of that.

 

Same applies to mixing VPN and Internet customers on the same PEs, if you are going to do that then you need a platform that can withstand DDoS attacks and still prefer VPN traffic over internet traffic in case of ASIC overload or congestion I know ASR9k can do that but I’m not sure about 6880-x.

 

adam

 

netconsultings.com

::carrier-class solutions for the telecommunications industry::

 

adam

Great !!! thank you Adam.

 

At the first stage we will start without Hw redundancy at PE's/ region and Pre-aggregation level, the idea behind that is the TCO / 5 - 7 years.

 

can you plz clarify for me the below points :

 

  • Some of the VPN's will be terminated on PE's Regions, so Asr 9006 / 9904 is it the best choice ? what about the internet facing box/Hw ?
  • if we put the asr 920 at pre-agg level, does it support the whole backbone ospf database mostly if the client internet access is on global routing table not on VPN ? is there any scaling issue ?
  • what is the best box for the Metro acces level (fiber and copper )
  • Where can we attache the Datacenter Nexus 7000 ? to PE region or to Core /GW internet ?
  • if we build the whole backbone as single OSPF area 0, this will not limite network scale for the future POP (beyond 50 POP's) ?
  • How can we run RRs on virtual routers /commodity hw ? can you explain plz ?
  • the internet prefixes will be limited to Core/ GW internet for loadbalancing over internet PIPE, only default route advertised to PE's, in this case is it better to have internet on VPN or on Global Table ?

Thank's

Hi,
Can any one support me on the above points plz ?
also is it better to extend the MPLS core to the backhaul or use seamless MPLS approach ?

THx.

  • Some of the VPN's will be terminated on PE's Regions, so Asr 9006 / 9904 is it the best choice ? what about the internet facing box/Hw ?

Please note that asr9000 series can go up to ~200Gbps per slot whereas 9900 series can go up to ~400gbps+ per slot but the cost is much higher due to fabric cards.

 

  • if we put the asr 920 at pre-agg level, does it support the whole backbone ospf database mostly if the client internet access is on global routing table not on VPN ? is there any scaling issue ?

If I remember correctly asr902 can go up to ~20k prefixes total so you can’t have many big customers with large VRFs on one asr902 –so in case you’ll run out of memory you might need to shuffle VRFs across the asr902 in the POP so that each remains well below 20k prefixes.  Regarding the internet access I recommend to migrate internet customer to a dedicated internet VRF –that way you don’t need to keep customer links and subnets in your OSPF database –it’s a bad practice.    

 

  • what is the best box for the Metro acces level (fiber and copper )

asr902 you can get them very cheap and these support the whole Carrier-Ethernet suite of features which you can’t find in any other switches  

 

  • Where can we attach the Datacenter Nexus 7000 ? to PE region or to Core /GW internet ?

That really depends on which consumer of the DC services is expected to be bigger, e.g. if you plan on installing google and accamai caches in there then your customer base will be the biggest consumer so you should place it closest to your customer base to save core BW, if however some internet services are expected to be the biggest consumer then DC needs to be close to Internet edge. But you can actually connect the DC to both (various places around your backbone) to get the best of both worlds  

  • if we build the whole backbone as single OSPF area 0, this will not limite network scale for the future POP (beyond 50 POP's) ?

You can go far beyond 50 pops, and thousands of nodes (just disable LSA age timer and configure your ospf links as p2p).

 

  • How can we run RRs on virtual routers /commodity hw ? can you explain plz ?

You can buy virtual router from cisco csr1000v(IOS-XE) or asr9000v(IOS-XR) and then using a standard linux server using KVM/QEMU virtualization you can start a virtual router (it is very easy) you can then log in and do configuration like on a real router (from CLI you wouldn’t know a difference). The advantage is that you can buy linux server with loads of RAM and CPU so the RRs will be very powerful routers can have loads of BGP sessions and carry loads of prefixes.

 

  • the internet prefixes will be limited to Core/ GW internet for loadbalancing over internet PIPE, only default route advertised to PE's, in this case is it better to have internet on VPN or on Global Table ?

It is always better to have internet in a VPN I find it very flexible. As I mentioned above I’d strongly advice to migrate you internet customer base onto dedicated internet VRF, it will make your backbone more secure and more robust.  

 

adam

 

netconsultings.com

::carrier-class solutions for the telecommunications industry::

 

adam

Much appreciated !
thank you adam for your support.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: