INTER-AS L2 MPLS VPN

[petersrule2003]

Hi All,

I have inter as mpls vpn scenario set up on GNS.

I can ping the loop back of the PE in on AS from the other AS PE sourced from loopback as well.

But the pseudowire fails to come up.

What could be the reason for this. See output below.

R2#sh mpls l2transport vc 406 detail

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

  Destination address: 150.1.1.1, VC ID: 406, VC status: down

  Create time: 00:17:56, last status change time: 00:17:56

  Signaling protocol: LDP, peer 150.1.1.1:0 down

    MPLS VC labels: local 18, remote unassigned

    Group ID: local 0, remote unknown

    MTU: local 1500, remote unknown

    Remote interface description:

  Sequencing: receive disabled, send disabled

  VC statistics:

    packet totals: receive 0, send 0

    byte totals:   receive 0, send 0

    packet drops:  receive 0, seq error 0, send 0

R1#sh mpls l2transport vc de

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

  Destination address: 150.1.2.2, VC ID: 406, VC status: down

  Create time: 00:19:32, last status change time: 00:19:31

  Signaling protocol: LDP, peer 150.1.2.2:0 down

    MPLS VC labels: local 18, remote unassigned

    Group ID: local 0, remote unknown

    MTU: local 1500, remote unknown

    Remote interface description:

  Sequencing: receive disabled, send disabled

  VC statistics:

    packet totals: receive 0, send 0

    byte totals:   receive 0, send 0

    packet drops:  receive 0, seq error 0, send 0

R1#ping 150.1.2.2 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:

Packet sent with a source address of 150.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/245/608 ms

Note , i am using 3725 routers all the way.

R1#sh run int f0/0

Building configuration...

Current configuration : 116 bytes

!

interface FastEthernet0/0

no ip address

duplex auto

speed auto

xconnect 150.1.2.2 406 encapsulation mpls

end

R2#sh run int f0/0

Building configuration...

Current configuration : 116 bytes

!

interface FastEthernet0/0

no ip address

duplex auto

speed auto

xconnect 150.1.1.1 406 encapsulation mpls

end

[petersrule2003]

Timely response is appreciated as i am looking at deploying on real network soon.

P.S: New to L2VPN configs ,more confortable with L3VPN , please pardon my ignorance.

[Peter Paluch · Accepted solution]

Hi,

A couple of things to verify:

1. Is the MPLS enabled along the path of the pseudowire? For simplicity, make sure all your interfaces are configured with the mpls ip command.
2. If you are using different ASes with BGP, use the neighbor send-label between the eBGP peers to make sure that the inter-AS path is labeled as well.
3. What is the LDP RID selected by your routers? Make sure that the LDP uses the RID from the loopback interface using the global configuration command mpls ldp router-id lo0 force

If this does not help please post the exhibit of your topology and your configurations. Thanks!

Best regards,

Peter

[petersrule2003]

Hi Peter ,

Thanks for your response , i changed all the mpls router-id's to  use loopback and it worked .  Can you please explain why it didnt work  earlier. i know it has something to do with label forwarding , can t remeber the exact theory behind it.

Rgds

[Peter Paluch]

Hello,

Glad to see it worked.

To my knowledge, the LDP Router ID is actually used as an IP address, i.e. when LDP contacts a peer, it sends packets towards its Router ID (RID) as an IP address. This brings up various sorts of problematic behavior:

• If the interface from which the RID was borrowed is not advertised in a routing protocol, the LDP session fails because it tries to connect to an IP address for which there is no known route.
• If a targeted LDP session is established, it must be established towards the RID of the destination LSR as an IP address. Otherwise, the targeted LDP session will not be built and the following error message may be displayed:

*Mar  1 00:02:16.043: %ATOM_TRANS-4-CONFIG: 10.255.255.1 mismatches the peer router id 10.0.12.1

In this example, the 10.255.255.1 was an IP address specified in the xconnect command while the LDP RID of that router was 10.0.12.1.

LDP for packet-based IP networks uses per-platform label space, i.e. regardless of the ingress interface, the label assignment to a particular FEC is identical. However, the router itself may have several interfaces and several IP addresses, and it is hence possible to have several ways to contact this peer, especially over common segments. Therefore, it is prudent to establish only a single session if possible, because the label mappings advertised through multiple LDP peerings would still be the same. This is accomplished by contacting the neighbor under its single LDP RID. This is the underlying reason behind the requirement of matching the contacted router's IP address with the LDP RID.

Best regards,

Peter