[c-nsp] Bad routes in MPLS

[Tony]

Thanks for the info, I hadn't looked at those particular details. We had an OSPF event overnight which caused a couple of routes to get messed up so I had a look at the mls cef details of them. The route in question was 10.1.69.36/30 and I have a continual ping to the host 10.1.69.38 in this subnet. I've prefixed my comments with --- so that it will hopefully make them easier to see in the middle of the output. This is just a quick follow up, we've got an upgrade to SRE9a scheduled for next Wednesday night so hopefully that will resolve the issue for good (or at least for another 2 years of uptime).

Thanks,
Tony.



--- This is what it looked like when it was NOT working (it all looks ok to me):


7609#show mls cef  vrf xyz lookup 10.1.69.36 detail

M(4962   ): E | 1 FFF  0 0 0 0   255.255.255.252
V(4962   ): 8 | 1 264  0 0 0 0   10.1.69.36         (A:475208 ,P:1,D:0,m:0 ,B:0 )

7609#sho mls cef adjacency entr 475208

Index: 475208  smac: 0013.1abf.2280, dmac: 0012.7fee.ed40
               mtu: 1548, vlan: 1099, dindex: 0x0, l3rw_vld: 1
               packets: 19, bytes: 2238


--- So then I caused the route to get refreshed by putting a null0 route in, then removing it.


7609(config)#ip route vrf xyz 10.1.69.36 255.255.255.252 null0
7609(config)#no ip route vrf xyz 10.1.69.36 255.255.255.252 null0


--- At this point my ping started responding, but CEF details look strange. MTU is set to 1036 and packets/bytes counters are zero !?


7609#sho mls cef vrf xyz lookup 10.1.69.36 detail

M(4962   ): E | 1 FFF  0 0 0 0   255.255.255.252
V(4962   ): 8 | 1 264  0 0 0 0   10.1.69.36         (A:311374 ,P:1,D:0,m:0 ,B:0 )

7609#sho mls cef adjacency entr 311374

Index: 311374  smac: 0013.1abf.2280, dmac: 0012.7fee.ed40
               mtu: 1036, vlan: 1099, dindex: 0x0, l3rw_vld: 1
               packets: 0, bytes: 0


--- Decide to go back and do the route thing again:


7609(config)#ip route vrf xyz 10.1.69.36 255.255.255.252 null0
7609(config)#no ip route vrf xyz 10.1.69.36 255.255.255.252 null0



7609#sho mls cef vrf xyz lookup 10.1.69.36 detail

M(4962   ): E | 1 FFF  0 0 0 0   255.255.255.252
V(4962   ): 8 | 1 264  0 0 0 0   10.1.69.36         (A:311374 ,P:1,D:0,m:0 ,B:0 )

7609#sho mls cef adjacency entr 311374

Index: 311374  smac: 0013.1abf.2280, dmac: 0012.7fee.ed40
               mtu: 1548, vlan: 1099, dindex: 0x0, l3rw_vld: 1
               packets: 57, bytes: 6982


--- The pings are still working and now the CEF entry "looks" correct - MTU is OK and counters are incrementing. The other slightly strange thing is that when I did it the first time the adjacency entry number changed, but the 2nd time it didn't (stayed at 311374).






________________________________
 From: Saku Ytti <saku at ytti.fi>
To: cisco-nsp at puck.nether.net 
Sent: Thursday, 21 November 2013 12:27 AM
Subject: Re: [c-nsp] Bad routes in MPLS
 

On (2013-11-19 15:45 -0800), Tony wrote:

> Hi all,
> 
> We've been having an issue recently where we have routes on PE routers that look to be ok, but are not forwarding any traffic. Usually this can be resolved by doing "clear ip route vrf <vrf_name> <ip_prefix>" which causes the PE to re-learn the route and everything works again.

Could be number of reasons. You might want to confirm if 'sh mls cef vrf X
lookup Y' and 'sh mls cef adjacency X' are ok next time it happens.  If they
are not ok, you can in interim use script to pull out CEF and MLS CEF
periodically, compare and clear mismatches, I've done that few times.

But if MLS CEF is ok, unfortunately it still does not prove it'll work. If MLS
CEF looks ok too, you really would need to check from ELAM what the platform
is doing with the frames which are not passed, it usually gives lot of
information what is wrong.

But like Pete said upgrade to latest SRE might be good call, it'll be
supported at least until like mid 2015.

-- 
  ++ytti