Eventually the timeout value will become a CLI argument
The default timeout was nestled all the way in the lease constructor
This commit is the first step in making the timeout configurable by
moving it to the DHCPLease constructor
Signed-off-by: toby lorne <toby@toby.codes>
Closes #544
The above issue describes a situation where using the bridge plugin
with IPv6 addresses prevented `DEL` from working correctly.
`DEL` seems to be failing in the body of `TeardownIPMasq`
This arises because:
* twice delete postrouting rules: `ipn.String()` `ipn.IP.String()` #279
* we are using a version of go-iptables which is bugged for v6
PR github.com/coreos/go-iptables/pull/74 describes why this does
not work. The error message is not being checked correctly.
Using a later version of go-iptables means that
* when the second `ipt.Delete` fails (this is okay)
* we will correctly interpret this as an non-fatal error
* `TeardownIPMasq` will not prematurely exit the method
* `ipt.ClearChain` now can run
* `ipt.DeleteChain` now can run
This explains why this was working for v4 but not v6
This commit was amended to include v0.5.0 instead of a pseudo-version
v0.4.6-0.20200318170312-12696f5c9108
Signed-off-by: toby lorne <toby@toby.codes>
Values changed by Tuning plugin should be changed only for pod, therefore should be reverted when NIC is being moved from pod back to host.
Fixes: #493
Signed-off-by: Patryk Strusiewicz-Surmacki <patrykx.strusiewicz-surmacki@intel.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>
conntrack does not have any way to track UDP connections, so
it relies on timers to delete a connection.
The problem is that UDP is connectionless, so a client will keep
sending traffic despite the server has gone, thus renewing the
conntrack entries.
Pods that use portmaps to expose UDP services need to flush the existing
conntrack entries on the port exposed when they are created,
otherwise conntrack will keep sending the traffic to the previous IP
until the connection age (the client stops sending traffic)
Signed-off-by: Antonio Ojea <aojea@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>
The current cni config has an extra comma and cannot be parsed normally, the kubelet will report an error as follows:
"Error loading CNI config file: error parsing configuration: invalid character '}' looking for beginning of object key string"
Signed-off-by: xieyanker <xjsisnice@gmail.com>
The e2e tests already covers both versions, and since the plugin is
meant to be used in chains, this will augment the scope of the plugins
it can be used with.
Signed-off-by: Federico Paolinelli <fpaoline@redhat.com>
When specified from the user, the VRF will get assigned to the given
tableid instead of having the CNI to choose for a free one.
Signed-off-by: Federico Paolinelli <fpaoline@redhat.com>
The new tests expand coverage, checking deletion, ip address handling,
0.4.0 compatibility, behaviour in case of multiple vrfs.
Signed-off-by: Federico Paolinelli <fpaoline@redhat.com>
This plugin allows to create a VRF with the given name (or use the existing
one if any) in the target namespace, and to allocate the interface
to it.
VRFs make it possible to use multiple routing tables on the same namespace and
allows isolation among interfaces within the same namespace. On top of that, this
allow different interfaces to have overlapping CIDRs (or even addresses).
This is only useful in addition to other plugins.
The configuration is pretty simple and looks like:
{
"type": "vrf",
"vrfname": "blue"
}
Signed-off-by: Federico Paolinelli <fpaoline@redhat.com>
nc behaviour depends on the implementation version of what's on the current host.
Here we use our own client with stable behaviour.
Signed-off-by: Federico Paolinelli <fpaoline@redhat.com>
VRF support was introduced in ubuntu bionic, while it's missing in Xenial.
This also introduces a change in the behaviour of nc command.
On one hand, it requires a new line to send the buffer on the other side,
on the other it hangs waiting for new input.
To address this, a timeout was introduced to avoid the tests to hang,
plus the buffer sent is terminated with a new line character.
Signed-off-by: Federico Paolinelli <fpaoline@redhat.com>
This change allows providing an 'ipam' section as part of the
input network configuration for flannel. It is then used as
basis to construct the ipam parameters provided to the delegate.
All parameters from the input ipam are preserved except:
* 'subnet' which is set to the flannel host subnet
* 'routes' which is complemented by a route to the flannel
network.
One use case of this feature is to allow adding back the routes
to the cluster services and/or to the hosts (HostPort) when
using isDefaultGateway=false. In that case, the bridge plugin
does not install a default route and, as a result, only pod-to-pod
connectivity would be available.
Example:
{
"name": "cbr0",
"cniVersion": "0.3.1",
"type": "flannel",
"ipam": {
"routes": [
{
"dst": "192.168.242.0/24"
},
{
"dst": "10.96.0.0/12"
}
],
"unknown-param": "value"
},
"delegate": {
"hairpinMode": true,
"isDefaultGateway": false
}
...
}
This results in the following 'ipam' being provided to the delegate:
{
"routes" : [
{
"dst": "192.168.242.0/24"
},
{
"dst": "10.96.0.0/12"
},
{
"dst" : "10.1.0.0/16"
}
],
"subnet" : "10.1.17.0/24",
"type" : "host-local"
"unknown-param": "value"
}
where "10.1.0.0/16" is the flannel network and "10.1.17.0/24" is
the host flannel subnet.
Note that this also allows setting a different ipam 'type' than
"host-local".
Signed-off-by: David Verbeiren <david.verbeiren@tessares.net>
This change makes ipvlan master parameter optional.
Default to default route interface as macvlan does.
Signed-off-by: Tomofumi Hayashi <tohayash@redhat.com>
In GetCurrentNS, If there is a context-switch between
getCurrentThreadNetNSPath and GetNS, another goroutine may execute in
the original thread and change its network namespace, then the original
goroutine would get the updated network namespace, which could lead to
unexpected behavior, especially when GetCurrentNS is used to get the
host network namespace in netNS.Do.
The added test has a chance to reproduce it with "-count=50".
The patch fixes it by locking the thread in GetCurrentNS.
Signed-off-by: Quan Tian <qtian@vmware.com>
