Pseudowire over XRd not working?

[SA2]

Hi, We´ve been using XRd as a way to do integration testing with our autoprovisioning platform using gnmi.
This works great.

However I'm currently trying to do end to end testing of the whole solution with actual traffic forwarding across the finished service.
(A simple ping test from the CPE to a loopback on a remote SE).

Routing/LDP is up and running and all the XRd nodes have reachability and signal the PWHE correctly, it is UP/UP.
But trying to forward traffic through it fails.

Ive simplified the setup to be more minimal for testing. but still seeing the same issue

The configuration on AGG1:

Configuration on AGG2 is mirrored.

CPE1 has a ip interface with 1.1.1.1/24 trying to ping 1.1.1.2 on CPE2.

The packets are received on AGG1 and sent across mpls to AGG2.
As can be seen on wireshark:

AGG2 however does not seem to recognise that these should be sent out to CPE2. and reports nothing received or sent in the show l2vpn group g xc p details output.

Is this something that simply does not work on the XRd-control plane version?
Or should it work but with restrictions to performance.
We would just like to do simple verification of the configured service in this virtual environment.

-Anders

[MHM Cisco World]

 Share 

Show l2vpn xconnect group g  xc-name p detail 

MHM

[SA2]

Hi, Ive attached a more complete drawing with configs, output and wireshark captures.
It seems I miss remembered the problem, the traffic seems to get through the tunnel, but the egress LSR is unable to put the dot1q header back on. so the egress arp request gets the wrong ethernet header.

[MHM Cisco World]

PW is type 5 and hence the traffic send with vlan tag'

And you dont use vlan rewrite (pop 1) then traffic not tag and drop in PE2.

Add vlan rewrite and check again.

MHM

[SA2]

Hi, the configuration on both Aggs use rewrite ingress tag pop 1 sym.
Or did I misunderstand something?

[Harold Ritter]

Hi @SA2 ,

This is not a configuration issue. Your initial configuration would work on XRv9k. As @Ramblin Tech mentioned, XRd control plane has limited data plane support. 

Regards,

[Ramblin Tech]

As the XRd datasheet says: "XRd Control Plane provides minimal forwarding capabilities", so it is quite possible that the data-plane functionality of the XRd control-plane flavor does not provide complete support for PWHE.

Do you have access to XRd vRouter flavor?

[SA2]

>> Do you have access to XRd vRouter flavor?
Unfortunately not as that requires specific hardware and privilege.

[SA2]

Also after changing from subinterface with vlan tag to the main interface (gig0/0/0/2 l2transport) on both aggs,
the arp request frame still appears mangled at the egress LSR.

So it's not directly related to the vlan encapsulation prosess atleast

[MHM Cisco World]

You change PE from subinterface vpan tag to main interface' did you remove the tag from CE's side?

MHM

[MHM Cisco World]

You can captuee traffic check the vpan tag add to frame egress/ingress PE

MHM

[SA2]

Yes when doing interface tunnel mode and not vlan.
the configuration on the CPE was
int gig0/0/0/0
 ipv4 address 1.1.1.1 255.255.25.0
!

The Agg configuration was then changed to:

int gig0/0/0/2 l2transport
!
l2vpn xconnect group g p2p p
 int gig0/0/0/2
!

[MHM Cisco World]

Ok' 

Let type4 

Return tag to CE and PE 

Dont use rewrite vlan in PE

Config psuedowire-class internetwork vlan (this type4)

Then try ping from ce to ce 

MHM

[SA2]

I figured out the cause of the issue, with explicit null enabled for mpls on the AGG nodes, traffic experienced this strange issue.
Turning off explicit null on the AGG nodes fixed the issue, so now traffic is flowing.
Wheter or not explicit null actually works and its a simple issue of incorrect configuration I'm not sure.
Just turning off explicit null solves the issue for me, and Im ready to move on.

Thank you for the assistance.

[MHM Cisco World]

Yes I see label 0 in mpls packet above the VC label.

But that must work with explicit or without explicit.

Anyway I will do some search it can bug or there is restriction of using explicit in direct connect peer with l2vpn

Thanks alot for update me 

MHM