I'm guessing your hitting default SNMP LPTS rate limits which you may be able to change, but for various reasons may not be a good idea. Here is some good info on the LPTS architecture written by Xander himself.
https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-local-packet-transport-services-lpts-copp/ta-p/3123792 You might want to look at streaming telemetry. __ Jim On 8/1/25, 11:01 AM, "Arie Vayner via NANOG" <[email protected] <mailto:[email protected]>> wrote: CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. Could this be somehow related to control plane policing? You might be hitting some default policy threshold, and may have to adjust it to allow snmp from your specific sources at a higher rate. IIRC on ios-xr that's called lots or sdr (but I had been a while...) On Fri, Aug 1, 2025, 6:59 AM Drew Weaver via NANOG <[email protected] <mailto:[email protected]>> wrote: > 90 seconds... but also we can poll Supervisor 720s at the same rate and > they don't time out or delay responses. > > 😊 > > > -----Original Message----- > From: Mel Beckman <[email protected] <mailto:[email protected]>> > Sent: Friday, August 1, 2025 9:37 AM > To: [email protected] <mailto:[email protected]> > Cc: Drew Weaver <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> > Subject: Re: Cisco ASR9902 SNMP polling ... is interesting > > How often are you polling the interfaces? SNMP was never meant for high > frequency polling (e.g., once per second), yet I often see people using > SNMP as if it were a SCADA service, which is used in industrial automation > for high frequency supervisory control and data acquisition. SNMP probes > are typically anticipated by device designers to occur at 30 second or 60 > second intervals. > > -mel > > > On Aug 1, 2025, at 6:10 AM, Drew Weaver via NANOG <[email protected] > > <mailto:[email protected]>> > wrote: > > > > Hello, > > > > We purchased an ASR9902 I think almost 2 years ago now intending to > replace 4 routers with them. > > > > We had a history of lets just say design decision quirks with the router > that prevented us from deploying it until recently. > > > > Then when we finally were able to implement it we've noticed something > strange about how SNMP polling works in the router. > > > > If we poll SNMP on any interface that isn't one of the built in > management ethernet interfaces the response takes 8x-16x longer to respond > and exactly 62% of the polls time out. > > > > If we poll SNMP on the built-in MGMT interfaces the responses are still > slower than the ASR9001s that we used to use but they don't seem to time > out. > > > > I've had a TAC case with Cisco open over this for weeks now and they are > now saying that the slow responses and the 62% poll timeouts are > intentional and that they don't see any problem with the design. > > > > I understand the security implications of having control plane stuff > responding on all interfaces but the part I don't understand is why bind > the SNMP daemon to the non MGMT* interfaces at all if they are making a > moral or ethical decision to not allow SNMP to work on non MGMT interfaces. > Shouldn't it just not work at all then? Who came up with 62% timeout as the > right number? > > > > The larger implication is that I still can't find another router from > another vendor that does this. > > > > Has anyone else run into this or did you guys all avoid the ASR 9902 > like we should have? > > > > Thanks, > > -Drew > > > > _______________________________________________ > > NANOG mailing list > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nanog.org_archives_list_nanog-40lists.nanog.org_message_HUP4BJYN3E7YQZKMDT6PLM3XBTK7DCJU_&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=ysryPUJQffffnj7NA86CIwOOPWsLq5M3v5_s4HOyDNvnNLv1f3rVKsrdYPpBqkBS&s=4ACrFXyyWFX_bxDa3z7o9aQNmNy6DiDi3Xn9hjKjKJY&e= > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nanog.org_archives_list_nanog-40lists.nanog.org_message_HUP4BJYN3E7YQZKMDT6PLM3XBTK7DCJU_&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=ysryPUJQffffnj7NA86CIwOOPWsLq5M3v5_s4HOyDNvnNLv1f3rVKsrdYPpBqkBS&s=4ACrFXyyWFX_bxDa3z7o9aQNmNy6DiDi3Xn9hjKjKJY&e=> > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected] > <mailto:[email protected]>/message/C3BD4D2RCOWC75EMNUOHE62T3P3KWYJ6/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected] <mailto:[email protected]>/message/FWKMUUHY74HJZEBXB6TJKSF6UQH7RPKM/ The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/LLHOJG6AGH7HJPZ5V7DBWMVM5UZMBW5I/
