xdptap - Fault Injection: Duplicating Packets
 
 

xdptap - Fault Injection: Duplicating Packets

May 26, 2025
development, projects, HOWTO
xdptap, IXDP, AF_XDP, libxdp, RPCL

Overview: Packet Duplication #

This is about the third fault type that can be injected with xdptap in bridging mode: Packet duplication. It works similar to the other two fault types: Fault injection needs to be enabled on the RX interface and the probability is controlled by setting fault.dup.probability to the desired value.

Further related posts:

RPCL Control #

Setting the Packet Duplication Probability #

fault.dup.probability #

set FI duplication probability in 1/100000 units ( probability interface - )

The fault.dup.probability is interface specific and can be set in 1/100000 units. Its default value is 0 (0.000%).

Example:

ok # setting 50% dup probability on RX interface 0: 
ok 50000 0 fault.dup.probability
ok # enabling FI:
ok 0 fault.enable
ok if.stats
0 enp1s0f0 ixgbe queues:1 ZEROCOPY
  rx                    5420540
  tx                    1836527
  drop                  0
  noif                  0
  err                   0
  RX tap                disabled
  TX tap                disabled
  fault injection       enabled
    drop probability    0 (0.000%)
    bitflip probability 0 (0.000%)
    dup probability     50000 (50.000%)
    dropped by FI       0
    bitflipped by FI    0
    duplicated by FI    2
1 enp1s0f1 ixgbe queues:1 ZEROCOPY
  rx                    1836533
  tx                    8129341
  drop                  6
  noif                  0
  err                   0
  RX tap                disabled
  TX tap                disabled
  fault injection       disabled
    drop probability    0 (0.000%)
    bitflip probability 0 (0.000%)
    dup probability     0 (0.000%)
    dropped by FI       0
    bitflipped by FI    0
    duplicated by FI    0
ok
For becoming visible with ping, the ICMP Echo Requests need to be duplicated - duplicated Echo Replies on the return path are not shown. A typical test with the 50% packet duplication probability setting from above may then look like this:
$ ping t31b
PING t31b (10.11.0.31) 56(84) bytes of data.
64 bytes from u31y (10.11.0.31): icmp_seq=1 ttl=64 time=0.866 ms
64 bytes from u31y (10.11.0.31): icmp_seq=2 ttl=64 time=0.866 ms
64 bytes from u31y (10.11.0.31): icmp_seq=2 ttl=64 time=0.866 ms (DUP!)
64 bytes from u31y (10.11.0.31): icmp_seq=3 ttl=64 time=0.943 ms
64 bytes from u31y (10.11.0.31): icmp_seq=4 ttl=64 time=0.926 ms
64 bytes from u31y (10.11.0.31): icmp_seq=4 ttl=64 time=0.926 ms (DUP!)
64 bytes from u31y (10.11.0.31): icmp_seq=5 ttl=64 time=0.834 ms
64 bytes from u31y (10.11.0.31): icmp_seq=6 ttl=64 time=0.933 ms
64 bytes from u31y (10.11.0.31): icmp_seq=6 ttl=64 time=0.933 ms (DUP!)
64 bytes from u31y (10.11.0.31): icmp_seq=7 ttl=64 time=0.923 ms
64 bytes from u31y (10.11.0.31): icmp_seq=7 ttl=64 time=0.923 ms (DUP!)
64 bytes from u31y (10.11.0.31): icmp_seq=8 ttl=64 time=0.737 ms
64 bytes from u31y (10.11.0.31): icmp_seq=9 ttl=64 time=0.861 ms
64 bytes from u31y (10.11.0.31): icmp_seq=9 ttl=64 time=0.861 ms (DUP!)
64 bytes from u31y (10.11.0.31): icmp_seq=10 ttl=64 time=0.954 ms
64 bytes from u31y (10.11.0.31): icmp_seq=11 ttl=64 time=0.923 ms
64 bytes from u31y (10.11.0.31): icmp_seq=11 ttl=64 time=0.923 ms (DUP!)
^C
--- t31b ping statistics ---
11 packets transmitted, 11 received, +6 duplicates, 0% packet loss, time 10035ms
rtt min/avg/max/mdev = 0.737/0.894/0.954/0.052 ms
$