[c-nsp] CEF wrong next hop

Thu Sep 23 07:59:14 EDT 2004

An upgrade to what code?

In the ddts discussion with engineering there
was mention that someone upgraded to
12.3(7)T2 and the problem was not seen but
that wasn't confirmed.

Rodney

On Thu, Sep 23, 2004 at 08:25:46AM -0300, Tim Devries wrote:
> 
> 
> 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/
> _______________________________________________
> 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/