Add support for sniffing L2GRE encapsulated traffic to Packetbeat
- Dominant language
- Go
- Stars
- 12.7k
- Forks
- 5k
- Avg merge
- 2d 15m
- Merged PRs (30d)
- 385
Description
We've used Packetbeat for many purposes, and appreciate the ability to generate JSON data directly off the wire. Normally, we can place a network sniffer running beats right on a system connected to a span or tap to get the data we need, but in some cases, we want to use a remote sensor.
Several switch, router, and network aggregation and monitoring equipment (Gigamon, Cisco, Aruba etc.) can transmit locally monitored traffic over a layer 2 transport GRE tunnel. Essentially, a GRE connection is nailed up between the local system (Sniffer, Gigamon, etc.) and all traffic seen on the monitor port is encapsulated in GRE and sent up to the remote host.
The entire layer two (Ethernet) packets are included in the tunnel, so all that should need be done is to strip or ignore the first 37 bytes of data, which will expose a full frame. Then Packetbeat could work as normal when reassembling flows and decoding the protocol traffic.
Below is a screenshot of a Wireshark dissection of a sample DNS query encapsulated in GRE.

Contributor guide
Research direction
Start by tracing Packetbeat's packet-capture and protocol-decoding path, then compare it with the Wireshark dissection linked in the issue. Determine where the 37-byte L2GRE encapsulation can be handled so the inner Ethernet frame reaches normal flow reassembly and protocol decoding. Done means encapsulated traffic, including the sample DNS query, is processed as ordinary Packetbeat traffic.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100