Closed zshi-redhat closed 2 years ago
@zshi-redhat So this wouldn't be possible with tuning CNI chained because we don't know the interface name in advance?
{
"name": "mytuning",
"type": "tuning",
"sysctl": {
"net.ipv4.conf.${INTERFACE_NAME}.arp_notify": "1"
}
}
So, a potential SRIOV CNI NAD spec would look like below?:
{
"cniVersion": "0.3.1",
"name": "sriov-advanced",
"type": "sriov",
"trust": "on",
"garp": "on",
...
}
@martinkennelly I just got to know that it's not necessary to specify the interface name in CNI net-attach-def config, chained CNI like tuning CNI inherits the CNI result passed down from previous CNI which contains the args.IfName.
I need to check if it's possible to use tuning CNI for arp notificuation. What I noticed is that tuning CNI implements its own logic for sending arp notification, which relies on specifying a MAC change in the same tuning plugin. but in sriov case, we use sriov-cni to change the MAC address. Another thing is kernel/driver has support for generating garp packet for VF devices, while current implementation in tuning CNI doesn't make use of it. Also kernel/driver requires the device link be restarted in order to send the garp packet, not sure if tunning CNI would restart the link (down & up).
Question: shouldn't we send GARP by default on CmdAdd ?
Question: shouldn't we send GARP by default on CmdAdd ?
Nope with current sriov-cni implementation.
Two changes are required in sriov-cni to be able to send GARP: 1) Enable arp_notify for the VF device 2) Restart VF link (down & up) while IP has been assigned to VF Both the two are not met in sriov-cni.
@zshi-redhat im aware we are not doing that in SR-IOV CNI today, My question is, should we do that by default ? (say if IPAM is specified)
@zshi-redhat im aware we are not doing that in SR-IOV CNI today, My question is, should we do that by default ? (say if IPAM is specified)
I think so.
I saw mentions of using tuning plugin for that hence my previous question.
My 2 cent is that we should not rely on chained plugins for correct operation of SRIOV cni. It seems that sending GARP is a missing step in CmdAdd call
I'm working on a PR to add garp support in sriov-cni.
For IPv6: net.ipv6.conf.<interface>.ndisc_notify=1
Most probably it is enabled by default, but better would be to set it for sure.
The issue is to request adding GARP support in sriov-cni
What would you like to be added?
GARP packet is sent by kernel when /proc/sys/net/ipv4/conf//arp_notify is set to 1.
What is the use case for this feature / enhancement?
IP address allocated to VF may be re-used while SR-IOV pods are restarted/recreated in a cluster. It is desired to broadcast GARP packet while IP assignment is changed for a particular VF MAC.