Forwarding Exceptions — Traffic to the CPU
Some packets cannot or must not be handled by the fast path and are trapped (punted) to the CPU: ARP/ND, routing-protocol packets, packets to the switch itself, TTL-expired packets, and destinations with no resolved adjacency. Control-plane policing (CoPP) rate-limits these traps so the CPU (and control plane) survive. Trapped traffic is the slow path — powerful but scarce.
Prerequisites: Lesson 3.5 · Lesson 3.6
Learning objectives
- →Explain why certain packets must leave the fast path and go to the CPU.
- →Enumerate the major exception classes: ARP/ND, protocol packets, IP-to-me/management, TTL expiry, unresolved next hops, exception traps.
- →Describe how host interfaces (hostif) deliver trapped traffic to the CPU.
- →Explain control-plane policing (CoPP) and why it is essential.
- →Recognize the symptoms of CoPP drops and punt-path overload.
Half of 'weird SONiC' symptoms — slow ARP, flaky BGP under load, high CPU — are punt-path and CoPP effects, not routing bugs.
The CPU path is where control-plane health and data-plane forwarding meet; misunderstanding it sends you debugging the wrong plane.
What your CCNP already gives you
- • You know CoPP from IOS/NX-OS: protect the control plane from punted-traffic floods.
- • You know why ARP resolution, protocol packets, and TTL-expired traceroute packets reach the CPU.
What is new in SONiC
- • Traps are SAI host-interface trap objects mapped to trap groups and policers; CoPP is expressed in SONiC config and programmed via SAI.
- • Trapped traffic arrives on Linux 'host interfaces' (netdevs) and is visible with ordinary Linux tooling.
- • You can observe CoPP drops as counters, tying a control-plane symptom to a specific policer.
| In the analogy | In SONiC |
|---|---|
| The assembly line handling standard items automatically | Fast path (ASIC) |
| Kicking an unusual item to a human supervisor | Trap/punt to CPU |
| The categories of item the line is told to escalate | Trap types |
| A strict limit on how many escalations per second reach the supervisor | CoPP |
| The conveyor that carries escalated items to the supervisor's desk | Host interface (hostif) |
Where the analogy stops working
The exact trap set, how traps map to CoPP groups/policers, and default rates vary by SONiC image and ASIC. Treat the categories below as the map and confirm specifics on your platform.
Why anything leaves the fast path
The ASIC forwards the common case. Anything that requires *building* forwarding state, is *addressed to the switch*, or is *malformed/expiring* cannot be resolved by a table lookup and must go to software. The mechanism is a trap (a.k.a. punt): the pipeline redirects (or copies) the packet to the CPU via a host interface, and software handles it.
This slow path is essential — it is how adjacencies get resolved and how protocols run — but it is millions of times lower capacity than the fast path, so it must be strictly protected.
Major exception classes
| Class | Examples | Why it goes to CPU |
|---|---|---|
| Adjacency resolution | ARP request/response, IPv6 ND (NS/NA) | Builds the neighbor/adjacency (dst MAC) the fast path needs |
| Routing/control protocols | BGP, OSPF, LACP, LLDP, BFD (control), STP | Terminated and processed by control-plane software |
| IP-to-me / management | Packets addressed to a switch IP, SSH, SNMP, ping to the switch | The switch itself is the destination (IP2ME trap) |
| TTL / hop-limit expiry | TTL=1 packets, traceroute | Cannot be forwarded; must generate ICMP time-exceeded |
| Unresolved destination | Route present but neighbor not resolved | Trap to trigger ARP/ND for the missing adjacency |
| Exceptions/errors | IP options, MTU exceed (needs frag/ICMP), certain L3 errors | Fast path cannot legally handle; software must decide |
| DHCP / L2 relay | DHCP discover/relay where configured | Requires software relay/snooping handling |
Host interfaces: where trapped packets land
SAI host interface (hostif) objects connect the trap machinery to Linux netdevs. Trapped packets appear on these interfaces (per-port netdevs like Ethernet0, and CPU-directed paths), so ordinary Linux tools can observe control traffic. This is why you can, for instance, watch ARP or a protocol's packets with standard capture tools on the host — the punt path is Linux-visible.
Control-plane policing (CoPP)
CoPP rate-limits trapped traffic so a flood of exceptions cannot starve the CPU or drown the control plane. In SONiC, traps are grouped into trap groups, each bound to a policer with a committed rate/burst, and mapped to CPU queues. High-value control traffic (e.g., BGP, LACP, BFD) gets protected rates; lower-value or abusable traps (e.g., ARP broadcast, IP2ME) get tighter caps. The intent: even under attack or accident, the switch keeps its neighbors up and stays manageable.
The trade-off is real: set a policer too low and you throttle legitimate traffic (slow ARP, protocol flaps); too high and a flood can overwhelm the CPU. Defaults are tuned per image/ASIC — know where to see the drops.
Intermittent ARP failures, BGP/BFD flaps that correlate with traffic bursts, or 'ping to the switch is lossy but transit traffic is fine' are hallmark CoPP/punt-path problems. Transit (fast-path) forwarding is unaffected because it never touches the CPU — which is exactly the tell. Check CoPP/policer drop counters and CPU-queue drops, not the routing table.
Illustrative: observing the punt path and CoPP
# Trapped control traffic is visible on host netdevs (Linux):
sudo tcpdump -ni Ethernet0 arp or vrrp # ARP/protocol punts appear here
# CPU queue / CoPP drop counters (illustrative):
show queue counters # look for CPU-bound queue drops
# COPP/policer drops surface as counters tied to trap groups
# High control-plane CPU with idle data plane => punt-path pressure
show processes cpu | headIllustrative commands/outputs; exact tooling and counters vary by image and ASIC.
Common misconceptions
Myth: High CPU means the switch is forwarding a lot.
Reality: Transit forwarding is in the ASIC and barely touches the CPU. High CPU usually means heavy punting — an exception problem, not a throughput one.
Myth: CoPP drops are always bad and should be removed.
Reality: CoPP is protective by design; some drops of abusive/broadcast traffic are healthy. The goal is tuning, not disabling — removing it exposes the control plane to floods.
Myth: If transit traffic is fine, the switch is fine.
Reality: Transit can be perfect while the punt path (ARP, protocols, management) is starved by CoPP or a flood. The two planes fail independently.
- Symptoms that scale with load and hit control/management traffic (not transit) point at CoPP/punt path — check policer and CPU-queue drops.
- Slow or failing ARP/ND with a present route is an adjacency-trap issue; confirm the neighbor resolves and isn't being policed.
- Before 'fixing routing', confirm whether the affected traffic is fast-path (transit) or slow-path (to/through CPU) — they fail for different reasons.
Key takeaways
- ✓Packets that build state, are addressed to the switch, or are expiring/malformed are trapped to the CPU (slow path).
- ✓Major classes: ARP/ND, routing/control protocols, IP-to-me/management, TTL expiry, unresolved next hops, exception traps.
- ✓Host interfaces deliver trapped packets to Linux netdevs, making control traffic observable.
- ✓CoPP rate-limits traps via trap groups/policers to protect the CPU and control plane.
- ✓CoPP/punt-path problems hit control/management traffic while transit stays fine — a distinctive signature.
Tested against: SONiC 202305 / 202311 lineage · Upstream; trap sets/CoPP defaults vary by image and ASIC · Concepts general; specific traps are SAI/ASIC-dependent · last reviewed 2026-07. Exact commands and behavior can vary by SONiC release, image, hardware platform, and enterprise distribution.
Knowledge check
Which of the following are typically trapped (punted) to the CPU rather than forwarded entirely in the ASIC fast path? Select all that apply.
You want the highest-value next step, not a scattershot of checks.
BGP is Established, show ip route shows the prefix with a next hop, but traffic to it fails. After confirming the control plane is healthy, which single check most efficiently splits the problem in half?