[f-nsp] CAM and ip net-aggregate or ip supernet aggregate - does it help to free the cam up ? WAS:AW: cam strangeness
Stephen J. Wilcox
steve at telecomplete.co.uk
Mon Mar 6 11:08:30 EST 2006
Hi Gunther,
the problem wasnt just the cam filling, once it was full instead of ageing out
an entry and installing a new entry for the requested route it is matching
anything else in the CAM.
eg
i sent a packet to 10.10.10.10
i have a route 10.10.10.0/24 to go out of port 1 - this is not in the CAM
i have a route 10.10.0.0/16 to go out of port 2 - this is in the CAM
we expect to incur a cache miss and install the /24, instead the cache matches
the /16 and the packet is sent the wrong way
in Kristian's case, he was seeing matches to 0.0.0.0/0 to null0 matching where
no CAM entry was found and the packet was dropped when there was a valid route
in the routing table
Steve
On Mon, 6 Mar 2006, Gunther Stammwitz wrote:
> Hello Kristian,
>
> That sounds horrible! Didn't you open a case with TAC/technical-support?
> Which management module exactly are you using? Is it ironcore or jetcore and
> what are your settings regarding the cam-partition, the supernet-aggregation
> and the ip net-aggregate?
>
>
> I have seen some strange behaviour too on our jetcore-module:
> When enabling the ip supernet aggregate-command which the cpuload jumped
> from 10 to 20 or even 25% so we disabled it again. The interestint thing was
> that the cam was freed up to ~50% or something like that.
>
> The next try was to enable ip net-aggregate and the load jumped from 10% to
> 99 which was rather bad and caused a lot of packet loss and so on
> (Trouble!). The solutions was to use ip net-aggregate X where X is a number
> of let's say 10 or 30 so that the aggregation-process won't try to compres
> the cam every one second which is the default behaviour but rather every 10
> or maybe even 30 seconds.
> This reduced the load to 5% and we can't even notice the aggregation-process
> that should run from time to time. No packetloss no nothing
>
> Our current cam-usage is looking like this:
> #show cam ip 1/1 stat
> CAM IP statistics: free entries total entries
> level1: 8670 28672
> level2: 1147 2048
> level3: 1960 2047
> I'm not really sure that it was before but I think to remember that without
> any aggregation at all there were about 20000 entries (layer1) free but I'm
> not sure. We're using bgp with 3 full views.
>
> On another router that I'm managing there's a ironcore mgmt-card, 2 full
> bgp-views and some peers and most of the traffic is following the default
> route and the usage is looking like this:
> show cam ip 1/1 stat
> CAM IP statistics: free entries total entries
> level1: 4072 8192
> level2: 1726 2048
> level3: 2020 2047
>
>
> What do the others say: does aggregation help and does the cam usually fill
> up in an isp enviorment?
> What about situation with gameserver-providers or voip which causes a lot of
> connections?
>
> Gunther
>
>
More information about the foundry-nsp
mailing list