[c-nsp] TCAM troubles on 3750 stack

[Saku Ytti]

On (2006-05-01 12:38 +0200), Alexander Gall wrote:

> It got worse.  I had to perform an emergency reload after the router
> had started dropping all traffic routed via the default route (no time
> to investigate this new effect, though).  The symptom with the wrong
> mac address is now gone, but the "covering fib" effect is still there.
> This box seems truly broken.  Comments inline.

Ok, if you're opening TAC case for this, I'd really like to hear how 
it goes. Just in case I'll ran into same issue some day.
 
> Yes, all more specific routes with the same adjancency have the same
> RWI value and they work.  Clearly, the adjancency itself is fine.

Ok.

> > Covering FIB ADJ Failed, to me sounds like adjacency to the next-hop
> > is not ok, but I may be mistaken.
> 
> But the same adjancency is just fine for all other routes pointing to
> the same p2p link.  It doesn't make sense to me.

That is odd, perhaps some kind of 'pointer' to the RWI, in that spesific
prefix (0.0.0.0/0) is broken.

> Interesting.  We have IPv6 enabled in all subnets in question.

I even have ECMP enabled for IPv6 and haven't experienced problems :/.
(static routing for IPv6 only).

> I'd take the fact that it's precisely these special mac addresses that
> appear in forwarded packets as an indication that this is in fact
> relevant, i.e. it could be a bug in the code that programs the
> hardware for IPv6.

Yes, I'd tend to agree that this problem would only manifest in IPv6
enabled boxes, but I don't think that those MAC addresses itself
are sign that the bug has been triggered. I believe those MAC addresses
should be in 'tcam table mac-adress'  (but if you're seeing them in wire
in forwarded frames, that really sounds suspicious. I'd assume this
shouldn't be happening)

-- 
  ++ytti