[e-nsp] x650 CPU Load
Marcin Kuczera
marcin at leon.pl
Tue Mar 5 15:11:52 EST 2013
On 2013-03-05 14:09, Robert Kerr wrote:
> On 05/03/13 12:03, Marcin Kuczera wrote:
>
>> So - pure L2 VLAN with broadcast traffic that 100% goes towards CPU -
>> isn't is strage ?
>> No L3 interface on that vlan, but switch behaves like it is in promisc
>> mode on that and any other vlan !
>> We tried to disable learning on that vlan but it doesn't help, only
>> taking down this broadcast oriented traffic help.
>> (and than Cacti works fine, so snmpwalk has some low timeout on snmpwalk..
>> Is there any command to turn on/off promisc mode for CPU ?
>> For me it rather looks like a bug ?
> In addition to disabling learning, have you made sure IGMP snooping and
> bootprelay are switched off for the VLAN?
I tried that also, no positive result.
I understand that there are cases when bcasts need to be forwarded to
CPU, i.e. when
there is IP interface on particular VLAN.
There is also traffic like IGMP that needs to go to CPU, but all of
these should be recognized by switching chipset
and then forwarded.
If VLAN has no L3 interface than broadcast shouldn't go to CPU.
>
> You might also try an ACL with the 'deny-cpu' action? Totally untested
> of course... it might just blackhole the traffic entirely.
I can do test on that VLAN so if you have some example (I have never
done that before) I'll appreciate.
> Other than that I don't know - I have heard of people wrapping mirrored
> traffic in GRE tunnels to avoid such issues (cisco ERSPAN does this).
> Perhaps this may be an option depending on the source and destination.
That would have to be L3 forwarding, will work however it just workaround..
> We tend to use passive taps with direct cabling to the monitoring box to
> avoid this sort of thing.
Passive tap ? Could you expand this ?
Regards,
Marcin
More information about the extreme-nsp
mailing list