[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]

On Tue, 7 Mar 2006, Gerald Krause wrote:

> 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. 

ditto.

from the cam:
  1     19    12.211.79.164/32  000c.db59.0e00    81     100   ether 1/1

from the routing table:
        12.128.0.0/9       <x.x.x.x>57   v10               B   

from bgp:
*>i 12.128.0.0/9       <y.y.y.y>251   5           100    0      xxx xxx i


the route for y.y.y.y:
        <y.y.y.y>/32   <x.x.x.x>57   v10        5      O   
        <y.y.y.y>/32  *<z.z.z.z>120  v11        5      O   
Gateway: <z.z.z.z>120  
CIDX0: 22846[hw 9921 | 0x026c1 Right]

from the cam for y.y.y.y:
  1  22846    <y.y.y.y>/32  000c.db59.0e00   102     101   ether 1/2


In summary I have a /9 in teh routing table, it is set to route to a particular
next hop in BGP, this next hop has two OSPF paths. I dont see the /9 in the cam
but i do see /32s.

Perhaps this is caused by a load balancing phenemenon - it sees conflicting host 
routes in the cam and therefore does not add the aggregate

I'm investigating some more....

Steve