Cloud Native 14 min read

Decoding Calico’s IPIP Mode in Kubernetes: Architecture, Routing & Packet Capture

This article explains Calico's IPIP networking mode in Kubernetes, covering its architecture, core components, routing behavior, command‑line examples, and packet‑capture analysis to illustrate how pods communicate across nodes.

Efficient Ops
Efficient Ops
Efficient Ops
Decoding Calico’s IPIP Mode in Kubernetes: Architecture, Routing & Packet Capture

Introduction

This article analyzes Calico’s IPIP network mode in Kubernetes, explaining the devices such as cali* and tunl0 and cross‑node communication.

Calico Overview

Calico is a popular CNI plugin that provides L3 routing, BGP‑based networking, network security, and policy enforcement. It runs a vRouter on each node and broadcasts routes via BGP.

Architecture and Core Components

Key components include:

Felix – agent on each node configuring routes and ACLs.

etcd – highly available key‑value store for Calico data.

BGP Client (BIRD) – reads kernel routes and distributes them.

BGP Route Reflector (BIRD) – reduces mesh connections in large clusters.

How Calico Works

Each node acts as a router; pods are endpoints attached to this router. Standard BGP exchanges routes so that containers can reach each other across hosts.

IPIP and BGP Modes

IPIP encapsulates an IP packet inside another IP packet, creating a tunnel (tunl0) that forwards pod traffic. BGP is the underlying routing protocol.

IPIP Mode Analysis

Example commands show pod listings, ping tests, and routing tables on pods and host nodes, illustrating how traffic is routed through tunl0 and the cali* veth‑pair devices.

<code># kubectl get po -o wide -n paas | grep hello

demo-hello-perf-d84bffcb8-7fxqj   1/1 Running 0 9d 10.20.105.215 node2.perf <none> <none>

demo-hello-sit-6d5c9f44bc-ncpql  1/1 Running 0 9d 10.20.42.31 node1.sit <none> <none>
</code>
<code>ping 10.20.42.31
...
3 packets transmitted, 3 received, 0% packet loss
</code>

Routing tables on the pod and host reveal entries for the default gateway and the tunl0 interface, showing how the destination 10.20.42.31 matches the tunl0 route.

The cali* interface is one end of a veth pair created for the pod; the other end resides inside the pod.

<code># ip a
...
4: eth0@if122964: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1380 ...
    inet 10.20.42.31/32 scope global eth0
</code>

Packet captures with tcpdump demonstrate a double‑encapsulated IP packet: an inner pod‑to‑pod IP layer and an outer host‑to‑host layer carried over tunl0.

Compared with VXLAN, IPIP adds less overhead but provides weaker security.

Pod to Service Access

Service objects are accessed via ClusterIP; packet captures show the same IPIP encapsulation.

<code># curl -I http://10.10.48.254:8080/actuator/health
HTTP/1.1 200
Content-Type: application/vnd.spring-boot.actuator.v3+json
Transfer-Encoding: chunked
Date: Fri, 30 Apr 2021 01:42:56 GMT
</code>
Kubernetesnetworkpacket captureBGPCNICalicoIPIP
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.