we are trying to build a core setup with 4x M4300 24x24 switches.
We want to split the core into 2 switches per fire zone, but keep them working as one logical unit by using stacking in ring topology. As far as we understand, we can increase the stacking bandwidth by using more then one stacking connection per switch, so we decided to use 3x 10Gbit copper cables to connect to direct neighbor and 3x 10 Gbit SFP+ for connecting to room neighbor. When viewing stack diagnostics, web interface show only one path nstead of 3 paths. How can we ensure that all stack connections are used for highest bandwith or does using multiple connections only provides redundancy in case one link is down?
Thank you for your message and congratulations, NETGEAR M4300 series is world-class for high performance and nonstop forwarding (NSF) stacking topologies.
If System \ Stacking \ Advanced \ Stack-port Diagnostics show 1 path, it might indicate other "stack ports" are not working. Are we sure System \ Stacking \ Advanced \ Stack-port Configuration shows all your Stack Ports with "stack" in both Configured Stack Mode and Running Stack Mode for ALL units?
If not, the stack should be initialized again, one switch after the other?
I upgraded to firmware 12.0.2.20 and did a complete factory reset. After that I tried to build a stack between SW1 and SW2 by using 3x 10G copper connections. The packet-path summary shows, that only one stack connection is used.
For me this means that only 1x 10G port is in use, while port 2/0/45 + 2/0/47 are not.
I suspect an interpretation issue here, packet path is just a summary for the number of "hops" from one switch in the stack, to the other, when a packet needs to travel to reach its destination. The 2/0/43 physical interface is taken as the "main" one and shows up in the packet path summary. It shouldn't mean the other Stack Ports don't work, the other ports are considered as the same "path" from a switch-to-switch route standpoint. Your Stack Port configuration summary shows all 6 Stack Ports (per switch) running at 10G in Stack mode, so the stack algorithm should already parse traffic across all ports (load-balancing scheme).
I am exploring this "display issue" and will come back later on it. In the meantime, we need to control how your 3 x Copper and 3 x Fiber Stack Ports behave on each switch. Can you post the output of following two stacking commands (please consult M4300-24X24F support page, the CLI manual, Stack Port commands section starting page 38). Log in the M4300-24X24F stack using CLI, either local console or remote telnet/ssh, go (M4300-24X24F) >enable and enter the two commands:
(M4300-24X24F) #show stack-port
and
M4300-24X24F) #show stack-port counters all
If the stack is up and running, we should see the link status and the link speed for each of your Stack Ports with the first command, and the statistics (data rates, error rates, total errors, link flaps) for each of your Stack Ports with the second command. There should be no doubts left with it.
I confirm it is normal that the diagnostics show one port only, this port makes part of your Stack Ports and the packets can use any Stack Port, a little bit like in a LAG. I agree the unique port number can cause some confusion as you were expecting to see 3 ports from one switch to the other. We may want to enhance the Diagnostics table with the switch to switch route (number of hops) but without the port numbers, or with all of them. Thank you for reporting this cosmetic issue: please run the commands I provided and let us know if you have any doubt left.
please find the output (filtered), thanks for your help.
(SW-BHQ-CORE) #show stack-port
1 0/19 SFP+ AXM761 Stack Stack Link Up 10 1 0/21 SFP+ AXM761 Stack Stack Link Up 10 1 0/23 SFP+ AXM761 Stack Stack Link Up 10 1 0/43 Stack Stack Link Up 10 1 0/45 Stack Stack Link Up 10 1 0/47 Stack Stack Link Up 10
2 0/19 SFP+ AXM761 Stack Stack Link Up 10 2 0/21 SFP+ AXM761 Stack Stack Link Up 10 2 0/23 SFP+ AXM761 Stack Stack Link Up 10 2 0/43 Stack Stack Link Up 10 2 0/45 Stack Stack Link Up 10 2 0/47 Stack Stack Link Up 10
3 0/19 SFP+ AXM761 Stack Stack Link Up 10 3 0/21 SFP+ AXM761 Stack Stack Link Up 10 3 0/23 SFP+ AXM761 Stack Stack Link Up 10 3 0/43 Stack Stack Link Up 10 3 0/45 Stack Stack Link Up 10 3 0/47 Stack Stack Link Up 10
4 0/19 SFP+ AXM761 Stack Stack Link Up 10 4 0/21 SFP+ AXM761 Stack Stack Link Up 10 4 0/23 SFP+ AXM761 Stack Stack Link Up 10 4 0/43 Stack Stack Link Up 10 4 0/45 Stack Stack Link Up 10 4 0/47 Stack Stack Link Up 10
You're good to go, your stack is ready for load now. At the moment, there is no traffic passing through but all your Stack Ports are up and operational. Check the NSF (Non-Stop Forwarding) enablement in System \ Stacking \ NSF for immediate recovery and maximum availability of your core stack. Your downlinks should be distributed link aggregation (LAGs) across two switches, or more, for zero disruption in case of a switch failure, even the management unit.
If not done already, assign the highest Stack Priority to the unit you want to have as Stack Master (management unit) by default - and assign a lower priority to the secondary (backup) management unit you want to have in case of Stack Master failure. The other two switches should have even lower priorities. All that in System \ Stacking \ Advanced \ Stack Configuration.
To close on the "Diagnostics table", a diagnostic is run when you load the GUI web page or when you enter a CLI command. One packet is sent from one switch to the other and the "route" - the path - gets reported in the table. That's why we see only one egress port on every switch, there's only one packet and the stack algorythm just parsed that traffic through one port.
Keep us on the loop with your core installation using M4300 10G models, this will be of high interest for the Community!
