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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
