Cannot establish LDP session with a VRF neighbor

[miwitte]

I have been working on a lab scenario and I cannot get my LDP session to establish between 2 7200's running 12.2(29). Looks like the hellos are being sent and received, but something isn't right with the proccessing. When I do a "debug mpls ldp messages" I see my hello's sent/received on both peers(the one with vrf on the interface and the one without) However when I use the "debug mpls ldp session io" on my vrf router, I do not see the keepalives coming from the non vrf peer. So after 3 minutes the session times out and LDP neighbor goes down and back up. Now if I take off the "ip vrf forwarding AS1" command the peer work fine. It appears its something with the processing when the vrf is configured on the interface. I have tried hard coding the LDP to the loopback and gave both routers static routes to the loopback. The discovery looks ok as well as the show LDP neighbor. I also have 2 3640's running 12.3(14)T and they run fine with this config. I want to move on but following labs have the same type of configuration.

[n.nandrekar]

hi!

From your description it seems possible that the router id is in the global table and not in the vrf table. So probably the keepalives dont reach and the session goes down.

Can you try by specifying the transport ip for LDP? Go to the CE facing interface and give the command " mpls ldp discovery transport-address xxxx" as the interface ip address? You could do the same on the CE interface also but that might not be required if the CE loopback is reachable (but wont hurt to try).

Specifying the transport ip sends the ip in the ldp hello messages and helps initiate the tcp session with this ip rother than the router-id (which is the default transport ip).

"Sh mpls ldp discovery" is a command which will show you the reason for the session not being established.

Regards,

Niranjan

[shivlu jain]

mpls transport command always takes loopback for the peering. I think this should not required. It is only required it vendor doesnot support.

regards

shivlu

[n.nandrekar]

hi Shivlu!

MPLS Transport id is used for the peering and not the loopback whenever you specify it. I am sure his problem would be solved with this. You can try configuring the LDP in a vrf interface ( used for CsC scenarios) and the reason you will see for the session not coming up / flapping is that the router id is not reachable ( will be seen in sh mpls ldp discovery"). This is because the loopback which is picked up as a router id is not in vrf. When you specify a transport ip on the interface, that ip is used to initiate peering.. not the loopback / router id.

Regards,

Niranjan

[miwitte]

Thanks for the reply's! After playing around last night, I was able to finally get the session to stay up after I put a HOST route on the PE to the peer IP address(LDP ID on CE) as I already had the mpls ldp discovery transport-address interface command. Once I did this I got my Session keepalives from my CE peer. Now the weird thing is that I see my session hellos from the CE perfectly fine. Now on one side of the CsC I am using 3640's for the CE-PE routers and have no issue(well one I will get into) The 7200's on the other side are used for the PE-CE and the PE needed the host route pointing to the directly connected neighbor! I can only assume this is a quirk in the 12.2.29 code I am using. At this point I now have connectivity and labels appear to be propagating fine. However on my 7200 PE router I do not see the routes in the MPLS forwarding table from the other side(even though I can ping through AND the the CE has these routes in the mpls forwarding table). Doing a debug I do not see the advertisements to the 7200. When I look at "sh mpls ldp discovery all" on my 3640 PE I see its CE LDP neighbor showing no host route so I am pretty sure thats why it is not sending the label. I tried adding a host route to both the loopback and LDP ID and nothing. Further reading last night and I think this route needs to be a vrf route??

"ip route vrf AS1 150.1.45.5 255.255.255.255 s0/0.1" Again thanks for the replies!!

[n.nandrekar]

Hello Michael!

I am sorry but i got a lot confused with the 7200 and 3640s.... :) A topology might have helped but anyways.. looks like you have figured out the way. I didnt understand the problem correctly but one thing is for sure... the route for CE has to be added to the vrf. The global routing table on the carrier PE should only contain the carrier core routes. The route for CE if you have to add should be in the vrf on which you have started the ldp. That is the exact same reason that the LDP is not established if the transport ip is the router-id (default) which is in the global routing table.

But again dont you have a PE-CE protocol (e-bgp / ospf) running?? why would you require the static route there?

And in case you are using e-bgp as PE-CE on both sides be sure to configure AS-override. This is where i had wasted some time when I was trying out the scenarios. Hope this is not the problem here.

Cheers!

Niranjan

[miwitte]

Thanks for the quick response. Yes I am running OSPF between the PE-CE and on the CE I am advertising the loopback and the serial(which shouldn't matter since its directly connected). This is why I wouldn't have thought of adding any kind of route. The key to making this work however weird was the addition of a HOST route pointing to the CE LDP peer(I already tried to use a Host route to the loopback since it was the LDP ID). Now the thing I will fight tonight is the " host route" in the sh mpls ldp discovery all" on my 3640 PE. Again this scenario should just require very basic commands on the PE and CE such as

PE

ip vrf AS1

RD 2:1

route-target both 2:1

int s0/0.1

ip vrf forwarding AS1

ip address 150.1.12.2 255.255.255.0

mpls Ip

router ospf 2 vrf AS1

network 150.1.12.2 0.0.0.0 area 0

CE

int s0/0.1

ip address 150.1.12.1 255.255.255.0

mpls ip

router ospf 1

network 150.1.1.1 0.0.0.0 area 0

network 150.1.12.1 0.0.0.0 area 0

[n.nandrekar]

Wow!!! This really is wierd! Why should it work with a static route inserted in the VRF for the CE and not with the OSPF route already present in the VRF?? I havent faced this issue. The only thing i have noticed is that when I used transport ip as the interface ip for the LDP formation, the session was formed and up but still the "sh mpls dlp discovery" showed as "no host route" for the ldp router id. But this again is ok as you donot need that to be reachable as the session is formed with the interface itself.

Cheers!

[miwitte]

Agreed this should have been a no brainer to do. I will post what I see tonight I spent quite a lot of time on this. Since I am going through labs in preperation for the SP test i alway slike to work through any weirdness that may occur during the lab you never know when it will bite you again. I'll take off the route and show you the debugs.

[Harold Ritter]

Michael,

Can you do a "sh mpls ldp dis" and then a "show ip route vrf AS1 "

Regards,

[miwitte]

sure I'll fire up the rack tonight.

[miwitte]

Ok so I took the routes off for the LDP interface and bounced the serial interfaces. Notice that the hellos are coming in on the router with the VRF assigned, but I do not get the session keepalives. As you can see the LDP peer is discovered, has the correct neighbor parameters and the correct route learned via OSPF. However from the enclosed attachment you can see that the session keepalives from the CE router(150.1.12.2 are not there and the LDP neighbor goes down. Adding the host route to the 150.1.12.2 address makes it work. I am moving onto the no host route on the other side.

Rack1R4#sh mpls ldp discovery all

Local LDP Identifier:

150.1.4.4:0

Discovery Sources:

Interfaces:

Ethernet0/0 (ldp): xmit/recv

LDP Id: 150.1.2.2:0; IP addr: 150.1.24.2

VRF AS1: Local LDP Identifier:

150.1.45.4:0

Discovery Sources:

Interfaces:

Serial0/0.1 (ldp): xmit/recv

LDP Id: 150.1.5.5:0; IP addr: 150.1.45.5; no host route

[miwitte]

Well the host route fixed my discovery message but did not fix the fact that my CE routes are not in the mpls forwarding table, however they are in the CE forwarding table and i have connectivity to between end points. I am moving on spent wayyyy too much time here.

ip route vrf AS1 150.1.45.5 255.255.255.255 Serial0/0.1

Rack1R4#sh mpls ldp discovery all

Local LDP Identifier:

150.1.4.4:0

Discovery Sources:

Interfaces:

Ethernet0/0 (ldp): xmit/recv

LDP Id: 150.1.2.2:0; IP addr: 150.1.24.2

VRF AS1: Local LDP Identifier:

150.1.45.4:0

Discovery Sources:

Interfaces:

Serial0/0.1 (ldp): xmit/recv

LDP Id: 150.1.5.5:0; IP addr: 150.1.45.5

[miwitte]

cef tables don't look right

Rack1R2#sh ip cef vrf AS1

Prefix Next Hop Interface

0.0.0.0/32 receive

150.1.1.1/32 150.1.12.1 Serial1/0.1

150.1.3.3/32 150.1.12.1 Serial1/0.1

150.1.5.5/32 150.1.24.4

150.1.6.6/32 150.1.24.4

150.1.12.0/24 attached Serial1/0.1

150.1.12.0/32 receive

150.1.12.2/32 receive

150.1.12.255/32 receive

150.1.13.0/24 150.1.12.1 Serial1/0.1

150.1.45.0/24 150.1.24.4

150.1.56.0/24 150.1.24.4

224.0.0.0/4 drop

224.0.0.0/24 receive

255.255.255.255/32 receive

Rack1R2#

TERM_SERVER#4

[Resuming connection 4 to r4 ... ]

Rack1R4#sh ip cef vrf AS1

Prefix Next Hop Interface

0.0.0.0/0 drop Null0 (default route handler entry)

0.0.0.0/32 receive

150.1.1.1/32 150.1.24.2 Ethernet0/0

150.1.3.3/32 150.1.24.2 Ethernet0/0

150.1.5.5/32 150.1.45.5 Serial0/0.1

150.1.6.6/32 150.1.45.5 Serial0/0.1

150.1.12.0/24 150.1.24.2 Ethernet0/0

150.1.13.0/24 150.1.24.2 Ethernet0/0

150.1.45.0/24 attached Serial0/0.1

150.1.45.0/32 receive

150.1.45.4/32 receive

150.1.45.5/32 attached Serial0/0.1

150.1.45.255/32 receive

150.1.56.0/24 150.1.45.5 Serial0/0.1

224.0.0.0/4 drop

224.0.0.0/24 receive

255.255.255.255/32 receive

[miwitte]

lets try that again sorry..