[c-nsp] CEF wrong next hop

[Tim Devries]

Just as an FYI to the list, an IOS upgrade solved this problem.




-----Original Message-----
From: Tim Devries [mailto:tdevries at northrock.bm] 
Sent: Wednesday, September 22, 2004 9:06 PM
To: 'cisco-nsp at puck.nether.net'
Subject: Re: [c-nsp] CEF wrong next hop





>Rob, 

>I think that today the cef inconsistency checker just 
>detects for inconsistent information between 
>the RP and the LC's like on a 75xx or GSR. 
>It today doesn't do anything to correct the situation. 
>There is talk about having it do that at some point. 

>This sounds like a recursion problem. 

Apparently (according to CEF) it is not.

>The customer that hit the CSCee74177 bug never loaded 
>the debug image DE has put together to find root cause. 

The root cause, has nothing to do with static routes or proxy arp, other
then that I don't know, and in production messing about is just not a good
idea.  :)

>Can you post the 'sh ip route' and then a 'sh ip route' 
>for each next hop route then the 'sh ip cef'? 

Due to confidentiality, I would rather not.  However, I can tell you exactly
what the output is.  Show ip route x.x.x.x or 'show ip bgp x.x.x.x' shows
you that you can get to x.x.x.x via the BGP peer (correct).  Show ip CEF
x.x.x.x mask y.y.y.y shows you something completely incorrect and not even
in the routing table for that route (though the via address is a valid EBGP
peer one hop away - hence the loop).  This is where it gets weird. Show ip
cef | inc x.x.x.x shows you the /17 and /22 aggregate (the specific route is
obviously a /32 host) as being via the valid route (an iBGP route to an EBGP
peer).  So CEF doesn't even seem to know what is _the_ route with any
consistency, it just says it's available via the directly attached arp-able
peer router (wrong).  Proxy arp is turned off on that interface and so is
MLS.  There are no static routes that do anything to the cache when I remove
them and then clear the global CEF epoch.  Same problem.


>Can you easily reproduce it?

Reproduce it? Hell I'm trying to get rid of it.  Turning off CEF
accomplishes this, but that's not a solution.  Also, if I trace to the /17
network address (i.e. 69.0.128.0)instead of the /32 (69.0.224.231) my
routing works fine.  And to highlight this, the CEF table has no problem
with the 69.0.128.0/22, only the /32.  To top it off, in the routing table,
/17,/22, /etc and the CEF table all show the same BGP next hop, which is
different from what is the /32 next hop shown in CEF by 'show ip cef
x.x.x.x.  This /32 host address is understood as the /17 aggregate by the
router.  

Thanks for your help,

Tim


>Thanks, 
>Rodney 



On Wed, Sep 22, 2004 at 08:13:58PM +0000, rwcrowe at comcast.net wrote: 
> In the meantine while you identify if it is a bug or not, you can turn on
the cef consistency check to try to correct the information.

>
http://www.cisco.com/en/US/partner/tech/tk827/tk831/technologies_tech_note09
186a00800946f7.shtml 
> -- 
> Rob Crowe 
> rwcrowe at comcast.net 
> 
> 
> -------------- Original message -------------- 
> 
> > 
> > In 12.3(7)T1 we've noticed a problem running CEF whereby 
> > certain routes show the incorrect next hop (i.e. different from the
routing 
> > table) and result in routing loops. According to this document 
> >
(http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a008

> > 00cdf2e.shtml) this could occur if the routes were discovered via proxy
arp 
> > on the interface. This is not the situation in our case, though the 
> > _results_ are quite similar. 
> > 
> > This bug: 
> >
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee74177&cco_

> > product=IOS&fset=CEF/DCEF/FIB&swver=12.3&keyw=&target=7&train=T1 
> > 
> > is actually quite similar compared to what we are seeing, however unlike

> > that bug, when we kill CEF on our router the routing then returns to
normal 
> > (next hop learned via BGP), and all is well in the universe. I am
wondering 
> > if anyone else has seen the same or similar bug on the T train, as we
also 
> > have the same issue with another route on a router running version 
> > 12.2(17a). 
> > 
> > I'm assuming for the moment that it is a bug, simply because the
behaviour 
> > seems strange, and the bug is listed as not reproducible, and it is so
very 
> > close to our situation. As well, I do not think it is normal for CEF to 
> > have differing next hops from the entries in the routing table. 
> > 
> > Any advice would be appreciated, even if it is just to confirm that this
is 
> > a bug. 
> > 
> > Thanks, 
> > 
> > Tim Devries 
> > 
> > 
> > 
> > _______________________________________________ 
> > cisco-nsp mailing list cisco-nsp at puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/cisco-nsp 
> > archive at http://puck.nether.net/pipermail/cisco-nsp/ 
> _______________________________________________ 
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp 
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 

  
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/