Drew Weaver via NANOG wrote on 08/08/2025 14:31:
It couldn't be bothered to simply set it to 50000 if you set it to the configured maximum of 4294967295 It couldn't be bothered to simply say: "Hey we know the max for this platform is50000 so we set it to 50000 but you probably shouldn't be using 50000 for this value anyway" It could be bothered to do absolutely nothing and silently reject the command which made me laugh for about 5 minutes this morning.
Some years ago I was fighting with a low level pps rate limiter for a telemetry service on a long obsolete platform. The default limit caused packets to be dropped, and we finally settled on an updated figure based on the usual compromise of performance vs consequence. But: if we increased the limiter above what we had measured to be reasonable, this fairly quickly caused a performance cliff which affected other services, e.g. snmp / lacp timeouts, etc, so production impact. Although this was in the days of in-house NOS schedulers, I'd be fairly cautious in this area - particular on RTOS platforms like XR. If Cisco have implemented a pps limiter of 50k/s, that's a lot of snmp pps. Is this a realistic amount of requests to be properly serviced per second? SNMP packet encapsulation / general handling is one thing, but stats collection / intermediation can be more heavyweight. Bear in mind that the failure modes in this sort of situation are often non-linear. For sure it's a bit annoying that they don't warn that this is the maximum (possibly a platform / LC limit? i.e. possible that this is not a generic limit across all SPs on all types of unit), but at least the box won't fall over in production just because someone tweaked a parameter beyond what the hardware was likely capable of handling. Nick