What is `tunl0@NONE` and how is its IP assigned?

Open Source Calico Help
1

Hello all, I’m trying to figure out how to solve problem described here I also added a relevant question here I think I was able to narrow this problem down, and I have a calico related question as a result.

I installed calico as described here in a 3 master - 5 worker node cluster. When I do ip addr on each of the three master nodes I can see the following, respectively:

6: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 10.244.0.0/32 brd 10.244.0.0 scope global tunl0
       valid_lft forever preferred_lft forever

6: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 10.244.221.0/32 brd 10.244.221.0 scope global tunl0
       valid_lft forever preferred_lft forever

6: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 10.244.208.64/32 brd 10.244.208.64 scope global tunl0
       valid_lft forever preferred_lft forever

Can someone explain me, or point to the documentation, how these IPs are assigned and what tunl0@NONE is? In particular I would like to know if I whitelist them in a config, will they ever change? It seems that I can get those addresses also with calicoctl get node <nodeame> -oyaml under spec.bgp.ipv4IPIPTunnelAddr. But I’m not sure if they ever change.

Thank you in advance!

2

tunl0 is an IPIP tunnel that Calico uses for encapsulating pod traffic. You can disable this encapsulation in many environments for higher performance, but IPIP mode is a good default that works nearly everywhere.

See this page in the docs for more info: https://docs.projectcalico.org/networking/vxlan-ipip

Those IP addresses you see are allocated from Calico’s pool of IP addresses, which in most cases should be the same as the cluster CIDR for your Kubernetes network. They are allocated when the node starts up, and generally don’t change for existing nodes. Whenever a new node joins the cluster a new address is allocated for it.

1 Like
3

Thank you for this.

They are allocated when the node starts up

They are not changed on reboot, are they? I experimented a bit and they don’t seem to be changed, but I just wanted to make sure, given your “start up” wording.

Thank you again!

4

Another question is this:

With regualr pod to pod communication, the source IP address is ususaly the IP address of the pod. However when Kubernetes API Server makes a call to a pod via service proxy, the source IP address appears as descrived above - not the pod address but tunl0 interface address.

Could you please explain from netwroking perspecitve why that happens? I’d like to understand it a bit better.

Also, what is the signigicance of @NONE in the interface name?

5

They are not changed on reboot, are they?

That’s correct, but it’s worth some slight caveats to that statement. The allocations are keyed off the node name, so assuming that the node name isn’t changed, the IP will remain the same. If you rename the node, then restart it, the address might change.

6

The Kubernetes API Server runs in the host’s network namespace (either as a pod, or just as a binary, depending on the distro). It isn’t a regularly networked pod with its own per-pod IP address.

When a process in the host’s network namespace (API Server or any other process) connects to a pod, Calico knows it needs to encapsulate the packet in IPIP before sending it to the remote host. It chooses the tunnel address as the source so that we ensure that the remote host knows to encapsulate the return packets. In IPIP mode, the underlying network doesn’t know what to do with packets that have pod IP addresses on them, and might drop them. So, by encapsulating we ensure the return packets are delivered.

I’m not sure the @NONE is about off the top of my head, I’m afraid.

1 Like