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!

For the issue "150.1.5.5,150.1.6.6,150.1.56.0 and 150.1.45.0 are missing" , is 150.1.24.4 reachable from this PE? Have you given next-hop-self on the remote PE for the VPNV$ neighborship? As I see it, the labels are present in the vpnv4 label but not installed in the mpls fw table. says no path. So lets first see if the next hop is reachable for those networks.

- Niranjan

[Harold Ritter]

Michael,

Nothing stands out. Can you clarify what you meant by "cef tables don't look right".

Regards,

[Harold Ritter]

Michael,

Can you post the cmplete configs for R1 and R2, as well as a show version for both routers.

Regards,

[Harold Ritter]

Michael,

Would it be possible to remove the host route on the CE and try to ping 150.1.12.2.

Regards,

[n.nandrekar]

just posting a reply in the end to notify that i have replied to 1 of the comments in the middle of the flow which could be missed.

Regards,

Niranjan

[miwitte]

Thanks for the reply's! I will test out the above suggestions tonight, I did 2 more labs last night and they use a simular setup for R1 and R2.

1) as far as the the route to 150.1.24.4 yes the route is there as a OSPF route and I had put a HOST route on both sides just to see if that made a difference.

2) As far as the CEF table, the 150.1.5.0,150.1.6.0 and 150.1.56.0 do not have a interface associated with it I assume that why they are not in the forwarding table. If you look at R4's CEf table you will see that 150.1.3.0, 150.1.12.0 are in the CEF table with a interface and are also in the forwarding table so thats why I did not think next hop self was needed.

3) I will get the other info tonight.

Thanks again for the interest!

[Harold Ritter]

Michael,

2) Sorry I missed the missing interfaces for 150.1.5.5/32 and the others. I was specifically looking at the LDP issue between R1 and R2.

Regarding this specific issue with the missing interfaces, I see that the next-hop is 150.1.24.4, which I assume is the address of the directly connected interface on R4. This could lead to some unpredictable results. Make sure that the BGP session is established using the loopback address of the PEs (R2 and R4). This will probably solve the CEF table weirdness.

Regards,

[miwitte]

That is something to try. Curious why that would cause a issue. Also as far as the LDP issue I can break it by removing the host route on the CE router to the directly connected PE LDP neighbor. Once I put that route back in, I get my session keepalives back on the PE router from the CE router. Not behaviour I would expect. I could see if it was a host route to the LDP ID(loopback in my case) AND that was not in the routing table but thats not the case.

[Harold Ritter]

Michael,

There is many ways in which not using the loopback address can break the connectivity. One example would be if you had a P router in between your two PEs. The P router would rightfuly see the directly connected interface as a local subnet and would therefore advertise an implicit null to the ingress PE. Due to the implicit null receied for the BGP next hop, the ingress PE would only send the VPN label towards the P, which would not be able to forward the packets beased on the VPN label. This would cause the traffic to be dropped.

The recommendation is always to use a loopback interface address with a /32. This will avoid major headaches while deploying large netwroks.

Secondly, I agree that the behavior you are observing with LDP is not normal. I did a quick recreate and it worked like a charm, hence me asking for the configs and the "show ver".

Regards,

[miwitte]

OK the cef table and mpls forwarding table turned out to be hardware. I swapped the port from the fa0/0 on the NPE to eth 3/0 on one of the cards and its fine. Don't know what made me try that. Thanks for all the help with this one, I am about half way through WKBK1 and I still have all of the labs left in WKB2 so I am sure i will get stuck again. What a PITA!!

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 Ethernet3/0

150.1.6.6/32 150.1.24.4 Ethernet3/0

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 Ethernet3/0

150.1.56.0/24 150.1.24.4 Ethernet3/0

224.0.0.0/4 drop

224.0.0.0/24 receive

255.255.255.255/32 receive

Rack1R2#sh mpl

Rack1R2#sh mpls fo

Rack1R2#sh mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or VC or Tunnel Id Switched interface

16 Pop Label 150.1.1.1/32 0 Se1/0.1 point2point

17 Pop Label 150.1.12.1/32 0 Se1/0.1 point2point

18 Pop Label 150.1.4.4/32 0 Et3/0 150.1.24.4

19 Pop Label 150.1.1.1/32[V] 0 Se1/0.1 point2point

20 19 150.1.3.3/32[V] 457 Se1/0.1 point2point

21 Pop Label 150.1.12.0/24[V] 0 Se1/0.1 point2point

22 Pop Label 150.1.13.0/24[V] 0 Se1/0.1 point2point

23 18 150.1.5.5/32[V] 0 Et3/0 150.1.24.4

24 25 150.1.6.6/32[V] 0 Et3/0 150.1.24.4

25 19 150.1.45.0/24[V] 0 Et3/0 150.1.24.4

26 20 150.1.56.0/24[V] 0 Et3/0 150.1.24.4