Fixed my own xconnect, but how?

[jwbensley]

Very basic scenario;

f1/0--R1--f0/0----------f0/0--R2--f1/0

I wanted to create an mpls encapsulated xconnect between interface f1/0 on both routers (as this is part of an mpls network). I wrestled with this for some time and never got it to work. In the end I added another router in the middle and the xconnect came strait up. The only reason I can think for this, and the method behind the madness of adding a middle router, is that R1 and R2 are directly facing each other so MPLS won't add any labels on, because this is the last hop (so emply wouldn't tag anything, so it couldn't encapsulate the traffic).

Does this sound like a possible answer as to why I got this working eventually (using the original configuration) ? Or can an xconnect work here with just two directly facing routers? Should I have used an xconnect with l2tpv3 encapsulation here instead?

Thanks for reading.

[Peter Paluch · Accepted solution]

Hello,

That does not make much sense - MPLS L2 pseudowires use double labeling - the topmost label identifies the egress PE while the bottom label identifies the pseudowire. In the scenario of back-to-back PEs, the topmost label will not be present (because of Penultimate Hop Popping) but the bottom label identifying the pseudowire will still be present. I've configured a similar scenario just now in Dynamips and the pseudowire is working just fine.

There must have been some configuration error. Is it possible to post the configuration of your routers from the moment where the pseudowire did not work?

Best regards,

Peter

[Kishore Chennupati]

when you say it didnt work. what didnt work? did you capture some show commands that you can share?

Maybe we can see what could have gone wrong.

As peter suggested , config should also be good

HTH

Kishore

[jwbensley]

I have marked Peters answer as correct, as he is correct in that I am wrong This pseudowire should work because the VPN label would still be imposed even if the LSP tag isn't.

Sadly I haven't got the old configs anymore and all I could find in my notes is this partial output from "show mpls l2transport vc detail"

R1#show mpls l2transport vc detail

Local interface: Fa1/0 up, line protocol up, Ethernet up

  Destination address: 1.1.1.3, VC ID: 65099, VC status: down

    Output interface: if-?(0), imposed label stack {}

Without more output we can only speculate but these two direct PE's had fully converged IGP and iBGP peerings. Each could seach the others networks and LDP adjacencies were established via loopbacks, and LDP adjancencies were up.

I think it may have been an MTU issues, does that sound like a possibility? I think fa1/0 on R1 had a larger MTU (1540) than fa1/0 on R2 (1500). Would this cause the link to stay down?

[Kishore Chennupati]

Peter is always right .

In regards to the MTU , yes if there is MTU mismatch on the AC's in EoMPLS circuits then the PW stays down. One of the things that is exchanged in the messages is the MTU as well.

If you need more information on this there is a good book called "Layer 2 VPN Architectures"  by Cisco press. This has very good detailed explanation on all of the EoMPLS, L2TPv3,AToM,VPLS etc

HTH

Kishore

[jwbensley]

Thanks for the recommendation Kishore, I will be getting a copy of this book ASAP

Cheers!