Hi community !
I aim to accelerate proxmox packet processing with the bridge offload capabilities of connectx-6 and/or bluefield2 cards.
The particularity of my setup is that the proxmox manages routing VMs for which it provides vxlan termination. My proxmox uses BGP/EVPN to set up VXLAN tunnels and mac learning.
With the bluefield2 host mode (like simple connectx-6) I’ve deployed sriov with switchdev in eswitch mode. the VFs act as vnic for the virtual routers. it’s very reliable and the TC rules allow certain flows to be processed in hw (with the help of representor port).
however, despite activation of the anti spoof configuration, the VF does not filter the mac
ex :
/opt/mellanox/iproute2/sbin/ip l set ens1f1np1 vf 30 spoofchk on
i wondered if the mac anti spoof is well supported in eswitch mode. i don’t have an obvious answer however the following mlx5_core log is sent when i hot swap the mac with the command
/sbin/ip link set ens1f1np1 vf 30 mac 11:22:33:44:55:66
log :
[Tue Dec 10 17:45:48 2024] mlx5_core 0000:12:00.1: mlx5_esw_set_vport_mac_locked:2361:(pid 27158): Set invalid MAC while spoofchk is on, vport(1)
rejecting my forged mac is appreciate because it say something important
mlx5 refuse mac type local_usage, mlx5 expects real OUI mac
hum, interesting…
the function named mlx5_esw_set_vport_mac_locked is quite clear:
it suggests that the eswitch support vport mac lock aka “mac anti spoof”
let’s go deeper into the code
eswitch interactions with kernel is describe in drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
My anderstanding :
If spoofchk is enabled (evport->info.spoofchk = true), the NIC (ConnectX-6) should apply the check in hardware. This means that packet rejection does not depend on this code, but is handled at hardware level.
The key function for setting the MAC address is :
err = mlx5_modify_nic_vport_mac_address(esw->dev, vport_num, mac);
If this configuration is successful, the hardware knows the valid MAC address associated with this vport and rejects packets with a different MAC source address.
this is unfortunately not the behavior I observe…
a little help would be appreciated
thx