[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