GRE tunnel introspection for sFlow

[simonschdev]

Background

Generic Routing Encapsulation (GRE) is a tunneling protocol that allows to encapsulate data of various protocols (most prominently Ethernet and IP) in IP packets. For example, an Ethernet frame encapsulated in an IP packet would lead to the following overall header structure:

Outer Ethernet header | Outer IP header | GRE header | Encapsulated Ethernet frame

Alternatively, it is also possible to encapsulate pure IP packets only, using the following header structure:

Outer Ethernet header | Outer IP header | GRE header | Encapsulated IP packet

Most relevantly, the GRE header includes a field for the protocol type of the encapsulated protocol, which uses the EtherType codes.

Naturally, multiple GRE layers can be nested.

Problem

Currently, the header parsing for sFlow considers GRE a blackbox layer-4 protocol, only parses the outer headers, and records the corresponding flow information. For demonstration, we provide a PCAP file, containing sFlow records for 5 different flows that are encapsulated in an IP flow from 1.1.1.1 to 2.2.2.2. When recording these packets with sfcapd, nfdump shows the following records:

Date first seen         Duration         Proto      Src IP Addr:Port          Dst IP Addr:Port   Packets    Bytes Flows
2024-08-23 13:28:37.113     00:00:00.000 GRE            1.1.1.1:0     ->          2.2.2.2:0            1       84     1
2024-08-23 13:28:37.113     00:00:00.000 GRE            1.1.1.1:0     ->          2.2.2.2:0            1       70     1
2024-08-23 13:28:37.113     00:00:00.000 GRE            1.1.1.1:0     ->          2.2.2.2:0            1       90     1
2024-08-23 13:28:37.113     00:00:00.000 GRE            1.1.1.1:0     ->          2.2.2.2:0            1      106     1
2024-08-23 13:28:37.113     00:00:00.000 GRE            1.1.1.1:0     ->          2.2.2.2:0            1       42     1

However, in many scenarios where GRE tunneling is applied, the interesting flow information might be in the encapsulated packet.

Solution approach

We added a new command-line option -G to signal that sfcapd should consider the GRE-encapsulated packet relevant for extracting flow information. Whenever the -G flag is present and sfcapd encounters a GRE header (i.e., in sflow_process.c), the parsing restarts after the GRE header. This logic is applied recursively, i.e., always the 'innermost' packet is relevant for flow information.

Result & Tests

When feeding the same sFlow records as above to sfcapd with GRE parsing enabled, we observe the following nfdump output, making the tunneled flows visible:

Date first seen         Duration         Proto      Src IP Addr:Port          Dst IP Addr:Port   Packets    Bytes Flows
2024-08-23 13:49:27.054     00:00:00.000 UDP            3.3.3.3:53    ->          4.4.4.4:53           1       84     1
2024-08-23 13:49:27.054     00:00:00.000 UDP            5.5.5.5:53    ->          6.6.6.6:53           1       70     1
2024-08-23 13:49:27.054     00:00:00.000 UDP    7:7:7:7:7:7:7:7.53    ->  8:8:8:8:8:8:8:8.53           1       90     1
2024-08-23 13:49:27.054     00:00:00.000 UDP        11.11.11.11:53    ->      12.12.12.12:53           1      106     1
2024-08-23 13:49:27.054     00:00:00.000 GRE            1.1.1.1:0     ->          2.2.2.2:0            1       42     1

The last flow record with protocol GRE refers to a packet where the GRE header is not followed by any encapsulated packet (added for robustness checks).

Moreover, all tests run with make check still pass.

Contributors

This pull request is proposed by Simon Scherrer from NetFabric.ai.

[phaag]

Many thanks Simon for the pull request. I would propose, that for consistency sfcapd would take the same option arguments as nfpcapd does. This means for the more detailed fat-flows -o fat instead of -G. This would also allow more future options. Furthermore the outer most tunnel connection would go into the tunnel extension, which will preserve the original tunnel connection parameters.

If this is ok with you, I would accept this pull request and modify the code accordingly afterwards.

[simonschdev]

Hi Peter, many thanks for your reply - and sure, what you suggest makes a lot of sense. Let me know if I can help in any way!

[phaag]

Request accepted.
As discussed in an earlier comment, the cli option -G is going to be replaced in a future commit to be consistent with other options.