Meraki

alemabrahao

Yes, you can use it. There are all documents that you need to understand about access manager. https://documentation.meraki.com/Platform_Management/Access_Manager

alemabrahao

The guide that the @RWelch sent you doesn't mean you have to integrate with Zscaler, but rather how you should configure the tunnel to achieve what you need.

alemabrahao

Only full, explicit MAC addresses are supported. MR MQTT Data Streaming - Cisco Meraki Documentation

alemabrahao

The risk is that without STP intervention, you have two active Layer 2 paths between the same devices, and the MX will happily forward frames between them, creating a loop that STP cannot detect. That's all for today. 😉

alemabrahao

Yes, access ports also send BPDUs (because STP runs on all switch ports by default). So in your scenario, The access port sends BPDUs for the single spanning-tree instance, the trunk port also sends BPDUs for the same instance, the MX doesn’t process them, it just forwards them like normal frames if both ports are in the same bridge domain and the VLAN carrying those BPDUs is allowed on both links. When the switch receives its own BPDU back on the other port, RSTP detects a loop and will block one of the two ports (usually the one with the higher port ID or cost). This is because STP doesn’t care about VLAN separation here, it’s one topology for all VLANs. So the only way STP does not block is if, the access VLAN is not allowed on the trunk, BPDUs never loop back, STP sees no loop, both ports stay forwarding. If the access VLAN is allowed on the trunk, the MX forwards BPDUs, STP sees a loop, blocks one port. If the trunk includes the access VLAN, RSTP will block one port. If the trunk excludes the access VLAN, STP won’t see the loop and both ports will forward (which is risky).

alemabrahao

MX does not process or generate BPDUs. If the MX receives a BPDU on one port, it treats it as normal Layer 2 traffic and forwards it out other ports in the same bridge domain (unless the MX is in routed mode and the VLANs are isolated). So yes, if the access VLAN is allowed on the trunk, the MX will forward those BPDUs between the trunk and access port.

alemabrahao

It will not be blocked. There are a few things that can be done to prevent this from occurring: Avoid connecting more than two switches in the same STP domain directly to the LAN of the MX Isolate the MX in its own broadcast domain by implementing Layer 3 switching downstream The STP Root Bridge doesn't generate TCNs to notify of topology changes, only the non-root switches do. This can cause longer failover and STP convergence times and should be considered when setting up the root bridge and/or redundant links in the environment.

alemabrahao

Not necessarily; you can have multiple MX ports connected to the same switch and they won't be blocked. Note: The MX does not run STP in any capacity, and will not exchange BPDUs with other switches or participate in the root bridge election process. If the MX received BPDUs on the LAN, these BPDUs will be re-forwarded within the broadcast domain that they were received on. If there are multiple switches connected to the LAN of the MX participating in an STP election, all BPDUs sent to the MX will be forwarded to other links with the same VLAN allowed, which can cause switches to see BPDUs from multiple other switches, causing ports to get into an unknown/unidentifiable state and impacting the root bridge election process. Below is a diagram illustrating how the STP election process can be affected by this MX LAN forwarding behavior - when 3+ switches are connected in the same broadcast domain, each switch will receive BPDUs from 2 or more switches on their connected uplinks. In the case of switches 2 and 3, the uplink is both a root port and a designated port from the switches' perspectives, causing the ports to go into an unknown state. In practice, this can also result in rapid STP port status changes for uplinks on multiple switches. https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Networks_and_Routing/MX_Layer_2_Functionality

alemabrahao

To be honest, I'm aware of those possibilities, but I haven't considered them because I haven't had time to test them yet.

alemabrahao

If you try to connect another device to the same network, will it receive an IP address? If you configure an MX port and set the access mode to VLAN 40, will the device receive an IP address?

alemabrahao

Is the MX the gateway for all networks or is it the switch? If it's the switch, you need to configure the IP helper address.

alemabrahao

No, there are no particular settings for the printer. And what about the port connected to the MX, how is it configured? Is the MX the gateway for all networks or is it the switch? If it's the switch, you need to configure the IP helper address. You're probably forgetting some very small detail.

alemabrahao

You mentioned having a dedicated VLAN but not receiving an IP address. Did you correctly tag the VLAN on both the switch port and the SSID? Is it possible to share the configuration?

alemabrahao

Meraki uses the Captive Network Assistant behavior built into operating systems like Android, iOS, and Windows. When a device connects to Wi-Fi, the OS tries to verify Internet connectivity by reaching specific endpoints (e.g., connectivitycheck.gstatic.com for Android). If those checks fail, the OS assumes the network is “captive” and triggers the splash page popup. So yes, the captive portal can appear even without Internet access.

alemabrahao

Please refer the documentation.

alemabrahao

Go to Switch > Switch ports in the Meraki dashboard, select ports 49 and 50, click split. https://documentation.meraki.com/Switching/MS_-_Switches/Design_and_Configure/Configuration_Guides/Port_and_VLAN_Configuration/Switch_Ports#Splitting_Aggregated_ports

alemabrahao

Between sites A and B, you have configured a non-Meraki VPN or an Auto VPN. If it's an Auto VPN, you only need to advertise the networks, and site C will automatically receive the routes. However, if it's a non-Meraki VPN, you need to configure a tunnel with site C, because non-Meraki VPNs don't participate in SD-WAN.

alemabrahao

I can only think of two ways. 1 - Create some kind of automation via API. 2 - Use a router or other firewall in conjunction with the MX since this type of configuration is not possible.

alemabrahao

Nothing in particular. https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Operate_and_Maintain/Monitoring_and_Reporting/Syslog_Server_Overview_and_Configuration https://n8n.io/integrations/cisco-meraki/and/qradar/ https://www.ibm.com/docs/en/dsm?topic=management-adding-log-source

alemabrahao

When you set up MFA, didn't you save the backup codes? Unfortunately, without the backup codes you won't be able to access the panel. Try contacting support.

alemabrahao

Good point.

alemabrahao

There really is no limitation on the MX side. In your case, I would check with support to see if it's actually a bug, which I believe it isn't, but rather that something has been overlooked.

alemabrahao

Can you share your configuration please? Another question: is the device directly connected to the MX recorder or is it connected to a switch? Is the correct VLAN properly configured on the port to which the client is connected?

alemabrahao

Do you have an interface on the 17.x.x..x network configured on the MX record? Do you have any firewall rules restricting any type of communication? There are no limitations regarding the use of a specific address block on the MX.

alemabrahao

I suggest you open a support case.

About alemabrahao

alemabrahao

Alessandro Abrahao

Community Record

Badges