Pseudowire issue between IOS/IOS-XR

[sebas7]

Hello everyone,

I'm facing an issue and would appreciate your help. Here's my topology:

Client A (ASR1K) — dot1q — PE (IOS) — P (IOS-XE) — PE (IOS XR) — dot1q — Client B (NCS5500)

I'm trying to establish a pseudowire between the two clients through the MPLS backbone. The L2 circuit comes up successfully with no signaling issues, but there’s no IP connectivity between the customer routers.

Since I’m limited in the production network, I reproduced the scenario in a virtual lab and performed packet captures to understand what's going on — and I found something unexpected:

When I ping from Client B to Client A, I see the ARP request reaching Client A, but it has double dot1q encapsulation (QinQ). I believe this is why it fails.

When I ping from Client A to Client B, the ARP request reaches Client B but without any VLAN tag, despite arriving on a subinterface expecting dot1q.

From the beginning I suspected a dot1q handling issue, but I didn’t know how to prove it until I ran the captures.

Interestingly, if I remove dot1q encapsulation at both ends and use plain physical interfaces, the pseudowire works perfectly and I get full connectivity in the lab.

I tried applying rewrite ingress tag pop 1 symmetric on the IOS XR PE, but it doesn’t help — traffic never even reaches the MPLS core when that command is applied.

Has anyone experienced something similar or have ideas on how to handle this dot1q behavior across mixed platforms?

IOS configuration :

interface Gi0/0.2161

 encapsulation dot1q 2161

 xconnect x.x.x.x 2161 encapsulation mpls

For IOS-XR , I use : https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/vpn/75x/b-l2vpn-cg-ncs5500-75x/configure-point-to-point-layer-2-services.html

Again the PW is UP but not ping connectivity.

Thanks in advance!

Best regards,

[M02@rt37]

Hello @sebas7 

Please share ios-xr config side.

[sebas7]

Hello,

Here below the configuration in the IOS-XR PE.

l2vpn

 xconnect group EoMPLS-PW-2161

  p2p EoMPLS-PW-2161

   interface GigabitEthernet0/0/0/1.2161

   neighbor ipv4 1.1.1.1 pw-id 2161

interface GigabitEthernet0/0/0/1.2161 l2transport

 encapsulation dot1q 2161

The circuit was established correctly, everything is UP, and if I use the physical interface without any subinterface, everything works fine. The issue is with the subinterface.

Thanks

[Joester Brondani · Accepted solution]

Hello @sebas7 

Have you tried using "rewrite ingress tag pop 1 symmetric" in the sub-interface?

Joester Brondani
CCIE SP/EI
CCDE

[sebas7]

Hello,

Yes, I tried that command. When I applied it, I couldn't see the traffic reaching the P router. Without that command, the traffic flows without issues—it's only when it reaches the endpoints that I encounter the problem described earlier.

Regards

[sebas7]

Hello everyone,

I found the root cause of the issue — and yes, you were partially right.

When I applied the rewrite ingress tag pop 1 symmetric command on the IOS XR side, I didn’t initially notice that the pseudowire went down due to an MTU mismatch. IOS XR automatically adjusts the MTU when the rewrite command is applied, which resulted in a difference I hadn’t accounted for. Once I corrected the MTU value, connectivity was restored.

However, that still didn’t solve the issue in the production network.

The actual problem was this: when configuring xconnect on a subinterface in IOS, the platform handles it as a Type 5 pseudowire (raw Ethernet, no VLAN tag). But on the IOS XR side, I had configured it as VLAN-based, which means Type 4 pseudowire (Ethernet VLAN, expects a VLAN tag). This mismatch was causing the failure.

Once I changed the IOS XR configuration to use Type 5, everything started working correctly.

So the key takeaway is:

"VLAN-based" in IOS and "vlan transport-mode" in IOS XR do not mean the same thing.

Next time I’ll focus strictly on the PW Type (4 or 5) to avoid such inconsistencies.

Thanks again for your input!