This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
We're looking at replacing our existing HP Procurve switch with the NetGear M4300 range.
Below is our proposed design, but as I'm new to these switch I'd like some feedback on this architecture if possible to ensure this is the best solution.
As we have a requirements for 8 Edge switches and 2 Server switches (ESXi cluster), we exceed the 8 switch per stack limit.
So, the conclusion was to create 3 stacks. Stack 1 would consist of two M4300-12X12F (or 8X8F) switches as a collapsed core, combine with two M4300-24X for the servers (ESXi cluster)
Although we could put the remaining 8 Edge switches into a single stack (I think), we thought that splitting these into 2 stacks would improve the performance (reduced over subscription to core/spine).
The Edge Stack 2 and Stack 3 would be joined to Stack 1 with 2 fibres each to form a LAG uplink.
PNG of suggested architecture attached.
Questions
Is this a good solution for our requirements, if not, any suggestions appreciated?
For connecting the Edge stack to core switches, we will have one fibre going to the stack master and the second to the stack standby. Can these two fibres be in LAG?
We'll have multiple VLAN's (Data, Voice, SIP, Management). Can the Core M4300-12X12F switches act as as router for all these and route out to our Firewall cluster?
I've checked out your schema and while having larger stacks can simplify management, there is that odd case where a crashing stack tears down more than you'd want. I'm a bit sceptical if I'd want your core of 2x M4300-12X12F to be stacked with your server switches (M4300-24X) or if I'd go with stacks for maintenance flexibility.
The regular update guide for thes switches implies a full reboot of a stack (you can reboot staggered though but it still brings short disconnects), that's why I'd likely keep the server and core separated in 2 stacks. Same applies with the stack between 1st and 4th floor. I'd likely keep that one as a stack within a rack as well.
"[...] we will have one fibre going to the stack master and the second to the stack standby. Can these two fibres be in LAG?"
Yes, that's what I have. 2 switches at the core where LAGs are spread across both stack members to connect other switches redundantly.
I haven't yet run M4300 as a router, but they have some L3 capabilities and Inter-VLAN could be done on them as I understand it. I intend to get into that topic soon, but can't vouch how well they are that. the 12X12F has a smaller backplane compared to larger models.
I've checked out your schema and while having larger stacks can simplify management, there is that odd case where a crashing stack tears down more than you'd want. I'm a bit sceptical if I'd want your core of 2x M4300-12X12F to be stacked with your server switches (M4300-24X) or if I'd go with stacks for maintenance flexibility.
The regular update guide for thes switches implies a full reboot of a stack (you can reboot staggered though but it still brings short disconnects), that's why I'd likely keep the server and core separated in 2 stacks. Same applies with the stack between 1st and 4th floor. I'd likely keep that one as a stack within a rack as well.
"[...] we will have one fibre going to the stack master and the second to the stack standby. Can these two fibres be in LAG?"
Yes, that's what I have. 2 switches at the core where LAGs are spread across both stack members to connect other switches redundantly.
I haven't yet run M4300 as a router, but they have some L3 capabilities and Inter-VLAN could be done on them as I understand it. I intend to get into that topic soon, but can't vouch how well they are that. the 12X12F has a smaller backplane compared to larger models.
