1 .. SPDX-License-Identifier: GPL-2.0
10 Devices capable of offloading the kernel's datapath and perform functions such
11 as bridging and routing must also be able to send specific packets to the
12 kernel (i.e., the CPU) for processing.
14 For example, a device acting as a multicast-aware bridge must be able to send
15 IGMP membership reports to the kernel for processing by the bridge module.
16 Without processing such packets, the bridge module could never populate its
19 As another example, consider a device acting as router which has received an IP
20 packet with a TTL of 1. Upon routing the packet the device must send it to the
21 kernel so that it will route it as well and generate an ICMP Time Exceeded
22 error datagram. Without letting the kernel route such packets itself, utilities
23 such as ``traceroute`` could never work.
25 The fundamental ability of sending certain packets to the kernel for processing
26 is called "packet trapping".
31 The ``devlink-trap`` mechanism allows capable device drivers to register their
32 supported packet traps with ``devlink`` and report trapped packets to
33 ``devlink`` for further analysis.
35 Upon receiving trapped packets, ``devlink`` will perform a per-trap packets and
36 bytes accounting and potentially report the packet to user space via a netlink
37 event along with all the provided metadata (e.g., trap reason, timestamp, input
38 port). This is especially useful for drop traps (see :ref:`Trap-Types`)
39 as it allows users to obtain further visibility into packet drops that would
40 otherwise be invisible.
42 The following diagram provides a general overview of ``devlink-trap``::
44 Netlink event: Packet w/ metadata
45 Or a summary of recent drops
49 +---------------------------------------------------+
62 | devlink | (non-drop traps)
74 +---------------------------------------------------+
89 The ``devlink-trap`` mechanism supports the following packet trap types:
91 * ``drop``: Trapped packets were dropped by the underlying device. Packets
92 are only processed by ``devlink`` and not injected to the kernel's Rx path.
93 The trap action (see :ref:`Trap-Actions`) can be changed.
94 * ``exception``: Trapped packets were not forwarded as intended by the
95 underlying device due to an exception (e.g., TTL error, missing neighbour
96 entry) and trapped to the control plane for resolution. Packets are
97 processed by ``devlink`` and injected to the kernel's Rx path. Changing the
98 action of such traps is not allowed, as it can easily break the control
100 * ``control``: Trapped packets were trapped by the device because these are
101 control packets required for the correct functioning of the control plane.
102 For example, ARP request and IGMP query packets. Packets are injected to
103 the kernel's Rx path, but not reported to the kernel's drop monitor.
104 Changing the action of such traps is not allowed, as it can easily break
112 The ``devlink-trap`` mechanism supports the following packet trap actions:
114 * ``trap``: The sole copy of the packet is sent to the CPU.
115 * ``drop``: The packet is dropped by the underlying device and a copy is not
117 * ``mirror``: The packet is forwarded by the underlying device and a copy is
123 Generic packet traps are used to describe traps that trap well-defined packets
124 or packets that are trapped due to well-defined conditions (e.g., TTL error).
125 Such traps can be shared by multiple device drivers and their description must
126 be added to the following table:
128 .. list-table:: List of Generic Packet Traps
134 * - ``source_mac_is_multicast``
136 - Traps incoming packets that the device decided to drop because of a
138 * - ``vlan_tag_mismatch``
140 - Traps incoming packets that the device decided to drop in case of VLAN
141 tag mismatch: The ingress bridge port is not configured with a PVID and
142 the packet is untagged or prio-tagged
143 * - ``ingress_vlan_filter``
145 - Traps incoming packets that the device decided to drop in case they are
146 tagged with a VLAN that is not configured on the ingress bridge port
147 * - ``ingress_spanning_tree_filter``
149 - Traps incoming packets that the device decided to drop in case the STP
150 state of the ingress bridge port is not "forwarding"
151 * - ``port_list_is_empty``
153 - Traps packets that the device decided to drop in case they need to be
154 flooded (e.g., unknown unicast, unregistered multicast) and there are
155 no ports the packets should be flooded to
156 * - ``port_loopback_filter``
158 - Traps packets that the device decided to drop in case after layer 2
159 forwarding the only port from which they should be transmitted through
160 is the port from which they were received
161 * - ``blackhole_route``
163 - Traps packets that the device decided to drop in case they hit a
165 * - ``ttl_value_is_too_small``
167 - Traps unicast packets that should be forwarded by the device whose TTL
168 was decremented to 0 or less
171 - Traps packets that the device decided to drop because they could not be
172 enqueued to a transmission queue which is full
175 - Traps packets that the device decided to drop because they need to
176 undergo a layer 3 lookup, but are not IP or MPLS packets
177 * - ``uc_dip_over_mc_dmac``
179 - Traps packets that the device decided to drop because they need to be
180 routed and they have a unicast destination IP and a multicast destination
182 * - ``dip_is_loopback_address``
184 - Traps packets that the device decided to drop because they need to be
185 routed and their destination IP is the loopback address (i.e., 127.0.0.0/8
189 - Traps packets that the device decided to drop because they need to be
190 routed and their source IP is multicast (i.e., 224.0.0.0/8 and ff::/8)
191 * - ``sip_is_loopback_address``
193 - Traps packets that the device decided to drop because they need to be
194 routed and their source IP is the loopback address (i.e., 127.0.0.0/8 and ::1/128)
195 * - ``ip_header_corrupted``
197 - Traps packets that the device decided to drop because they need to be
198 routed and their IP header is corrupted: wrong checksum, wrong IP version
199 or too short Internet Header Length (IHL)
200 * - ``ipv4_sip_is_limited_bc``
202 - Traps packets that the device decided to drop because they need to be
203 routed and their source IP is limited broadcast (i.e., 255.255.255.255/32)
204 * - ``ipv6_mc_dip_reserved_scope``
206 - Traps IPv6 packets that the device decided to drop because they need to
207 be routed and their IPv6 multicast destination IP has a reserved scope
209 * - ``ipv6_mc_dip_interface_local_scope``
211 - Traps IPv6 packets that the device decided to drop because they need to
212 be routed and their IPv6 multicast destination IP has an interface-local scope
214 * - ``mtu_value_is_too_small``
216 - Traps packets that should have been routed by the device, but were bigger
217 than the MTU of the egress interface
218 * - ``unresolved_neigh``
220 - Traps packets that did not have a matching IP neighbour after routing
221 * - ``mc_reverse_path_forwarding``
223 - Traps multicast IP packets that failed reverse-path forwarding (RPF)
224 check during multicast routing
227 - Traps packets that hit reject routes (i.e., "unreachable", "prohibit")
228 * - ``ipv4_lpm_miss``
230 - Traps unicast IPv4 packets that did not match any route
231 * - ``ipv6_lpm_miss``
233 - Traps unicast IPv6 packets that did not match any route
234 * - ``non_routable_packet``
236 - Traps packets that the device decided to drop because they are not
237 supposed to be routed. For example, IGMP queries can be flooded by the
238 device in layer 2 and reach the router. Such packets should not be
239 routed and instead dropped
242 - Traps NVE and IPinIP packets that the device decided to drop because of
243 failure during decapsulation (e.g., packet being too short, reserved
244 bits set in VXLAN header)
245 * - ``overlay_smac_is_mc``
247 - Traps NVE packets that the device decided to drop because their overlay
248 source MAC is multicast
249 * - ``ingress_flow_action_drop``
251 - Traps packets dropped during processing of ingress flow action drop
252 * - ``egress_flow_action_drop``
254 - Traps packets dropped during processing of egress flow action drop
266 - Traps IGMP Membership Query packets
267 * - ``igmp_v1_report``
269 - Traps IGMP Version 1 Membership Report packets
270 * - ``igmp_v2_report``
272 - Traps IGMP Version 2 Membership Report packets
273 * - ``igmp_v3_report``
275 - Traps IGMP Version 3 Membership Report packets
276 * - ``igmp_v2_leave``
278 - Traps IGMP Version 2 Leave Group packets
281 - Traps MLD Multicast Listener Query packets
282 * - ``mld_v1_report``
284 - Traps MLD Version 1 Multicast Listener Report packets
285 * - ``mld_v2_report``
287 - Traps MLD Version 2 Multicast Listener Report packets
290 - Traps MLD Version 1 Multicast Listener Done packets
293 - Traps IPv4 DHCP packets
296 - Traps IPv6 DHCP packets
299 - Traps ARP request packets
302 - Traps ARP response packets
305 - Traps NVE-decapsulated ARP packets that reached the overlay network.
306 This is required, for example, when the address that needs to be
307 resolved is a local address
308 * - ``ipv6_neigh_solicit``
310 - Traps IPv6 Neighbour Solicitation packets
311 * - ``ipv6_neigh_advert``
313 - Traps IPv6 Neighbour Advertisement packets
316 - Traps IPv4 BFD packets
319 - Traps IPv6 BFD packets
322 - Traps IPv4 OSPF packets
325 - Traps IPv6 OSPF packets
328 - Traps IPv4 BGP packets
331 - Traps IPv6 BGP packets
334 - Traps IPv4 VRRP packets
337 - Traps IPv6 VRRP packets
340 - Traps IPv4 PIM packets
343 - Traps IPv6 PIM packets
346 - Traps unicast packets that need to be routed through the same layer 3
347 interface from which they were received. Such packets are routed by the
348 kernel, but also cause it to potentially generate ICMP redirect packets
351 - Traps unicast packets that hit a local route and need to be locally
353 * - ``external_route``
355 - Traps packets that should be routed through an external interface (e.g.,
356 management interface) that does not belong to the same device (e.g.,
357 switch ASIC) as the ingress interface
358 * - ``ipv6_uc_dip_link_local_scope``
360 - Traps unicast IPv6 packets that need to be routed and have a destination
361 IP address with a link-local scope (i.e., fe80::/10). The trap allows
362 device drivers to avoid programming link-local routes, but still receive
363 packets for local delivery
364 * - ``ipv6_dip_all_nodes``
366 - Traps IPv6 packets that their destination IP address is the "All Nodes
367 Address" (i.e., ff02::1)
368 * - ``ipv6_dip_all_routers``
370 - Traps IPv6 packets that their destination IP address is the "All Routers
371 Address" (i.e., ff02::2)
372 * - ``ipv6_router_solicit``
374 - Traps IPv6 Router Solicitation packets
375 * - ``ipv6_router_advert``
377 - Traps IPv6 Router Advertisement packets
378 * - ``ipv6_redirect``
380 - Traps IPv6 Redirect Message packets
381 * - ``ipv4_router_alert``
383 - Traps IPv4 packets that need to be routed and include the Router Alert
384 option. Such packets need to be locally delivered to raw sockets that
385 have the IP_ROUTER_ALERT socket option set
386 * - ``ipv6_router_alert``
388 - Traps IPv6 packets that need to be routed and include the Router Alert
389 option in their Hop-by-Hop extension header. Such packets need to be
390 locally delivered to raw sockets that have the IPV6_ROUTER_ALERT socket
394 - Traps PTP time-critical event messages (Sync, Delay_req, Pdelay_Req and
398 - Traps PTP general messages (Announce, Follow_Up, Delay_Resp,
399 Pdelay_Resp_Follow_Up, management and signaling)
400 * - ``flow_action_sample``
402 - Traps packets sampled during processing of flow action sample (e.g., via
404 * - ``flow_action_trap``
406 - Traps packets logged during processing of flow action trap (e.g., via
410 - Traps packets dropped due to the RED (Random Early Detection) algorithm
412 * - ``vxlan_parsing``
414 - Traps packets dropped due to an error in the VXLAN header parsing which
415 might be because of packet truncation or the I flag is not set.
416 * - ``llc_snap_parsing``
418 - Traps packets dropped due to an error in the LLC+SNAP header parsing
421 - Traps packets dropped due to an error in the VLAN header parsing. Could
422 include unexpected packet truncation.
423 * - ``pppoe_ppp_parsing``
425 - Traps packets dropped due to an error in the PPPoE+PPP header parsing.
426 This could include finding a session ID of 0xFFFF (which is reserved and
427 not for use), a PPPoE length which is larger than the frame received or
428 any common error on this type of header
431 - Traps packets dropped due to an error in the MPLS header parsing which
432 could include unexpected header truncation
435 - Traps packets dropped due to an error in the ARP header parsing
438 - Traps packets dropped due to an error in the first IP header parsing.
439 This packet trap could include packets which do not pass an IP checksum
440 check, a header length check (a minimum of 20 bytes), which might suffer
441 from packet truncation thus the total length field exceeds the received
445 - Traps packets dropped due to an error in the parsing of the last IP
446 header (the inner one in case of an IP over IP tunnel). The same common
447 error checking is performed here as for the ip_1_parsing trap
450 - Traps packets dropped due to an error in the GRE header parsing
453 - Traps packets dropped due to an error in the UDP header parsing.
454 This packet trap could include checksum errorrs, an improper UDP
455 length detected (smaller than 8 bytes) or detection of header
459 - Traps packets dropped due to an error in the TCP header parsing.
460 This could include TCP checksum errors, improper combination of SYN, FIN
462 * - ``ipsec_parsing``
464 - Traps packets dropped due to an error in the IPSEC header parsing
467 - Traps packets dropped due to an error in the SCTP header parsing.
468 This would mean that port number 0 was used or that the header is
472 - Traps packets dropped due to an error in the DCCP header parsing
475 - Traps packets dropped due to an error in the GTP header parsing
478 - Traps packets dropped due to an error in the ESP header parsing
479 * - ``blackhole_nexthop``
481 - Traps packets that the device decided to drop in case they hit a
484 Driver-specific Packet Traps
485 ============================
487 Device drivers can register driver-specific packet traps, but these must be
488 clearly documented. Such traps can correspond to device-specific exceptions and
489 help debug packet drops caused by these exceptions. The following list includes
490 links to the description of driver-specific traps registered by various device
496 .. _Generic-Packet-Trap-Groups:
498 Generic Packet Trap Groups
499 ==========================
501 Generic packet trap groups are used to aggregate logically related packet
502 traps. These groups allow the user to batch operations such as setting the trap
503 action of all member traps. In addition, ``devlink-trap`` can report aggregated
504 per-group packets and bytes statistics, in case per-trap statistics are too
505 narrow. The description of these groups must be added to the following table:
507 .. list-table:: List of Generic Packet Trap Groups
513 - Contains packet traps for packets that were dropped by the device during
514 layer 2 forwarding (i.e., bridge)
516 - Contains packet traps for packets that were dropped by the device during
518 * - ``l3_exceptions``
519 - Contains packet traps for packets that hit an exception (e.g., TTL
520 error) during layer 3 forwarding
522 - Contains packet traps for packets that were dropped by the device due to
525 - Contains packet traps for packets that were dropped by the device during
526 tunnel encapsulation / decapsulation
528 - Contains packet traps for packets that were dropped by the device during
531 - Contains packet traps for STP packets
533 - Contains packet traps for LACP packets
535 - Contains packet traps for LLDP packets
537 - Contains packet traps for IGMP and MLD packets required for multicast
540 - Contains packet traps for DHCP packets
541 * - ``neigh_discovery``
542 - Contains packet traps for neighbour discovery packets (e.g., ARP, IPv6
545 - Contains packet traps for BFD packets
547 - Contains packet traps for OSPF packets
549 - Contains packet traps for BGP packets
551 - Contains packet traps for VRRP packets
553 - Contains packet traps for PIM packets
555 - Contains a packet trap for unicast loopback packets (i.e.,
556 ``uc_loopback``). This trap is singled-out because in cases such as
557 one-armed router it will be constantly triggered. To limit the impact on
558 the CPU usage, a packet trap policer with a low rate can be bound to the
559 group without affecting other traps
560 * - ``local_delivery``
561 - Contains packet traps for packets that should be locally delivered after
562 routing, but do not match more specific packet traps (e.g.,
564 * - ``external_delivery``
565 - Contains packet traps for packets that should be routed through an
566 external interface (e.g., management interface) that does not belong to
567 the same device (e.g., switch ASIC) as the ingress interface
569 - Contains packet traps for various IPv6 control packets (e.g., Router
572 - Contains packet traps for PTP time-critical event messages (Sync,
573 Delay_req, Pdelay_Req and Pdelay_Resp)
575 - Contains packet traps for PTP general messages (Announce, Follow_Up,
576 Delay_Resp, Pdelay_Resp_Follow_Up, management and signaling)
578 - Contains packet traps for packets that were sampled by the device during
581 - Contains packet traps for packets that were trapped (logged) by the
582 device during ACL processing
583 * - ``parser_error_drops``
584 - Contains packet traps for packets that were marked by the device during
590 As previously explained, the underlying device can trap certain packets to the
591 CPU for processing. In most cases, the underlying device is capable of handling
592 packet rates that are several orders of magnitude higher compared to those that
593 can be handled by the CPU.
595 Therefore, in order to prevent the underlying device from overwhelming the CPU,
596 devices usually include packet trap policers that are able to police the
597 trapped packets to rates that can be handled by the CPU.
599 The ``devlink-trap`` mechanism allows capable device drivers to register their
600 supported packet trap policers with ``devlink``. The device driver can choose
601 to associate these policers with supported packet trap groups (see
602 :ref:`Generic-Packet-Trap-Groups`) during its initialization, thereby exposing
603 its default control plane policy to user space.
605 Device drivers should allow user space to change the parameters of the policers
606 (e.g., rate, burst size) as well as the association between the policers and
607 trap groups by implementing the relevant callbacks.
609 If possible, device drivers should implement a callback that allows user space
610 to retrieve the number of packets that were dropped by the policer because its
611 configured policy was violated.
616 See ``tools/testing/selftests/drivers/net/netdevsim/devlink_trap.sh`` for a
617 test covering the core infrastructure. Test cases should be added for any new
620 Device drivers should focus their tests on device-specific functionality, such
621 as the triggering of supported packet traps.