missing mpls forwarding information

[olorunloba]

I have this funny situation

I can see labels for a route on the mpls binding, but it doe not show up in the forwarding table.

PE#sh mpls ldp bindings 10.10.10.105 32 detail

tib entry: 10.10.10.105/32, rev 12223

local binding: tag: 316 (owner LDP)

Advertised to:

192.168.0.4:0 10.11.10.130:0

remote binding: tsr: 192.168.0.4:0, tag: 127

remote binding: tsr: 10.11.10.130:0, tag: 190

PE#sh mpls for 10.10.10.105

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

From the cef, i have

PE#sh ip cef 10.10.10.105

10.10.10.105/32, version 409, epoch 0, cached adjacency 10.163.8.13

0 packets, 0 bytes

Flow: AS 0, mask 32

tag information set, unshareable, all rewrites owned, one or more rewrites mis

sing

local tag: 316

via 10.16.1.13, 0 dependencies, recursive

next hop 10.16.1.13, FastEthernet0/1/0.5 via 10.16.1.13/32

valid cached adjacency

and wondering about the missing rewrites.

Help from anybody

[nisha_kulkarni]

Hi...

Can u post ur config????

[Harold Ritter]

Can you post a "sh mpls ldp nei " for the host being used as the next hop (10.16.1.13).

Thanks,

[olorunloba]

10.16.1.13 is not an LDP neighbour. The command therefore returns nothing. 10.16.1.13 is a CE router, that also has the said network. This route is statically configured on the PE router. What I do not understand is the reason why the label disappers. Note that after a clear ip route, it is resolved, only for the problem to occur later on.

Any ideas?

[Harold Ritter]

Only the label received from the LDP neighbor matching the next-hop installed in the RIB should be installed in the (LFIB), which is not the case in your scenario.

Could you please explain which label is installed in the LFIB when you do a "clear ip route".

Thanks,

[Harold Ritter]

Sorry, I was just focusing on one part of your question.

Now, about the "rewrites missing" message. What does the static route for 10.10.10.105 look like on the PE. Is it pointing at the physical interface?

Thanks,

[Harold Ritter]

Also, do you see the "TFIB-7-SCANSABORTED" message in the log on the PE. If so, you might be running into CSCee62326.

Hope this helps,

[olorunloba]

Thanks Harold for your posts.

This is the mpls forwarding and binding after clearing the route.

PE#sh mpls ip binding 10.10.10.105 32 detail

10.10.10.105/32, rev 12223

in label: 316 (owner LDP)

Advertised to:

192.168.0.4:0 10.11.10.130:0

out label: 127 lsr: 192.168.0.4:0

out label: 190 lsr: 10.11.10.130:0

PE#sh mpls forwarding-table 10.10.10.105

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

316 Untagged 10.10.10.105/32 6164139 Fa0/1/0.5 10.16.1.13

The route is pointing to an address, which is know via a connected distance

PE#sh ip route 10.10.10.105

Routing entry for 10.10.10.105/32

Known via "static", distance 1, metric 0

Tag 29091

Redistributing via ospf 1

Advertised by ospf 1 metric-type 1 subnets route-map GLOBAL

Routing Descriptor Blocks:

* 10.16.1.13

Route metric is 0, traffic share count is 1

Route tag 29091

PE#sh ip route 10.16.1.13

Routing entry for 10.16.1.0/23

Known via "connected", distance 0, metric 0 (connected, via interface)

Routing Descriptor Blocks:

* directly connected, via FastEthernet0/1/0.5

Route metric is 0, traffic share count is 1

And yes, I do get the %TFIB-7-SCANSABORTED:. It seems to occur every 1 hour. From the bug tool, it says there is no operational impact; but there is in this case. Do you think is the same issue?

[Harold Ritter · Accepted solution]

Can you try configuring the ip route as follow to see if it will solve this issue:

ip route 10.10.10.105 255.255.255.255 FastEthernet0/1/0.5 10.16.1.13

Hope this helps,

[olorunloba]

Hmm, I will try that, but because the problem would sometimes no occur for days, I will not be able to say immediately if it solves the problem.

But what do you think the problem is, and why do you think configuring the route as above might solve the issue.

[Harold Ritter]

This message by itself doesn't cause any operational issue but my be symptomatic of something else going wrong. Can you look at one of the neighboring routers and do a "sh ip cef 10.10.10.105".

BTW: what version of code do you use on the PE?

Thanks,

[olorunloba]

Thanks Harold.

Configuring the router did solve the issue. But I'm wondering what the issue actually is. Researching through the bug site, it seems to me that the mpls forwarding table seems to have problems with recursive routes lookup. Can that be the issue here?