[f-nsp] CAM and ip net-aggregate or ip supernet aggregate - does it help to free the cam up ? WAS:AW: cam strangeness

[Gerald Krause]

On Tuesday 07 March 2006 07:55, Kristian Larsson wrote:
>> But this makes the situation not clearer to me. I simply would expect 
>> the NI forwarding all incomming packets towards the 4 next hops 
>> through  
>> 4 /18 CAM entries regardless if the host is reachable in the end or 
>> not.
> checkout ip hw-drop-def-in-hardware or something 
> like that.. 

Ok, I found "ip hw-drop-on-def-route" - but even this command will 
prevent the NI from creating /32 CAM 'drop' entries and force packet 
drops to be processed in software: why the system has to drop packets 
for this /18 at all when the network is not directly connected? The 
*next* hops (RTR1/2) should take care of this, not the NI:

                   +----SW1----+------+
                   |           |      |
     UPLINK----NI400          RTR1   RTR2
                   |           |      |
                   +----SW2----+------+


     NI400:      Static: 0/0 -> null0,       OSPF: 212.79/18 -> RTR1/2
     RTR1/2:     Static: 212.79/18 -> null0, OSPF: 0/0 -> NI


In my opinion 'unreachable hosts & dropping packets' could/should not be 
the source of the problem that I'am face (seeing a lot of 212.79.x.x/32 
CAM entries on the NI). I really don't get the point at the moment. 


-- 
Gerald