[24.11] Initial platform support for layer-3 routed networks (L3-VNI)

[sysvinit]

This change adds initial support for using EVPN-VXLAN as a transport for layer 3 routed-to-the-host networking. Networks which have the layer3 flag set in the ENC data will have an additional VRF device will be created which will be configured as the parent interface for other devices associated with that network (bridge device, VXLAN device).

PL-133324

@flyingcircusio/release-managers

Release process

• Created changelog entry using ./changelog.sh

PR release workflow (internal)

• PR has internal ticket
• internal issue ID (PL-…) part of branch name
• internal issue ID mentioned in PR description text
• ticket is on Platform agile board
• ticket state set to Pull request ready
• if ticket is more urgent than within the next few days, directly contact a member of the Platform team

Design notes

• Provide a feature toggle if the change might need to be adjusted/reverted quickly depending on context. Consider whether the default should be on or off. Example: rate limiting.
• All customer-facing features and (NixOS) options need to be discoverable from documentation. Add or update relevant documentation such that hosted and guided customers can understand it as well.

Security implications

• Security requirements defined? (WHERE)
  • This is a initial preview for a new feature, however this is gated behind an ENC flag which is currently not implemented in the directory. Merging this should not cause any changes in behaviour on existing hosts.
• Security requirements tested? (EVIDENCE)
  • Tested on various hardware hosts in DEV.

[ctheune]

We should review this together - I can't quite follow all the code and have the impression that we might want to pay attention to comments and factoring to keep it readable/understandable for the future us's.

[ctheune]

HMMM! This is interesting, we should check back with our vlan/vxlan/... numbering scheme and whether that can fit without shifting the values ...?

[sysvinit]

That's not a bad idea actually. We definitely have space in the numbering scheme as it stands at present, so we could reserve those four IDs and then map the virtual network ID one-to-one to kernel tables.

[ctheune]

agreed. add assertions and update the docs.