Meraki

Bruce · ‎Jan 25 2021

Welcome to the community @CarlosCoque. Hope you can share some of your experiences to help others, and learn a few things on the way too.

Bruce · ‎Jan 25 2021

Assuming you’re talking about whether it’s a standard or crossover Ethernet cable. I can’t remember the las time I specifically used a crossover cable. Most ports now (including, I believe all the Meraki MX devices) have Auto MDIX ports, so they should automatically detect whether they need to crossover, and do it themselves.

Bruce · ‎Jan 25 2021

Since only VLANs 2 and 3 are allowed on the trunks on the left-hand side of the diagram, a loop has definitely been formed for these two VLANs based on the diagram. Are these VLANs in use? Are these any other ports on the four switches that RSTP has put into blocking state? What model switches are they, has someone enabled ‘broadcast storm controls’ to make the network workable (although obviously not correct)? Are there any messages in the Event Logs?

Bruce · ‎Jan 24 2021

Yep, you read the document correctly. It’s an improvement from when the WiFi6 access points first came out, they could only be in a wireless network with other WiFi6 access points if you wanted to use NBAR. I imagine that eventually we’ll see greater integration, but probably not until the MX devices support NBAR too (so that they can make the combined reporting work in the Dashboard) - until then you’ll need at least two networks per site if you’re using an MX and want NBAR statistics from an MR.

Bruce · ‎Jan 22 2021

Remember that the MX devices need to be able to reach the internet from their WAN ports to register to the Dashboard. @cmr’s approach works well, where you can use private IP addressing on the VPLS with the Dashboard traffic coming back to a headed data centre and then being NATed out to the internet by a firewall (or similar).

Bruce · ‎Jan 22 2021

The MX failover is for an entire MX, not individual VLAN interfaces. But the MX will send VRRP messages on all configured VLANs (it does not send them on WAN interfaces though - failure of a WAN is detected through other means). Thus, say you have 3 VLANs configured, and the VRRP messages fail on one (e.g. cable fault, intermediate switch fault, or a port fault) there will be no failover since the VRRP messages a still being received via other VLANs. In this regard you need to be careful when planning your failover scenario to ensure you don’t end up being ‘half failed’, and understand the failure scenarios. If you’ve multiple ports from an MX to physical infrastructure you also need to ensure you fully understand the spanning-tree implications.

Bruce · ‎Jan 22 2021

Yep, this is a problem I’ve come across too. You can’t remove yourself as an admin from an organisation, you have to get someone within that organisation to remove you - and support can’t/won’t help you here. The only way to do this is to reach out to someone in the organisation and request they remove you.

Bruce · ‎Jan 22 2021

Following on from the comments @GreenMan made, I tend to look at the MX vs. MS decision as security vs. bandwidth (it’s not that simple, but it’s a good starting point). The MX is slow (in comparison to the MS) and this may be a problem if you’re pushing a large amount of data between VLANs, but it does give you a stateful firewall if you’re trying to segment/secure some servers for instance. The MS on the other hand will switch traffic at line rate (or close to), and so throughput generally isn’t an issue, but it doesn’t have the firewall capabilities, although it does support ACLs (which aren’t stateful). I tend to do inter-VLAN routing on a switch if I can, especially where I don’t need the security of the MX so as to reduce the load on the MX - but that’s just personal opinion.

Bruce · ‎Jan 21 2021

@DerikA a when you do create your port channels on the Catalyst side make sure you’re using LACP for the aggregation - that’s the only method that the Meraki switches support.

Bruce · ‎Jan 21 2021

That seems odd. If the MX is reporting that the setup of the VPN didn’t succeed then I’d tend to think that it didn’t succeed. I’d want to do a packet capture on the WAN side of the MX to confirm my packets were being encrypted and not sent in the clear (they may just be being NATed). If it really is being encrypted then I’d open a ticket with support.

Bruce · ‎Jan 20 2021

Unfortunately it only gets applied to the device, there is no way to apply it on a per user basis. If you’re feeling adventurous then there isn’t any reason why you couldn’t write a script and use the APIs to apply a Group Policy to devices based on the user - I believe all the information is available through the API. The only issue will be how instantaneously the Group Policy can be applied - you may end up having to use polling, which depending on the interval may not be fast enough. It comes down to how much effort you want to put in the achieve an outcome.

Bruce · ‎Jan 20 2021

Yes, the MX15 software is beta only (for the moment). Yes the user needs to login first as the policy is applied to the client, so its easiest if the client appears in the client list - and yes, if these use multiple clients then the policy will need to be applied to each one. Hence why it would not be manageable with a large number of users or client. Its something to consider, but it may not work for your environment.

Bruce · ‎Jan 20 2021

From everything I've heard it is reasonably imminent. But be aware that it will require the MX16 firmware, which will be beta, so you'll need to decide whether you're comfortable running beta firmware. If you want a better idea of timing I suggest you reach out to your Meraki AM or SE, they should be able to provide you a clearer timeline.

Bruce · ‎Jan 20 2021

The BGP implementation on the Meraki MX devices is intended to peer with a Data Centre core for the headend of an SD-WAN solution. Its not intended for ISP peering. The scenario is that SD-WAN can run iBGP across it as a single autonomous system to exchange routes, and then you use eBGP to the data centre (with the MX in VPN concentrator mode) to exchange routes into the network.

Bruce · ‎Jan 20 2021

@Atags , you're on the right track, and what you've configured is correct if you're trying to block access to 10.1.11.1/32. You apply the Group Policy just like any other under Network-wide -> Clients - this is what I mean by applying it to the device (probably should've said client). You should see a Client VPN appear in the client list like this (this is a snip from my Dashboard): This is the bit that may be new on the MX15 firmware. You can see the 'VPN' symbol on the far left, it will be green for an active connection, and the MAC address comes from the VPN virtual adapter on the client (so even if the client device connects to your office network sometimes, such as a laptop, it will still appear as another client when on the VPN as the MAC address from the VPN virtual adapter will be different to the Ethernet MAC). Click on the MAC address and it will show you the 'client' and then you should be able to apply a Group Policy. You can also find the MAC address (and click on it) from the Event Log to, here's an example of my successful connection, showing the MAC address and the client ID.

Bruce · ‎Jan 19 2021

@Atags what Karsten states is correct. What you can try though is using Group Policy applied to the devices - if you've only got a handful of clients it may be a practical solution, but if you've got hundreds, probably not. If you create a Group Policy you can configure a custom Layer 3 firewall for traffic coming in from the Client VPN devices to which the policy is applied, this custom policy should include all your normal rules (since it overrides them) and also any specific rules to block/allow access to specific subnets. (I quickly tried this on MX15.38 firmware and it does work, but I suggest you do some more thorough testing). The gotcha is that there is no way to dynamically apply the policy to a device, hence why I said it would only be manageable for a handful of devices. You can't dynamically assign Group Policy using AD based on user credentials for Client VPN either, so you really are limited to manual device assignment. You may be able to delve into a bit of automation with scripting and the API. Events appear to be logged that you could use to associate a username with a device MAC address (or you may be able to get this from the API - haven't looked), and then you could potentially assign a Group Policy based on that. Just some thoughts, needs some more rounding out.

Bruce · ‎Jan 19 2021

As Blake correctly stated, there is no configuration file on the switches. Unlike a 'traditional' switch the Meraki switches are completely cloud managed. Yes, they do obtain (download) a configuration from the Meraki cloud - they obviously have to to be able to operate - but its not a configuration that is readable, or can be extracted from the switch. If you're looking to take a backup (snapshot in time) that you can keep then what is available through the Dashboard is essentially the current configuration (unless you've made any changes in the last couple of minutes that haven't made their way to the switch). You can access most of this configuration through the Dashboard API, and I'm sure there are some scripts out there (e.g. on Git Hub) that do exactly this. If you're looking to ensure that there is a backup of the configuration in case the switch fails then you don't need to, that's one of the great things about Meraki - the configuration is held in the Dashboard. And just for comfort there are two copies of your shard (essentially where your Dashboard is stored) in a primary Data Centre for your region, and a third in a secondary Data Centre in your region... so you should never be without your configuration through the Dashboard.

Bruce · ‎Jan 19 2021

Couple of things to check first - make sure your MX firmware is up to date. Double check your network connections and make sure you're not introducing a loop into your network some how. Remember, the MX devices don't run spanning tree (STP) so if you have multiple connections from the same switch (or switch stack) to the MX then you need to ensure that the switch is running STP to prevent loops. Do you have a diagram of how things are connected? If you're sure there are no loops forming when you enable Port 19, and your firmware is up to date then I'd suggest you open a support ticket as something doesn't seem right.

Bruce · ‎Jan 19 2021

When licenses are purchased there is no difference between new/additional licenses and renewal licenses. What makes the difference is when the license key is added to the Dashboard. If it is a renewal then it needs to be added as a ‘renewal’ which resets the licenses to match what is in the license key. If the licenses are added as ‘additional’ or new device licenses then they will be added as if more devices are being added to the network - essentially doubling the number of licenses, and halving the length, hence why the new co-term date is only two years out (there was a promo for new licenses which gave and extra year for free, i.e. for 3 years they got a four year license, which when halved gives the two years). If the licenses were only added recently you may be able to remove them from the license page and add them again as a renewal. If not then you will need to raise a support ticket and get the Meraki team involved.

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.

About Bruce

Bruce

Community Record

Badges