Host network configuration

    This address must also be the one the api-server will be listening on, as the first address of the uplink (a.k.a main interface for the host).

    • It grabs the primary interface with the chosen driver, either placing it in a dedicated network namespace, or removing it entirely as a Linux netdev depending on the driver. In any case, the interface disappears from the host’s root network namespace
    • It configures it in VPP with the same configuration (addresses, routes) it had in Linux
    • It creates a tap interface between VPP and the host
    • This interface is also reconfigured with all the addresses and routes that the host had configured on the original interface

    The new tap interface (named enp216s0f1 in this example) is also configured with routes towards the Kubernetes service CIDR and the pod CIDR, so that the Linux host can reach the workloads through VPP. These routes use a reduced MTU to accommodate for encapsulations.

    • In VPP you will find it with the name tap0
      • It is configured unnumbered, as a child of the primary interface avf-0/d8/a/0
    • It is also registered as the default punt path
      • This means that all the traffic that would be dropped by VPP (which includes the traffic to the VPP address that is not handled by VPP itself, but not the tunnel traffic which is decapsulated / decrypted by VPP) will be passed to this interface, so the Linux host will receive and process it

    A packet destined to the host arrives on the uplink, let’s say it has src=192.168.0.2,dst=192.168.0.1

    • VPP receives it, sees that the destination address is the one configured on its interface
    • As it doesn’t have specific handling configured for this packet, it looks up the punt path, and sends it into tap0
    • Linux looks up the route for 192.168.0.0/24, forwards it into the tap interface
    • VPP receives it on the interface tap0
    • It looks up 192.168.0.2 in the fib, finds a route on the uplink interface (configured with 192.168.0.1/24)
    • The packet is sent on the uplink

    Let’s say the api server lives on Node A.

    If a pod on Node B wants to talk to the api-server on Node A, the packet flow will be the same as described above.

    • In Node B, standard routing happens ( will give details on this node)
    • When reaching Node A, we’re in the same situation as previously
    • Things happen exactly the same way as if the packet was coming from the uplink
    • The return traffic from the host is received by VPP on tap0, and is routed directly to the pod on tunN