Cannot establish LDP session with a VRF neighbor

Unanswered Question
May 27th, 2008
User Badges:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
n.nandrekar Tue, 05/27/2008 - 20:34
User Badges:
  • Silver, 250 points or more

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 Tue, 05/27/2008 - 23:59
User Badges:
  • Silver, 250 points or more

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 Wed, 05/28/2008 - 01:41
User Badges:
  • Silver, 250 points or more

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 Wed, 05/28/2008 - 04:51
User Badges:

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 Wed, 05/28/2008 - 06:03
User Badges:
  • Silver, 250 points or more

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 Wed, 05/28/2008 - 06:47
User Badges:

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 Wed, 05/28/2008 - 09:46
User Badges:
  • Silver, 250 points or more

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 Wed, 05/28/2008 - 11:04
User Badges:

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 Wed, 05/28/2008 - 11:06
User Badges:
  • Cisco Employee,

Michael,


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


Regards,

miwitte Wed, 05/28/2008 - 16:35
User Badges:

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 Wed, 05/28/2008 - 17:03
User Badges:

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 Wed, 05/28/2008 - 17:23
User Badges:

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

n.nandrekar Wed, 05/28/2008 - 22:27
User Badges:
  • Silver, 250 points or more

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 Wed, 05/28/2008 - 18:20
User Badges:
  • Cisco Employee,

Michael,


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


Regards,

Harold Ritter Wed, 05/28/2008 - 18:01
User Badges:
  • Cisco Employee,

Michael,


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


Regards,

Harold Ritter Wed, 05/28/2008 - 18:23
User Badges:
  • Cisco Employee,

Michael,


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


Regards,

n.nandrekar Wed, 05/28/2008 - 22:30
User Badges:
  • Silver, 250 points or more

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 Thu, 05/29/2008 - 04:21
User Badges:

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 Thu, 05/29/2008 - 05:37
User Badges:
  • Cisco Employee,

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 Thu, 05/29/2008 - 10:00
User Badges:

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 Thu, 05/29/2008 - 10:11
User Badges:
  • Cisco Employee,

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 Thu, 05/29/2008 - 18:22
User Badges:

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

Actions

This Discussion