Meraki

GreenMan · ‎Oct 2 2023

Suponiendo que haya configurado la regla correctamente en Security & SD-WAN > Site-to-site VPN supongo que había un flujo activo establecido que coincidía con esta regla. El cambio de regla solo comenzará a aplicarse una vez que el flujo activo se elimine de la tabla MX. Si necesita realizar una prueba de inmediato y puede permitirse el tiempo de inactividad, reinicie el MX para verificar.

GreenMan · ‎Oct 2 2023

Run this endpoint against any Network returning "VLANs are not enabled....." https://developer.cisco.com/meraki/api-v1/get-network-appliance-single-lan/

GreenMan · ‎Sep 29 2023

I'm afraid I don't know the answer to this Q, but posting it in the Mobile Device Management forum would have helped make it clearer hat you were asking about, Meraki-wise: https://community.meraki.com/t5/Mobile-Device-Management/bd-p/enterprise-mobility-management

GreenMan · ‎Sep 29 2023

If I remember rightly, you can deploy multiple overlapping profiles, in which case the most restrictive setting is applied.

GreenMan · ‎Sep 29 2023

I'm wondering if you maybe didn't get the right license to match the device you have. For wireless APs, each model uses the same license LIC-ENT (you just choose the duration 1, 3, 5, 7 or10). But MX or MS to some degree depends on the model of appliance or switch you buy. E.g. a 24-port license is no good if you have a 48-port switch. As ww said, the Organization > License info page should tell you Or maybe you have insufficient license quantities? You need one license per device

GreenMan · ‎Sep 29 2023

If you look for Meraki config and restore in GitHub, there are a bunch of scripts available there covering this area. If you're after something slicker, less DIY and more structured (but chargeable), there are a number of Meraki Ecosystem partners who cover this kind of API-based automation. These are two I've seen 'in passing', but they're not alone in the Network Automation area of the Ecosystem website: https://apps.meraki.io/en-US/apps/380757/boundless-%7C-automation https://apps.meraki.io/en-US/apps/394857/dna-assure

GreenMan · ‎Sep 27 2023

I believe the question was about the uplink data rate provided, rather than the PoE level (?) There would be nothing stopping a client associating at the high data rates, on an AP uplinked at just 1 Gbps and they will likely not see too much difference in performance (they're going to have to be right under the AP, with an expensive/powerful device to get them anyay). You're much more likely to have uplink bandwidth concerns if you have loads of clients connected to the same AP, even if they're not connected at the very highest data rates - but they are generating a lot of traffic. In such instances though, you may well hit channel availability issues before you hit the 1 Gbps ceiling.

GreenMan · ‎Sep 27 2023

Wired connection - simple? Really...? Also: think about battery consumption - BLE was chosen for a reason

GreenMan · ‎Sep 22 2023

Esto puede variar ampliamente y estará dictado principalmente por el entorno (qué obstrucciones hay, etc.) Las paredes, por ejemplo, atenuarán y reflejarán las señales, y en diferentes niveles, dependiendo de los materiales utilizados. Una serie de otros factores locales también cambiarán la potencia de transmisión aplicada por las radios de los puntos de acceso, por ejemplo, para evitar interferencias con otros transmisores en la misma frecuencia. Realmente deberías tener un sitio realizado. Este tipo de cosas se analizan con más detalle aquí: https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MR_Wireless

GreenMan · ‎Sep 22 2023

OK so, with no more Catalyst switches in the LAN, you will be employing just RSTP 👍 Just follow the general recommendations for configuing STP on Meraki switches - in particular make sure your MS425 stack is your root bridge

GreenMan · ‎Sep 22 2023

Assuming your MS425 units are co-located, stacking cables would be MA-CBL-40G-1M (1 metre version). -50CM or -3M versions are also available. https://meraki.cisco.com/wp-content/uploads/2020/05/meraki_datasheet_sfp.pdf If they are more widely separated (unlikely, if you're replacing a sigle chassis), look at using Flexible Stacking, via fibre links: https://documentation.meraki.com/MS/Stacking/Switch_Stacks#Understanding_Flexible_Stacking You should look into using OSPF as an alternative dynamic routing protocol, supported by the MS425s (and the 355s, if you need to route on those too). You will need to look into what other routers / layer-3 switches the 4500 is currently exchanging routes with using EIGRP and possibly transition them to OSPF too. Likewise any other routers, beyond, in the same EIGRP setup. I'd also check whether a full routing protocol is really needed. Often, if you're on the periphery of a larger network you can achieve similar outcomes using (say) a static route or routes to a virtual IP address (a pair of routers running HSRP / VRRP, for example). Not sure what else you may have, switching-wise, downstream of the 4500, by way of access switches, but you will want to check out the Spanning Tree setup; MS switches do not support the proprietary PVST / PVST+ that Catalyst switches are usually running. https://documentation.meraki.com/MS/Meraki_Campus_LAN%3B_Planning%2C_Design_Guidelines_and_Best_Practices#STP_in_a_Hybrid_LAN I'd recommend you hook up with an experienced Cisco Partner to help you with this project.

GreenMan · ‎Sep 22 2023

Assuming the spokes are connected to a common virtual MX in the same Umbrella DC you can consider it that Umbrella itself is not decrypting the traffic. The vMX will effectively doing this, I suspect, when flipping between the two tunnels

GreenMan · ‎Sep 21 2023

vMX-L for Azure is in the works, but not currently readily accessible. Contact your Meraki account team, to see if they can get you onto the closed beta. In the meantime, n x VMX-M if you need a scaled production environment now.

GreenMan · ‎Sep 21 2023

Did you raise a case with Meraki Support?

GreenMan · ‎Sep 20 2023

Por profiles don't apply to MR76 - see here: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Port_Profiles#Applying_profiles_to_APs_with_2_ports It is possible though, in principle, to extend wired LANs across a Meraki MR-based wireless link, in roughly the way you want. You will want to read this thoroughly, if you haven't already: https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link You'll note that port profiles are not used as part of this setup.

GreenMan · ‎Sep 20 2023

To my knowledge there are no API endpoints for this, currently

GreenMan · ‎Sep 19 2023

Many clients seem to do strange things, when 11v process happens (this changed significantly with MR29, on the Meraki side). Many environments work more reliably with client balancing disabled, for this reason, it seems. (Hence net new Meraki setups have it disabled by default). Maybe try with balancing enabled, but be prepared to switch off if you see issues of this type.

GreenMan · ‎Sep 19 2023

If you don't use vMX, you'll be using non-Meraki VPN, which is a whole load less functional and more difficult to build resilience

GreenMan · ‎Sep 19 2023

As mentioned before, I think you need "no hub to hub" to be enabled

GreenMan · ‎Sep 19 2023

Are you using vMX in Azure for this? (Definitely recommended!)

GreenMan · ‎Sep 16 2023

As per the previous comments, if you set a VLAN ID within the management config of an AP, it will always send the resulting management traffic with that 802.1Q tag. If you have the same VLAN configured as the native VLAN on the switch port, to which the AP is attached, you should remove the VLAN ID in the AP management configuration. The AP will then send untagged and the switch will process that traffic within the native VLAN.

GreenMan · ‎Sep 16 2023

I think you should raise a case with Meraki Suppport, if you didn't already.

GreenMan · ‎Sep 14 2023

I don't believe either of these calls will provide RSTP status. I'm not aware of an endpoint that provides this, actually. In the Dashboard UI, take a look at port 7 on this screenshot , for how RSTP blocked ports appear. Ignore the orange colour, the - sign is the key bit.

GreenMan · ‎Sep 14 2023

I'd recommend you have Meraki Support enable a backend setting known as "no Hub to Hub" on the Organization - and change your (two) client-only sites to be Spokes, connecting (presumably) to both HQ and the Data Centre. I'd also recommend using BGP to exchange routes between the MXs in the DC (I presume these are configured as VPN Concentrators?) and your upstream router / L3 switch on the LAN side https://documentation.meraki.com/MX/Networks_and_Routing/Border_Gateway_Protocol_(BGP)

GreenMan · ‎Sep 11 2023

I'm interested in why you'd want to do this? Using the API implies a significant scale: lots of MXes configured as Hubs. Given the quantity of tunnels you end up with, with a full mesh of Hubs, for example, these things often don't go well together. If you only have a handful of Hubs (i.e. you use Hub and Spoke setup - which is what's recommended, in order to scale, generally) you'd normally configure each of them through the UI.

About GreenMan

GreenMan

Community Record

Badges