NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Netgear M4300 - Spine and Leaf
All reference documentation I've found, nicely summarised by a Netgear support agent in this post (https://community.netgear.com/t5/Managed-Switches/M4300-spine-and-leaf-with-more-than-8-switches/td-p/1168178) shows the spine switches being interconnected.
My understanding of the leaf-spine (Spine & Leaf) CLOS network design is to ensure each point on the spine and leaf switches has multiple paths to another in the same layer. Spine switches should connect to each leaf, never another spine. Each leaf should also never connect to another leaf, only to the spine switches.
I also can not validate how intelligent Stacking is as we can't retrieve bandwidth counters via SNMP when changing ports to stack mode. Are there alternative SNMP OIDs available when ports are in stack mode?
We are in the process of implementing a stack of 3 x M4300-8F8X (spine) with 4 x M4300-96X (leaf) switches. We intend to setup distributed LAGs from the X96 leaf switches to servers and enabling local preference mode. This results in the 96X forwarding received traffic via the destination's LAG port on the same switch traffic arrived on and stops traffic unnecessarily loading stack uplinks. This works as expected, although Netgear documentation is extremely poor (something along the lines of "enabling local preference mode enables local preference").
If each 96X has 6 x 10G stack members (2 to each 24X24F) there should be 6 equal distance hops between each 96X leaf switch. If server A sends data to server B and both only have 2 x uplinks running LACP (each uplink in a unique 96X) I assume a single steam of data would have 6 possible choices .
How does one confirm architecture and plan for upgrades and/or eradicate traffic polarisation without metrics without something as simple as SNMP?
My understanding of the leaf-spine (Spine & Leaf) CLOS network design is to ensure each point on the spine and leaf switches has multiple paths to another in the same layer. Spine switches should connect to each leaf, never another spine. Each leaf should also never connect to another leaf, only to the spine switches.
I also can not validate how intelligent Stacking is as we can't retrieve bandwidth counters via SNMP when changing ports to stack mode. Are there alternative SNMP OIDs available when ports are in stack mode?
We are in the process of implementing a stack of 3 x M4300-8F8X (spine) with 4 x M4300-96X (leaf) switches. We intend to setup distributed LAGs from the X96 leaf switches to servers and enabling local preference mode. This results in the 96X forwarding received traffic via the destination's LAG port on the same switch traffic arrived on and stops traffic unnecessarily loading stack uplinks. This works as expected, although Netgear documentation is extremely poor (something along the lines of "enabling local preference mode enables local preference").
If each 96X has 6 x 10G stack members (2 to each 24X24F) there should be 6 equal distance hops between each 96X leaf switch. If server A sends data to server B and both only have 2 x uplinks running LACP (each uplink in a unique 96X) I assume a single steam of data would have 6 possible choices .
How does one confirm architecture and plan for upgrades and/or eradicate traffic polarisation without metrics without something as simple as SNMP?
2 Replies
Replies have been turned off for this discussion
Hi bbs2web,
My understanding of the leaf-spine (Spine & Leaf) CLOS network design is to ensure each point on the spine and leaf switches has multiple paths to another in the same layer. Spine switches should connect to each leaf, never another spine. Each leaf should also never connect to another leaf, only to the spine switches.
I also can not validate how intelligent Stacking is as we can't retrieve bandwidth counters via SNMP when changing ports to stack mode. Are there alternative SNMP OIDs available when ports are in stack mode?I inquired your concern to the higher tier of NETGEAR Support and just got a feedback. As per the higher tier of NETGEAR Support, while there is no SNMP object for stacking link, we have 'show stack-port counter' outputs that shows the traffic rate.
How does one confirm architecture and plan for upgrades and/or eradicate traffic polarisation without metrics without something as simple as SNMP?
As per the higher tier of NETGEAR Support, the NMS300 is recommended for ethernet port traffic but we have show stack-port counter to support the stack mode information. SNMP for stacking is more of a feature request. You may post your concern as feature request on the Idea Exchange Board for Business here.
For more information about NMS300, kindly access the NMS300 product page here.
Regards,
DaneA
NETGEAR Community Team
I just want to follow-up on this. Let us know if you have further questions.
Otherwise, if ever your concern has been addressed or resolved, I encourage you to mark the appropriate reply as the “Accepted Solution” so others can be confident in benefiting from the solution. The NETGEAR Community looks forward to hearing from you and being a helpful resource in the future!
Regards,DaneA
NETGEAR Community Team
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
