Meraki

GreenMan · ‎Oct 27 2020

Yes - changes made in a Template are automatically pushed to all Networks bound to that Template. Bear this in mind, when organizing your Dashboard; where might you need to test a planned change, in a limited way, before you push that change to all sites...? There are, however, a number of settings that cannot be locally overridden. It should become obvious to you what these are, by loooking at 'Configure' on a Network bound to a Template. https://documentation.meraki.com/General_Administration/Templates_and_Config_Sync/Managing_Multiple_Networks_with_Configuration_Templates#Local_Overrides What do you need to change, per Network? Remember there are essentially no limits to the number of Templates you can use. If something needs to be locally over-ridden for a subset of sites - maybe you need more than one Template? If Templates are ultimately not flexible enough for you, that's where the Dashboard API comes in, for automating changes at scale.

GreenMan · ‎Oct 27 2020

There are so many variables in getting a 'good' wireless connection, that such issues are particularly hard to troubleshoot in the Community. And remember; your Meraki licensing entitles you to use Meraki Support 24x7, 365 days a year. Be prepared to gather quite a lot of information, to enable the Network Support Engineer to assist you with the troubleshooting. Worth remembering too - MR18 was announced for End of Sale in 2016 and that 802.11n tech is relatively old, these days. Meraki will continue to support MR18 til early 2024, but can't fundamentally update its underlying capacity. With the maturing of WiFi6, perhaps it's time to start thinking about an upgrade? Anyway - see what Support makes of it first. Good luck!

GreenMan · ‎Oct 27 2020

Could I suggest you log a case with Meraki Support?

GreenMan · ‎Oct 27 2020

By default the branches (spokes) will learn the routes for all the other branches (though it doesn't actually use OSPF to achieve that - they would still be able to reach them, even with OSPF disabled). It is possible to have Support configure a back-end setting to prevent spokes from learning about subnets at other spokes, if you so wish - in some large solutions, this saves resources on the 'smaller' MX models. bear in mind - even with that configured, if you advertised a supernet which included all your branch subnets, from the vMX Hub, each spoke would still be able to reach other spoke. You can indeed filter the traffic flowing over the AutoVPN tunnels though, even if the routes are available, using VPN firewall rules, configured under Security appliance > Configure > Site-to-site VPN https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-site_VPN_Firewall_Rule_Behavior Remember too, when using OSPF - it's a one-way street; the Spokes do not automatically learn what subnets you're using for your services, within the cloud DC. You have to configure those as Local networks at the Hub.

GreenMan · ‎Oct 27 2020

If you are relaying DHCP requests to another DHCP server, the MX is then effectively not handling DHCP for that VLAN, so I would not expect to see details for that subnet on the MX. If you require such details, I would look on the DHCP server you are actually relaying to.

GreenMan · ‎Oct 26 2020

If I'm interpreting this correctly, this will have been instigated by a change in the Meraki setup by your own Organization admins. I would suggest you contact your own people prior to speaking with Meraki Support.

GreenMan · ‎Oct 26 2020

With static routes, you can point traffic at any destination you require, not just another VLAN on the same L3 switch. Many customers require just a handful of (summary) routes, which they can ppoint at their WAN CPE or Internet firewall. If the next-hop address is provided using VRRP or HSRP, you can have a degree of dynamic resilience too. It might not address every possible need - but it will be good enough for lots of deployments.

GreenMan · ‎Oct 26 2020

I'm not 100% certain, but I think it likely that the cellular IP is a dynamic IP (probably an RFC1918 one) allocated by the mobile carrier to the mobile data link itself, which will then be (Carrier Grade) NATed to a general public IP, unless you order an appropriate data plan for your SIM.

GreenMan · ‎Oct 24 2020

No... This is from the MG21 Dashboard settings documentation: "The MG is only supported in routed mode. It acts as a layer 3 gateway between the subnets configured below. Client traffic to the Internet is translated (NATed) so that its source IP becomes the uplink of the cellular gateway." https://documentation.meraki.com/MG/MG_Wireless_WAN_Dashboard_Settings

GreenMan · ‎Oct 23 2020

You will need to line up the mobile data connection for that MX via wired uplink, beforehand. It's not possible to do ZTP via LTE connection only. The modem in that MX supports up to 300 Mbps, I believe, with the very best of coverage etc. In practise the chances are you may not get that, but I gather the limiting factor is often the capability / flexibility of the carrier's infrastructure to support all the relevant standards. If you need VPN to work, this can be limited/prevented by carrier grade NAT implemented on the carrier's network; a SIM designed for a data-specific plan is usually the best approach.

GreenMan · ‎Oct 23 2020

Almost... You have to tell AWS what traffic to send to the vMX: all the IP subnets that you want to be able to access your AWS resources, at the sites on the other end of the AutoVPN tunnels. You don't want all your AWS traffic going out through the vMX - it will be a one-armed VPN Concentrator, not a firewall to protect your AWS instance. Of course, those subnets might still mean all the traffic...

GreenMan · ‎Oct 23 2020

Are you using AutoVPN on your MX?

GreenMan · ‎Oct 23 2020

Use a dot1Q trunk from your L3 stack to your perimeter router, carrying two VLANs; one purely for management of the L3 switches, the other as a transit for all other traffic routing through/by the L3 stack.

GreenMan · ‎Oct 23 2020

key point, to add to what has already been said: MXs do not participate in Spanning Tree, beyond simply forwarding BPDUs within the same broadcast domain; any loops you create must be resolved by the switching, so think very carefully about the loops you are creating, where the root bridge lies and what links are going to be discarding. https://documentation.meraki.com/MX/Networks_and_Routing/MX_Layer_2_Functionality#MX_Handling_of_Multicast_Traffic

GreenMan · ‎Oct 23 2020

It's already available, via API - check out this section of the documentation: https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Network_Objects_Configuration_Guide#API

GreenMan · ‎Oct 23 2020

This is indeed almost certainly caused by iOS 14. I'd start by having a read here: https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Meraki_and_iOS_14_MAC_Address_Randomization Note the reference that under certain circumstances, iOS 14 is sending a malformed ARP response that carries the HW MAC address instead of the Randomized MAC address it should instead be using. Basically you're asking that the networking system, which didn't cause the problem, guesses what is causing two different clients to claim the same IP address. You could consider managing iOS clients with Systems Manager, which allows wireless profiles to be configured to turn off the randomization behaviour, but I realise this in unrealistic in many use cases.

GreenMan · ‎Oct 23 2020

Yes - don't do that: "Avoid configuring a L3 interface for the management vlan." You can only serve DHCP if you have configured a L3 interface. Try using a different management VLAN for all the downstream devices (for which you can serve DHCP) - with a dedicated VLAN for management of the routing switches.

GreenMan · ‎Oct 23 2020

Well... what benefits were you hoping to get from using BGP? Also: I missed the reference to Direct Connect. I must admit; I’m not massively familiar with it, but I understand it’s a dedicated link between your site and an AWS DC. AWS pushes the pros here: https://aws.amazon.com/directconnect/ but it will probably have all the usual pros and cons associated with something ‘dedicated’ - It will probably be more expensive (you’ll need to run the numbers for your scenario though) but maybe more dependable - and how will it scale, if you need to connect more locations to your AWS instance?

GreenMan · ‎Oct 23 2020

You need to explain what you are looking to do more fully, to answer this but... BGP is always route specific - it’s a dynamic routing protocol. It exchanges information with other BGP routers. Load balancing does not handle routes - in the MX implementation it knows there are potentially two paths available for certain outbound traffic flows: via WAN1, or via WAN2. (In pure routing terms, there are two equal cost routes & they are not learned from anywhere else). It can allocate flows to each, based on how you configure it. Because MX NATs outbound traffic, the return traffic uses the same WAN link.

GreenMan · ‎Oct 22 2020

Are you sure the destination for the video session resolved to an address within the VPN? Are you also sure the client accessing the resource was in a subnet defined within the VPN? (Packet capture over the Site-to-site VPN should help with that)

GreenMan · ‎Oct 22 2020

The way I see it, customers who are going to be interested in MT sensors for their server / comms rooms are going want to monitor those locations with at least one camera. That / those camera(s) are then also their BLE gateways. Everyone's happy (?)

GreenMan · ‎Oct 22 2020

If you have a site with an MX acting basically as a firewall/UTM + you have two WAN links and you want to share Internet-bound traffic across them, use load balancing configured in Security appliance > Configure > SD-WAN & traffic shaping: https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Load_Balancing_and_Flow_Preferences#Load_Balancing If you add no other configuration (indicating preferences of which specific WAN links you want identified traffic streams to take) flows will be allocated based upon the bandwidths you configure for each WAN uplink. If VPN of some kind is involved, it gets a bit more exciting

GreenMan · ‎Oct 22 2020

The BGP available from Meraki MX may not be what you're thinking it is. E.g. you can't hook up an MX to an Internet link and simply learn the Internet routing table (or a subset thereof, controlled by the eBGP peer). Instead BGP is used only to exchange routes in and out of Meraki AutoVPN. It's basically used in the Data Centre, to allow the branch SD-WAN to let the DC know which sites / subnets are reached via a particular Hub MX. It also allows a new service to be deployed in the DC and made readily reachable by all the branches on the SD-WAN. Of course, the fact that it performs peer monitoring and provides dynamic updates also offers other benefits, in terms of solution resilience. If you want to do very clever route manipulation, you are likely to need to implement this within the upstream eBGP routers, with which the Hub MXs are peering. https://documentation.meraki.com/MX/Networks_and_Routing/BGP

GreenMan · ‎Oct 22 2020

If you use vMX in your AWS instance, the VPN between the two is Meraki <-> Meraki AutoVPN, so it's much easier to configure. It will also build overlay tunnels across both WAN uplinks from the branch MXs (spokes) - if the branch MXs have two. The MXs now closely monitor the performance of both these end-to-end paths (packet loss, latency and jitter). As well as load balancing, you can then also make use of SD-WAN policy and performance rules to manage traffic across those two available paths - this includes the ability to fail over specific applications between the paths, if the monitored performance doesn't meet the criteria you configure for them. The non-Meraki VPN to any other IPSec device virtualised at your cloud provider provides a secure tunnel connecting the two and not that much else.

GreenMan · ‎Oct 22 2020

@ww is spot on. If you want to filter traffic passing over AutoVPN, you'll need VPN firewall rules, configured under Security appliance > Configure > Site-to-site VPN. https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-site_VPN_Settings#VPN_Firewall_Rules https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-site_VPN_Firewall_Rule_Behavior

About GreenMan

GreenMan

Community Record

Badges