Today, it is not possible to use host-device CNI to move a
host device to container namespace if a device already exists
in that namespace.
e.g when a delegate plugin (such as multus) is used to provide
multiple networks to a container, CNI Add call will fail if
the targeted host device name already exists in container network
namespace.
to overcome this, we use a temporary name for the interface before
moving it in/out of container network namespace.
Signed-off-by: adrianc <adrianc@nvidia.com>
The new `disableContainerInterface` parameter is added to the bridge plugin to
enable setting the container interface state down.
When the parameter is enabled, the container interface (veth peer that is placed
at the container ns) remain down (i.e: disabled).
The bridge and host peer interfaces state are not affected by the parameter.
Since IPAM logic involve various configurations including waiting for addresses
to be realized and setting the interface state UP, the new parameter cannot work
with IPAM.
In case both IPAM and DisableContainerInterface parameters are set, the bridge
plugin will raise an error.
Signed-off-by: Or Mergi <ormergi@redhat.com>
When the master interface on the node has been deleted, and loadConf tries
to get the MTU, This causes cmdDel to return a linkNotFound error to the
runtime. The cmdDel only needs to unmarshal the netConf. No need to
get the MTU. So we just replaced the loadConf function with
json.unmarshal in cmdDel.
Signed-off-by: cyclinder <qifeng.guo@daocloud.io>
This extends the tap plugin API enabling the user to instruct the CNI
plugin the created tap device must be set as a port of an *existing*
linux bridge on the pod network namespace.
This is helpful for KubeVirt, allowing network connectivity to be
extended from the pod's interface into the Virtual Machine running
inside the pod.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
Using ptp plugin with non default routes, we get the following error
when cri-o call CheckNetworkList():
```
Expected Route {Dst:{IP:198.18.128.0 Mask:ffff8000} GW:<nil>} not found in routing table
```
Using cniVersion 0.3.1 to bypass the check, we can see that the
route is added with a gateway
```
$ ip r
198.18.0.0/17 via 198.18.0.1 dev eth0 src 198.18.3.102
198.18.0.1 dev eth0 scope link src 198.18.3.102
198.18.128.0/17 via 198.18.0.1 dev eth0
```
If GW is nil only check if we have a route with a DST that matches, and
ignore the GW.
Fixes #886
Signed-off-by: Etienne Champetier <e.champetier@ateme.com>
add vlan trunk support for veth
vlan trunk only support L2 only mode without any IPAM
refer ovs-cni design
https://github.com/k8snetworkplumbingwg/ovs-cni/blob/main/pkg/plugin/plugin.go
design:
origin "vlan" option will be PVID or untagged vlan for the network.
"vlanTrunk" will setup tagged vlan for veth.
entry type:
`{ "id": 100 }` will specify only tagged vlan 100
`{ "minID": 100, "maxID": 120 }` will specify tagged vlan from 100 to
120 (include 100 and 120)
vlanTrunk is a list of above entry type, so you can use this to add
tagged vlan
`[
{ "id": 100 },
{
"minID": 1000,
"maxID": 2000
}
]`
complete config will be like this
{
"cniVersion": "0.3.1",
"name": "mynet",
"type": "bridge",
"bridge": "mynet0",
"vlan": 100,
"vlanTrunk": [
{ "id": 101 },
{ "minID": 1000, "maxID": 2000 },
{ "minID": 3000, "maxID": 4000 }
],
"ipam": {}
}
Signed-off-by: Date Huang <date.huang@suse.com>
this prevents the error to be lost which was causing the
panic while accesing a nil var.
Fix #830
Signed-off-by: Marcelo Guerrero Viveros <marguerr@redhat.com>
This commit updates the import of ginkgo to v2 in
all of the tests.
Signed-off-by: liornoy <lnoy@redhat.com>
Co-authored-by: Sascha Grunert <sgrunert@redhat.com>
This PR adds a plugin to create tap devices.
The plugin adds a tap device to the container.
The plugin has a workaround for a golang netlink library
which does not allow for tap devices with no owner/group
to be created. When no tap owner/group is requested, the
plugin will fall back to using the ip tool for creating
the tap device. A fix to the golang netlink lib is pending.
Signed-off-by: mmirecki <mmirecki@redhat.com>
It was noticed that, sometimes, the mac of the host-side of the veth
changes after setting up the bridge. So, just refresh it.
Fixes: #805
Signed-off-by: Casey Callendrello <c1@caseyc.net>
Leverages the Linux dummy interface type to create network interfaces
that permists routing packets through the Linux kernel without
them being transmitted.
This solution allows use of arbitrary non-loopback IP addresses within
the container.
Related to #466
Signed-off-by: Mircea Iordache-Sica <mircea@arista.com>
