> > 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... _______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
