Copp For Ospfv3 Packets - Dell Z9000 Configuration Manual

Dell#conf
Dell(conf)#control-plane
Dell(conf-control-plane)#service-policy rate-limit-cpu-queues cpuq_rate_policy

CoPP for OSPFv3 Packets

This functionality is supported on the S6000, S4810, S4820T, Z9000, and MXL platforms.
You can create an IPv6 ACL for control-plane traffic policing for OSPFv3, in addition to the CoPP support
for VRRP, BGP, and ICMP. This functionality is supported on the S4810, S4820T,S6000, MXL, and Z9000
platforms. You can use the ipv6 access-list name cpu-qos permit ospfv3 command to allow
CoPP traffic for OSPFv3. Control Plane Policing (CoPP) enables more number of CPU queues to be made
available on ports for IPv6 and ICMPv6 packets.
CoPP enhancements are to enhance the capability of FTOS by utilizing more number of CPU queues on
CMIC port and sending control packets to different queues that internally reduce limitation or contention
of control protocols sharing the same queues (that is, before this functionality of CoPP for OSPV3 was
introduced, OSPF might have caused the LACP flap because of both control traffic sent to same Q7 on
CPU port). Non CPU port should have only 4 dedicated control queues and remaining shared for both
data and traffic. Number of control queues is increased on the CPU port. When tunneling packets from
non-master to master unit, high-gig queues are used.
Prior to the release 9.4.(0.0), all IPv6 packets are taken to same queues there is no priority between the
ICMPv6 packets and unknown IPv6 packets. Due to this NS/NA/RS/RA packets not given high priority
leads to the session establishment problem. To solve this issue, starting from release 9.4.(0.0), IPv6 NDP
packets use different CPU queues when compared to the Generic IPv6 multicast traffic. These entries are
installed in system when application is triggered..
CPU Processing of CoPP Traffic
The systems use FP rules to take the packets to control plane by CopyToCPU or redirect packet to CPU
port. Only 8 CPU queues are used while sending the packet to CPU. The CPU Management Interface
Controller (CMIC) interface on all the systems supports 48 queues in hardware. However, FTOS supports
only 8 CMIC queues – 4 for data streams that are CPU bound – SFLOW packets, packet streams that are
trapped to CPU for logging info on MAC learn limit exceeded and other violations, L3 packets with
unknown destination for soft forwarding etc. Other 4 CMIC queues will carry the L2/L3 well-known
protocol streams. However there are about 20 well known protocol streams that have to share these 4
CMIC queues. Since FTOS uses only 8 queues most of the queues are shared to multiple protocols. So,
increasing the number of CMIC queues will reduce the contention among the protocols for the queue
bandwidth.
Currently, the systems support only 8 queues per front end or backplane ports, 4 for data and 4 for
control. In stacked systems, the control streams that reach standby or slave units will be tunneled
through the backplane ports across stack-units to reach the CPU of the master unit. In this case, the
packets that reach slave unit's CMIC via queues 0 – 7 will take same queues 0 – 7 on the back-plane
ports while traversing across units and finally on the master CMIC, they are queued on the same queues 0
– 7. In this case, the queue (4 – 7) taken by the well-known protocol streams are uniform across different
queuing points, and the queue (0 – 3) taken by the CPU bound data streams are uniform. In back-plane
ports, queue 0 – 3 will carry both the front-end bound data streams as well as the CPU bound data
streams which is acceptable but the well-known protocol streams must not be mixed with the data
streams on queues 0 – 3 in back-plane ports.
244
Control Plane Policing (CoPP)