d2b223ffca
SR-IOV binding driver uses pyroute2 library to set MAC addresses to VFs. This is internally implemented via ioctl(SIOCSIFHWADDR) giving it the name of that device. This is equal to calling 'ip link set dev $VFDEV address $MAC'. However, there is another way to set MAC address for VF. It works via netlink RTM_SETLINK message to the PF. This is equal to calling 'ip link set dev $PFDEV vf $VFID mac $MAC'. How it works: * ioctl(SIOCSIFHWADDR) asks the VF driver to set the MAC --> VF driver asks PF to set MAC for it --> PF sets the MAC for VF. * RTM_SETLINK message asks the PF to set MAC for VF --> PF sets the MAC for VF. In case of setting directly via PF, PF additionally sets an "administratively changed MAC" flag for that VF in the PF's driver, and from that point on (until the PF's driver is reloaded) that VF's MAC address can't be changed using the method #1. It's a security feature designed to forbid MAC changing by the guest OS/app inside the container. Above leads to the issue where SR-IOV CNI is not able to set MAC address for VF if its MAC was previously administratively set at least once (by hands or other software): ioctl SIOCSIFHWADDR: Cannot assign requested address kernel: igb 0000:05:00.0: VF 0 attempted to override administratively set MAC address Reload the VF driver to resume operations After that CNI fails the whole transaction, i.e. fails to change the interface name as well and subsequently fails the binding. Netlink PF method to change MAC addresses should be used always. This will additionally forbid the MAC changing from the inside of container. Change-Id: Ic47672e4ce645d9d37b520b6a412a44ae61036e1 Closes-Bug: 1825383 Co-authored-by: Danil Golov <d.golov@samsung.com> Signed-off-by: Ilya Maximets <i.maximets@samsung.com> |
||
|---|---|---|
| .zuul.d | ||
| contrib | ||
| devstack | ||
| doc | ||
| etc | ||
| kubernetes_crds | ||
| kuryr_kubernetes | ||
| playbooks | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .gitreview | ||
| .pre-commit-config.yaml | ||
| .stestr.conf | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| README.rst | ||
| babel.cfg | ||
| cni.Dockerfile | ||
| cni_ds_init | ||
| cni_py3.Dockerfile | ||
| controller.Dockerfile | ||
| controller_py3.Dockerfile | ||
| lower-constraints.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Team and repository tags
Project description
Kubernetes integration with OpenStack networking
The OpenStack Kuryr project enables native Neutron-based networking in Kubernetes. With Kuryr-Kubernetes it's now possible to choose to run both OpenStack VMs and Kubernetes Pods on the same Neutron network if your workloads require it or to use different segments and, for example, route between them.
- Free software: Apache license
- Documentation: https://docs.openstack.org/kuryr-kubernetes/latest
- Source: https://git.openstack.org/cgit/openstack/kuryr-kubernetes
- Bugs: https://bugs.launchpad.net/kuryr-kubernetes
- Overview and demo: https://superuser.openstack.org/articles/networking-kubernetes-kuryr
- Release notes: https://docs.openstack.org/releasenotes/kuryr-kubernetes/
Contribution guidelines
For the process of new feature addition, refer to the Kuryr Policy