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 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>
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>
Previously, the bridge plugin ignored DNS settings returned
from an IPAM plugin (e.g. the host-local plugin parsing
resolv.conf to configure DNS). With this change, the bridge plugin
uses IPAM DNS settings.
Similarly to #388, this change will use incoming DNS settings if set,
otherwise IPAM plugin returned DNS settings
Signed-off-by: Kern Walster <walster@amazon.com>
The new macspoofchk field is added to the bridge plugin to support
anti-mac-spoofing.
When the parameter is enabled, traffic is limited to the mac addresses
of the container interface (the veth peer that is placed in the
container ns).
Any traffic that exits the pod is checked against the source mac address
that is expected. If the mac address is different, the frames are
dropped.
The implementation is using nftables and should only be used on nodes
that support it.
Signed-off-by: Edward Haas <edwardh@redhat.com>
Controlling the mac address of the interface (veth peer) in the
container is useful for functionalities that depend on the mac address.
Examples range from dynamic IP allocations based on an identifier (the
mac) and up to firewall rules (e.g. no-mac-spoofing).
Enforcing a mac address at an early stage and not through a chained
plugin assures the configuration does not have wrong intermediate
configuration. This is especially critical when a dynamic IP may be
provided already in this period.
But it also has implications for future abilities that may land on the
bridge plugin, e.g. supporting no-mac-spoofing.
The field name used (`mac`) fits with other plugins which control the
mac address of the container interface.
The mac address may be specified through the following methods:
- CNI_ARGS
- Args
- RuntimeConfig [1]
The list is ordered by priority, from lowest to higher. The higher
priority method overrides any previous settings.
(e.g. if the mac is specified in RuntimeConfig, it will override any
specifications of the mac mentioned in CNI_ARGS or Args)
[1] To use RuntimeConfig, the network configuration should include the
`capabilities` field with `mac` specified (`"capabilities": {"mac": true}`).
Signed-off-by: Edward Haas <edwardh@redhat.com>
Instead of checking the total number of addresses, which might vary
depending on the IPv6 Privacy Address settings of the distro being
used, just check that we have the number of non-link-local addresses
we expect.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Removing content and pointing at the new website as a part of the CNI Documentation migration.
Signed-off-by: Nate W <4453979+nate-double-u@users.noreply.github.com>
fix #463
link host veth pair to bridge, the Initial state
of port is BR_STATE_DISABLED and change to
BR_STATE_FORWARDING async.
Signed-off-by: honglichang <honglichang@tencent.com>
If the Linux kernel is not built with the parameter
CONFIG_BRIDGE_VLAN_FILTERING, passing vlanFiltering in
the Bridge struct returns an error creating the bridge interface.
This happens even when no parameter is set on Vlan in the CNI config.
This change fixes the case where no Vlan parameter is configured on
CNI config file so the flag doesn't need to be included in the struct.
Signed-off-by: Carlos de Paula <me@carlosedp.com>
Now that libcni has the ability to print a version message, plumb it
through correctly.
While we're at it,
- fix import paths
- run gofmt
- add some more comments to sample
- add container runtime swappability for release
With the VLAN filter, the Linux bridge acts more like a real switch, Allow to tag and untag
vlan id's on every interface connected to the bridge.
This PR also creates a veth interface for the bridge vlan interface on L3 configuration.
Related to https://developers.redhat.com/blog/2017/09/14/vlan-filter-support-on-bridge/ post.
Note: This feature was introduced in Linux kernel 3.8 and was added to RHEL in version 7.0.
