[c-nsp] ASR1004 vs 7606(RSP720-CXL)

Justin Shore justin at justinshore.com
Fri Nov 27 22:48:13 EST 2009


Lincoln Dale wrote:
> so some extent it depends on exactly how far 'down' into your DC you extend MPLS VPNs.
> 
> for example, do you extend it down to the access layer?
> or at what point do you map a MPLS VPN into a VRF or VLAN?

Our MPLS/VPNs stop above our top-of-rack L2 switches with VRFs mapped 
into VLANs from there on out.  Our DC isn't just a colo but is primarily 
a hosting solution.  The gist of the difference is that we're hosting 
the customer's network for them in our DC; not just a colo caged 
environment where the SP hands them a cable with Internet access at a 
given CIR and walks away.  Our DC is an extension of the customer's 
private LAN, containing all their routes.  Without MPLS/VPN customer 
prefixes would walk all over each other.  Could we do it with multi-VRF? 
  Sure, but it would be a bitch.  CVPN, L2L and firewall services are in 
7600s upstream of the DC (and miles apart).  Getting them down to the DC 
would require either tunnels in VRFs or 1Q trunks with sub-ints or SVIs 
assigned to unique VRFs with a matching config on the far side.  Routers 
at each level are paired and dual-homed to the opposing levels.  It 
would be a configuration nightmare.  And given Cisco's removal of BFD 
support on SVIs on 7600s, it would also be slow to converge during fiber 
cuts, interface failures or router crashes.

> because even without MPLS today, many folks with N7K quite happily make use of VRFs on N7K, although in cisco parlance you'd call it "vrf lite".

If we had N7Ks in our DCs it would be possible but I sure wouldn't want 
to be responsible for the multi-VRF config between redundant chassis. 
It would be just as bad reaching out to hardware VPN solutions since the 
only VRF-aware VPN solutions in Cisco's arsenal is either an IOS router 
with AIMs or VSAs (I think you can CVPN or L2L into a VRF on an ISR or 
7200; never tried it), or the IPSec SPAs in 6500/7600s.  ASA's aren't 
VRF-aware.  On top of that you have a 2nd set of ASAs or some other 
firewall appliance for hosting customer firewall contexts and they too 
require more 1Q trunks with sub-ints or SVIs in VRFs on the N7Ks.

You're right; you can use N7Ks in DCs and get around the lack of 
MPLS/VPN options but it greatly depends on the kind of DC you run and 
the services you provide.  If it's a hands-off colo environment where 
the SP drops the customer Internet access and doesn't nothing else on 
the network then the N7K is an awesome fit (possibly even over kill, not 
that that's a bad thing).  The customer can bring their own firewall or 
VPN appliance if the want and they provide their own local routing and 
switchports.  If you're DC is more of a hosting solution and you provide 
other services to customers (CVPN, L2L, FW, IDS) besides raw Internet 
and cage space then the N7K in its current form is a problem to be 
overcome.  You can either use it to drop raw Inet to those customer that 
only want that service and then use it as top of the line L2 switching 
solution with L3 tasks handled upstream, or you pick a platform that 
does everything in one fail swoop.  A 65/7600 with IPSec SPAs, FWSMs 
67xx 10G LCs feeding Nexus or 4900 top-of-rack switches would be such a 
solution.  I would love to have the N7K or any of the Nexus switches in 
my DC for L2 switching over what I have today.  I'm very eager to deploy 
the N1K in VMWare too.  That would be very nice.

> one nice characteristic of NX-OS is that everything is vrf aware.  i.e. there is no such thing as a "global table", rather there is a "default vrf" where everything goes if you don't explicitly use vrfs.

That would be a wonderful feature.  So many things on vanilla IOS are 
still not VRF aware.  Someday...

> SOME people use it for L2.  the majority of deployments i've seen are making extensive use of L3.

Like I said above I think there are cases where it definitely works and 
works well.  But if you sell services that don't mess with the N7K then 
you either have a lot of admin overhead bridging multiple products 
together to build your solutions, you have to limit what you use it for 
(L2) and rely on other products to do other things (L3, special 
services), or you pick a solution that does everything in one box. 
Personally I like top-of-rack switches over the expense of populating a 
65/7600 full of electrical Ethernet ports (and the nightmare of wiring 
it all back to one location and a mess of patchcords on the front of a 
large chassis) so I would chose to use a smaller 65/7600 and go with 
something else for the L2.

When the Nexus platforms get MPLS they will be even more awesome than 
the currently are and they will have even more uses throughout the 
network than they do today.  I look forward to that day.

Justin


More information about the cisco-nsp mailing list