[c-nsp] Virtual CPE as a service on Metro-E last mile - Suggestions/inputs required

[Aaron]

You mentioned ... " I'm thinking q-in-q is what you mean when you say "MAC
in MAC". "

I've read that 802.1ah PBB (Provider Backbone Bridging) is actually a
technology that allows for MAC Hiding to address scalability issues created
from a previous technology known as 802.1ad PB (Provider Bridging).

It seems that there is more to it than just simply stacking up a couple
tags.

Just because you stack up a few tags, I don't believe that you get mac
hiding.

I think, as I previously mentioned, that you have to implement something
like PBB to hide macs.

Aaron




-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Bill
Wichers
Sent: Thursday, May 21, 2015 1:15 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Virtual CPE as a service on Metro-E last mile -
Suggestions/inputs required

We just run q-in-q from a relatively inexpensive CPE switch back to our
nearest node. The advantage to this is that it's simple, and we can run
either over our own fiber or tunnel through other carrier's networks if
needed for type-2 circuits. If you're tunneling you need to make sure your
carrier supports q-in-q and jumbo (or at least larger than normal frames) to
accommodate the tags. You can also support your customer's VLAN tags by
running q-in-q yourself, your encapsulated tags just get encapsulated again
with the carrier's q-in-q and the tags stack. The frames get bigger though,
which is why the upstream devices need to support larger than normal
Ethernet frames. I'm thinking q-in-q is what you mean when you say "MAC in
MAC". We've successfully used this for three "layers" of stacked tags (our
carrier, then us, then our customer).

For our type-2 circuits that run over other carrier's metro-E networks, we
usually run an open network with the carrier that lets us run our own tags
anywhere we want. The downside is that this becomes an any-to-any network so
you have to be careful with broadcasts as the network grows. The upside is
that you can control the far-end locations your POP sees by running your own
VLAN layout since each carrier interface is a trunk port *at each site*.
This is how we usually do it. If you have each far end site presented to you
as a VLAN tag by your carrier at your POP then you will have added
complexity trying to run q-in-q yourself.

You can also run MPLS from the CPE device. This usually necessitates a more
complex, and thus more expensive, CPE switch, but it's more flexible and
less prone to broadcast issues. 

  -Bill



> Hi Pros,
> 
> Thinking of Virtual CPE as a service to enterprise customers where CPE 
> is virtualized in POP and low cost device in customer premises as a 
> simple bridge device which bridges the traffic to v-CPE in POP. This 
> is to have
cost
> advantage to customers and in POP, any different service can be easily 
> enabled as required by customer solution - firewall, routing, wan
acceleration
> etc.
> 
> But the challenge is the backhaul from customer premise to our POP is 
> on Metro-E Layer 2 switched network. Hence the Layer 2 cannot be 
> extended on Metro-E which can cause significant ARP broadcast as the 
> gateway for customer LAN is in v-CPE in POP.
> 
> Couple of queries:
> 
> a. Is there a way to configure MAC-in-MAC between a bridge device in 
> customer premises and a MAC-in-MAC gateway till our POP, so that 
> Metro-E backhaul can only see outer MAC address? Can this option be 
> possible, If
yes,
> what would be cost advantage gained when the bridge device costing is low?
> 
> b. Sure other providers would be doing this kind of solution, but how 
> do
they
> achieve this and overcome the challenges of LAN extension over shared 
> Metro-E L2 switched network.
> 
> Thanks in advance,
> Arun
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/