Here is an illustration I use to illustrate the internal “receive path” the control, management, and signal planes take. Note the risk. It is very easy to hit a router/switch control/management plane. You do not need to flood the link to overload the control plane.
 > On Aug 4, 2025, at 06:14, Ryan Hamel via NANOG <[email protected]> wrote: > > Tom, > > I 100% agree with this, thank you for going into greater detail on that. > > Kind regards, > > Ryan Hamel > > ________________________________ > From: Tom Beecher <[email protected] <mailto:[email protected]>> > Sent: Sunday, August 3, 2025 6:39 AM > To: Ryan Hamel <[email protected] <mailto:[email protected]>> > Cc: North American Network Operators Group <[email protected] > <mailto:[email protected]>>; Mel Beckman <[email protected] > <mailto:[email protected]>> > 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. > > 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 <[email protected] > <mailto:[email protected]><mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]><mailto:[email protected]>> > Sent: Saturday, August 2, 2025 4:23 PM > To: Tom Beecher <[email protected] > <mailto:[email protected]><mailto:[email protected]>> > Cc: [email protected] > <mailto:[email protected]><mailto:[email protected]> > <[email protected] > <mailto:[email protected]><mailto:[email protected]>>; Mel Beckman > <[email protected] <mailto:[email protected]><mailto:[email protected]>> > 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 <[email protected] > <mailto:[email protected]><mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]><mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > 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 <[email protected] >> <mailto:[email protected]><mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> >> wrote: >> >> On Sat, 2 Aug 2025 at 21:02, Tom Beecher via NANOG >> <[email protected] >> <mailto:[email protected]><mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> >> 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/[email protected]/message/7KXUNRGFI5OEVSDEDU2OL5VMY5NBGQCV/> >> >> <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%3Chttps://lists.nanog.org/archives/list/[email protected]/message/7KXUNRGFI5OEVSDEDU2OL5VMY5NBGQCV/%3E> > _______________________________________________ > 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/[email protected]/message/CF3QHVTISL6LDFTOWG4E3KK54QEDHUIY/> > > <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%3Chttps://lists.nanog.org/archives/list/[email protected]/message/CF3QHVTISL6LDFTOWG4E3KK54QEDHUIY/%3E> > _______________________________________________ > 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/[email protected]/message/OJ7ICXLSPFND32X2XS2U7XIWA6DALSIF/> > > <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%3Chttps://lists.nanog.org/archives/list/[email protected]/message/OJ7ICXLSPFND32X2XS2U7XIWA6DALSIF/%3E> > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/[email protected]/message/BVVKHMXYQHAHJXGWTO7CTRQZH33S4GRW/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/UXSWL466YQNBWNTU5F5RTCXRUE5D4PCW/
