Hi, No, Meraki doesn't intentionally slow down the speed during the grace period. The grace period typically refers to the time when a device is being registered or when a firmware update is in progress. During this time, network performance may be temporarily affected due to the device not being fully functional yet or the update process consuming resources, but there's no throttling or intentional slowdown by Meraki. If you're noticing a significant drop in speed during this period, it might be worth checking for other factors, like network congestion, bandwidth usage, or device configuration issues. ... View more

Hi, It sounds like you're not getting the full bandwidth from your ISP due to a few potential factors. First, check that your WAN port on the MX68CW is correctly configured for the speed your ISP is providing. Ensure that you're using the correct port (typically the primary WAN port) and that it’s set to the right speed in the Dashboard. Additionally, verify that you're using a high-quality Ethernet cable that supports gigabit speeds. If you're using a cable rated for lower speeds, that could be limiting your throughput. Also, check if there are any traffic shaping or QoS settings in your Dashboard that might be limiting bandwidth. Lastly, consider running speed tests directly from the MX68CW to rule out any device-specific limitations and ensure the throughput issue is isolated to the MX68CW. ... View more

Hi Gianluca, It sounds like you're on the right track with trying to avoid waiting on rate limits, but the issue seems to stem from how the `Retry-After` header is being handled by the Meraki API client. By default, the client respects this header, even if `wait_on_rate_limit=False` is set. This setting doesn't override the behavior of waiting on 429 responses; it's more about controlling automatic retries for specific API calls. To resolve this, you may need to modify your custom script to handle 429 responses manually. When you get a 429 status, you could just skip that device and proceed with the next one, returning an empty response to Prometheus. This way, you avoid waiting for the retry and let Prometheus handle the retry logic at its own interval. You can also check the `Retry-After` value directly in your script and decide whether to proceed with the next device immediately. ... View more