[c-nsp] What does L2PT actually do on the wire?

[Anton Kapela]

On May 19, 2010, at 7:47 AM, Jeff Aitken wrote:

> The frame is not encapsulated, the destination mac addr is rewritten to
> 01:00:0c:cd:cd:d0.  At the far end of the "tunnel", the original mac is
> restored.

This is slightly misleading in the context of this metro case -- the examples shown are p2p xconnecs, where said ports are expecting the untagged l2 protocols (vtp/dtp/cdp/etc) to appear. It seems like, in Howard's case, he's handing the provider "already tagged, or double tagged" data as per his CE being the QinQ 'edge.'

The part about: "Transparent Layer 2 protocol tunneling is performed by provider edge (PE) routers on the inbound side of the service-provider network that overwrite the customer PDU-destination MAC address in an Ethernet packet with a well-known Cisco proprietary multicast address (01-00-0c-cd-cd-d0)" seems like it's appropriate for p2p only, xconnect-based mpls ethernet VC's.

Even if the $provider is not doing MPLS, Perhaps the issue is, then, the provider is not flooding 01-00 to the far end, singly tag'd or not.

FWIW, the language is quite different in the context of "lan only" switches, when discussing l2tp:

"The encapsulation involves rewriting the destination media access control (MAC) address in the PDU. An ingress edge switch rewrites the destination MAC address of the PDUs received on a Layer 2 tunnel port with the Cisco proprietary multicast address (01-00-0c-cd-cd-d0). The PDU is then flooded to the native VLAN of the Layer 2 tunnel port. If you enable Layer 2 protocol tunneling on a port, PDUs of an enabled protocol are not sent out. If you disable Layer 2 protocol tunneling on a port, the disabled protocols function the same way they were functioning before Layer 2 protocol tunneling was disabled on the port."

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/l2pt.html#wpxref18102

-Tk