Culprit identified! Those date format strings are sneaky, would be lying if I said I'd never done that exact same thing. ... View more

Oh that's perfect. I was under the impression that that view was limited to clients only seen in the past 30 days, glad that's not the case. Excellent find, thank you! ... View more

This is a question for the GLPI vendor, not the Meraki forums. There's a good chance they have an updated MIB that needs installed that will contain the sysobjectID for the MR36. ... View more

To clarify a bit, if you set up the MX to send syslog to a syslog receiver, it will source that traffic from the highest #'d VLAN interface defined on the MX. So, if you have a couple interfaces defined like so: VLAN 10 - 10.10.10.0/24 VLAN 20 - 10.10.20.0/24 VLAN 30 - 10.10.30.0/24   The syslog traffic will source from the VLAN 30 interface, 10.10.30.1.   If at any point you add VLAN 40 - 10.10.40.0/24, the syslog will then come from 10.10.40.1.   If the site-to-site VPN/Meraki AutoVPN is in play, the syslog will source from the highest #'d VLAN participating in the VPN ... View more

Syslogs will come from the devices themselves.   In the case of MX's, the logs will source from the biggest #'d VLAN defined. For example, if you have 3 VLANs defined:   VLAN 10 - 10.10.10.1 VLAN 20 - 10.10.20.1 VLAN 30 - 10.10.30.1   Logs from this MX will source from VLAN 30.   Additionally, the dashboard itself can send syslog (think login attempts & the like); However, I've not mucked around with this at all. ... View more

Create Device Live Tools Speed Test - Meraki Dashboard API v1 - Cisco Meraki Developer Hub   I think you need to read the speedtest endpoint documentation a bit more closely. To actually perform the speedtest you need to POST @ /devices/{{serial}}/liveTools/speedTest. This will perform the test, and return the results. Those results then get stored (tracked by a unique ID).   The query you have above is the query to retrieve the results of a previously run speedtest.   Edit: And note that this endpoint appears to only be available if you have the Early Access API enabled ... View more

Fire a query at /organizations/{{orgid}}/devices   That'll return a listing of all the devices owned by the org, their names, serial #'s, mac addresses, and a bunch of other info.   Edit: Org, not Orc. This isn't Lord of the Rings. ... View more

This is the document our Active Directory/Group Policy folks followed to set the adapter settings:   Windows 10 802.1x Wired Authentication - IST Knowledge Base - Confluence (atlassian.net) Note - Where it says to select User Authentication, use Machine Authentication   Edit: Better link ... View more

Are the users themselves authenticating via 802.1X, or is the computer authenticating via 802.1X using something like a machine certificate?   We use computer auth via machine certificate, and had some trouble with Windows 11 in-place upgrades. It had to do with part of the upgrade process (a task sequence via MECM, I believe) performing a NIC driver upgrade as part of the task sequence. This NIC driver update wiped out the 802.1X machine authentication settings that we applied to the "ethernet" connection via Group Policy. Once the settings were wiped, the machine would get kicked off the network, thus group policy couldn't enforce the 802.1X configuration. Bit of a catch22.    Our MECM admin ended up adding a step to the task sequence to force the settings back into place after the NIC driver was upgraded.   A more general, common culprit is that the "Wired Autoconfig" service can get disabled, it's worth checking if that's what's going on.   EDIT: After re-reading your initial post, I wonder if  these are in-place upgrades or are these wipe-> fresh images? If these are being wiped and given a fresh image, are you re-applying the 802.1X configuration in Windows? ... View more

I've seen some behavior like this on a few of our MX67's, it seems like WAN2 just goes numb even if everything should work. A physical reboot of the MX resolves it, if it's what I've seen before (rebooting via the dashboard doesn't do it) ... View more

You can cycle through each individual network with the scripting language of your choice, via the API, and set DHCP reservations using the following endpoint: Update Network Appliance Vlan - Meraki Dashboard API v1 - Cisco Meraki Developer Hub ... View more

Seconding this as probably the easiest thing to try/check.   I spent a fair bit of time last month tracking down what sounds like maybe a similar problem - folks complaining about completely random disconnects. When I went digging in the AP event logs, it really looked like the clients were severing their connections for an unknown reason. Thought maybe a sleep/power save feature was the issue but ruled that out pretty quick.   It turned out to be a faulty driver with a newer model of HP Laptop that recently started being deployed back in June, the driver issue had been present from the get-go but didn't hit critical mass until early October. This was specifically HP PB650G8 laptops with the Intel(R) Wi-Fi 6 AX201* wireless NIC, we snagged the latest driver from Intel's site, deployed it, and the problem went away entirely. ... View more

Fun fact, if you navigate to an open case in one tab of your browser and leave it there, your session will never time out. Or at least that's been my experience, but we're a single org. ... View more

This does appear to be resolved in 18.205! ... View more

+1 for wireshark/packet captures for this. Meraki's traffic analysis leaves much to be desired when digging into specific bandwidth spikes. Much better to gather up the raw packets and use Wireshark's analysis tools to figure out your top talkers (and what they're talking about). ... View more

I haven't tried 18.205, but can give it a shot at my test site this evening and respond back.   I did run this up the totem pole with our Meraki product reps, who are escalating with the MX product team. I should hear from support in the next day or two about gathering some data to hopefully help address the problem at some point in the future (assuming it's not already fixed in 18.205). ... View more

Looks like you got a near-copy paste of the answer they gave me back in May! That doesn't bode well...   I hope you are doing well, I've got answers from our Product Specialist team about our troubleshooting session and some suggested steps going forward.   Firstly I'd like to go into why DHCPv6 is renewing every 15 minutes on this service. Looking at the DHCPv6 Packets I mentioned during the call seeing the values for 30 and 60 minutes on the DNS options, however, on top of this the address lease the ISP is providing has the following values.   T1: 900 T2: 1350   The T1 and T2 values are set by the DHCP server and determine when the client (in this case the MX) will attempt to renew the lease at those timers. The following excerpt is taken from the RFC for DHCPv6 found at https://www.rfc-editor.org/rfc/rfc8415.html :   "The server selects the T1 and T2 values to allow the client to extend the lifetimes of any addresses in the IA_NA before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are 0.5 and 0.8 times the shortest preferred lifetime of the addresses in the IA that the server is willing to extend, respectively."   As the preferred lifetime is 30 minutes setting the T1 timer at 15 minutes does match the RFC. It becomes simply a case that the lifetimes for the lease that have been set on the DHCPv6 server (ISP) are far too short causing frequent renewals and disruptions.   Moving onto the loss and latency, what we're seeing here is going to be expected behavior on an MX. When the MX successfully renews its DHCP lease it has to refresh the interface configuration. This is expected behavior for an MX and the main reason that we recommend any interface-related changes are made outside of production hours.   -------- In summarization; the MX is renewing its DHCPv6 lease every 15 minutes due to the short lease lifetimes that have been set by the ISPs DHCPv6 server. When the MX is renewing the lease successfully it refreshes the interface as expected which causes temporary loss/latency.   How we can move this forward to reduce impact:   1. Disabling IPv6 would be the easiest option but if the ISP is unable to disable IPv6 this is not viable. Additionally, you are already aware Meraki does not have the option to disable IPv6 on WAN interfaces putting this option in a lock unless it can be readdressed with the ISP.   2. As we discussed the next option would be to have the ISP provide a static IPv6 address which can then be configured in Dashboard - this removes the DHCP lease timers completely   3. Have the ISP increase the lifetimes that the DHCPv6 server is setting - this would need to be negotiated with the ISP but ideally, you would aim to set them to occur outside of business hours. ... View more

Good question, needs testing which I'll try to get done in the next day or so. I ran this up the pole with our Meraki representatives to get their take; I fully agree that a no-change renewal should absolutely not cause any form of disruption and am angling this as a bug vs. expected behavior. ... View more

Negative, access to our dashboard/API is only allowed from our public-facing address. Can't use the dev hub to test 😞 ... View more

I've got a candidate site upgrading to 18.107.6 tonight to test this. Will follow-up in the morning.   Radio silence on my ticket thus far 😞   EDIT: I got impatient and upgraded my candidate site this evening before leaving, and can confirm that this issue persists in MX18.107.6. ... View more