Mirror or Redirect Traffic with tc-mirred Safely

tc-mirred is the action that copies or steals packets to another interface, and mixing up mirror with redirect is how you take down the wrong link. You'll attach it to an ingress filter, then choose between copying matching packets and moving them outright. The examples use the installed iproute2 version 6.1.0-1ubuntu6.4, whose tc reports iproute2-6.1.0. Allow about fifteen minutes for a disposable test interface, or longer if this touches a live network path.

• Root privileges for the commands that create interfaces, qdiscs, filters or actions.
• A destination interface the kernel can use, such as a dummy interface for observation or an IFB device for ingress processing.

This guide changes traffic handling on the selected interface. Do not test the redirect example on a production link without a console or another recovery path.

1. Confirm the installed syntax

Start with read-only checks. They confirm which binary and package you're about to use:

$ command -v tc
/usr/sbin/tc
$ tc -V
tc utility, iproute2-6.1.0, libbpf 1.3.0
$ dpkg-query -W -f='\${Package} \${Version}\n' iproute2
iproute2 6.1.0-1ubuntu6.4

The action boils down to four decisions:

• ingress or egress describes the direction in which the packet appears on the destination interface.
• mirror copies the packet and lets the original continue.
• redirect moves the packet, so the original path no longer receives it.
• The destination follows dev DEVICENAME, and an optional index INDEX gives the action a positive, unique 32-bit identifier.

The common shape is:

action mirred egress mirror dev DESTINATION
action mirred egress redirect dev DESTINATION

2. Create a harmless mirror destination

For a first test, create a dummy interface and bring it up. This only touches the local network namespace, and needs root:

# ip link add dummy0 type dummy
# ip link set dummy0 up
# ip link show dummy0

Expected output names dummy0 and shows it UP. The interface never sends the mirrored frames onto a physical network; it just gives you somewhere to inspect or count them.

# ip link delete dummy0 type dummy

Deleting the dummy interface removes its queued packets, and any filter that still references it loses its destination. Do this only after removing the filter in step 5.

3. Attach an ingress filter that mirrors selected packets

Replace eth0 with the interface whose incoming traffic you're examining. Add the ingress qdisc first, then a filter that matches ICMP packets and mirrors them to dummy0:

# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: protocol ip \
    u32 match ip protocol 1 0xff \
    action mirred egress mirror dev dummy0

Protocol number 1 is ICMP, so the u32 match selects IPv4 ICMP packets while mirred copies each match to the dummy interface. The original packet keeps to its normal path, because this is mirror, not redirect.

Verify the installed filter and action:

# tc filter show dev eth0 parent ffff:

Look for a match on the IP protocol and an action resembling mirred (Egress Mirror to device dummy0); exact counters and formatting vary. If the ingress qdisc already exists, tc qdisc add can fail with a file-exists error. Inspect it with tc qdisc show dev eth0, and never replace an existing production qdisc blindly.

4. Observe the copy without affecting the original

Run a capture in a second terminal. This is an ordinary read operation, though packet capture may need elevated privileges depending on your setup:

# tcpdump -ni dummy0 icmp

Generate a known test packet from another terminal, using an address that's safe and reachable in your environment:

$ ping -c 3 192.0.2.1

The documentation address 192.0.2.1 is reserved for examples and may not answer. What matters is that matching requests or replies show up on the mirror destination while the source command still follows its normal route. If nothing appears, check that the traffic is IPv4 ICMP, that eth0 is the right receiving interface, and that the filter is attached to the expected parent.

To inspect counters, ask for statistics:

# tc -s filter show dev eth0 parent ffff:

A rising packet counter is evidence the filter matched. It does not by itself prove a capture program read every copied packet.

5. Remove the test configuration

Remove the filter before deleting its destination. This is a state-changing operation and needs root:

# tc filter del dev eth0 parent ffff: protocol ip \
    u32 match ip protocol 1 0xff \
    action mirred egress mirror dev dummy0

Check that the filter is gone:

# tc filter show dev eth0 parent ffff:

If the output still shows the rule, do not delete the qdisc yet. Use the exact filter listing to identify the installed protocol, preference and handle, then remove that specific filter according to your host's existing configuration. The ingress qdisc may be shared with other filters, so never run tc qdisc del dev eth0 ingress as a generic cleanup command.

Once you've confirmed no required filter remains, remove only the dummy destination:

# ip link delete dummy0 type dummy

6. Redirect traffic only with a recovery plan

Redirecting is useful when traffic must pass through another processing path, but it isn't a second form of mirroring. A redirect steals the matching packet from the original path: if the destination is down, misconfigured or unable to process the packet, the service loses traffic.

The manpage's representative pattern redirects traffic that exceeds a police rate to the loopback interface. The smaller pattern below shows the action shape without claiming loopback is a suitable destination for your service:

# tc filter add dev eth0 parent ffff: protocol ip \
    u32 match u32 0 0 \
    action mirred egress redirect dev lo

# tc filter del dev eth0 parent ffff: protocol ip \
    u32 match u32 0 0 \
    action mirred egress redirect dev lo

For ingress shaping, an IFB destination is normally created and configured separately, then used as the redirect target. The destination interface must exist and be up; mirred does not create it or configure a qdisc on it.

7. Use an explicit action index when you need to manage it

Most one-off filters can let the kernel assign an action identifier. If another tool needs a stable one, add a positive index:

action mirred egress mirror index 42 dev dummy0

The index is an action ID, not a filter priority and not an interface number. Pick a value unique among the actions you manage, and confirm it in tc filter show output before writing automation around it.