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

[Bill Wichers]

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/