Meraki

Bruce · ‎Jan 18 2021

I may be completely off track here, but if you're trying to specify a host for those two fields have you tried using the 'subnet mask' of /32, (i.e. 255.255.255.255), which is generally used to specify a host. For example, "srcCidr": "192.168.128.56/32" and "destCidr": "2.2.2.9/32".

Bruce · ‎Jan 17 2021

If you're thinking of replacing the APs so they are WiFi 6 and replacing the switches to potentially make them compatible with the Ruckus Cloud solution then cost really shouldn't be an issue - I would expect that if you need to make those changes then your partner and Meraki AM should be able to help you with minimising the dollar cost conversation. And you'll be able to get some trial gear to make sure everything will work as you expect. If you're just shopping around with a kit list then its unlikely you'll be getting the best from Meraki. If you were planning to leave the Ruckus APs or current switching in place then I fully understand the dollar cost conversation.

Bruce · ‎Jan 15 2021

I think you did a good job of hitting the nail on the head with regards to why you’d migrate to Meraki. The Dashboard is the real key to the Meraki solution. It will provide you that single point to monitor and manage your network across all your devices - without having to connect to individual devices and remember (sometime obscure) command lines. It also provides you and great, and still growing, API if you don’t want to get completely away from the command line or scripting for automation or those time consuming iterative tasks. You don’t mention the size of your network, but the place I also find Meraki excels is across multiple sites when you’re trying to manage or maintain the same (or similar) configurations on multiple wired or wireless networks. It can also be great on a large single site too, for example where you want to configure multiple ports on multiple switches in one go. From a cost point there is always a cost of change, but the key here is to consider the reduced operational overhead from the Dashboard, as well as getting brand new hardware. You should also make sure you’re working closely with your Meraki AM or partner to ensure you’re getting right-sized hardware, and the right pricing for your migration (they’d love to see you on a full-stack Meraki solution).

Bruce · ‎Jan 15 2021

Like everyone else, the OS field isn’t something I’ve ever relied on - the best one I’ve seen is an Xbox One S reporting as Android. If you want reliable device level profiling then I’d recommend Cisco ISE, it’s marginally more complex than using the Meraki Dashboard, but far more accurate (and customisable too).

Bruce · ‎Jan 15 2021

To add to what Blake said, remember that you don’t create VLANs on the MS, they just accept all 802.1q tags (unless you specifically deny them), and you don’t have to create an interface for a VLAN. So for the ports connecting to the closed camera system you just assign them as access ports to the VLAN number - simple 😀

Bruce · ‎Jan 15 2021

Once you’ve added a device into your CCW configuration you should be able to add a service to it, which will let you select from the available Meraki NOW SKUs.

Bruce · ‎Jan 15 2021

Hi MX-2020, Sounds like you are moving in the right direction. Here are couple more pointers. You can configure the MX to have as many IP addresses as you want (within reason). Each VLAN you create on the MX has an IP address which is ‘on’ the MX. Don’t think of these as management IP addresses as the MX (like all Meraki devices) is cloud-managed, so they’re actually managed via the internet facing interface. If you want the MX to have 10.10.80.50 on it, then assuming this is on VLAN80, the IP address for VLAN80 should be 10.10.80.50. I can’t see why the ME router needs to connect to the switch, why not connect it directly to the MX WAN2? Having an interface on VLAN99 on the MS is just going to complicate things and add no value that I can see. You could use VLAN99 on the MS without an IP address, but in that case why not just connect the MX WAN2 to the ME router? You can setup DHCP relay on either the MX or MS, but if the DHCP server is in VLAN80 then you don’t need a relay for any devices connecting to VLAN80 the sever will respond to them anyway, you will need to configure DHCP relay for other VLANs though to direct them to the DHCP server. You shouldn’t need to set any specific NAT, the MX will do PAT of the local IP addresses to the respective WAN IP address without any additional configuration.

Bruce · ‎Jan 14 2021

If you’re talking 100m of clear space (I.e. nothing in the Fresnel Zone) then you will most likely get a Mesh connection using the MR74 and MA-ANT-20. How good the actual signal strength is, and so what speed you get will be very dependent on the obstructions. If you’re talking about a client being able to connect to a MR74 with MA-ANT-20 will mostly depend on the client. Clients generally have a lower TX power than the access point, and will vary that TX power depending on power state (e.g. battery charge, external power, screen being locked). Again, theoretically, you should be able to connect a client at 100m, but it’s going to depend on the environment and the client, and it’s unlikely you’ll get close to the maximum throughput the MR74 is capable of.

Bruce · ‎Jan 13 2021

At first glance it looks like it should work (I.e. purely from the capability of the access points, antennas and the distances involved). My main concern would the obstructions to the RF signals, all the trees and other vegetation, as well as structures that are in the sites - they will all impact the wireless mesh and the connection to the client devices. You should also remember that when using wireless mesh, for every hop from the gateay (I.e the wired access point) you will essentially be halving the uplink speed. With this in mind you may want to see if you can get more access points hardwired. I would strongly recommend two things: find a local Meraki partner who can help you with site surveys to ensure you get the performance and coverage you are hoping for, and get some Meraki kit as a trial to see how it performs in real life. As I said, it looks like it should be fine, but you really won’t know until you get kit on the ground and test it.

Bruce · ‎Jan 12 2021

The information provided by everyone else is all relevant and worth understanding. A couple of points to add... The third party site-to-site configuration is organisation-wide, so when you add the new MX it will try and build a VPN to Azure (unless you stop it with tags). So you’ll just need to configure the Azure end for the new site. Why do you want to stop traffic directly between the sites over VPN? Using the VPN firewall rules, will stop this traffic, but it will stop all communications between the sites - it won’t force it through the Azure site or anything ‘clever’ like that.

Bruce · ‎Jan 12 2021

@PhilipDAth is correct in what he states. Connect one antenna to both the 2.4GHz ports and the other antenna to both the 5GHz ports. The H and V on the antenna are the polarisation of the elements in the antenna, ‘horizontal’ and ‘vertical’, you need one of each in each band for things to work as expected.

Bruce · ‎Jan 12 2021

If your access point is coming online as a repeater then it’s most likely it can’t get an IP address via DHCP on the Ethernet connection. So check to make sure the cables are good, and that your subnet/VLAN and DHCP are correctly configured (and that there are spare DHCP addresses available). I don’t believe configuring a static IP address will work if the access point is running as a repeater.

Bruce · ‎Jan 11 2021

It is a little bit complicated 😀, and I can’t see why it should be. There are a couple of things to consider... The MS can really only have one default route (i.e.0.0.0.0/0) so all internet traffic from the MS will be sent the same way, either to the MX or your ME service - there isn’t really an option for using one as the backup to the other from the MS210 as the routing is static. Why not connect the ME router directly to the MX WAN2 (i.e. not via the MS) and disable load balancing. With WAN1 configured as the primary, internet traffic should go out WAN1, unless it fails in which case it will go via WAN2 to your ME service. Your Flow Preference will ensure that all ‘internal WAN’ traffic uses WAN2 (unless it fails) - although note that it will be NATed to the WAN2 IP address. Note that you may be limited by the throughput of the MX. Have a single link between the MX and MS, connected to one of the MX LAN ports. This will have two VLANs on it. I’d have the native VLAN as your management VLAN, and a tagged VLAN as a transit VLAN between the MS and MX for all non-management traffic. Keep all the management interfaces, MS and MR, on this management VLAN (will mean you probably need to switch the MRs to use bridge mode and assign a VLAN tag to all traffic from the SSID). Hope these, along with everyone else’s suggestions may help.

Bruce · ‎Jan 8 2021

Find more use cases and positioning for the MS390 (hopefully with more robust firmware), along with Adaptive Policy with the Wifi5/6 MR devices (and hopefully also with MX SD-WAN support).

Bruce · ‎Jan 8 2021

To support what @cmr stated, here’s the Meraki document that supports the design he is outlining in his response, https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair#Fully_Redundant_(Switch_Stack).

Bruce · ‎Jan 6 2021

Great job all. With the holiday season over I guess it’s back to some sort of normality. @DarrenOC thoughts are with you, you guys will get through it.

Bruce · ‎Jan 4 2021

You mention that you tested with another MX NATed behind another device. Is that other device also a Fortigate firewall? It’s possible that the Fortigate is detecting the L2TP/IPSec and trying to be ‘smart’ with its NAT and actually introducing a problem. I would see if there is ‘smart’/application processing on the Fortigate that you can turn-off and just let NAT be NAT.

Bruce · ‎Jan 4 2021

As Philip stated there is not an endpoint to get the same information that is available for the MS. The closest you can get on the MX is the /networks/{networkId}/appliance/ports endpoint, but this doesn’t provide interface bandwidth/duplex configuration. (Since you have to use the local status page to get the bandwidth/duplex on a MX and it can’t be changed through the Dashboard, I wonder if this is a shortcoming of the Current MX firmware?) EDIT: Be aware that the capabilities of a MX switch port are far less than those of a MS switch port.

Bruce · ‎Jan 3 2021

Welcome to the community. There’s many people who could offer advice on third party VPNS to/from a MX appliance. If you post in the Security/SD-WAN topic about what you’re trying to achieve and what you’re experiencing I’m sure you’ll get some responses. Depending how far you’ve got with your troubleshooting this document might be of assistance https://documentation.meraki.com/MX/Site-to-site_VPN/Troubleshooting_Non-Meraki_Site-to-site_VPN_Peers

Bruce · ‎Jan 1 2021

As Karsten stated, if the traffic is in the same VLAN then there is no inspection. If you’re passing traffic between VLANs then the MX firewalls apply as well as the IDS/IPS rules, but not the AMP - that only applies to traffic arriving directly on the WAN/internet port. So the MX can be good for macro level segmentation for a small server farm (where you can put each server in its own VLAN), the greatest limitation may by the throughput of the MX appliances (which Karsten’s suggestion of a Cisco Firepower may ‘fix’) If you’re wanting to provide inspection for all traffic within a data centre, along the lines of micro segmentation, then l’d be looking at other technology. Something like Cisco ACI can achieve that, or there are options depending on what hypervisor you are using (e.g. VMware NSX).

Bruce · ‎Dec 22 2020

There is no native rollback in the Meraki Dashboard. The closest option you have is to work backwards through the Change Log (Organization -> Change Log) to undo whatever changes were made.

Bruce · ‎Dec 22 2020

You can't specify the AP for a Repeater to use as a Gateway so far as I'm aware. The Meraki Mesh uses a proprietary routing algorithm to determine the best path to use based on a number of metrics, so theoretically it will always make the best choice (but that's theory and not practice). There's a little bit on this topic in this document, https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Wireless_Mesh_Networking

Bruce · ‎Dec 22 2020

Welcome, hope you find some useful information here, and continue to build on your Meraki experience.

Bruce · ‎Dec 21 2020

Welcome to the community @LibertyM01. If you want to master Meraki you've come to the right place. There's some great people here, with some great knowledge and experience. And you'll soon discover why the Meraki solution is so awesome (and some of the elements that are still being made awesome) 😀

Bruce · ‎Dec 21 2020

Yep, its one of them...

About Bruce

Bruce

Community Record

Badges