Skip to content

Vxlan tunnel 7717 v2.4#14820

Closed
catenacyber wants to merge 4 commits intoOISF:mainfrom
catenacyber:vxlan-tunnel-7717-v2.4
Closed

Vxlan tunnel 7717 v2.4#14820
catenacyber wants to merge 4 commits intoOISF:mainfrom
catenacyber:vxlan-tunnel-7717-v2.4

Conversation

@catenacyber
Copy link
Contributor

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/7717

Describe changes:

  • Treat vxlan as its own tunnel in order to be able to log ARP over VXLAN
  • ebpf: check maps compatibility (and realize that our current ebpf did not handle 3 layers of vlan)

SV_BRANCH=OISF/suricata-verify#2521

These are the first commits before #14378 with a dedicated ticket

#14369 with review taken into account

ebpf program now handles 3 layers of vlan
Instead of directly accessing the field

Will allow PacketTunnelType to hold the precise tunnel type like
DECODE_TUNNEL_ERSPANII with a modification of PacketIsTunnelChild
Ticket: 7717

Allows for instance to process/log ARP packets over VXLAN.

That means we need to decode the ethernet layer above vxlan
instead of skipping it as part of the vxlan, even if the vxlan
decoder still checks the ethernet layer to avoid FPs.
@catenacyber catenacyber requested review from a team and victorjulien as code owners February 16, 2026 10:33
SCLogError("Too many BPF maps in eBPF files");
break;
}
if (strcmp(bpf_map__name(map), "flow_table_v4") == 0) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See https://github.com/OISF/suricata/pull/14820/changes#r2811731591 I wonder if we should add some magic for padding/alignment...

This was referenced Feb 16, 2026
@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline = 29617


/* tunnel type: none, root or child */
enum PacketTunnelType ttype;
uint8_t ttype; // enum PacketTunnelType
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably also move it to the first cacheline, as there is a 2 byte gap there and this field should also not change after it has been set.

	uint8_t                    proto;                /*    44     1 */
	uint8_t                    recursion_level;      /*    45     1 */
	uint16_t                   vlan_id[3];           /*    46     6 */
	uint8_t                    vlan_idx;             /*    52     1 */
	uint8_t                    flowflags;            /*    53     1 */
	uint8_t                    app_update_direction; /*    54     1 */
	uint8_t                    sig_mask;             /*    55     1 */
	uint16_t                   pkt_hooks;            /*    56     2 */

	/* XXX 2 bytes hole, try to pack */

// MOVE HERE?

	uint32_t                   flags;                /*    60     4 */
	/* --- cacheline 1 boundary (64 bytes) --- */
	struct Flow_ *             flow;                 /*    64     8 */
	uint32_t                   flow_hash;            /*    72     4 */
	uint8_t                    ttype;                /*    76     1 */

	/* XXX 3 bytes hole, try to pack */

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool

@catenacyber
Copy link
Contributor Author

Next version in #14837

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants