[f-nsp] [FastIron] RIP routes does not get into CAM

[Heath Jones]

> >  I have a FastIron 800, learning routes from a RIP neighbor and having
> > some directly attached networks.
> >  I suspect that the network is facing an IP scan for all my prefixes'
> > IPs and that is seeming to get the Fastiron a little distirbed :
> >  - Directly attached networks have a PING RTT around 1ms which is normal.
> >  - Networks learned from RIP have a PING RTT around 30ms which is not
> > normal. The RIP neighbor is directly attached to the FastIron and the
> > link is tested and good (direct PING between neighbors is <1ms)

Hi Youssef,

I'm not familar with this architecture specifically to that level, but
I'll throw in what I do know generically.
Apologies in advance if you already know this..

CAM is used for MAC address matching, TCAM is used for IP prefix matching.
The distinction is important, given the scenario you think is occurring.

If you have IP packets coming in from a single path, the MAC address
should not change.
Also, I would imagine this device already knows the MAC addresses for
all of your local neighboring devices. Therefore there should be no
issue with the CAM.

The TCAM is based on routing information, it doesn't learn in the same
way. It is built from all of your RIP routes for instance and will not
dynamically change depending on source / destination traffic.

To understand the problem a bit better, what is the topology?
You have this device (A) connected to another device (B), that is
advertising RIP prefixes to (A).
Pinging A-B is <1ms, pinging anything beyond B from A results in 30ms?
How utilised is the link from B to beyond? Is it a single ethernet
with dot1q going out to an edge?

Running through my mind is perhaps CPU is being chewed on that/those
edge devices, with ICMP replies, or ICMP unreachables etc...