I been thinking on an adequate design for a new client... This client will need a very "modern" setup - no servers on premises (VPN to Azure), and heavily reliant on internet connectivity... This is more like a members club with lots of members that will be utilizing Wi-Fi only for internet connectivity. VPN usage to Azure is mainly for Credit Card transactions between the client's Point-of-Sales system and merchant application on Azure, as well as some live streaming between the client location and web server on Azure.
I know that in most cases there will be core or collapsed core design that the access level switches are connected to, however, this particular LAN has almost no need for it - almost all traffic is directed to the Web. The Firewall will be handling DHCP and VLAN traffic.
I have 3 floors, each floor has an access switch stack (of about 2 switches). I was thinking of instead of using a core switch of any kind (which is also limited by budget), just fiber uplink each switch stack directly to the firewall...
any thoughts on that??
Solved! Go to solution.
A modern switch typically doesn't really care if it forwards Ethernet-frames or IP datagrams. Adding in the Switch as a core will add a couple of nano-seconds which is irrelevant for Internet-access.
And with that many SFP-Ports on the firewall, I still would directly connect the access-switches and see the firewall as "the core".
I would probably configure it that way. Depending on the amount of users perhaps one VLAN per floor for some separation and also extra VLANs for Voice, printers etc.
The idea is good as long as user load is less. Also I may use saved money to achieve redundancy at the Firewall Level if already not planned.
Because there is not enough funds for both an actual aggregation switch for the core, as well as firewall redundancy, I chose firewall redundancy due to this environment's heavy dependency on internet connectivity.
The amount of users are actually going to be pretty dense - hundreds of users per day. I was thinking of this design for that reason - with the amount of internet traffic, this design might improve the throughput by eliminating a device.
I usually see networks where there is a core switch, but is functioning dually as a core and access switch that also has end devices connected to it... I would think this has an affect on the downstream traffic because its busy switching between both end points and access switches. So, given the nature of this particular network, I would actually be doing the same if I go with the "traditional" design.
That said, wouldn't eliminating the core switch and uplinking the access switch stacks directly to the firewall provide a more "sufficient" connection?
There will be no practical difference in throughput if you have an additional Core-Switch or not. But it really seems that it is not needed here for functionality. The only problem could be connectivity of the firewall to the switches. With three floors you need a lot of SFP-ports on the firewall to directly connect the access-switches. Or do you have copper from the firewall placement to the access-switches?
Firewall-redundancy is definitely more important, if you use Meraki MX, you only need an additional appliance and no additional license. That comes pretty cheap.
I will be using a MX250 - it has 8 SFP+ (10Gb) ports, which should be enough to connect the other 2 switch stacks with redundant Fiber Uplinks. The first switch stack will only use 2 of those SFP+ ports per firewall.
You don't think there would be any difference by using the MDF access switch stack as a Core?
A modern switch typically doesn't really care if it forwards Ethernet-frames or IP datagrams. Adding in the Switch as a core will add a couple of nano-seconds which is irrelevant for Internet-access.
And with that many SFP-Ports on the firewall, I still would directly connect the access-switches and see the firewall as "the core".
Before you go ahead using MX as core device be careful and read this article:
https://documentation.meraki.com/MX/Networks_and_Routing/MX_Layer_2_Functionality
MX does not run Spanning Tree or support aggregation (LACP)
Design sounds good in theory but as @Tore has highlighted STP may be an issue with dual links.
But nothing that could not be managed with proper switch configuration. And a “Core” would also be connected redundantly and we have the same situation.
What the link mentioned is to configure L3 switching on the switches, but I don't think I need to complicate it further if adding a core switch will not affect speed or throughput in anyway.
I reviewed the link:
What I got from the it is that even with the switches connected to the firewall independent of each other like a star topology - not mesh - and there are no loops possible, because the switches are on the same broadcast domain, it will still pass BDPUs over the MX uplinks and carry out the STP process between the switches; thus, only one switch can still be the ROOT bridge…
In order to determine a root bridge between 3 or more switches, it seems the switches need to be directly uplinked to each other and is able to process BPDUs, correct?? So, as the Meraki link is states, more than 2 switches cannot complete the STP process if they are uplinked to a MX independent of each other; although this will not cause a loop, it can lead to the ports to going into a unknown state due to the inability to determine a root?
This could be remedied by disabling STP, but, this cannot be done if redundant links are to be utilized.
In conclusion, there is no work-around and going with the “traditional” setup with a core switch is best in this situation.
At least the "Core"-approach will work straight forward as it is a completely common way todo it. The way with multiple access-layers to the MX is possible also with 3+ switches, but you have to take care not to mess up the different native VLANs to the different access-layers to "repair" the STP-setup.
I got word from the low voltage team that they are only setting up 2 IDFs (although there are 3 floors) - Basement and 2nd Floor. This changes my design... I am going to Stack the MS225-48LP switches (1 stack per floor)... I am also installing some MS350-24X for the mGig ports for MR56 WAP uplinks - these will be a separate stack per floor...
Since 2 separate switches can be directly connected to the MX with no STP issues, maybe I will go with connecting a core MS350-24X and a core MS225-48LP to the MX... I will test that out first... but overall, I may just go the easier route.
Thank you all for your input - you all really helped me out.