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.
host-local and static ipam plugins
tuning, bandwidth and portmap meta plugins
Utility functions created for common PrevResult checking
Fix windows build
Recent CNI specification changes require the container ID on ADD/DEL,
which the testcases were not providing. Fix that up so things work
when this repo gets CNI revendored.
Namespace creation had an unergonomic interface and isn't used, except
for testing code. Remove it; downstream users should really be creating
their own namespaces
In real-world address allocations, disjoint address ranges are common.
Therefore, the host-local allocator should support them.
This change still allows for multiple IPs in a single configuration, but
also allows for a "set of subnets."
Fixes: #45
This change adds support for IPv6 container/pod addresses to the CNI
bridge plugin, both for dual-stack (IPv4 + IPv6) and for IPv6-only
network configurations.
The proposed changes support multiple IPv6 addresses on a container
interface. If isGW is configured, the bridge will also be configured with
gateway addresses for each IPv6 subnet.
Please note that both the dual-stack functionality and support for multiple
IPv6 container/gateway addresses depends upon containernetworking/cni
PR 451 "ipam/host-local: support multiple IP ranges".
This change could potentially be committed independently from this host-local
plugin change, however the dual-stack and multiple IPv6 address
functionality that is enabled by this change can't be exercised/tested
until the host-local plugin change is committed.
There are some IPv6 unit test cases that are currently commented out
in the proposed changes because these test cases will fail without the
prior commits of the multiple IP range host-local change.
This pull request includes a temporary workaround for Kubernetes
Issue #32291 (Container IPv6 address is marked as duplicate, or dadfailed).
The problem is that kubelet enables hairpin mode on bridge veth
interfaces. Hairpin mode causes the container/pod to see echos of its
IPv6 neighbor solicitation packets, so that it declares duplicate address
detection (DAD) failure. The long-term fix is to use enhanced-DAD
when that feature is readily available in kernels. The short-term fix is
to disable IPv6 DAD in the container. Unfortunately, this has to be done
unconditionally (i.e. without a check for whether hairpin mode is enabled)
because hairpin mode is turned on by kubelet after the CNI bridge plugin
has completed cmdAdd processing. Disabling DAD should be okay if
IPv6 addresses are guaranteed to be unique (which is the case for
host-local IPAM plugin).
Updates the spec and plugins to return an array of interfaces and IP details
to the runtime including:
- interface names and MAC addresses configured by the plugin
- whether the interfaces are sandboxed (container/VM) or host (bridge, veth, etc)
- multiple IP addresses configured by IPAM and which interface they
have been assigned to
Returning interface details is useful for runtimes, as well as allowing
more flexible chaining of CNI plugins themselves. For example, some
meta plugins may need to know the host-side interface to be able to
apply firewall or traffic shaping rules to the container.
Add possibility to reconfigure bridge IP address when there is a new value.
New boolean flag added to net configuration to force IP change if it is need.
Otherwise code behaves as previously and throws error
* bridge: Test the following interface's hardware address for the CNI specific
prefix:
- bridge with IP address
- container veth
* plugins/macvlan test: ensure hardware addr
This will give deterministic MAC addresses for all interfaces CNI
creates and manages the IP for:
* bridge: container veth and host bridge
* macvlan: container veth
* ptp: container veth and host veth
