The control plane receives 100% of the packets, providing the control plane policies allow it to. The control plane is likely connected to the ASIC via a mix of a PCI-E interface (providing the programming interface and an emulated NIC) and/or a specialized NIC port.
Different vendors and platforms do this differently, but generally the forwarding complex element has two egress paths ; one goes to the device fabric used for through traffic, the other goes to the control plane. Packets that egress to the fabric are usually chopped up into cells that are reassembled at the forwarding complex connected to the outbound interface. The control plane connection is usually just a standard ethernet to an internal control plane switch. The forwarding complex wraps up the packet and transmits it that direction, and it's passed over to the RP/RE that way. There is internal policing here to prevent elements from running the CP over. Some of those are user configurable, others are not. ( Vendor dependent.) When you say 'the control plane receives 100% of the packets', it sort of depends on what you define as the 'control plane'. That's usually defined as 'did the packet get to the RE/RP to process it' There are many scenarios by which this can break : - Interface buffers may be full - Interface buffers may be drained fast enough - Oversubscription of forwarding complex - Poorly designed QoS - Incorrect config/bugs of control plane policer on internal interface to CP switch - Central CPU (RE, RP, etc) overwhelmed - Internal CP switch manfunctioning On Sun, Aug 3, 2025 at 12:35 AM Ryan Hamel <ryan@rkhtech.org> wrote:
Mel,
The control plane receives 100% of the packets, providing the control plane policies allow it to. The control plane is likely connected to the ASIC via a mix of a PCI-E interface (providing the programming interface and an emulated NIC) and/or a specialized NIC port. If the CPU port is experiencing packet loss (my stance is very unlikely), that can be a separate discussion. I agree that an escalation is the appropriate response here, where TAC should try to reproduce the issue with Drew's config.
Kind regards,
Ryan Hamel
------------------------------ *From:* Mel Beckman via NANOG <nanog@lists.nanog.org> *Sent:* Saturday, August 2, 2025 4:23 PM *To:* Tom Beecher <beecher@beecher.cc> *Cc:* nanog@lists.nanog.org <nanog@lists.nanog.org>; Mel Beckman < mel@beckman.org> *Subject:* Re: Cisco ASR9902 SNMP polling ... is interesting
Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.
I’ll just let the incivility of you both stand.
-mel
On Aug 2, 2025, at 3:52 PM, Tom Beecher <beecher@beecher.cc> wrote:
Mel-
Saku did not call *you* any names. He called your *incorrect statements* in this thread 'bizzard drivel'. Which he is absolutely correct about. While your intentions may certainly have been to help, your statements here have been frankly dead wrong and did not accomplish that.
Probably just want to take the L here.
On Sat, Aug 2, 2025 at 5:34 PM Mel Beckman via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Saku,
What is actually appalling is that a member of NANOG calls “bizarre drivel” the honest and sincere attempts by other members to help identify the possible problem. There’s no cause to be uncivil, people can disagree without stooping to name-calling.
-mel
On Aug 2, 2025, at 11:46 AM, Saku Ytti via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote:
On Sat, 2 Aug 2025 at 21:02, Tom Beecher via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
I don't have in depth knowledge of Cisco's SNMP implementations, or even the ASR platform specifically, but if Cisco TAC is telling you this is 'normal', they are completely full of shit, and you should click any and every 'escalate' button you can find.
This almost sounds like a default control plane DDOS policer / LPTS , something like that.
There are various complicated reasons for this, LPTS policer is unlikely culprit, but possible. Bug search will show various DDTS with poor SNMP performance outcome, most of them are unrelated to LPTS.
But absolutely correct, the right solution is to escalate. In common case this would be SE from your account team, who would fight for you internally.
It is appalling that OP came to nanog after correctly suspecting TAC is gaslighting them, some community member piled on with what can only be described as a bizarre drivel. -- ++ytti _______________________________________________ NANOG mailing list
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F7KXUNRGFI5OEVSDEDU2OL5VMY5NBGQCV%2F&data=05%7C02%7Cryan%40rkhtech.org%7C935f5b9276c34753763108ddd21bb022%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638897738572035533%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6ZnOfMhjhXcOW6xJQgBOLUTCz9tS4Uzyb8esw9zjkww%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7KXUNRGFI5OEVSDEDU2OL5VMY5NBGQCV/> _______________________________________________ NANOG mailing list
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FCF3QHVTISL6LDFTOWG4E3KK54QEDHUIY%2F&data=05%7C02%7Cryan%40rkhtech.org%7C935f5b9276c34753763108ddd21bb022%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638897738572091179%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rMHLcrZ21hVS2zLMHWW2nmH%2FZoF%2FPm3gZdU1ViywGQc%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CF3QHVTISL6LDFTOWG4E3KK54QEDHUIY/> _______________________________________________ NANOG mailing list
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FOJ7ICXLSPFND32X2XS2U7XIWA6DALSIF%2F&data=05%7C02%7Cryan%40rkhtech.org%7C935f5b9276c34753763108ddd21bb022%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638897738572130874%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=J8MV4YiEOgQROlfuT5ij7baERA6aF8bH0Tm%2Bg2%2FMKC0%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OJ7ICXLSPFND32X2XS2U7XIWA6DALSIF/>