Restrictions on Ethernet L2 circuits?

Endresen Even Even.Endresen at
Fri Jan 1 22:16:55 UTC 2010

> > Couldn't PBB or even Q-in-Q provide that isolation as well, at least for
> > point-to-point services? I must say that I don't personally have much
> > experience with those, because we tend to connect our customers to
> > EoMPLS-capable routers directly.

> QinQ does nothing to reduce the number of MAC addresses required.
> PBB can do this, but there is still not a lot of  PBB equipment
> available.


PBB would help a lot, but as far as Cisco equipment is concerned, it is only supported on 7600 with ES40 line cards:

On my wish list is PBB support on access layer switches, like the Cisco ME3400. This would bring the benefits of tunneling out to the very edge of the network.

We have an MPLS core with a hierarchial Ethernet layer 2 access network between the core and the customer. Typically there are two or three switches between the the PE node and the customer. Even though we are building the MPLS network further out towards the edge, there will always be a layer 2 access network.

It is the switches in the access network that is my concern. We have seen some rather strange problems over the years, like customer nodes that flood MAC address tables with spoofed MAC addresses, and frames that are reflected, causing switches to continually re-learn the same MAC-addresses from different ports. MAC header encapsulation at the very edge of the network would protect the switches in the access layer, and thereby make the service providers more willing to offer more transparent products to their customers.



This message and any attachment is intended for the person(s) 
named above only. It may contain information that is confidential 
or legally privileged. If you have received this communication in 
error, please erase all copies of the message and its 
attachments and notify us immediately. Thank You.

This footnote confirms that the email and attachment(s) has 
been swept by our anti-virus solution for the presence of known 
computer viruses.

More information about the NANOG mailing list