Core Switch or No

SOLVED
GFrazier
Getting noticed

Core Switch or No

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??

1 ACCEPTED SOLUTION
KarstenI
Kind of a big deal

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".

View solution in original post

12 REPLIES 12
KarstenI
Kind of a big deal

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.

AjitKumar
Head in the Cloud

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.

Regards,
Ajit
AjitsNW@gmail.com
www.ajit.network
GFrazier
Getting noticed

@KarstenI @AjitKumar 

 

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?

KarstenI
Kind of a big deal

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?  

KarstenI
Kind of a big deal

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".

Tore
Getting noticed

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)

UCcert
Kind of a big deal

Design sounds good in theory but as @Tore has highlighted STP may be an issue with dual links.

Darren O'Connor | uccert.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
KarstenI
Kind of a big deal

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.

GFrazier
Getting noticed

@KarstenI 

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.

 

 

@Tore @KarstenI 

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.

KarstenI
Kind of a big deal

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.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels