James, EVC configuration default signaling is VC Type 5 regardless of rewrite is configured or not. VC type 5 does not mean that it will pop the tag. EVC will not strip the tag in the absence of rewrite. It will forward the packet as it is received. If you need to change the VC type then you need to use the command "interworking vlan”. Little bit history, VC type 4 came into being since some hardware did not have the capability to manipulate the tag at egress hence the concept of dummy tag. VC type 4 is pretty much becoming non existent and is being supported on legacy platforms only. VC type 5 will be the default signaling moving forward where users will have the flexibility to add/remove tags based on the EVC configuration.
Best Regards, [http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg] Waris Sagheer Technical Marketing Manager Service Provider Routing Segment [email protected]<mailto:[email protected]> Phone: +1 408 853 6682 Mobile: +1 408 835 1389 CCIE - 19901 <http://www.cisco.com/> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> on behalf of James Bensley <[email protected]<mailto:[email protected]>> Date: Wednesday, July 29, 2015 at 11:38 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [c-nsp] Pseudowire VC Types on Cisco Hi All, Can someone please clarify for me why the following pseudowires ARE working? This is a lab scenario, here is a link to the topology, I want to test a pseudowire that will carry multiple tagged C-VLANS: http://null.53bits.co.uk/uploads/networking/cisco/mpls/pwe3-testing/EVC-Mac-Issue.png The 1941 is acting as two CPEs, it has gi0/0.11 in vrf1 and gi0/1.11 in vrf2 configured as 192.168.0.1 and 192.168.0.2 respectively. To ping from gi0/0.11 (192.168.0.1) to gi0/1.11 (192.168.0.2) the traffic needs to pass over a pseudowire between two PEs, the ME3800 and ASR1001. This is the configuration and results (same config and "show" output on both PEs) when configuring the EoMPLS pseudowire on the PEs using an xconnect on an EVC with dot1q encapsulation set: http://null.53bits.co.uk/uploads/networking/cisco/mpls/pwe3-testing/IOS%20to%20IOS-XE%20EVC%20tagged.txt interface GigabitEthernet0/1 description ME3600-Gi0/3 switchport trunk allowed vlan none switchport mode trunk no cdp enable service instance 11 ethernet encapsulation dot1q 11 xconnect 10.0.0.2 123 encapsulation mpls ME3800#show mpls l2transport binding 123 Destination Address: 10.0.0.2,VC ID: 123 Local Label: 19 Cbit: 1, VC Type: Ethernet, GroupID: 0 MTU: 1500, Interface Desc: ME3600-Gi0/3 VCCV: CC Type: CW [1], RA [2] CV Type: LSPV [2], BFD/Raw [5] Remote Label: 20 Cbit: 1, VC Type: Ethernet, GroupID: 0 MTU: 1500, Interface Desc: ME3600-Gi0/4 VCCV: CC Type: CW [1], RA [2], TTL [3] CV Type: LSPV [2] Ping works fine. My question is why is the VC type “Ethernet” (which I assume is VC type 5?) when I haven’t configured a “rewrite” operation to PoP the VLAN tag before the frame enters the xconnect? Since I want to carry the dot1q tag I want this to be VC type 4 surely? Is it simply that IOS negotiates to VC type 5 by default? If I reconfigure the xconnect’s as follows the VC type becomes “Eth VLAN” (which I assume is VC Type 4?) so now I assume the C-VLAN is being carried across the pseudowire: http://null.53bits.co.uk/uploads/networking/cisco/mpls/pwe3-testing/IOS%20to%20IOS-XE%20EVC%20tagged%20VC-4.txt pseudowire-class EoMPLS-dot1q encapsulation mpls interworking vlan interface GigabitEthernet0/1 description ME3600-Gi0/3 switchport trunk allowed vlan none switchport mode trunk no cdp enable service instance 11 ethernet encapsulation dot1q 11 xconnect 10.0.0.2 123 pw-class EoMPLS-dot1q In both cases ping works. However as you can see in the configs, the ME3600 which sits in the middle of the lab tying everything together at layer 2, this is configured with EVCs that expect tagged frames. In the first scenario with VC type "Ethernet", is the dot1q tag being stripped by the PE despite the lack of “rewrite” command because it is VC type 5? And when the frame lands at the other PE is is added back on again because the EVC is configured with “encapsulation dot1q 11” again, even though there is no “rewrite” command here either? Or because it is VC type 5 and the VLAN ID is signalled during pseudowire setup so the remote PE and push it onto the frame before transmission onto the remote access circuit? Sadly this is a remote lab so I can't easily go there and plug my laptop in and run wireshark In both scenarios the frames are coming out of the PE towards the ME3600 layer 2 devices as tagged, I can see the dot1q frame count increasing with "show int gi0/4 controller | i Dot" Any help is appreciated. Cheers, James. _______________________________________________ cisco-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
