Page MenuHomeVyOS Platform

VPP: synchronize SA traffic counters back to Linux XFRM
Closed, ResolvedPublicFEATURE REQUEST

Description

Problem statement:

When IPsec traffic is forwarded in the VPP dataplane (bypassing the Linux kernel datapath), the Linux XFRM subsystem does not observe those packets. Consequently, kernel-side per-SA accounting (bytes/packets) does not reflect real traffic volume for SAs that are actively forwarding in VPP.

This can lead to incorrect or delayed behavior for kernel mechanisms that rely on XFRM counters/state, specifically:

  • SA lifetime handling when configured with byte-based or packet-based limits (expiry/rekey triggers may not fire as expected).
  • Kernel-side visibility/telemetry for IPsec SAs (e.g., ip -s xfrm state shows stale counters).
  • Potential inconsistency for replay protection/monitoring when the kernel is not tracking traffic progression for an offloaded SA.

Goal / requirement:

Provide a mechanism that ensures Linux XFRM SA byte/packet counters (and any required related SA state) are kept sufficiently synchronized for SAs whose traffic is forwarded by VPP, so that lifetime/accounting and operational observability remain correct. Additional key criteria: the new mechanism should not impact system or packet processing performance.

Details

Version
-
Is it a breaking change?
Perfectly compatible
Issue type
Feature (new functionality)

Event Timeline

Viacheslav triaged this task as Normal priority.Feb 10 2026, 5:46 PM
Viacheslav moved this task from Need Triage to Completed on the VyOS Rolling board.

Hello,

I observed some issues with rekey related to this ticket. With this patch enabled in vpp rekeying the child_sa is not working properly. It seems like the kernel sometimes will send a expired message for the newly established child SA.
In the strongswan logs you will see received a XFRM_MSG_EXPIRE and subsequent deletion of the new child sa. Sometimes rekeying will succeed, sometimes there will be 30 or more keyexchanges in a row.

I could reliably reproduce with sudo swanctl --rekey --child <tunnel>.

This doesn't happen without this patch.

Hi, @stevijo !

We have not seen anything like this in our tests.

I could reliably reproduce with sudo swanctl --rekey --child <tunnel>.

Could you please share a full config and the steps required to reproduce the issue, so we can reproduce it exactly in the way you do?

Thank you @zsdc for your fast response!

I tried to isolate the issue with two virtual vyos instances and newest rolling release and couldn't do it with that simplified config.

My setup here is also a bit special as I am connecting a NixOS linux box with a vyos running vpp via ipsec and there is a lot of variables.
I will dig a bit more, I might have prematurely commented here without trying to look deeper into the root cause.

Will let you know, when I have some configs to reproduce or if some of the other components might have been the culprit of the issue I am seeing.