Learn Flannel - VXLAN Backend (Default)

#Introduction

In episode 3 you saw the flannel.1 interface being created. Now it's time to understand what that interface actually is: the heart of the VXLAN backend, Flannel's default used by the majority of clusters in the world.

Episode 4 dissects VXLAN from the protocol side all the way to configuration. You will understand why Pod packets are wrapped in UDP on port 4789, how the flannel.1 interface learns addresses from other nodes, and why the 50-byte overhead must be a consideration when setting MTU.

#How VXLAN Works

#UDP Encapsulation on Port 4789

VXLAN, short for Virtual eXtensible LAN, is an encapsulation standard that wraps the original Ethernet frame in a UDP packet. In Flannel, packets from a Pod on node A destined for a Pod on node B are wrapped as follows: the original Ethernet frame gets a VXLAN header, then UDP and IP headers are added with the destination set to node B's host IP.

ip -d link show flannel.1

The output of ip -d link show flannel.1 shows the word vxlan along with the VNI number, port, and local address. This is proof that every packet passing through this interface will be encapsulated.

#The flannel.1 Interface and FDB Learning

The flannel.1 interface is the entry and exit point of encapsulation on every node. When flanneld gets subnet info from another node, it fills the forwarding database, or FDB, with address pairs: the remote subnet, the virtual flannel.1 MAC address on the remote node, and the remote host IP.

bridge fdb show dev flannel.1
ip neigh show dev flannel.1

The bridge fdb show dev flannel.1 command shows the MAC-to-host-IP mappings, while ip neigh show dev flannel.1 shows the learned addresses. The combination of the two determines where packets must be wrapped.

#Configuring the VXLAN Backend

#Setting VNI and Port

VNI is the virtual network identifier, default 1, and the default port is 4789. Both can be adjusted through net-conf.json if port 4789 conflicts with another service on the host.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "vxlan",
      "VNI": 1,
      "Port": 4789
    }
  }

Note that the Type: vxlan field is the key that selects the backend. The VNI and Port values above are Flannel defaults, so writing them explicitly is only useful if you want to change them. Make sure these changes are consistent across all nodes because they all read the same ConfigMap.

#Direct Routing: An Overhead-Saving Option

For traffic between nodes on the same subnet, Flannel provides the DirectRouting option. When enabled, intra-subnet packets are forwarded directly without encapsulation, like the host-gw backend, while cross-subnet traffic still uses VXLAN. This is a compromise between performance and flexibility.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "vxlan",
      "DirectRouting": true
    }
  }

#VXLAN Limitations

#The 50-Byte Overhead

Every VXLAN packet carries 50 bytes of overhead: 14 bytes of original Ethernet recalculated, 8 bytes of VXLAN header, 8 bytes of UDP, and 20 bytes of IP. As a consequence, the effective MTU inside a Pod becomes the host MTU minus 50.

ip link show eth0
ip link show flannel.1

If eth0 has an MTU of 1500, flannel.1 automatically gets an MTU of 1450. This MTU calculation and adjustment will be covered thoroughly in episode 16, including how to avoid fragmentation.

#CPU Overhead and Network Limits

Encapsulation and decapsulation use CPU on every node, although with modern kernels and VXLAN offload the burden is relatively small. On networks with very high throughput, this overhead can be felt. For those scenarios, you can consider host-gw, explained in episode 5.

#Inspecting VXLAN Directly

#Tracing Encapsulated Packets

To prove encapsulation works, you can capture packets on the eth0 interface while two Pods on different nodes ping each other. The traffic you see is no longer raw ICMP, but UDP on port 4789 wrapping that ICMP.

sudo tcpdump -ni eth0 udp port 4789

The tcpdump output will show UDP packets with destination port 4789. You can confirm that every conversation between Pods goes through this path, exactly as VXLAN is designed.

#End-to-End Verification

Finally, run a simple functional test to make sure the overlay is healthy:

kubectl run nettest --image=busybox --restart=Never -- sleep 3600
kubectl exec -it nettest -- ping -c 3 <ip-pod-node-lain>

If the ping succeeds, the whole chain works: Pod, bridge, route, flannel.1 interface, and VXLAN encapsulation.

#Conclusion

Episode 4 opened the black box of the VXLAN backend: UDP encapsulation on port 4789, the roles of the flannel.1 interface and FDB, VNI and port configuration, plus the 50-byte overhead inherent to this design.

Key takeaways:

• VXLAN wraps Pod frames in UDP on port 4789 toward the destination host IP.
• The flannel.1 interface is the encapsulation doorway on every node.
• The FDB connects remote subnets with the remote host's MAC and IP.
• VNI and Port can be adjusted via net-conf.json; the defaults are 1 and 4789.
• The 50-byte VXLAN overhead makes Pod MTU = host MTU minus 50.
• DirectRouting saves overhead for intra-subnet traffic.

In the next episode, episode 5, we will explore the host-gw backend and other alternatives — direct routing without encapsulation for maximum performance, plus wireguard, ipsec, ipip, udp, and extension, along with the security note on CVE-2026-32241. You will be able to choose the right backend for your needs.