[e-nsp] x650 CPU Load

Marcin Kuczera marcin at leon.pl
Tue Mar 5 07:03:46 EST 2013


On 2013-03-05 11:21, Robert Kerr wrote:
> On 04/03/13 22:26, Marcin Kuczera wrote:
>> On 2013-03-04 10:30, Robert Kerr wrote:
>>> On 01/03/13 15:36, Marcin Kuczera wrote:
>>>> On 2013-03-01 11:32, Shankar wrote:
>>>>> Traffic is getting CPU forwarded. You might need to check why ??
>>>> Is there any set of commands that could guide me to get the reason ?
>>> If you do show l2stats you can see the 'number of packets to CPU' per
>>> VLAN - which might help you tell if it's a particular VLAN causing the
>>> problem. Typically the things going to the CPU are stuff that will be
>>> flooded, so high levels of broadcast or flooded multicast on a
>>> particular VLAN might be responsible.
>> Well,
>> I have a lot of vlans with stats like that:
>> Slot-1 SummitStack-GZE.3 # show l2stats Default
>> Bridge interface on VLAN Default:
>> Total number of packets to CPU = 1822970.
>> Total number of packets learned = 941959.
>> Total number of IGMP control packets snooped = 28545.
>> Total number of IGMP data packets switched = 0.
>> however, still - I don't think that these are reasonable packets to be
>> sent to CPU,
>> this looks like CPU gets something that it shouldn't, some kind of a bug.
> It's certainly normal to have some packets to CPU... but it can be hard
> to tell how much as it depends on how much other traffic is on that
> VLAN. You can clear l2stats first to zero the counter then see what the
> counters look like after a minute or two.
>
> One thing I know causes a lot of packets to CPU is microsoft network
> load balancing set to active-active. I have never got a straight answer
> from extreme as to whether this is a bug or not, they just kept telling
> me to set it to active-passive.

Ok, I know the vlan that causes high load.

This is a vlan without any IP and a lot of traffic that is 100% broadcasts.
Reason for this traffic is a mirror from a specyfic traffic on a router 
forwarded to a particular VLAN.
Because of DST is unknown, it is ff:ff:ff:ff:ff:ff - then it is 
intercepted on interface working in promisc mode
and some analysis is performed.

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 ?

Regards,
Marcin



More information about the extreme-nsp mailing list