Out-of-band ping

The libevl tree comes with an example illustrating a basic usage of the EVL network stack implementing an ICMPv4(ECHO) responder, named oob-net-icmp. In order to run this example, you need two computers on the same ethernet LAN, one is the target system running EVL (the responder), the other may be any box which can issue ICMPv4 packets (the issuer).

Configuring the ICMPv4 responder

As explained earlier, there are two ways for enabling out-of-band traffic to flow through a network device using EVL. We are going to illustrate the one using VLAN tagging. In this configuration, the following steps are required before you can send/receive network packets through the EVL network stack on the target system:

  1. Create a regular VLAN interface on top of a physical network device attached to the system.

  2. Turn the new VLAN interface into an EVL network port, this can be done either programmatically, or by writing to a device-specific pseudo-file /sysfs. Under the hood, this adds an EVL-specific context to the underlying physical device supporting the VLAN interface, allocating the resources needed for dealing with out-of-band traffic.

  3. Add the new VLAN identifier to the set of out-of-band VLANs EVL monitors, so that it picks incoming packets flowing on those instead of leaving them for processing by the regular network stack.

For instance, enabling out-of-band networking over VLAN #42 on the physical network interface named ’eth0’ would translate to the following shell commands:

# Attach a VLAN device with tag 42 to the real 'eth0' device
$ sudo ip link add link eth0 name eth0.42 type vlan id 42

# Assign an arbitrary address to that VLAN device, e.g. 10.10.10.11
$ sudo ip addr add 10.10.10.11/24 dev eth0.42

# Tell EVL that the VLAN device is an out-of-band network port:
$ sudo evl net -ei eth0.42

# Eventually, tell EVL to pick packets tagged for VLAN 42 (you could ask EVL
# to monitor multiple VLANs by passing a list of tags like '42-45,100,107'
# the same way):
$ sudo -c "echo 42 > /sys/class/evl/net/vlans"

Configuring the ICMPv4 issuer

Now let’s run a ping command from the issuing box to the IP address of the VLAN device created earlier for the responder on the target system (that box does not have to run EVL). All you need is create a peer VLAN device on that box attached to the same ethernet LAN, then ping the responder machine which runs the oob-net-icmp program, e.g. assuming ’eno2’ is the name of the physical network interface on such host:

# sudo ip link add link eno2 name eno2.42 type vlan id 42
# sudo ip addr add 10.10.10.10/24 dev eno2.42
# sudo ip link set eno2.42 up
# ping 10.10.10.11

Some NICs (e.g. Intel e1000) may need a delay between the moment the VLAN filter is updated and the link is enabled in their hardware. If in doubt, make sure to pause for a short while between both operations, especially if the corresponding ‘ip’ commands are part of a shell script.

Eventually, this test program running on the EVL-enabled machine should output traces as it replies to the ICMPv4(ECHO) requests, e.g.:

# /usr/evl/tidbits/oob-net-icmp -i eth0.42
listening to interface eth0.42
[0] count=84, proto=0x800, ifindex=2, type=0, halen=6, mac=xx:xx:xx:xx:xx:xx
[1] count=84, proto=0x800, ifindex=2, type=0, halen=6, mac=xx:xx:xx:xx:xx:xx
[2] count=84, proto=0x800, ifindex=2, type=0, halen=6, mac=xx:xx:xx:xx:xx:xx
[3] count=84, proto=0x800, ifindex=2, type=0, halen=6, mac=xx:xx:xx:xx:xx:xx
[4] count=84, proto=0x800, ifindex=2, type=0, halen=6, mac=xx:xx:xx:xx:xx:xx
[5] count=84, proto=0x800, ifindex=2, type=0, halen=6, mac=xx:xx:xx:xx:xx:xx

Interpreting ping statistics

Even in favorable LAN setup and traffic conditions (small lan, fast switch, few hosts, low collision rate), do not over- or misinterpret the roundtrip times reported by the ping command on the issuer:

  • flooding the responder may cause delays due to verbose tracing because the buffer of the EVL proxy to stdout those traces go through might saturate, blocking the caller until it drains. At the very least, turn on the silent mode (’-s’ option switch) for the responder program to prevent this.
  • when considering the average roundtrip time reported, you need to account for the fact that the ICMPv4 responder to ping is normally the remote kernel, not an application running in user-space. The fact that such application gains real-time support with EVL may not fully compensate for the cost of transitioning from kernel to user-space on average when the responder system is stressed.
  • when considering the maximum roundtrip time reported, you need to factor in whether the NIC driver on the responder system is out-of-band capable or not. If not, then a larger portion of the roundtrip does not benefit from real-time support.

In other words, if you want to accurately compare the latency figures between the EVL-enabled network stack and the regular one, you need 1) to have an out-of-band capable NIC driver, 2) to have strictly identical issuer <-> responder set-ups, 3) to look for the worst-case figure, although the average figure is significant, the maximum latency and jitter figures are key in this context.

Last modified: Thu, 26 Jun 2025 23:32:10 +0200