Summary

VPP sFlow does not generate packet flow samples when enabled on a VyOS VPP bonding interface.
At the same time, VyOS configuration validation rejects enabling sFlow directly on the physical interfaces that are members of the VPP bond.
Manual runtime configuration in VPP proves that sFlow works correctly on those physical bond member interfaces (eth2 and eth3) and immediately generates valid FLOW samples.
As a result, with a VPP bond there is currently no working persistent VyOS configuration for VPP sFlow packet sampling:
vppbond0 is accepted by VyOS, but generates no packet samples.
eth2 / eth3 generate packet samples correctly in VPP, but VyOS refuses to configure them because they are bond members.

Relevant documentation behavior

The VyOS rolling documentation for VPP sFlow states that sFlow can be enabled on selected VPP interfaces and that only received traffic is sampled.
For a VPP bond topology, the current validation and runtime behavior leave no interface that can be configured through VyOS and actually generate packet flow samples.

Topology

       VPP bond
    BondEthernet0
     /          \
  eth2          eth3
   |              |
DPDK RX        DPDK RX

Tagged traffic seen on physical members:

VLAN 301 - subscriber side
VLAN 998 - external side

VyOS configuration

set system sflow agent-address '192.168.60.11'
set system sflow polling '30'
set system sflow sampling-rate '1000'
set system sflow server 192.168.60.46 port '6343'
set system sflow vpp
set vpp sflow header-bytes '128'

Test 1: VPP VLAN subinterface

Trying:

set vpp sflow interface 'vppbond0.301'

fails on commit:

[ vpp sflow ]
vppbond0.301 must be a VPP interface for sFlow monitoring
[[vpp sflow]] failed

[ system sflow ]
dependent vpp_sflow: vppbond0.301 must be a VPP interface for sFlow
monitoring
[[system sflow]] failed

Commit failed

This test is included for completeness. The main issue is the bond/bond-member behavior below.

Test 2: Physical bond members

Trying to configure the physical interfaces:

set vpp sflow interface 'eth2'
set vpp sflow interface 'eth3'

fails on commit:

[ vpp sflow ]
Interface eth2 is already used as VPP bonding member interface and
cannot be added to a VPP feature
[[vpp sflow]] failed

[ system sflow ]
dependent vpp_sflow: Interface eth2 is already used as VPP bonding
member interface and
cannot be added to a VPP feature
[[system sflow]] failed

Commit failed

The same restriction applies to the other bond member.

Test 3: Bond interface

VyOS accepts:

set vpp sflow interface 'vppbond0'

The resulting VPP runtime state shows the bond not enabled:

vpp# show sflow      
sflow sampling-rate 1000
sflow direction rx
sflow polling-interval 30
sflow header-bytes 128
sflow drop-monitoring disable
Status
  interfaces enabled: 0
  packet samples sent: 0
  packet samples dropped: 0
  counter samples sent: 0
  counter samples dropped: 0
  drop samples sent: 0
  drop samples dropped: 0
vpp# exit

after manually interface BondEthernet0 enabling

root@nat2:/home/pautina# sudo vppctl sflow enable-disable BondEthernet0
root@nat2:/home/pautina# sudo vppctl show sflow 
sflow sampling-rate 1000
sflow direction rx
sflow polling-interval 30
sflow header-bytes 128
sflow drop-monitoring disable
sflow enable BondEthernet0
Status
  interfaces enabled: 1
  packet samples sent: 0
  packet samples dropped: 0
  counter samples sent: 1
  counter samples dropped: 0
  drop samples sent: 0
  drop samples dropped: 0
root@nat2:/home/pautina#

No FLOW records are received by the collector. Only periodic counter records are exported.

Runtime test proving that sFlow works on bond members

The physical members are:

7: eth2 ... alias MLX-0
8: eth3 ... alias MLX-1

Feature configuration shows both physical interfaces use bond-input on the device input path.

Manually enabling sFlow directly in VPP on eth2:

sudo vppctl sflow enable-disable eth2

immediately produces:

sflow sampling-rate 1000
sflow direction rx
sflow polling-interval 30
sflow header-bytes 128
sflow drop-monitoring disable
sflow enable eth2

Status
  interfaces enabled: 1
  packet samples sent: 593
  packet samples dropped: 0
  counter samples sent: 2
  counter samples dropped: 0
  drop samples sent: 0
  drop samples dropped: 0

The collector immediately receives valid packet FLOW samples, including tagged traffic from both relevant VLANs:

FLOW,192.168.60.11,7,0,...,0x0800,998,0,80.93.115.31,100.210.248.4,6,...,443,17116,...,1000
FLOW,192.168.60.11,7,0,...,0x0800,301,0,172.16.249.80,62.221.75.108,17,...,50143,26676,...,1000

The same runtime test was performed on eth3:

sudo vppctl sflow enable-disable eth3

and valid FLOW records are generated immediately:

FLOW,192.168.60.11,8,0,...,0x0800,301,0,172.16.246.78,142.251.152.4,17,...,38818,443,...,1000
FLOW,192.168.60.11,8,0,...,0x0800,998,0,74.125.250.240,100.210.248.22,17,...,3478,34838,...,1000

Linux interface indexes confirm:

7: eth2
8: eth3

Therefore the sFlow inputPort values in the received records correspond directly to the physical bond members.