[c-nsp] Pseudowire VC Types on Cisco

Wed Jul 29 15:45:52 EDT 2015

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
waris at cisco.com<mailto:waris at cisco.com>
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: "cisco-nsp-bounces at puck.nether.net<mailto:cisco-nsp-bounces at puck.nether.net>" <cisco-nsp-bounces at puck.nether.net<mailto:cisco-nsp-bounces at puck.nether.net>> on behalf of James Bensley <jwbensley at gmail.com<mailto:jwbensley at gmail.com>>
Date: Wednesday, July 29, 2015 at 11:38 AM
To: "cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>" <cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>>
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  cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/