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 <[email protected]> To: [email protected] 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
