About Bruce

Bruce

@Tore the Meraki switches (since they run RSTP) will only interact with instance 0 of MSTP. Instance 0, the common and internal spanning tree (CIST), is used to carry the CST across the MSTP domain.

Bruce

@treimers you could have a problem with an IPSec client behind a Meraki firewall depending on the client operation, and what services you are running on the MX. Meraki AutoVPN - shouldn’t cause any issues. Although it is IPSec based it uses ports negotiated through the VPN registry, not the standard ports. Third party peers in Site-to-site VPN - having these configured could cause you problems as these use the standard IPSec ports to establish the connection. Client VPN - if you have the L2TP client VPN enabled them this may well be causing you issues as it uses the standard IPSec ports. Hope this provides some idea where to look/check.

Bruce

Assuming the MX105 is just like the MX75/85 then (at launch) you’ll only be able to have two WAN ports active at a time, plus USB failover - essentially like any other Meraki device. Putting a SFP into one of the SFP ports will disable the corresponding RJ45 port (this automatic behaviour can be overridden on the local status page).

Bruce

@ECI_Adelaide did you set up the new wireless SSID as NAT mode, using Meraki DHCP? This will have that effect. It’s as @CptnCrnch describes, the domain suffix not being set. It’s likely the best way to set up the SSID will be in Bridge Mode and tag all traffic for a VLAN, then make sure there is a DHCP server on the VLAN (either directly, or contactable via DHCP relay), where you can configure all the DHCP options you need.

Bruce

Welcome @TokyoKevin. Congratulations on passing your exam, and there are plenty of people here who can point you in the right direction if you’ve got questions.

Bruce

Welcome @ssaunders, post away and everyone will try and help.

Bruce

Your API key is your authentication to the Dashboard. Think of it as your username and password all wrapped up into a single non-comprehendable string of characters, and treat it with the same respect. I get what you are saying, but your API key is everything in the Meraki APIs at the moment. This is why you’re only ever shown it once when you generate it, never to see it again - you need to keep it secure.

Bruce

@RumorConsumer there are some minor differences between the two and technically the MR52 may perform marginally better. The MR52 is a 4x4 array and so can use an additional signal path for MRC. But most clients are only a 2x2 or 3x3 antenna array, and so any benefit in one direction may be lost on the other direction. If there is a benefit its going to be minor, and if your current experience is that bad then you are better of putting in another access point, its going to be a much better solution. Also, keep in mind that the MR42 and MR52 are end of sale at the end of July - or sooner if Meraki hits supply issues. So you may need to consider what your next move is. Again, a Wifi 6 access point (MR44, MR46, MR56) may perform slightly better (due to some of the technical advances) but any improvement will likely only be minor and again I'd be suggesting you're better off putting an additional AP in.

Bruce

You'll need to have a look through the Windows server and see if you can ascertain what is going on from the windows event log or performance monitors. What is the memory utilisation doing? Is it running out of memory (as well as the CPU peaking)? Do you see the WMI provider take CPU or Memory (the MX scrapes the Security Log every 5 seconds). Is the Security Log large, open it and see how many records are there (are there any logs there at all?).

Bruce

@jjlarsson yes, you’re correct. If you’re using the MA-ANT-20 then you need to order 2x that SKU, so you have 4 antennas. Two on the top, two on the bottom of the AP.

Bruce

I haven’t heard of anything around SHA512 for the Meraki MX appliances, and I know a number of other vendors support it. I’d open a case with support just to check whether or not there is something they’re able to turn on for your network to support it. Other than that your best bet is to reach out to your local Meraki SE or AM to see if they can provide some information (it’s unusual to get forward looking information here). If you do use the Meraki MX for your connection, just remember that third party site-to-site VPN routes aren’t shared across AutoVPN connections (just in case you have any). This means it’s often easier to use a different firewall (like a Cisco FTD or ASA) for such connections, then static routes to/from the MX - that may solve two problems, the SHA512 issue, and the sharing routes over AutoVPN.

Bruce

@Twitch How much work it is to combine organisations depends on how big they are. Moving devices is easy, moving licenses is easy to (although requires support’s help if you’re in co-termination licensing mode), the hard part is moving the configuration. Depending how many networks and how complex they are it could be easy or hard.

Bruce

@JonasResende what outcome are you looking for? The traffic shaping rules apply to both VPN traffic and internet traffic, any should also apply to traffic using Full Tunnel Exclusion (note that application based Full Tunnel Exclusion requires the SD-WAN Plus license). So, you can create some basic limitations on maximum traffic bandwidth using the shaping rules. If you can use the MX16 firmware (the beta firmware) then you will get many more applications available in your rules as it uses the Cisco NBAR engine.

Bruce

@Twitch I don’t believe there is a way to advertise the remote routes across each organisation’s AutoVPN without adding some additional hardware to the network. One answer could be for the parent company to put a VPN concentrator (part of their Meraki organisation) as a spoke into your network. You can then create static routes from your MX to point to this, and advertise those static routes into your AutoVPN. They then create local subnets on the MX concentrator to match your network subnets, which then get advertised into their AutoVPN.

Bruce

Glad it helped. With regards to the TX Power, this is just the maximum the AP can use for that MCS, it doesn’t mean it will (or has) to use it. If you have multiple APs in the environment the Meraki cloud will adjust their power levels to reduce the interference between APs while still maintaining good service to the clients.

Bruce

There’s actually a couple of ways you can do this, and it’s probably easier if you don’t need a VPN over your private network. You can either connect your private network to WAN2 and make this the primary WAN link (since you say it has an internet connection), and then get support to enable no-NAT capabilities on the network (assuming you want to preserve client IP addresses). Or you can just create a VLAN and use the LAN-side and add some static routes to the MX and connect to the private network that way. If you’re able to do either of the above then you can still run AutoVPN to connect to the sites where you only have broadband (assuming they have Meraki MX devices). You can set the SD-WAN preferences to prefer WAN1. And if you were connecting to your private network via WAN2, theN it’s likely You could still failover to WAN2 for these connections too, so long as there is a NAT on the internet connection via WAN2, this should still allow a second path to the broadband connected sites. If you want to encrypt traffic over the private network and you have MX devices at all the sites then you can run AutoVPN over that too, then you just need to correctly define your flow preferences, either WAN1 or WAN2 to get the path selection right. So long as there is an internet connection from the private network that provides a NAT then this should all work fine. You’ll just need to make sure you understand the paths and get the SD-WAN path rules correct for your preferred paths.

Bruce

Did the destination happen to be across an AutoVPN tunnel, and you’re using a full tunnel with this MX as the exit hub? If that’s the case then the IDS/IPS only operates in IDS (i.e. non-blocking mode) for traffic destined across the AutoVPN tunnel. (Reference, https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings, first blue highlighted box).

Bruce

My understanding is that the TX Power (conducted) is the maximum power that can be sent to the antennas for that data rate - the actual emitted power may vary slightly based on the radiation pattern of the antenna. And the receive sensitivity is the absolute lowest signal strength at which the access point can receive a signal to meet that data rate. Other factors can also play into this, especially the receive sensitivity. For a quality signal you also need a good signal to noise ration (SNR), so if your noise floor is too high then you won’t meet the expected data rates anyway. You also need to remember that just because your AP can transmit at, one power level, it doesn’t necessarily mean the client can achieve the same power levels to send its signal back. it’s also worth noting that depending on your region and the regulatory authority for radio frequency use there may also be software restrictions enforced on the device to ensure it is compliant with local laws.

Bruce

@suneq, we often use the design that you show with private IP addresses between ISP devices and the MXs. This is because in Australia there are very few (if any) carriers that will provide a /29 as the link, they'll only provide a /31 or /30, sometimes it has to be PPPoE. (They'll provide a /29 over the top of the link, but not as the link IP addresses themselves). So the public /31 or /30, or PPPoE termination, sits on the ISP device with a /29 private IP address range between the ISP devices and MXs exactly as you state. The ISP devices also do a NAT from the private IP addresses to the public as @DashboardDunce stated. The only downside of using private IP addresses is the NAT, it can make things a little more complicated (sometimes) and can impact the performance of the ISP device (depending on that device).

Bruce

If the Windows systems are using the same HP Probook G series without issue, then you can basically rule out hardware - so the laptop and the Meraki access points. So it comes down to the configuration and the drivers. I would start by looking at the drivers for the WiFi on the Ubuntu systems and see if there are updates available there, then see if you can spot any configuration differences between the Ubuntu systems and the Mac (since as they are both Linux variants).

Bruce

Welcome @VilasithP, if you keep on watching this community you'll see lots of what is happening in the world of Meraki. If you look at some of the recent posts you'll see there was just announced some new MX and MG models, and also a new MV and MT too.

Bruce

@endrianusgohan, just to add to what @ww said, when you do set this up (assuming you are doing full tunnel) your content filtering, etc. will be performed by the full tunnel client (i.e. closest to where the client is). This is stated in https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings.

Bruce

@jpier I agree with you that Postman is one great way to make multiple updates with only a few quick changes. You can also take this one step further and use a scripting language like Python to access the APIs. Another path you may want to consider is using the Policy Objects for the firewalls (yes, its beta, but its been around a while now, and there are great successes with it). You define organisation-wide Policy Groups which you can then use in your inbound and outbound firewall rules (they don't work on Group Policy, yet). Then if you need to make a change you just update the Policy Object and its applied everywhere that policy is used.

Bruce

@Lock007 I'm assuming that your DNS server also runs your AD Domain Controller function, as its the DC function that the MX integrates with. The MX integration has two parts to it, it binds to the DC to gather group memberships via LDAP, and it scrapes the security logs for logon events using WMI to match users to IP addresses. I'd check both the Windows server event logs and MX event logs for errors to see if there is something not working correctly. I'd also check the permissions of the user account you are using to connect to the AD DC - maybe temporarily use a domain admin account to see if there is a rights issue, and then switch is back to a more restricted account if it works with the domain admin account (the permissions that are needed are given in this document, https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Configuring_Active_Directory_with_MX_Security_Appliances) Also, check the memory usage on the server too. If this gets high and results in a lot of swap file activity this may be driving the CPU usage up.

Bruce

@Silentshooter there are a lot of performance issues being reported with the MR45/MR55 access points, most (although not all) of which seem to be resolved by turning off some of the power saving features on the clients. Here is a good example, https://community.meraki.com/t5/Wireless-LAN/Getting-low-connectivity-MR45-Meraki/td-p/98915. From what I've read and seen it seems to be problems with the chipset that is used in the MR45/MR55 access points. This is a first generation 802.11ax (note, its not Wifi 6) chipset and seems to have been beset with issues, and most likely why these access points had such a sort lifespan (the MR55 is already end of sale, has been for almost a year, the MR45 is end of sale in a month). The MR46/MR56 access points which are true Wifi 6 do not seem to have anywhere near as many issues and use a different chipset. I know its not the answer you want, but try the power saving settings on the client and try disabling 802.1x on the APs to see if either of these make a difference. I'd also try the stable release candidate and beta firmware versions, you can always roll them back from the dashboard if they create more issues in the first two weeks (after than you can still roll back, but need to contact support).

Bruce

Community Record

Badges