I didn't physically pull the cable out. What I did was shut down both ports, removed one port from the port-channel via "No channel-group" and then no shut that interface. The port then came up and I did learn some mac addresses from the other side, but Mgmt to the Meraki switch never restored.  The core logs clearly indicated they were not receiving LACP. *Aug 27 19:32:19.093: %ETC-5-L3DONTBNDL2: Twe2/0/34 suspended: LACP currently not enabled on the remote port. *Aug 27 19:32:19.974: %ETC-5-L3DONTBNDL2: Twe1/0/34 suspended: LACP currently not enabled on the remote port. Meraki support has come back with there is a bug in version 16.7+ with meraki switches having issues sending LACP when a port comes back up. They recommended we upgrade to 17.1.1.  --Fixed an issue that caused unexpected LACP discarding states after aggregate links were restarted or reconnected   ... View more

Thank you so much for the quick reply and advice! ... View more

Hi Tony,   a) MX port connecting to C9300 in an access Transfer VLAN 10 with 2 IP's MX has 10.105.10.254, C9300 has 10.105.10.253 in a subnet of 10.105.10.252/30. b) there is only one 10G Fiber connection between those 2 devices, configured as an access port on both ends, both in VLAN 10 (transfer net). The C9300 takes care of the management VLAN 20, but either the MX nor the C9300 has a management IP from VLAN 20. With MS250-24 instead of C9300 exactly this config works fine in all other locations. I can ping from MX to C9300, but I can't ping from C9300 to MX and I can't ping to 8.8.8.8, but the C9300 is reachable from the Meraki Cloud and is online. So, I assume there is something different between C9300 and MS250 or other "legacy" Meraki Switches. ... View more

Thanks! ... View more

Righto - after giving up on this and in turn having my support case closed, there is clearly some bug with the MX.   What I failed to mention, was my fibre connection is (was) vlan tagged (10) and every time I attempted to set the interface to DHCP with the vlan tag, the MX would always seem to time out, and take a while to recover. So after configuring up an MX in the office for a customer, I left it on DHCP and boom, its worked with the fibre connection. Odd I thought, had Meraki performed stealth firmware updates? I went home and tried mine again. Nope, same issue. Device would spit the dummy and and not route, although the ISP sees an IP being assigned via DHCP. I then thought there are two differences, one the hardware, and two the VLAN tagging. I asked our ISP to remove VLAN 10, and within moments, DHCP worked and I could reach the internet. Ive had other devices using vlan10 without issues. Odd.   ... View more

This is *probably* way over-simplifying things, but we ended up with a similar situation at a couple sites. The way we handled it was using two unused VLANs to stretch the ISP connection from building A to building B, and vice-versa. Talked to the provider(s) to have them widen the subnet a smidge to handle 2 active devices, set IP's on WAN2 on both devices.   So, we have ISP auto-failover for both buildings, but not warm/spare in the event we lose one of the MX's; The idea being that one of our regional spares could be easily swapped with the 'dead' MX if/when needed. ... View more

The moment you go above 8 meters (26 feet) the signal via normal omni antennas may be insufficient on ground level for your handheld devices to receive.  Downtilt omni's don't cover the same horizontal distance at the same height but they concentrate more signal downwards so your usable signal on ground level covers a greater distance. The lightbulb with hat is a nice representation if that hat reflects the light rays downward to make them brighter. ... View more

Well I'm a little skeptical what an AI can offer who just gets it's information on any other public website 😉 I'm hoping since the MS130X/R series have some sort of advanced ASIC to support Adaptive policy it would also support NBAR at least for fingerprinting traffic. My question originates from the time you could not have non-NBAR and NBAR capable devices on the same network while NBAR was enabled.  Since newer networks are usually combined even MS210's with Wi-Fi 6(E) hardware it still can use NBAR on the Wi-Fi and MX side.  But this would cause inconsistencies in the traffic analytics. ... View more

Hello everyone, Thanks for these instructions. That's it. Tunnel password. I haven't read anything about it anywhere. But that's how it works with iPSK and an encrypted connection and authentication via MAC. Thank you very much! ... View more

Good news, Everyone!   Both articles are now updated!   MS425 Overview and Specifications has a clarification about MTU value in the Dashboard.   Switch Settings has a new and improved MTU Settings section covering all.   Thank you, @RaphaelL ! Yes, I realised that while working in first article. This is why it took me longer than usual to publish updates. ... View more

Hey @GIdenJoe  The MS family datasheet specifies the different "routing capabilities" that each model has and mentions the DHCP relay for said models. Other models add static routes, DHCP server capabilities, dynamic routing, or VRRP. https://meraki.cisco.com/product-collateral/ms-family-datasheet/?file ... View more

I've power cycled the APs and they seem to be holding connections now.   ... View more

From the dashboard just open a new support case asking to roll back network X to firmware y.  If you want to do it urgently, then call them direct, the numbers are on the support page and should also be available from the ticket email you will get. ... View more

Yeah this is the case, i have a MS390 Uplink to another MS390 in a IDF and the UDLD Error always shows on the uplink port for the switch. ... View more

This is where computer authentication comes in. Only accept the certs that have been distributed by your internal CA. ... View more

QoS will only do you any good in cases where you have high channel utilization. As @ConnorL suggests you may have a poor roaming experience.  So if your Wi-Fi is using any kind of enterprise based authentication then 802.11r is a must.  However if it is a simple open or WPA personal kind of network then you could have bad spots in your Wi-Fi where you don't have enough dual AP coverage for handovers between AP's. Keep in mind that it simply can also be a client specific issue.  So testing with multiple clients is a necessity. As far as the QoS goes: - If you can identify the downstream traffic of Wi-Fi calling you can add them to a QoS rule in your dashboard configuration.  Make sure you set layer 3 marking DSCP to EF (expedited forwarding) and if you hopefully are tagging your user traffic with a VLAN tag you must also add the PCP tag of 6 which will add that traffic to the voice queue.   For upstream traffic you can't do anything since it's the clients that have to tag their own traffic before sending it upstream.  So you could only verify this by doing several captures over the air and try to identify the voice packets (which won't be easy). ... View more

I agree.  Essentially I'm blind now if there is an actual problem.  Boss said that he's open to the idea of a GPO to turn off IPv6 but it's a "we'll get to it when we get to it" priority which means likely never. ... View more

This was the reason why I also thought about the C9200's being able to be licensed by subscription licenses. It's in the dcloud demo.   ... View more

You have to make sure your switches have a management VLAN set so you are always sure they will primarily try to get an address on the mgmt VLAN behind the Fortigate.   When that fails for any reason the switches will attempt DHCP on any VLAN which can include the VLAN 501.  If they go online that way everything should still work though but your switches would be in a different VLAN.  If there is something on the second ISP blocking access to dashboard then yes the switches would fail to connect but traffic should still be forwarded.   Also since you have a stack, why don't you create aggregates on your Fortigates? It is best practice to also not cross an ISP over two stackmembers.  So you can either keep both VLAN 500 and 501 ports (should be six in total) on your left switch or have VLAN 500 on switch 1 and 501 on switch 2.  Then if one switch goes down you don't lose both your ISP's. ... View more

As @CoreyDavoll1 already mentioned.  In Meraki you cannot use a management IP on a switch that uses it's own routing table to reach the cloud. You have to see that management IP as being on another VRF.   So basically you have two choices. You can widen your uplink VLAN subnet to the upstream router/firewall to accomodate the extra IP's needed for MGMT.  For example: your L3 switch uses 10.0.0.0/29 as uplink subnet pointing to 10.0.0.1 for it's 0.0.0.0/0 route. and using 10.0.0.2 as routing IP but using 10.0.0.3, or 4 or 5 as MGMT IP. The other option is to have a separate VLAN subnet between your uplink device and your switch to get your MGMT IP's on. ... View more

I'm not sure if this could be a cause but the MX64 is meant for 50 users or below.  You could be running into transient issues because the device is overloaded.   You should also run a pcap to see if your device successfully sends ARP requests and receives ARP replies every few minutes from the MX since ARP entries do timeout after a while even when using a connection actively. ... View more

Normally if you configured your Anyconnect on your MX with using the certificated provided by Meraki, make sure you connect using the dynamic-m URL and NOT the IP address. The autogenerated certificate uses the dynamic-m name as CN and that cert should be trusted by most OS'es. ... View more

Thanks for all the suggestions.  I wonder if I just didn't wait long enough when applying the policies to test.  I stopped and retried pings, but I only waiting about 2 minutes or so.  From what you are saying, it might have to be 10 minutes or more or possibly even a reboot to kick in.  This makes testing pretty hard. ... View more

In the earlier days of iPSK without RADIUS I used to have to reboot the APs from time to time.  I presume it was a problem with the downloaded list like @GIdenJoe mentioned.   It has been rock solid reliable for a long time now.   I would try giving an affected AP a reboot and see if it makes any difference. ... View more

I think you get this backward. The intention of the BGP implementation on MX is to provide the spoke routes to some infrastructure.  So all your spoke networks that participate in autoVPN will be injected into BGP and given to it's configured neighbor. The clicking of default route in the VPN page is meant for branches to use that MX as a full tunnel endpoint to reach all other destinations. The upstream infrastructure needs it's own way to reach the internet outside of the BGP implementation on the MX. ... View more