Afaik, L2PT is a port behavior, not a encaps type; it treats these (special ethertype frames) like other untagged frames arriving on an L2 port configured for 1q tunneling. Think of l2pt as "selective port ethertype ignoring." So, it doesn't change SA or DA of the frame, and something looking closely at the headers in the middle would see a single-Q tag ethertype value, on top of a regular stp/vtp/cdp frame.
It is possible that your provider is doing something amazingly bone-headed here, and maybe is un-tagging the outermost frame, and dropping the special frame bits. Did they "coordinate" outer vlan numbers with you? ------Original Message------ From: Howard Jones Sender: [email protected] To: [email protected] Subject: [c-nsp] What does L2PT actually do on the wire? Sent: May 19, 2010 4:43 AM We have a metro-ethernet link between two sites, where our CE are a pair of 3750G switches. We run q-in-q for a couple of internal things, with all the L2PT options enabled (cdp, vtp, stp, lacp etc etc). We've found that even with all that enabled, CDP (for example) doesn't get to the far end, and it turns out that our MPLS provider's default product blocks a series of L2 protocols. We see encapsulation counters for L2PT going up, but 0 for decapsulation. My question though is: what is L2PT actually doing? My original assumption was that it was encapsulating these packets in another frame header, so they would no longer look like STP or CDP or whatever to intervening devices. That doesn't appear to be the case though, or they wouldn't get blocked. Thanks in advance for any illumination... Howie _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -Tk _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
