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
106 The ``devlink-trap`` mechanism supports the following packet trap actions:
108 * ``trap``: The sole copy of the packet is sent to the CPU.
109 * ``drop``: The packet is dropped by the underlying device and a copy is not
115 Generic packet traps are used to describe traps that trap well-defined packets
116 or packets that are trapped due to well-defined conditions (e.g., TTL error).
117 Such traps can be shared by multiple device drivers and their description must
118 be added to the following table:
120 .. list-table:: List of Generic Packet Traps
126 * - ``source_mac_is_multicast``
128 - Traps incoming packets that the device decided to drop because of a
130 * - ``vlan_tag_mismatch``
132 - Traps incoming packets that the device decided to drop in case of VLAN
133 tag mismatch: The ingress bridge port is not configured with a PVID and
134 the packet is untagged or prio-tagged
135 * - ``ingress_vlan_filter``
137 - Traps incoming packets that the device decided to drop in case they are
138 tagged with a VLAN that is not configured on the ingress bridge port
139 * - ``ingress_spanning_tree_filter``
141 - Traps incoming packets that the device decided to drop in case the STP
142 state of the ingress bridge port is not "forwarding"
143 * - ``port_list_is_empty``
145 - Traps packets that the device decided to drop in case they need to be
146 flooded (e.g., unknown unicast, unregistered multicast) and there are
147 no ports the packets should be flooded to
148 * - ``port_loopback_filter``
150 - Traps packets that the device decided to drop in case after layer 2
151 forwarding the only port from which they should be transmitted through
152 is the port from which they were received
153 * - ``blackhole_route``
155 - Traps packets that the device decided to drop in case they hit a
157 * - ``ttl_value_is_too_small``
159 - Traps unicast packets that should be forwarded by the device whose TTL
160 was decremented to 0 or less
163 - Traps packets that the device decided to drop because they could not be
164 enqueued to a transmission queue which is full
167 - Traps packets that the device decided to drop because they need to
168 undergo a layer 3 lookup, but are not IP or MPLS packets
169 * - ``uc_dip_over_mc_dmac``
171 - Traps packets that the device decided to drop because they need to be
172 routed and they have a unicast destination IP and a multicast destination
174 * - ``dip_is_loopback_address``
176 - Traps packets that the device decided to drop because they need to be
177 routed and their destination IP is the loopback address (i.e., 127.0.0.0/8
181 - Traps packets that the device decided to drop because they need to be
182 routed and their source IP is multicast (i.e., 224.0.0.0/8 and ff::/8)
183 * - ``sip_is_loopback_address``
185 - Traps packets that the device decided to drop because they need to be
186 routed and their source IP is the loopback address (i.e., 127.0.0.0/8 and ::1/128)
187 * - ``ip_header_corrupted``
189 - Traps packets that the device decided to drop because they need to be
190 routed and their IP header is corrupted: wrong checksum, wrong IP version
191 or too short Internet Header Length (IHL)
192 * - ``ipv4_sip_is_limited_bc``
194 - Traps packets that the device decided to drop because they need to be
195 routed and their source IP is limited broadcast (i.e., 255.255.255.255/32)
196 * - ``ipv6_mc_dip_reserved_scope``
198 - Traps IPv6 packets that the device decided to drop because they need to
199 be routed and their IPv6 multicast destination IP has a reserved scope
201 * - ``ipv6_mc_dip_interface_local_scope``
203 - Traps IPv6 packets that the device decided to drop because they need to
204 be routed and their IPv6 multicast destination IP has an interface-local scope
206 * - ``mtu_value_is_too_small``
208 - Traps packets that should have been routed by the device, but were bigger
209 than the MTU of the egress interface
210 * - ``unresolved_neigh``
212 - Traps packets that did not have a matching IP neighbour after routing
213 * - ``mc_reverse_path_forwarding``
215 - Traps multicast IP packets that failed reverse-path forwarding (RPF)
216 check during multicast routing
219 - Traps packets that hit reject routes (i.e., "unreachable", "prohibit")
220 * - ``ipv4_lpm_miss``
222 - Traps unicast IPv4 packets that did not match any route
223 * - ``ipv6_lpm_miss``
225 - Traps unicast IPv6 packets that did not match any route
226 * - ``non_routable_packet``
228 - Traps packets that the device decided to drop because they are not
229 supposed to be routed. For example, IGMP queries can be flooded by the
230 device in layer 2 and reach the router. Such packets should not be
231 routed and instead dropped
234 - Traps NVE and IPinIP packets that the device decided to drop because of
235 failure during decapsulation (e.g., packet being too short, reserved
236 bits set in VXLAN header)
237 * - ``overlay_smac_is_mc``
239 - Traps NVE packets that the device decided to drop because their overlay
240 source MAC is multicast
242 Driver-specific Packet Traps
243 ============================
245 Device drivers can register driver-specific packet traps, but these must be
246 clearly documented. Such traps can correspond to device-specific exceptions and
247 help debug packet drops caused by these exceptions. The following list includes
248 links to the description of driver-specific traps registered by various device
254 Generic Packet Trap Groups
255 ==========================
257 Generic packet trap groups are used to aggregate logically related packet
258 traps. These groups allow the user to batch operations such as setting the trap
259 action of all member traps. In addition, ``devlink-trap`` can report aggregated
260 per-group packets and bytes statistics, in case per-trap statistics are too
261 narrow. The description of these groups must be added to the following table:
263 .. list-table:: List of Generic Packet Trap Groups
269 - Contains packet traps for packets that were dropped by the device during
270 layer 2 forwarding (i.e., bridge)
272 - Contains packet traps for packets that were dropped by the device or hit
273 an exception (e.g., TTL error) during layer 3 forwarding
275 - Contains packet traps for packets that were dropped by the device due to
278 - Contains packet traps for packets that were dropped by the device during
279 tunnel encapsulation / decapsulation
284 See ``tools/testing/selftests/drivers/net/netdevsim/devlink_trap.sh`` for a
285 test covering the core infrastructure. Test cases should be added for any new
288 Device drivers should focus their tests on device-specific functionality, such
289 as the triggering of supported packet traps.