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>
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 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>
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>
if the runtime is not passing portMappings in the runtimeConfig,
then DEL is a noop.
This solves performance issues, when the portmap plugin is
executed multiple times, holding the iptables lock, despite
it does not have anything to delete.
Signed-off-by: Antonio Ojea <aojea@redhat.com>
It may happen that you want to map a port only in one IP family.
It can be achieved using the unspecified IP address of the
corresponding IP family as HostIP i.e.:
podman run --rm --name some-nginx -d -p 0.0.0.0:8080:80 nginx
The problem is that current implementation considers the
unspecified address valid and appends it to the iptables rule:
-A CNI-DN-60380cb3197c5457ed6ba -s 10.88.0.0/16
-d 0.0.0.0/32 -p tcp -m tcp --dport 8080 -j CNI-HOSTPORT-SETMARK
This rule is not forwarding the traffic to the mapped port.
We should use the unspecified address only to discriminate the IP
family of the port mapping, but not use it to filter the dst.
Signed-off-by: Antonio Ojea <antonio.ojea.garcia@gmail.com>
A /64 mask was used which routed an entire cidr based on source,
not only the bound address.
Fixes #478
Signed-off-by: Lars Ekman <lars.g.ekman@est.tech>
The DNAT hairpin rule only allow the container itself to access the
ports it is exposing thru the host IP. Other containers in the same
subnet might also want to access this service via the host IP, so
apply this rule to the whole subnet instead of just for the container.
This is particularly useful with setups using a reverse proxy for
https. With such a setup connections between containers (for ex.
oauth2) have to downgrade to http, or need complex dns setup to make
use of the internal IP of the reverse proxy. On the other hand going
thru the host IP is easy as that is probably what the service name
already resolve to.
Signed-off-by: Alban Bedel <albeu@free.fr>
--
v2: Fixed the tests
v3: Updated iptables rules documentation in README.md
v4: Fixed the network addresses in README.md to match iptables output
Add the following idempotent functions to iptables utils:
DeleteRule: idempotently delete an iptables rule
DeleteChain: idempotently delete an iptables chain
ClearChain: idempotently flush an iptables chain
Signed-off-by: Antonio Ojea <antonio.ojea.garcia@gmail.com>
It turns out that the portmap plugin is not idempotent if its
executed in parallel.
The errors are caused due to a race of different instantiations
deleting the chains.
This patch does that the portmap plugin doesn't fail if the
errors are because the chain doesn't exist on teardown.
Signed-off-by: Antonio Ojea <antonio.ojea.garcia@gmail.com>
Use a Describe container for the It code block of the
portmap port forward integration test.
Signed-off-by: Antonio Ojea <antonio.ojea.garcia@gmail.com>
Concurrent use of the `portmap` and `firewall` plugins can result in
errors during iptables chain creation:
- The `portmap` plugin has a time-of-check-time-of-use race where it
checks for existence of the chain but the operation isn't atomic.
- The `firewall` plugin doesn't check for existing chains and just
returns an error.
This commit makes both operations idempotent by creating the chain and
then discarding the error if it's caused by the chain already
existing. It also factors the chain creation out into `pkg/utils` as a
site for future refactoring work.
Signed-off-by: Tim Gross <tim@0x74696d.com>
This change sends gratuitous ARP when MAC address is changed to
let other devices to know the MAC address update.
Signed-off-by: Tomofumi Hayashi <tohayash@redhat.com>
The CNI spec states that for DEL implementations, "when CNI_NETNS and/or
prevResult are not provided, the plugin should clean up as many resources as
possible (e.g. releasing IPAM allocations) and return a successful response".
This change results in the firewall plugin conforming to the spec by not
returning an error whenever the del method is not provided a prevResult.
Signed-off-by: Erik Sipsma <sipsma@amazon.com>
* Increase entroy from 2 bytes to 7 bytes to prevent collisions
* Extract common library function for hash with prefix
* Refactor portmap plugin to use library function
fixes #347
Co-authored-by: Cameron Moreau <cmoreau@pivotal.io>
Co-authored-by: Mikael Manukyan <mmanukyan@pivotal.io>
