Restrictions on Ethernet L2 circuits?
Even.Endresen at bkk.no
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
PBB would help a lot, but as far as Cisco equipment is concerned, it is only supported on 7600 with ES40 line cards: http://www.cisco.com/en/US/docs/ios/cether/configuration/guide/ce_mac_evc_pbb_ps6922_TSD_Products_Configuration_Guide_Chapter.html
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
More information about the NANOG