Possibly a faulty controller? Let us know how you go. ... View more

BPDUs are never sent untagged. It must have a VLAN-ID. So then yes, you must tag on the non-meraki switch Trunk ports. Which is more manual work to do and get working, and a pain to tshoot..  You don't have to use Option a. You mention the non-meraki switches can run MST. If you run the same Spanning Tree Protocol across all switches. Then it's very easy to design and tshoot.  Here is the rest of the quote: "MS series switches to participate in spanning tree a spanning tree instance must be running on VLAN 1 of all switches and VLAN 1 is allowed on all trunk ports running PVST+ so that BPDUs are seen by the Meraki switches in the topology." ... View more

"47.2W for each APs." 40Watts is the Maximum for the MR57. Did you mean 47.2 Volts? https://documentation.meraki.com/MR/MR_Overview_and_Specifications/MR57_Datasheet#Specifications Judging from that Screenshot; perhaps Spanning Tree could be shutting ports??? That would make sense if configured in 'Power Sharing' mode'.  As you have an Agg/Port Channel configured. Make sure it is configured correctly and matching on both the switch and MR57. See below details. https://documentation.meraki.com/MR/MR_Overview_and_Specifications/MR57_Dual_Uplink_High_Availability#Prerequisites ... View more

Hi @allywenzel , I do see this type of situation often. Usally something changes to cause this.  That log "stp_tcn_error" 'Topology Change Notification". Meaning the Layer 2 path or Spanning Tree is changing where all traffic should go. Most of the time, someone plugged in something. Or in your case, most likley a cable or device is misbehaving. As @RaphaelL reccomended, check you RSTP Root and make sure it is it is in fact the Root. Use the following guides to assist in the investigating and mitigation.    https://documentation.meraki.com/MS/Monitoring_and_Reporting/Loop_and_MAC_Flap_Detection_on_MS   https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/General_MS_Best_Practices       ... View more

For beginners, there is a Getting Started with Cisco Meraki webinar scheduled for Thursday 12/12 at 9:00am PST.   ... View more

Oh damn, of course, you are right. It is even clearly described in the link I added, but I messed that up. Thanks for the correction. ... View more

Hi @carlto , This might interest you 😉 "BGP peering over IPsec VPN tunnels can be enabled on the Meraki Security Appliance. This unlocks new dynamic routing use cases for customers in addition to enabling resiliency and redundancy over IPsec VPN peers. "   https://documentation.meraki.com/MX/Site-to-site_VPN/BGP_routing_over_IPsec_VPN         ... View more

Did you get a resolution to this? Having the same issue and interested to know if you found anything. ... View more

During the recent CrowdStrike incident, I had a customer use the Microsoft-provided PXE server and image to remotely recover machines.  Below is a mock-up (IP addresses made up) of what it looked like.  We put the Microsoft PXE boot server in their data centre, and the machines were recovered over SD-WAN.     I can also tell you that while this worked for a high percentage of their machines, we had a single digit percentage that would not PXE boot (they would start and then fail), which we put down to BIOS bugs. ... View more

PS: And this is not for "certificate based authentication" as the document you are pointing to, but "Server certificates" on the MX itself, for the initial connection : https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance#Server_Certificates ... View more

Hi @SysOP , Do you perhaps have RADIUS VLAN Override configured on that SSID? if so, what does ISE see when this issue occurs? https://documentation.meraki.com/MR/Access_Control/MR_Meraki_RADIUS_2.0#RADIUS_VLAN_Override ... View more

Yes, it's possible to implement a device policy where new devices are blocked by default and then manually allowed or set to normal access. This is a common approach to ensure that only authorized devices have access to the network while maintaining control over policy exceptions. Here's how you can achieve this: Create a Default Policy: Set up a default policy that blocks all new devices. This policy should apply to all devices that connect to the network initially. Add Allow/Normal Policies: Create specific policies that allow or grant normal access to devices that are manually approved. These policies should be applied to the devices you want to grant access to. Apply and Monitor: Apply these policies and monitor the network to ensure that new devices are initially blocked and only the approved devices have the desired access. General Steps: Set Default Block Policy: Configure the default policy to block any device that connects to the wireless network. Manually Adjust Policies: Once a device is identified and verified, manually change its policy to allow or normal access. Verify: Ensure the policies are working as intended by testing with new devices and checking access permissions. This approach ensures that anySonic Happy Hour new device will not have network access until it is explicitly allowed. The exact configuration steps will depend on the wireless controller or network management system you are using, so consult your device's documentation for specific instructions.   ... View more

Hi @JordanCN , This would be a web browser cookie situation, I've tested this many times. Here is how I resolved this. 1.) Go to the Dashboard page you prefer. Note the time/date. 2.) Logout of the Dashboard. 3.) In you broswer history. Delete all entries of the Dashboard. EXCEPT the page preference... NB, you might need to add a column to see time/date that page was visted. 4.) enjoy... 😀   ... View more

If you capture on the MX LAN side you should have each packet twice in the capture. Once with the source MAC address of the device in VLAN 60 and the MX as destination.  And the second time with the MAC address of the MX as source and the windows/printer device in VLAN 70.  If you see those packets twice, then the MX is forwarding correctly and you are experiencing issues on the switched network or on the end hosts. ... View more

Hey there! In general, for most capable Layer 2/3 devices. You tag the port with your VLANs, then create virtual interfaces for each VLAN and add the layer 3 IP details; as shown in your examples. However, I am not certain about FirePower configurations. It's best to refer to the configuration guides or reach out to their support team for assistance. The Meraki Switch shouldn't be a problem as long as the port configurations are correct. ... View more

Out of curiosity @Ryan_Miles , let's say we remove the account altogether and they have access to multiple Organizations. Do we assume that we need to re-invite that account to each Org? ... View more

I've had a few issues with PoE devices not getting power on 355s.  Mainly older devices where the CDP or LLDP information doesn't exist or doesn't come through properly.  The newer firmwares have been dealing with this, what version are you running? ... View more

Thanks for sharing your experience! They've tried with a long fiber and the switches seem to be not recognizing the GBICs on the stack ports... Those MS355 switches will connect to an ACI Spine Layer 2 switch, so they can't make the redundancy any other way on Layer 3. ... View more

  If it is happening Inbound too. Then that would mean that the problem is 'No Voice Path'. I.e. RTP/Audio streams. This is mostly due to a problem with signalling or due to Firewall/NAT/Port Forward issues.   Check the Voice Platform for indications of signalling problems. Check the configuration of firewall, switch, routers etc on the voice path. If you only have 2 VLANs, you might want to use 1 VLAN for Data and the other for ALL VoIP related traffic. Of course, always consult the Vendor's Platform guide. See below Meraki guide for common tips.   https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/VoIP_on_Cisco_Meraki%3A_F.A.Q._and_Troubleshooting_Tips#Internal_Notes_-_Additional_VoIP_Troubleshooting_FAQs   And remember, Packet Captures are your best friend. 😁 ... View more

Hi @rhamersley , As @thaack mentioned, Group Policy is the way to go for seperation and security. However, if you are finding that they are not enough IP address being assigend. You can simply expand the subnet range. E.g. 192.168.1.0/22 would give you 1022 IPs to use.  ... View more

Thanks so much 🙂 ... View more

Hi @db3 , If your goal is to block IP/Subnets, there are a few ways this can be achieved. This does depend on your design though. E.g. Enabling a Group Policy to block traffic is a great way.   https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/MR_Firewall_Rules       ... View more

Hi @Martinsen , As @PhilipDAth  has mentioned. The best option is to check the local status page on the switch. If all ok, then factory reset them. ... View more

No problem at all @van604 ... It is fairly new feature and sometimes I forget it is there. But when I do remember, it saves me a lot of time, going through pcaps & logs. ... View more