[c-nsp] Strange behavior with 12008

[David Sinn]

Sounds awe-fully like CEF is broken on the providers network.  As 
someone said, a reload of their LC's in one of their routers could fix 
this, as could a full re-load of the router causing the problem.  The 
issue is which one...

The likely cause is that they have equal cost multi-path between your 
router and the next set of closest hops to the destination you are 
trying to get to.  Packets are hashed based on source/dest, hence the 
reason that odd works even doesn't (in my last job, it was fun to 
explain to customers why their machine didn't work and their office 
mates did).

So the problem could be that first hop 12008, most likely due to having 
a failed adjacency for one of equal path next-hop's specifically as the 
on the LC that your circuit lands on sees things.  Having them check 
the CEF table in the LC in question could prove valuable.  ("exec 
slot/all" is helpful here.)

Another spot they should look at is the two routers one hop up from the 
12008 in question that is in the multi-path on to your destination.  It 
could be one of the receive LC on those two routers, again with 
something funky in the CEF table (doesn't have a longest match prefix 
for the dest?  Doesn't have a valid adjacency either).

If ATM is involved then it could be the PVC/SVC between routers in the 
providers network having been dropped on one end (AKA the remote router 
things VC 2 is the real one back the the near router, but the near 
router thinks it's 1.  Been there.)

I've had all of the above happen on 12000's running 12.0(28)S, so it 
comes with the territory.

David


On Jan 19, 2006, at 11:42 AM, Erica wrote:

> Hi All
>
> Here's the situation.  Last week we suddenly lost connectivity to a 
> website
> on provider A's network.  When we started investigating the issue we
> discovered that when they were trying to talk to us, they were stopped 
> at
> our providers router, with what looked like a ACL blocking traffic 
> from that
> particular IP.  We checked through all the ACL's on the interface and 
> found
> nothing that should be blocking their IP's.  More investigation has 
> found
> that we can get to all odd IP addresses in their blocks, but none of 
> the
> even IP addresses.  For example, xxx.xxx.xxx.66 is not accesible to 
> us, but
> xxx.xxx.xxx.67 is.  The route path also is currently symmetrical.  The
> router in question that we are passing through is a 12008 running 12.0 
> (28)
> S with several GE-GBIC-SC-B= cards.
>
> My provider is completely stumped, as no one they know has ever seen 
> this
> type of behavior.  I thought I would help them out and see if anyone 
> here
> had come across this type of thing before.
>
> Many thanks for your input.
>
> Erica
> _______________________________________________
> 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/
>