About Bruce

Bruce

There are still a few teething issues with the MS390 switches. Best I’d suggest is that you make sure you have the latest firmware from whichever train you’re on (I.e. General Release, or Beta), and if the problems persist log a call with support. They’ll be able to let you know if it’s a known bug, and if not will be able to look into it further (and potentially add it to the bug list).

Bruce

Yep, connect one ANT-25 antenna to both the top ports, and another ANT-25 antenna to both the bottom ports. The difference with the MR84 (being a 4x4 access point) is that all the ports are dual band (so both 2.4GHz and 5GHz) and you want to have the antennas covering the same area so that all the smarts of 802.11ac Wave 2 work as expected.

Bruce

The only way I could think of doing that is to get creative with a script and an API, and see what can be done there. Something along the lines of alerting via a Webhook on movement, then have a script to a trigger a number of snapshots on the camera, that you then post somewhere. It’s a basic outline, but should be achievable.

Bruce

@NickHorton I believe what you are referring to is what Meraki have called ‘Motion Recap’, where it blends frame together to show the motion. You should be able to disable this on the Motion Alerts page under the Camera Settings.

Bruce

This document shows the basics of how to use AutoVPN as a backup to an MPLS link, which is the basis of what you are trying to achieve, https://documentation.meraki.com/MX/Deployment_Guides/MPLS_Failover_to_Meraki_Auto_VPN. The way I’d configure the MX is with the P2P on one of the LAN ports, as an access port in its own VLAN so it essentially becomes a Layer 3 link. Then configure a static route to the subnets at the other site with ‘while next hop responds to ping’ (or ‘while a host responds to ping’ if you prefer) pointing across the link. The Static route will have preference over any VPN routes so the traffic will go over the P2P link. If the link fails then the Static route will drop out of the routing table and the VPN route will become active, sending the traffic back over the VPN link. You won’t be able to use the point to point link for Internet traffic as you can’t set a default in the event that the Internet fails, that’s not the way the MXs work. As such you should never end up in the situation where internet traffic goes across the P2P link, unless you purposely put in a default route to do that (which means nothing will ever go out the internet links, except traffic to the Meraki cloud). Hope this provides some guidance.

Bruce

Sure, no worries. 1) The 802.1x processes by themselves allow for a user to be authenticated and for a VLAN to be assigned to the port. With the original 802.1x once a user was authenticated and VLAN assigned there was no way to change the authorisation on the port until the user physically disconnected and reconnected. Modern systems required that if security conditions change the authorisation of the port can be changed, and hence in the last five years or so switches have supported CoA to enable this. You need a RADIUS server that supports CoA (e.g. Cisco ISE, Aruba ClearPass) if you’re going to use it, but for standard 802.1x almost any RADIUS server can be used. See here, https://documentation.meraki.com/MS/Access_Control/Change_of_Authorization_with_RADIUS_(CoA)_on_MS_Switches 2) There is a document (which I can’t find now) which outlines the compatibility of Cisco ISE with Meraki MS switches. From memory they don’t support URL redirect, and they definitely don’t support TrustSec/SGT (the MS390 is slightly different, but best not go there). EDIT: found the document https://community.cisco.com/t5/security-documents/how-to-integrate-meraki-networks-with-ise/ta-p/3618650 Hope this helps.

Bruce

When RSTP is disabled on a port, the port takes no part in spanning-tree, so it always passes traffic. It won’t send BPDUs, and it won’t process incoming BPDUs (so essentially they get dropped). The recommendation is generally not to disable RSTP as if you do get a loop it will take down your network.

Bruce

The MX only forms it’s AutoVPN tunnel on the WAN ports, so you won’t be able to get the SD-WAN working if you’re using a LAN port on the HQ MX.

Bruce

You can use the MAC Whitelist feature on a port (see https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Switch_Ports) to restrict which MAC addresses can connect to a port, that would allow you to achieve what you want in a basic way. But don’t use this if you’re trying to build a secure network, MAC addresses are easy to spoof. If you are trying to create a secure network then you need to look at using 802.1x with usernames and passwords (or certificates) - although that takes the complexity up a few notches.

Bruce

If you don’t want to purchase a concentrator for the head-end then the only other option with the Meraki solution is to get a route to the internet from the MPLS network. This could be one that the MPLS service provider can provide and manage for you (it only needs to be small, and just needs a NAT for outbound traffic). The alternative is you can add yourself if the MPLS provider lets you inject a default route into MPLS network (obviously you then need to ensure the routing is correct and that it’s secure - similar to the concentrator model, but slightly different).

Bruce

@Malarkey_MX I don’t have an MX84 to confirm with but I believe it means you’ll get nothing if you connect to the Management port. The MX84 will behave like other MXs where you connect to one of the internal IP addresses (i.e. often the ones configured as VLAN gateways) to get the local status pages.

Bruce

Until the cameras can connect t back to the Dashboard you won’t be able to update them. If they fail to connect on their primary wireless profile they should then try the secondary, and then the backup if you’ve configured it. Unfortunately if none of your wireless profiles are working I believe you’re actually going to have to connect a cable to each camera to get them going again. That could be a WAP in mesh mode if you can’t get a cable there.

Bruce

Hi @BeniMaurer welcome to the exciting world of Meraki. If you hit any bumps with your projects then don’t be afraid to post int the forums, it might just be something someone knows how to fix.

Bruce

I don’t believe there is a Meraki rack mount kit for the 8-port MS120 switches. The only Meraki mounting solutions for these switches are built into the switches - the slide out arms underneath them for wall mounting (but they’re not rack mounts). If there was a rack mount kit it was probably a third party solution.

Bruce

It depends how many switches you have and the variety between port configurations. If there is a small number of switches or the switchports are all configured pretty much the same, then it’s pretty straightforward to configure through the Dashboard - select multiple ports and configure all the ports in one hit. Obviously there may be Layer 3 interfaces and the like to configure too, but the bulk of the configuration is normally the ports. If there is a bit more variety between the switch port configurations then I’d look to the API. You can write a script to extract the current configuration from a port and write it to the new switch. It may take a bit of effort, but will be way less mundane and hone your scripting skills. There’s probably something to do this (or very close to this) already on GitHub.

Bruce

Welcome @GregLiu. There's plenty to learn about the Meraki APIs - there's a technical forum just for them. If you haven't already found it, it's also worth checking out the Meraki section of Cisco DevNet, that's got some great stuff to get you going with Meraki APIs, https://developer.cisco.com/meraki.

Bruce

Welcome Cody. I hope you're able to get an insight as to some of the things that can be done with the Meraki solution from the forums. And there's plenty of people ready to make suggestions if you find yourself stuck anywhere.

Bruce

Why not just try and define the same /24 as a static towards Azure, that you have over the AutoVPN? Static routes take priority, so it may just work. This document has the route precedence, and just underneath describes something similar, https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior. You’ll need to test it, as this might be one of those things that should work, but doesn’t.

Bruce

Welcome Bernard. Sounds like you have a lot of interests and experience there. So far as simplify, automate and secure go you’ve found the right product in Meraki - just add your favourite scripting language to the Meraki APIs and off you go. There’s a bunch of great people in here who can help point you the right way if you get stuck.

Bruce

@Axel_R sounds like you installed an MS390 🤪 🤣 I cleared all my website data in Chrome and Safari, all seem to be working fine today.

Bruce

Either way should work, either with the native VLAN, or using VLAN10, so long as the MX100 is configured as a trunk port and the correct VLANs permitted. Either will separate the tunnelled traffic onto the VLAN that is configured on the MX60 WAN port, with the SSID traffic being tagged as specified in the SSID. Personally I’d use the native VLAN, but that’s only my preference as it’s generally easier to configure the first comms to the MX if it’s on the native VLAN.

Bruce

You need to understand what your traffic flows are to build the best design. As @cmr stated having spokes in NZ and Australia and a hub in the UK could leave you with VoIP traffic going ‘the long way’, and ultimately a poor user experience. If you only have a small number of locations then you might be better off with a single central hub, and then configure the other sites as either hubs or spokes depending on what the traffic flow is likely to be. There is no ‘automatic’ choice of which hub to go via in the Meraki solution, it’s all on predefined preferences which are used based on availability.

Bruce

I’m taking a stab in the dark here, but are you dropping guest Wifi onto the local LAN and then via a NAT on the ISR putting it into a GRE tunnel that then drops out into a DMZ or similar at a head-end? If this is the case then you’ll most likely have to look at rearchitecting the wireless guest network, rather than solving it in the way you currently do. Are you using Wireless Controllers? Are they centralised? Can you use Local Mode on the controllers for guest? Can you add a guest anchor for the guest traffic? Do you even need the guest traffic to be backhauled across the WAN?

Bruce

I’ve only seen the Layer 3 Roaming with a Concentrator used once, and I’m trying to remember how it worked. From memory I believe you’re correct in what you’ve written. When you configure the SSID you set the VLAN number, and this is the tag which is applied to the traffic as it exits the VPN concentrator MX. Between the MR and the MX it uses an IPSec tunnel between the management IP address and network of the MR and the IP address configured on the WAN1 of the VPN Concentrator MX. I think you may be right about the documentation being wrong as an MX in VPN concentrator mode has no idea what VLANs it has attached (unlike a MX in NAT/routed mode, which does). The ‘difficult’ part is understanding the traffic flow for the SSID at the VPN Concentrator MX end when the traffic leaves the IPSec tunnel. In this regard my understanding is that the IP address on the MX is largely irrelevant - there is only one IP address on the MX, and it’s in the native VLAN, but you could have many SSIDs, with different VLANs terminating on it. Traffic receives the defined tag and is placed onto the network, essentially you create a VLAN that stretches from the MR all the way through the VPN Concentrator MX (which is effectively Layer 2 only) and out to the default gateway for the VLAN wherever that is (the MX100 in your scenario). For traffic returning to the MR, sent from the default gateway for that VLAN (again, the MX100 in your scenario), there is no IP address on the VPN Concentrator MX for that VLAN. My understanding is that the VPN Concentrator MX will listen for, and forward all the Layer 2 frames into the IPSec tunnel for the clients in the VLAN that it has learnt about, essentially operating as a Layer 2 bridge/switch for the VLAN. Now, if I’m understanding you correctly you’re essentially trying to separate the client traffic on the SSID, from the Meraki management traffic, IPSec tunnel traffic, and so forth that the VPN Concentrator MX is generating. In this case you’re on the right track. You’ll end up removing the .10 address on the VPN concentrator MX for VLAN100 and replace it with the IP address in VLAN10. The trunk between the MXs will need to have the native VLAN set to 10. And this isn’t going to be a seamless change or something you can do remotely, you’re changing the one IP address that the VPN Concentrator MX communicates with the rest of the world, and all the IPSec tunnels will need to re-establish. But it should be possible.

Bruce

For straight 802.1x assignment of a VLAN when a user first connects to the network, CoA isn’t required. Enabling CoA configures the switch to listen for CoA messages from the RADIUS server. This allows some more advanced servers, e.g. Cisco ISE (there are other vendors too), to tell the switch to perform the authorisation of the switch port again, so allowing the VLAN to be changed after initial authentication has been performed. This is useful where the RADIUS server has separate threat feeds, or is performing ongoing posture monitoring and can detect, or be informed, of a change in the client state. There is also a new feature that you may be interested in too called Group Policy ACL, https://m.youtube.com/watch?v=nekC3_z5SDk. It’s akin to dACLs on the Cisco Catalyst. I can’t find any information on the Meraki site about it, but it was included in the MS14.5 release notes - so you’d need to run the beta code train.

Bruce

Community Record

Badges