Table 2. Feature History
Feature Name |
Release Information
|
Feature Description |
SNMP RX Queuing
|
Cisco IOS XE Bengaluru 17.6.1a
|
This feature introduces a Control Plane Policing queue to shape incoming SNMP traffic in Cisco cBR-8 routers. It reduces the
need for the SNMP poller to retransmit the polling request in case the request is dropped when SNMP traffic overloads the
queue.
|
SNMP RX Queuing Redesign
|
Cisco IOS XE Dublin 17.12.1x
|
In previous releases, SNMP RX Queuing could impact AOM to CPP downloads, resulting in slow response to changing cable conditions.
In this release, the new design fixes these issues. SNMP RX Queuing is more responsive to cable modem flaps, more responsive
to resiliency changes of bandwidth on a link in response to impairments, and so on, while using the SNMP RX queue with saturating
SNMP traffic.
|
Spike in SNMP traffic leads to drops in punt-path-rate-limiting (PPRL). Cisco IOS XE Bengaluru 17.6.1a release introduces
a Control Plane Policing queue to shape incoming SNMP traffic. It reduces the need for the SNMP poller to retransmit the polling
request in case the request is dropped when SNMP traffic overloads the queue.
This feature is disabled by default. Use the following command to configure this feature:
cable rxq snmp rate packets-per-second qlimit packets [ avg-pkt-size bytes]
For example:
Router(config)#cable rxq snmp rate 1024 qlimit 8192 avg-pkt-size 1500
Router(config)#end
The SNMP packet rate range is 64–1024 packet/second. The queue limit range is 64–8192 packets. The average packet size range
is 95–1500 bytes, the default size is 128 bytes.

Note
|
The RXQ rate must be smaller than the punt-policer rate, so that RXQ handles the rate-limiting of SNMP packets.
|
When you update the RXQ parameters, the existing queue must be empty. It results in a delay before the new queue parameters
take effect.
To verify the SNMP RX queuing configuration, use the show command as shown in the following examples:
Router#show platform hardware qfp active feature docsis rxq idx 1
Idx Uidb Qid Rate(Kbps) Qlmt(Byte)
1 0x0003ed92 0x0000b3a0 12288 12288000
Router#show plat hard qfp active infra bqs queue output default interface-string RXQ0
Interface: RXQ0 QFP: 0.0 if_h: 4718 Num Queues/Schedules: 1
Queue specifics:
Index 0 (Queue ID:0xb3a0, Name: )
Software Control Info:
(cache) queue id: 0x0000b3a0, wred: 0x52783200, qlimit (bytes): 12288000
parent_sid: 0x29e23, debug_name:
sw_flags: 0x48000011, sw_state: 0x00000801, port_uidb: 257426
orig_min : 0 , min: 1228800
min_qos : 0 , min_dflt: 0
orig_max : 0 , max: 0
max_qos : 0 , max_dflt: 0
share : 1
plevel : 0, priority: 65535
defer_obj_refcnt: 0, cp_ppe_addr: 0x00000000
Statistics:
tail drops (bytes): 115203800 , (packets): 525349
total enqs (bytes): 208955400 , (packets): 1131326
queue_depth (bytes): 0
licensed throughput oversubscription drops:
(bytes): 0 , (packets): 0
Feature Restrictions
Starting with Cisco IOS XE Dublin 17.12.1x, the updated design for SNMP RX Queuing does not cause issues with AOM to CPP downloads.
However, three features are affected by this design change:
-
Per-interface punt-policer:
The punt-policer can be configured on a per-interface basis. This is in addition to the regular global punt-policer. However,
RXQ processing runs in parallel to the per-interface punt-policer. Therefore, SNMP packets that go through RXQ bypasses the
per-interface punt-policer.
-
Embedded Packet Capture (EPC) debugging:
Egress EPC processing on the control-plane interface is performed before RXQ processing. This means that EPC captures packets
that may be subsequently dropped by RXQ.
-
Packet-tracing debugging
Packet-tracing information is not maintained as the packet traverses RXQ. So, if the packet is dropped, the expected output
is seen in the packet-tracing output. If the packet successfully goes through RXQ and continues along the punt-path, packet-tracing
shows the packet as being 'consumed', and no data after RXQ is recorded.