Contributed by Peter N. M. Hansteen on from the ERSPAN in the works dept.
erspan(4).
An early version of the code, but possibly close to being ready for further development in-tree was
presented
by David Gwynne (dlg@) in a
message to tech@:
List: openbsd-tech Subject: erspan(4): ERSPAN Type II collection From: David Gwynne <david () gwynne ! id ! au> Date: 2025-05-12 1:27:59 we were exploring how to better let us see what's happening on access networks or specific ports on a switch at work. our switches are pretty much all cisco, which has ERSPAN. ERSPAN in it's various forms ships Ethernet packets over GRE for collection and analysis on another system. There's 3 types of ERSPAN encapsulation, but Type II seems broadly implemented.
this implements support for ERSPAN Type II in OpenBSD as a tunnel interface. this allows OpenBSD to collect ERSPAN encapsualted packets with existing tooling, particularly those built around BPF (like tcpdump and bpflogd). it also supports transmitting packets, so it can be added as a span port on bridge(4) or veb(4). unfortunately this means it can actually work as a tunnel interface, but i can't stop people doing every silly thing they want to do. ERSPAN type II is supposed to be configured between two endpoints, a sender and receiver, and includes a Session ID in it's shim header so you can tell different capture sessions apart. this configuration is mapped to ifconfig erspanX tunnel LOCALIP REMOTEIP for the endpoint addresses, and ifconfig erspanX vnetid SESSIONID for the session id. you can wildcard the remote ip by not specifying one, ie, ifconfig erspan0 tunneladdr LOCALIP. this lets the interface capture all erspan packets sent to it, regardless of where it comes from. however, this disables it's ability to transmit packets. in this mode you can also unset the vnetid to allow reception of packets for all ERSPAN sessions. the driver shows the encapsulated Ethernet packets via BPF, ie, tcpdump -i erspanX will show the Ethernet packet that are captured on the remote device. it also supports BPF with the DLT_LOOP type to show the encapsulating IP, GRE, and ERSPAN headers. eg: if i have a collector interface set up like this: $ ifconfig erspan0 erspan0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,MONITOR> mtu 1500 lladdr fe:e1:ba:d0:9e:d8 index 7 priority 0 llprio 3 encap: vnetid none txprio packet rxprio payload groups: erspan tunnel: inet 192.168.2.3 ttl 64 nodf so if the remote device captured this Ethernet frame: 11:16:26.975309 78:72:5d:29:b9:bf 01:00:5e:00:00:66 8100 118: 802.1Q vid 33 pri 6 \ 10.153.135.3.1985 > 224.0.0.102.1985: [udp sum ok] HSRPv1 [tos 0xc0] [ttl 1] (id 0, \ len 100) you can also capture the transport header so you can tell where it came from with tcpdump -y LOOP (-vveeni erspan0 -s1600), which looks like this: 11:16:26.975309 192.168.128.153 > 192.168.2.3: gre [S] 88be seq 0 erspan II session \ 11 vlan payload cos 0 index 2752: 78:72:5d:29:b9:bf 01:00:5e:00:00:66 8100 118: \ 802.1Q vid 333 pri 6 192.168.135.3.1985 > 224.0.0.102.1985: [udp sum ok] HSRPv1 [tos \ 0xc0] [ttl 1] (id 0, len 100) (ttl 248, id 55158, len 154) 192.168.128.153 is a switch that has a capture session configured. wiring this into bpf also means i can use bpflogd to write all the collected packets to disk without stopping people running tcpdump against the interface to watch packets live, or even use something like the remote ssh capture stuff in wireshark. cos erspan is GRE, it can reuse a lot of what's already there in if_gre.c as well as cisco devices, ive tested this as a collector for monitoring sessions from a vmware dvswitch. i dont know if anyone else is interested in this stuff or if it's just me. Index: if_gre.c =================================================================== [ … ]
with the rest of the message presenting the patch for those of us who will want to test and/or read the code.
If you have ERSPAN capable equipment, we strongly suggest you want this, and we encourage you to set up to test and report back.