Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About GFrazier
Community Record
82
Posts
13
Kudos
2
Solutions
Badges
Oct 28 2021
8:37 AM
I have an MX250 with dual 250WAC redundant power supplies. In the "Security & SD-WAN / Power" setting both slots (1 and 2) are showing as "powering". Does both power supplies draw at once? If so, do they draw at half capacity equaling 250WAC OR does one provide power as the primary until a failover event? If so, how do I determine which one is drawing as a primary?
... View more
Aug 17 2021
7:22 AM
@Inderdeep Thanks for the info @BlakeRichardson and @GiacomoS Thanks you for clarifying the DHCP Blocking and sending the documents - I will run the packet capture and make the changes.
... View more
Aug 12 2021
8:35 AM
@Inderdeep Thanks... thing with this is there actually is a device that is connected via Wi-Fi that is detected as a DHCP server.
... View more
Aug 12 2021
8:10 AM
Received an alert that a new DHCP server was detected. It is a device that connected to the network via Wi-Fi... There are 3 SSIDs - the device is connected via one SSID that is on a specific VLAN, but the "new DHCP server" was given a different VLAN ID which is a duplicate to an existing VLAN. There is a policy setting in the DHCP Server Configurations that allows or denies DHCP servers... Would setting this to "Deny" affect the DHCP servers configured on the Firewall or does this only apply to end-devices that connect to the LAN? Or should I just block that particular DHCP Server??
... View more
Aug 3 2021
2:10 PM
I see where you can import a CSV file in the Security & SD-WAN/DHCP settings to append or replace the DHCP configurations. Is there a way to EXPORT the DHCP configurations to a CSV file?
... View more
Labels:
- Labels:
-
Other
May 4 2021
8:51 PM
@PhilipDAth Thanks... I will take a look.
... View more
May 4 2021
9:40 AM
@PhilipDAth I didn't mention: They do actually have another connection. I have the spare MX connected to it, so when it fails over (and it has done so due to primary connection being lost), I will lose the Azure VPN connection. I have the redundancy for Circuits - I was just aiming to have the automated failover in case one of the MX's fail for some reason... However, now that I think of it, I have not had our Azure guy create a tunnel for the spare circuit. We didn't know if the client was going to keep that circuit because it was for temporary use while the primary circuit was being prepared. I will confirm with the client if they will keep that circuit and have the Azure team create a separate VPN tunnel for that... Treat it as a hub (Azure) and spoke as we already have done since we have 2 locations and they both point to the same Azure IP. I will look into placing a switch between the MX's and Comcast.
... View more
May 3 2021
12:55 PM
DELIMA! I currently have two MX250s, connected HA. We have a Gig Comcast fiber connection with 6 IPs, however, Comcast failed to mention that they will charge us double if they enable another port on their device for us to use as a secondary connection. The idea was to connect the Secondary MX WAN1 to a secondary port on the Comcast modem for the failover connection, buuut, since we do not want to be charged for 2 separate circuits (although it’s just one circuit), we cannot use those additional IPs as intended. FYI: We have the Primary MX connected via VPN to the Azure cloud. I know we can use a switch between the Firewall and Comcast modem; however, I really do not want to install a single point of failure to our WAN connection - which negates the entire reason for the failover links (and redundant firewalls) to begin with. To install one switch, we would need yet another switch, then that switch would need a secondary connection for redundancy, which takes us back to the drawing board. So, if the Primary MX goes down, we will have to physically move the connection from the Primary MX WAN1 port to the Secondary MX WAN1 Port... This seems far easier than connecting more devices. I really would like for this to all be automated, but just looks like it may be better to do this manually. HOWEVER, I do not know if configuring WAN1 on the Secondary MX with the exact same IP as the Primary MX will be an issue. Keep in mind that we have a VPN connection to the Azure Cloud which sees the one IP from the Primary MX so this mirror configuration would be beneficial... So, in theory: If the Primary MX goes down, one of our men on site can move the WAN cable from the Primary MX WAN1 port to the Secondary MX WAN1 port that has a mirror configuration, and the connection along with the VPN connection should come back up... Thoughts????
... View more
Mar 24 2021
10:07 AM
@Inderdeep Thanks for the info... but I think the actual switch itself would be of more help being that I was just reminded that PoE will not transmit over the Copper Modules - the Switch SFP ports don't support PoE or "PoF" for that matter.
... View more
Mar 24 2021
9:57 AM
1 Kudo
@cmr Ya know? I completely freaking forgot about that... Either way, I would need to get a switch anyways to provide PoE.
... View more
Mar 24 2021
9:48 AM
@cmr I overlooked the MS355Xs... I am definitely going to use them for future deployments. Thanks for the info. I was hoping Meraki has copper modules that can transmit more than 1Gbps.
... View more
Mar 24 2021
9:44 AM
@Inderdeep Are there any Coper Modules for Meraki switches that can handle data transition of more than 1Gbps?? We currently have 2 locations that are setup in the more "traditional" manner. We have MS225-48LPs and MR56 APs... I am using the SFP ports for inter-switch and firewall uplinks, while the APs' multi-gig ports are uplinked to the 1GbE Switch Ports. Since the facilities have specific locations where wi-fi usage is more business than the other casual areas, I was thinking of using the remaining available SFP ports for certain APs that will provide a wider trunk for larger data transmission, which can help increase performance in strategic areas. If there were Copper Modules that could provide Multi-Gig speeds, I could implement this without the high cost or the need to wait years for them to upgrade.
... View more
Mar 24 2021
9:28 AM
1 Kudo
@ww Correct, I do understand the issues with the Wi-Fi spectrum. My thoughts on the AP situation is that an AP, still, is just an Access Point to the LAN just like Access Switches - each switch has at MOST 48 ports that each support up to 1Gbps. Currently, the ideal uplink for a physical switch is the SFP ports that can transmit up to 10Gbps of aggregated data per port. Since a Wi-Fi AP is nothing but a wireless access switch, and today's standards of Wireless connectivity can theoretically reach speeds over 1Gbps - even if those end devices does not reach those speeds - the data transmitted to and from multiple devices can definitely add up; the trunk (or uplink) from a Wi-Fi AP, just like any physical switch, should be able to handle an aggregated amount of speed above the theoretical max. This is why this is concerning to me - I often tend to see in other businesses there is something causing slowness on the network (Gig switches uplinked via one CAT5 or CAT6 cable), and in some cases the bottleneck is more than likely the uplink of the switches; Just think the same goes for a lot of Wi-Fi setups as well.
... View more
Mar 24 2021
7:37 AM
I have been thinking of a more innovative network design for a client's location that will be using Wi-Fi as the main means of connectivity for their clients - they will usually have a large number of devices at one time. Now, I have seen and been using the most "traditional" way of setting up Access Points - up-linking them to access switch GbE ports. I was thinking of incorporating one of Meraki's Aggregation switches to manage the APs. I was looking at the MS425 models because they have plenty of available 10G SFP ports. The MR56 AP has a 5Gbps Multigigabit Ethernet Port. This would provide more available bandwidth for the APs to service a large number of devices at once instead of squeezing most of that traffic through a 1G switch port (lots of streaming and LAN traffic by the clients); however, I do not see a Multi-Gig Copper Module for the Meraki brand switches - I do see the 1GbE SFP Copper Module... If this module only max at 1Gb (hence the name), this will make the entire idea useless... Is it possible to make this setup work?
... View more
Feb 14 2021
8:02 PM
@cmr Oh ok, so I did have a couple of times where the switches did lose connectivity as if they were rebooted - I had no idea why. So, this is a known issue with the MS225's?? I read the "Known Issues" with the 14.8 and it only spoke of the MS350 with such issues. Do you work with the MS225's? I was trying to stay away from the Beta versions, but looks like I may have to give it a try.
... View more
Feb 14 2021
9:36 AM
@cmr Hi, I think its more the MS225's because from what I understand, the MX's do not do Spanning Tree - they don't recognize BPDU packets, correct? An individual switch cannot be selected as a root when the switches are stacked, so I was thinking since the stack is seen as one switch, it would simply see the 49th port on switch 3 as port 147. Or at lease differentiate switch 1 port49, switch 2 port49 and switch 3 port49. Not sure how it sees it, but if the Firewall is not a factor in selecting the STP root, and the entire stack is the only STP root that can be chosen, then maybe using both ports 49 as an uplink may have been the issue. I can try using a different port for the redundant uplink - I will do that and see what happens. I don't have the MS225s in L3 mode at the moment because I didn't want to overly complicate the configurations being that we just moved all of their servers to Azure.
... View more
Feb 13 2021
9:37 AM
I recently setup network hardware for a client site. I connected the core firewall to the MX with redundant uplinks, however, at some point I lost all connectivity to the switches. The setup is 3 stacked MS225 switches uplinked via fiber to the MX: Switch 1 uplinks from port 49 to MX port 25, Switch 3 uplinks from port 49 to MX port 26. I am on firmware version 14.8 on the switches - I have read up on the firmware issues and there is nothing stating issues with STP and BPDU. Also, in my switch settings, I had not yet set a STP priority since we have not connected any other switches yet aside from the core stack. I only had the option of selecting the entire stack, not an individual switch. After working with no issues for weeks, the connection to the switches were lost due to the redundant uplink a Meraki Support Rep had discovered, but was unable to tell me if this was a known issue. I did inquire if it had anything to do with me using port 49 on both switches in the same stack, but they were unable to answer that. I am now very concerned and afraid to try redundant uplinks with this particular hardware... This client site is in a different state and I want to ensure redundancy as much as possible. I will be installing the rest of the switches on the other floors in about 2 weeks and need to know if there is any pointers someone can give that will ensure the redundant uplinks will work without going through the same problem once the client officially opens.
... View more
Jan 12 2021
10:54 AM
We currently moved a client to Azure and setup a Site-to-Site VPN. I chose the Hub configuration. Now our client is expanding to another geographical location and we will need to connect that site to the Azure VPN. What VPN configuration should be chosen - Hub or Spoke, and should the original site be changed to Spoke? From what I am gathering, the Hub or Spoke configuration is only for Meraki devices... Also, I am assuming in order to have a Spoke, a hub must exist.If this is the case, I should choose Hub as the site-to-site configuration? If I do not want my Meraki MX's to "talk" via the VPN Mesh, I would then configure the outbound Firewall Rules for the VPN to deny all traffic to the other Meraki VPN networks while allowing traffic to the non-meraki Azure VPN device?
... View more
Nov 5 2020
8:47 AM
@bluecavalry Well, I found that the MS225's just have limited Layer 3 capabilities like inter-VLAN connectivity - they don't have full Layer 3 routing abilities. The MS250s and above are actually Layer 3 switches with full Layer 3 capabilities. Switching capabilities Layer 3 Warm spare redundancy (VRRP) OSPF Routing MAC forwarding entries, up to 32K DHCP Server, DHCP Relay 802.1X Authentication DHCP Snooping STP Enhancements IPv4 and IPv6 ACLs https://meraki.cisco.com/product/switches/stackable-access-switches/ms250-48/
... View more
Oct 26 2020
9:22 AM
@cmr Thanks... Quick Question: I have a client setup that will have all MS225 switches in each IDF on separate floors. In this case, the MS225 stack (3 switches) in the MDF should do the Inter-VLAN Routing being that would be the "core" switch, right?
... View more
Oct 26 2020
8:40 AM
@cmr So, you guys are just using them for inter-Vlan connectivity then?
... View more
Oct 26 2020
8:00 AM
MS225 - Capability: Layer 2 - Basic Layer 3 Connectivity MS250 - Capability: Layer 3 Layer 3 Access The difference is the MS250 can route at layer 3. So what exactly does the MS225 do at Layer 3 - Just VLAN connectivity and DHCP? So, basically the MS225s are not really L3 switches?
... View more
Oct 23 2020
5:44 PM
@Bruce I really appreciate your input, Bruce. I will make sure to keep this in mind and configure accordingly. Thank all you guys for your help on this. Originally, I was doing networking more in depth, but I moved away from it for a few years as a Telecom Manager for the State (GA Dept of Public Health). I am now back to doing this and looks like I have gotten rusty on a few things. I "discovered" the Meraki product and it has surely made networking life easier than it used to be. I know I will be posting here quite a few times in the future for tips and information - Hopefully, you all will not tire of giving me advice here and there.
... View more
Oct 23 2020
11:17 AM
@GreenMan THANK YOU for the info!! I assumed that the MX had some sort of STP feature being that it can act as a switch to some extent. I was going to connect the MS’s directly to the MX (separate uplinks) just as it has in the diagram from the link you sent me (thanks). but looks like this is not such a good idea after all. We are expecting to upgrade all equipment to: MX250, MR225-48LP’s (L3 switches). Even with that setup (separate uplinks directly to MX), looks like I would have to do some extra configuring for it to work correctly. Looks like I will just need to use the traditional setup: MX --> MS (for distribution). As a matter of fact, we may need 3 MS’s in the MDF - the other switches are in different locations of the building. I would also like you guy’s opinion on this as well... we will be upgrading and expanding their network soon: SW1, 2, 3 in MDF SW4 & 5 in IDF closet on another floor SW6 & 7 in IDF closet on another floor My thoughts were to do this: -Setup Sw1 for Layer 3 switching, while relay DHCP to MX250. --SW1 Distribution Switch, uplinked to MX250 --Sw2 & 3 Stacked and uplinked to Sw1 --Sw4 & 5 Stacked and uplinked to Sw1 --Sw6 & 7 Stacked and uplinked to Sw1 I have never utilized DHCP relay for switching - do you think this is a good idea to let the MX handle this? I want to make sure I optimize the LAN as much as possible. I want to be sure I am configuring DHCP correctly. If this helps, all servers will be in the Cloud (Azure) - even our printing service. We will have VLANs separating traffic between Guests, Members, and Staff.
... View more
Oct 22 2020
6:47 PM
1 Kudo
Thank you very much - that was helpful. I do think we may be pushing the limits to the MX. We are urging for an upgrade to the devices anyways - more ports are needed and better devices. We are looking at an MS225-48LP model (layer 3) and MX250. I will make sure I use the layer 3 features on the "core" switch.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 2103 | May 13 2023 4:55 PM | |
| 1094 | Oct 10 2020 9:42 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 2 | 7208 | |
| 2 | 7447 | |
| 1 | 1847 | |
| 1 | 4871 | |
| 1 | 5983 |
© 2024 Cisco Systems, Inc.
