Meraki

Bruce · ‎Oct 25 2021

From what I remember (it’s been a while since I did a swap though), you also have to go and re-enable the AutoVPN if you were using it. You just re-enable it, all the settings should still be there.

Bruce · ‎Oct 25 2021

This article has the failover times in it, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/Meraki_SD-WAN. It mentions that tunnel performance is tested every second, but nothing more than that. I’m not sure if Meraki AutoVPN uses IPsec Dead Peer Detection, or a version of it (I expect it does) - there is plenty of information on the internet about that, but not sure what parameters Meraki use.

Bruce · ‎Oct 24 2021

VPN failover is detected quickly in the scenario you’ve given, as even though it’s an indirect failure the VPN tunnel on that link goes down and is detected pretty quickly through the IPsec tunnel mechanisms, and so traffic can be routed over other VPN tunnels. With the indirect failure and the straight internet link, the physical and layer 2 link doesn’t go down, so you have to wait for the other tests to timeout, which take the time.

Bruce · ‎Oct 21 2021

@FlyingFrames, no there isn't (well, not that I've ever discovered). Everyone is treated equal with regards to API calls - one free tier for everyone.

Bruce · ‎Oct 20 2021

@Mohit_Chauhan, the antennas attached to the MR86 should both cover exactly the same area. The MR86 is a 4x4 MIMO device and so for it to operate correctly all four of the antennas must have the same coverage. If you’re attaching patch or sector antennas to a MR86, then within the physical enclosure are effectively four antennas, 2x 2.4GHz, and 2x 5GHz. Attach one to the top connectors, and another to the bottom connectors on the AP, and that gives you your 4x4 MIMO on both radios.

Bruce · ‎Oct 18 2021

Hmmmm.... okay. Not sure what is going on here, but I've got some thoughts. Before you connect to the VPN, you need DNS connectivity to a Public DNS server. So for instance, if you're at home or mobile you need to be getting the DNS settings via DHCP so that they point to the ISP - not your internal DNS. This will enable you to resolve the dynamic hostname initially. When you connect you should get DNS settings pushed through the VPN configuration that are then used over the VPN connection - this will likely be your internal DNS server so you can resolve internal hostnames. The internal DNS server needs the forwarder configured as described so that the client can continue to resolve the dynamic hostname at intervals to maintain connectivity. I'm not entirely sure, but looking at the trail of posts you may not be addressing point 1.

Bruce · ‎Oct 14 2021

What is on those ports? It looks like you are seeing the STP changes because the ports are going up and down - they’re flapping. Every time a port goes up or down you see the corresponding change in STP, either moving to designated, or moving to disabled.

Bruce · ‎Oct 12 2021

What is showing up in the event log? If Port 25 is your only connection to the Cisco Catalyst switches then in general you shouldn’t be seeing that error. Check the STP Bridge Priority for the Meraki switches, by default it is 32768, make sure that the root bridge Cisco Catalyst has a priority lower than this on VLAN 1, like 8192 (the Cisco Catalyst defaults to 32768 too).

Bruce · ‎Oct 12 2021

@JodyB, no, the license has to match the switch model exactly (only exception is the MS390 switch models). You’ll need to talk to your reseller and get a RMA on the incorrect license and order the correct one.

Bruce · ‎Oct 11 2021

@Michael_Gibbs, the v1 endpoint is /organizations/{organizationId}/inventoryDevices See the reference here, https://developer.cisco.com/meraki/api-v1/#!get-organization-inventory-devices

Bruce · ‎Oct 11 2021

@hmc250000, what @WirelesslyWired said is true, so long as the Meraki switches are not 'between' two Cisco Catalyst switches - i.e. you don't have Catalyst -> Meraki -> Catalyst (Root Bridge). As well as including VLAN1 on the trunk, I believe it also needs to be the Native VLAN, and you need to make sure the Cisco Catalyst is the Root Bridge. I believe the Cisco Catalyst sends a Standard BPDU on the Native VLAN, for VLAN 1 (its a bit more complicated than that, but ultimately that's the easiest configuration to achieve). If you do have the Meraki switches between the Catalyst switches then the only real option is to move the Catalysts to MST as has already been said.

Bruce · ‎Oct 8 2021

As @cmr stated, you need an internet connection from your MPLS network - either directly from the network, or by using the MX in VPN concentrator mode at the head-end. Each WAN interface on an MX needs to be able to directly contact the Meraki VPN registry to 'share' its IP addresses and port number; WAN1 won't ever provide WAN2's details to the registry, each has to have its own connection. A document on how AutoVPN works with the VPN registry can be found here if you want to understand it a bit further, https://documentation.meraki.com/MX/Site-to-site_VPN/Meraki_Auto_VPN_-_Configuration_and_Troubleshooting.

Bruce · ‎Oct 7 2021

Great job all, and keep up the good work. Nice one @Brash, keep those posts going!! @PhilipDAth, thanks - you're correct about lockdowns, nothing else to do, that's what I credit the last month worth of posts to. We'll be out of it soon 😀 (then back to the normal number of posts).

Bruce · ‎Oct 4 2021

As has been mentioned, every device in the network needs a license to work. If you don't apply a license for the MS220-8P then you have to remove it from the Network in the Meraki Dashboard. If you don't your Organisation will show that it is out of license compliance, and after 30 days the network will cease to pass traffic.

Bruce · ‎Oct 2 2021

You mention a lot about expected internet bandwidths, but not much about WAN? One of the primary use cases we see with the MX is for SD-WAN. Are you going to be using them for SD-WAN (now or future), or is your use case only for internet perimeter? Do you have a WAN at the moment, is it MPLS-based, could you make savings moving to SD-WAN? At the end of the day, as everyone else has said I wouldn’t be skimping on the MX sizing. I’d be very reluctant to use an MX68 or MX75 for a site of 500 users (I also find it hard to believe 500 users could only require ~150Mbps of bandwidth (but I don’t know your use case). Think carefully about your traffic flows and where your VLAN Layer 3 interfaces are. Although some of the figures in the sizing guide may be applicable to only traffic heading out the WAN port (e.g. Max throughput with all security features enabled), others will have an impact on inter-VLAN traffic if your Layer 3 interfaces are hosted on the MX (e.g. Max stateful (L3) firewall throughput in NAT mode). The other parameters which will impact performance, and which Meraki don’t provide figures around, is the number of concurrent sessions across the device, and the rate that these are established and torn down. This is in line with the ‘simple’ approach Meraki uses, and I’d imagine is encompassed in the recommended client count. I’d suggest making use of the free trial gear through your local Meraki rep if you can, and do some performance testing to make sure you get the right size - in this instance it will be the only way to be sure.

Bruce · ‎Sep 30 2021

I don't think you'll get this working - there are other posts with the same issue on the community. In addition, the Configuring DHCP relay document for the MX, https://documentation.meraki.com/MX/DHCP/Configuring_DHCP_Relay, has this note about half way down: "Note: The DHCP server configured must be in a subnet configured on the MX, including directly-connected VLANs, static routes, and subnets participating in AutoVPN. DHCP servers sitting behind a 3rd-party VPN peer are not supported." EDIT: Also, https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Configuring_DHCP_Services_on_the_MX_and_MS states "Note: On an MX, the DHCP server cannot be over a 3rd party VPN peer connection."

Bruce · ‎Sep 30 2021

I would guess that the MX appliances and the MR access points do a lot of their packet processing in CPU, due to the nature of what they do, and so limiting/shaping traffic is just part of the software. On the other-hand a lot of what switches do is performed in hardware/ASICs, which is a trade-off in flexibility for performance. I'm guessing that the ASICs in the switches can't do the limiting/shaping, and doing it in software on the CPU would likely cripple the switches. So I doubt you will ever see that capability in the traditional Meraki switches (in the MS390, who knows, that's a different beast). (The throughput on even the most expensive MX is only 6Gbps, and on a the fastest MR is not going to exceed 10Gbps, whereas a small 24 port MS210 potentially needs to push 56Gbps (plus another 80Gbps for stacking) - hence why its done in ASICs, and thus limits the flexibility).

Bruce · ‎Sep 30 2021

Tough one to prove conclusively unless you can inject latency into one of the links. That said, the page you need is: Security & SD-WAN -> VPN Status, which shows the link being chosen for each flow - whether its the primary link, the only link, or its being chosen on basis of performance. Then click on one of the peers on this table (which is on the above page): And it will take you two a page showing all the latency, jitter and loss metrics for the links to/from that site. This should show that the MX is monitoring the links. As I said, causing a failover needs you to then be able to introduce latency, and then you can show that the chosen link changes from the VPN Status page.

Bruce · ‎Sep 30 2021

I would question if you really need to be running concentrators with your Meraki wireless solution. There are reasons to use a concentrator, but normally I'd suggest that you look at bridge mode on the SSID and drop the traffic straight onto the local LAN and then route it from there. If you do need to use concentrators, then you can't really just add two more MX450 in a new data centre and make them a redundant 'cluster'. The MX appliances operate in a high availability (HA) mode as a pair, and only as a pair. In concentrator mode (which is the same a passthrough in the Dashboard configuration) the two HA MXs each have their own IP address, but also have a shared IP address which only the active concentrator 'owns'. All the traffic from the APs goes back and forth to the shared IP address. If you want to do failover between data centres you have to create a Layer 2 link between the two MXs (which will be in separate data centres), and also use a mechanism to ensure the Layer 3 interface for the VLANs that are coming from the APs (which are dropped onto the wire by the concentrator) is in the correct data centre too - this could be something like VRRP or HSRP on your core. You'd need to work through the design of this, and the failover scenarios to make sure it works as expected. At the end of the day you end up with two HA pairs - whether both are active in DC A and failover to DC B, or whether one is active in DC A and fails over to DC B, and vice versa, is part of the design. As has been said by many though, an SSID in a network can only use a single HA concentrator pair, and hence why you need to split the HA pair between the data centre. For each campus though, which I assume is a separate Meraki network, you can specify a different concentrator for the same SSID. So Campuses 1,2 and 3 could use HA Concentrator pair I, and Campuses 4 and 5 could use HA Concentrator pair II. When you add the new MX450s they have to be in the same Meraki Organisation (otherwise you won't be able to select them as a concentrator for the wireless access points). But they will have to be in a separate Meraki Network to the existing concentrators. A Meraki Network can only have one MX appliance (concentrator) or two if they are configured as an HA pair. You've got a bit of design work to do to get it working properly, and key to it will be getting the Layer 2 link between the data centres in place, so the MXs in each DC can 'talk' to the other half of their HA pair.

Bruce · ‎Sep 29 2021

@thomasthomsen when you use the Group Policy ACL its enforced on the switch, it uses the capability of the MS devices ACL mechanism and dynamically applies the policy in the Group Policy to that port - its just like any other ACL that you apply on the switch. Remember its only the Layer 3 policy in the Group Policy that is applied (and that's because the MS only does ACLs). EDIT: Should mention, check the models its supported on too - its not supported on all models. Newer models, MS210 and up only (except MS390). So no support on MS220 or MS120 switches.

Bruce · ‎Sep 29 2021

There is no way to enforce traffic shaping on switch ports. If you've got an MX then you can do it upstream on the MX by applying a Group Policy to a VLAN for example, but that's your only real option (obviously upstream appliances from other vendors could potentially do the job too).

Bruce · ‎Sep 29 2021

@PhilipDAth, you're correct that was the case, but now your can apply the Layer 3 ACLs from a Group Policy to a MS port with 802.1x. You return the name of the Group Policy in the Filter-ID in the RADIUS response. Needs the MS14 firmware though. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_and_Applying_Group_Policies

Bruce · ‎Sep 29 2021

I’ve never tried to, but I’ve also never seen anything that says you can. What are you trying to achieve? Can you use Group Policy ACLs to lock the port down?

Bruce · ‎Sep 24 2021

If you’re not using the USB cellular (or inbuilt cellular on an MX67C or MX68CW), then you can contact support and request that they make the Cellular firewall rules apply to WAN2. Then you can put in additional rules for when WAN2 is active.

Bruce · ‎Sep 23 2021

You’d have to make LAN1 your first preference (and move the MPLS to here if you want that to be your preferred path), then WAN1, and finally WAN2. As the link @ww provided shows, a static route supersedes both AutoVPN and the default WAN (NAT) route. So if you create a default route (0.0.0.0/0) with a gateway (next-hop) of the IP address accessible via LAN1 (i.e. the MPLS network), and set it to active only when the next-hop responds (you could also use a setting in the destination subnet). So all the time that route is active traffic will go via the MPLS (on LAN1), if it fails traffic will revert to using the WAN ports. This only works if there is not a more specific route via the AutoVPN (if there is you’ll need to create statics for those more specific routes via LAN1 too - unfortunately it takes away some of the simplicity of the Meraki solution). You can also try using the source-based default routes to achieve a similar outcome of setting a default route via the MPLS if it’s attached to LAN1.

About Bruce

Bruce

Community Record

Badges