Table of Contents

CoPP Config and Management

Config Schema

Examples

Limitations

Example model & SONiC version:

• Aurora 830, Aurora 721, Aurora 621
• Netberg SONiC: sonic-broadcom-202311.n0

CoPP Config and Management

The control plane policing (CoPP) feature increases security on the switch by protecting the CPU from unnecessary or DoS traffic and giving priority to the important control plane and management traffic.

For example, control packets such as sFlow, ICMP, LLDP, ARP, and routing protocols (BGP, OSPF, etc) are handled by the local processor. These control packets are matched as exact or prefix matches with address fields. A control classifier engine in the switching ASIC decides whether to trap to the CPU upon its configuration. The CoPP configuration limits the rate at which these packets can be handled, and the rest are dropped.

The default CoPP configuration is fine-tuned for system operation. Users should take extreme caution before making changes or modifications, as the system can become dysfunctional. Recovery will require reversing the changes from a backup or resetting to the factory default configuration.

/etc/sonic/copp_cfg.json holds all CoPP-related tables.

It has two sections:

1. “COPP_GROUP” to manage queue groups with actions, priorities, queues, etc. Each group have several options to indicate how the protocol packets are handled under certain conditions.

"COPP_GROUP": {
           "default": {
                   "queue": "0",
                   "meter_type":"packets",
                   "mode":"sr_tcm",
                   "cir":"600",
                   "cbs":"600",
                   "red_action":"drop"
           ...
           "queue4_group2": {
                   "trap_action":"copy",
                   "trap_priority":"4",
                   "queue": "4",
                   "meter_type":"packets",
                   "mode":"sr_tcm",
                   "cir":"600",
                   "cbs":"600",
                   "red_action":"drop"
           },
...

2. “COPP_TRAP” manages traps for different types of traffic.

"COPP_TRAP": {
        "bgp": {
                "trap_ids": "bgp,bgpv6",
                "trap_group": "queue4_group1"
        },
        "lacp": {
                "trap_ids": "lacp",
                "trap_group": "queue4_group1",
                "always_enabled": "true"
        },
        ...
        "sflow": {
                "trap_group": "queue2_group1",
                "trap_ids": "sample_packet"
        }
}

The trap group default trap IPv4/IPv6 packets with TTL=0 in their IP headers to the CPU.

Config Schema

A CoPP trap consists of trap ID and trap group. The latter has options – action and meter indicating how to handle the protocol packets under matched conditions. The meter can be packets or bytes; the action can be copy, trap, or drop. The trap ID is predefined as protocol packets, e.g. BGP, LACP, STP, and so on. A trap group offers configurable criteria to trigger the trap upon matching, and we will describe them below.

{
  "COPP_GROUP": {
    "<group-name>": {
      "queue": <CPU queue#>,
      "trap_action": <trap, copy, or drop>,
      "trap_priority": <priority>,
      "meter_type": <packets, bytes>,
      "mode": <sr_tcm, tr_tcm, storm>,
      "color": <aware, blind>,
      "cbs": <commit burst size>,
      "cir": <commit information rate>,
      "pbs": <peak burst size>,
      "pir": <peak information rate>,
      "green_action": <action for packets marked as green>,
      "yellow_action": <action for packets marked as yellow>,
      "red_action": <action for packets marked as red>,
      "genetlink_name": <psample for sflow>,
      "genetlink_mcgrp_name": <packets for sflow>
    }
  },
  "COPP_TRAP": {
    "<trap-name>": {
      "trap_ids": <list of trap ID>,
      "trap_group": <group name>
    }
  }
}

Parameter Description

• : group name.
  • queue: Specifies the CPU queue number (0..47) the packets will enqueue into for processing when trap_action is trap or copy. A strict queue priority, and a higher number means higher priority.
  • trap_action: packet_action; trap action which will be applied to all trap_ids for this group.
    • trap: trap the packets to the CPU for a process but not forward the packets.
    • copy: trap the packets to CPU for processing and forwarding the packets.
    • drop: drop the packets.
  • trap_priority: Specifies the trap group’s priority (0..65535). A higher number means higher priority.
  • meter_type: Specifies the meter type – packets or bytes.
  • mode: Specifies the meter mode – sr_tcm (Single Rate Three Color Marker), tr_tcm (Triple Rate Three Color Marker), and storm (storm control).
  • color: Specifies the color mode – aware (color-aware mode) or blind (color-blind mode).
  • cbs: Committed Burst Size (note). Packets or bytes depending on the meter_type value.
  • cir : Committed Information Rate (note). Packets or bytes depending on the meter_type value.
  • pbs: Peak Burst Size (note). Packets or bytes depending on the meter_type value.
  • pir: Peak Information Rate (note). Packets or bytes depending on the meter_type value.
  • green_action: packet_action on the packets marked as green by the meter. A valid value is the same as trap_action.
  • yellow_action: packet_action on the packets marked as yellow by the meter. A valid value is the same as trap_action.
  • red_action: packet_action on the packets marked as red by the meter. A valid value is the same as trap_action.
  • genetlink_name: genetlink_name; [Optional] “psample” for sFlow.
  • genetlink_mcgrp_name: multicast group name; [Optional] “packets” for sFlow.
• : Trap name to identify different trap configurations.
  • trap_ids: Predefined protocol packet list. Supported trap IDs are listed below.
  • trap_group: associates the trap ID to the trap group to apply actions for the protocol.

Supported trap IDs

• stp
• lacp
• eapol
• lldp
• pvrst
• igmp_query
• igmp_leave
• igmp_v1_report
• igmp_v2_report
• igmp_v3_report
• sample_packet
• switch_cust_range
• arp_req
• arp_resp
• dhcp
• ospf
• pim
• vrrp
• bgp
• dhcpv6
• ospfv6
• bgpv6
• vrrpv6
• neigh_discovery
• mld_v1_v2
• mld_v1_report
• mld_v1_done
• mld_v2_report
• ip2me
• ssh
• snmp
• router_custom_range
• l3_mtu_error
• ttl_error
• udld
• bfd
• bfdv6
• src_nat_miss
• dest_nat_miss
• isis

Some models may not support specific trap IDs or have limitations.

• src_nat_miss and dest_nat_miss work only on Trident3-x5/x7-based models.

Examples

ARP Config

To check and change the sampling rate for ARP packets, we need to check the corresponding COPP_TRAP section:

"arp": {
        "trap_ids": "arp_req,arp_resp,neigh_discovery",
        "trap_group": "queue4_group2",
        "always_enabled": "true"
},

These traps belong to the queue4_group2 group, and in the COPP_GROUP section we can see:

"queue4_group2": {
        "trap_action":"copy",
        "trap_priority":"4",
        "queue": "4",
        "meter_type":"packets",
        "mode":"sr_tcm",
        "cir":"600",
        "cbs":"600",
        "red_action":"drop"
},

We have a limit of 600 packets per second, and all packets above this value will get dropped.

BFD Config

An example of BFD packet trapping to CPU:

"queue5": {
        "trap_action":"trap",
        "trap_priority":"5",
        "queue": "5",
        "meter_type":"packets",
        "mode":"sr_tcm",
        "cir":"60000",
        "cbs":"60000",
        "red_action":"drop"
},
"bfd": {
        "trap_ids": "bfd,bfdv6",
        "trap_group": "queue5",
},

Limitations

User is expected to resolve any conflicts, say for a trap id or group, that arises due to values configured by the user.

Applying changes requires a system reboot.