[c-nsp] CEF wrong next hop

Fri Sep 24 09:16:32 EDT 2004

Tim,

About a year ago I've seen quite the same problem.
12K --12.0.25S (I think)
The problem was inconsistent routing info on LC where interface was
located and RP.
The problem never appeared again after reload.

Hope this helps
Jeff

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tim Devries
Sent: Thursday, September 23, 2004 2:06 AM
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_no
te09
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_note09186
a008

> > 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/

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.