Header Only - DO NOT REMOVE - Extreme Networks

N7 (7G4280-19) Switch Packet Processing more than 60%

I have a network with two N7 (2 x 7G4280-19 blades) in the core and several stacks with secureStacks B and C in the access. Almost all access stacks are connected to the two core boxes (N7). The two core N7 are interconnected with two 10G links in lag.
Multiple servers and other devices are connected to a C3 switch. This switch (C3) also has a uplink for each Core N7. A second C3 also has a uplink for each core N7. In this second C3 are connected the redundant links of the servers.
In a random way I'm having all the networks "down" because the route bridge gets with the "switch Packet Processing more than 60%.

Best Regards

5 replies

Userlevel 7
Switch packet processing means software forwarding. The real question is, why does that happen? A possible cause is unknown unicast flooding because of an NLB-like server load balancing machanism. See the GTAC Knowledge article EOS: How to configure multicast mac to stop flooding of NLB server traffic via slow path.

But of course that is just one possible reason, there are many others.
Hi, thank you for your reply.
Tell me, there is any way (Any EOS command) to know witch packets are being forwarding by software and by hardware?
Userlevel 7
There is no such command. You can check for unknown unicast flooding by using a network sniffer (e.g. Wireshark) connected to a normal access port. Flooded packets will be seen on any port of the VLAN. Any frame received that was not sent to the MAC of the sniffer PC was flooded.
Userlevel 4
There are a couple of quick and easy tests that you can do to find out what is happening:

1. Configure "movedaddrtrap" globally and per port to see if there are any mac moves. If there are unexpected mac moves then you will most likely have a loop on the network. The syslogs will tell you where the macs are moving to/from.

2. Take an open port and configure to egress all vlans on that port. Then put a wireshark analyser on the port and you will quickly see any broadcast , unscoped multicast or any flooded unicast traffic. This should give you an good idea of what the issue is as well.

Here is an article that deals with recommended L2 configurations to make the L2 environment resilient. Especially consider Loop Protect as this can isolate many issues that can fool spanning tree such as unidirectional forwarding on a link or looping behind a port.


Also the following article may help tracking this down :


If you continue to have issues and need more in depth support you may want to consider opening a case with us.

Hope this helps
Userlevel 2
Those are all good replies, but the first thing I would check is your spanning tree configuration. Make sure you have a root-bridge designated, and that it has a priority lower than the rest of the switches. You may find that if you follow the above suggestions that you'll find this out anyway.