Configure trust on sriov network

Incus
,
1

Hello,

i’m setting up a vrrp instance on my container with a sriov network attached.

for vrrp advertisements sent to multicast to work, trust must be on on the interface:

vf 5 link/ether 10:66:6a:2c:f2:5a brd ff:ff:ff:ff:ff:ff, vlan 40, spoof checking off, link-state auto, trust off

is there a way to configure this setting in incus ?

kind regards,

2

I’m managing several routers in VRRP with SR-IOV network devices, and have no problem relaying advertisements with trust off. What exactly is lacking in your case?

3

well, basically, my backup container doesn’t receive the advertisements from the master while the master receive the advertisements from the backup.

i checked everything, multicast enabled, firewall allowed.
this is the keepalived config:

vrrp_instance vrrp6_homelab {
    version 3
    # Set the state to "BACKUP" on the backup device
    state BACKUP
    interface homelab
    virtual_router_id 40
    # Set priority lower on the backup device
    priority 100
    advert_int 1
    no_accept
    use_vmac vrrp6_homelab
    garp_master_refresh 60
    virtual_ipaddress {
        # Link local must be specified first for IPv6.
        fe80::b00b:1/64
        2a0c:9a40:2753:b00b::1/64
    }
}

i asked because chatgpt suggested that this is the likely cause:

Perfect — now it’s confirmed:

vf 58 ... spoof checking on, trust off

That’s the smoking gun. With trust off, the VF cannot:

  • Accept packets for a different MAC (your VRRP VMAC).

  • Receive multicast traffic like ff02::12.

This is enforced in hardware by the NIC, so even if keepalived creates the VMAC inside the container, the NIC drops those packets before they reach the container.

4

Ah, I’m not using vMAC, so that may well be our fundamental difference here.
Not sure how well incus plays with its containers changing MAC addresses tho.
I’m interested in more feedback because I may switch to using vMAC addresses in the future.

5

Adding an sriov NIC property to Incus to allow marking it as trusted (security.trusted or similar) wouldn’t be particularly hard to add if useful.

We’d basically use the same logic we have for other VF properties where we need to record their initial state and then restore it on stop.

6

Super, i will make a feature request on github then.

7

Hi @stgraber,

I have a use-case for the trusted feature as well. Configuring an active-passive failover bond inside a VM requires the MAC address of the interface to be changeable by the guest (related feature spec in OpenStack).

Do you know whether progress has been made on this feature in the meantime? I could not find the mentioned issue.

If not, I could open that and attempt a PR if you like. I’ve not yet programmed in Go however, so this may require more feedback loops than a usual contributor :sweat_smile:

8

That should in no way refrain you from trying! I hadn’t done any Go before contributing to Incus either, and it’s the kind and patient feedback loop that actually made me want to continue contributing and try harder.

9

I can’t find an open issue for it on Github so I guess that’s why there hasn’t been any progress on this.

Would definitely be great if you could take a stab at it!

10

Thanks to both of you. I’ve opened Incus issue #2864 to track this feature :slight_smile: