yet another engineering blog

Who Builds the Pod Network? From Linux Commands to CNI

Levent Anil Ozen — Sat, 15 Aug 2026 00:00:00 GMT

In the first two parts, we kept Kubernetes out of the picture.

We created network namespaces, veth pairs, bridges, IP addresses, and routes ourselves. Then we moved beyond a single local network and followed packets through gateways, Linux routing, forwarding, and NAT.

So far, every piece of the network has been configured by hand.

For each new Pod-like namespace, we had to:

create namespace
      |
create veth pair
      |
move one end into namespace
      |
attach the other end to bridge
      |
assign an IP address
      |
configure routes

Kubernetes needs the same kind of networking setup whenever a Pod is created on a node, but that work is automated.

This is where CNI fits.

We briefly introduced CNI in the first article. Here, we will use it directly.

We will create an empty network namespace, connect it to a network through CNI, and inspect the Linux objects that appear.

What is CNI?

CNI stands for Container Network Interface.

It is a specification for how a runtime asks networking plugins to configure a network namespace.

The runtime provides information such as:

which network namespace to configure
what the interface inside it should be called
which operation should be performed
the network configuration itself

A plugin then performs the networking work.

A simple mental model is:

runtime
   |
   | CNI
   v
plugin
   |
   v
Linux networking

CNI is the contract. The plugin is the implementation.

For this lab, we will use two plugins from the official CNI plugins project.

The first is the bridge plugin.

It creates a veth pair, places one end inside the target network namespace, and connects the host end to a Linux bridge.

That is very close to the network we built manually in Part 1.

The second is host-local, an IP Address Management plugin, usually shortened to IPAM.

It chooses an available IP address from a configured range and keeps track of existing allocations.

Our setup will look roughly like this:

             CNI configuration
                    |
          +---------+---------+
          |                   |
          v                   v
   bridge plugin       host-local IPAM
          |                   |
          | create veth       | allocate IP
          | attach bridge     |
          +---------+---------+
                    |
                    v
             network namespace

Using the bridge plugin gives us a useful comparison with Part 1 because we already know what the resulting Linux network should look like.

Calling CNI with cnitool

When a runtime asks a CNI plugin to add a container to a network, the plugin receives information similar to:

CNI_COMMAND=ADD
CNI_CONTAINERID=...
CNI_NETNS=/run/netns/pod-a
CNI_IFNAME=eth0

It also receives the network configuration as JSON.

For this lab, the two operations we care about are:

ADD
 |
 | attach networking
 v

DEL
 |
 | remove networking
 v

CNI defines other operations as well, but ADD and DEL are enough for the lifecycle we want to look at here.

We could invoke the plugin binaries directly and provide those inputs ourselves, but cnitool gives us a simpler way to do it. It applies a CNI configuration to an existing network namespace.

A container runtime would normally sit above CNI:

container runtime
       |
       | CNI ADD
       v
    plugins
       |
       v
Linux networking

For this lab, cnitool takes the runtime's place:

    cnitool
       |
       | CNI ADD
       v
    plugins
       |
       v
Linux networking

That lets us inspect the CNI layer without needing a Kubernetes cluster or container runtime.

Before starting

I recommend using a disposable Linux VM.

I ran the lab inside a privileged Debian Bookworm container on Docker Desktop.

That environment also exposes a few kernel tunnel interfaces inside otherwise empty network namespaces. I leave those out of the outputs because they are unrelated to this lab. On a typical disposable VM, you may only see lo.

If you already have cnitool and the official CNI plugins installed, you can skip most of this section.

On Ubuntu or Debian:

sudo apt update
sudo apt install -y iproute2 iputils-ping git golang-go

Install cnitool:

go install github.com/containernetworking/cni/cnitool@latest
sudo install "$(go env GOPATH)/bin/cnitool" /usr/local/bin/cnitool

Check that it is available:

cnitool --help

Build the official CNI plugins:

git clone https://github.com/containernetworking/plugins.git
cd plugins
./build_linux.sh

For this lab, we only need:

bridge
host-local

Copy them into a conventional CNI plugin directory:

sudo mkdir -p /opt/cni/bin
sudo cp bin/bridge bin/host-local /opt/cni/bin/

Create the configuration directory:

sudo mkdir -p /etc/cni/net.d

Step 1: Create an empty network namespace

Create the first namespace:

sudo ip netns add pod-a

Inspect it:

sudo ip -n pod-a -br link

On my lab:

lo               DOWN           00:00:00:00:00:00 <LOOPBACK>

There is no eth0, Pod IP, host-side veth, or bridge yet.

Linux host

    pod-a
      |
      X

In Part 1, we started building those pieces manually from here.

For this lab, the namespace is all we create ourselves.

Step 2: Describe the network

Create /etc/cni/net.d/10-tiny-net.conf:

sudo tee /etc/cni/net.d/10-tiny-net.conf > /dev/null <<'EOF'
{
  "cniVersion": "1.0.0",
  "name": "tiny-net",
  "type": "bridge",
  "bridge": "cni0",
  "isGateway": true,
  "ipam": {
    "type": "host-local",
    "ranges": [
      [
        {
          "subnet": "10.10.0.0/24"
        }
      ]
    ]
  }
}
EOF

The important parts are:

"type": "bridge"
        |
        +--> use the bridge plugin

"bridge": "cni0"
        |
        +--> connect the namespace to this bridge

"isGateway": true
        |
        +--> let the bridge act as the subnet gateway

"ipam": {
  "type": "host-local"
}
        |
        +--> allocate IP addresses locally

"subnet": "10.10.0.0/24"
        |
        +--> allocate them from this network

At this point, we have only created a configuration file.

The bridge does not exist yet:

ip link show cni0

Device "cni0" does not exist.

And pod-a still has no eth0.

sudo ip -n pod-a -br addr

The configuration describes the network. The plugins have not applied it yet.

Step 3: Run CNI ADD

Run:

sudo env CNI_PATH=/opt/cni/bin \
  cnitool add tiny-net /var/run/netns/pod-a

In my lab, cnitool returned:

{
  "cniVersion": "1.0.0",
  "interfaces": [
    {
      "name": "cni0"
    },
    {
      "name": "veth6b96cdeb"
    },
    {
      "name": "eth0",
      "sandbox": "/var/run/netns/pod-a"
    }
  ],
  "ips": [
    {
      "address": "10.10.0.2/24",
      "gateway": "10.10.0.1",
      "interface": 2
    }
  ]
}

I removed the MAC addresses because they are not relevant here.

The result already tells us what was configured:

cni0
host-side veth
pod-a / eth0

and the allocated address:

10.10.0.2/24
gateway 10.10.0.1

We did not create any of those interfaces manually.

Let's inspect them.

Step 4: Inspect the namespace and host

Inside pod-a:

sudo ip -n pod-a -br addr

lo               DOWN
eth0@if12        UP             10.10.0.2/24 ...

lo is still down because the bridge plugin only configured the interface we asked it to create, eth0. It does not configure loopback. The official CNI plugins project has a separate loopback plugin for that job. We do not need it for this lab.

The ... hides the IPv6 link-local address that Linux also assigned.

The route table contains the directly connected subnet:

sudo ip -n pod-a route

10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.2

On the host:

ip -br addr show cni0

cni0             UP             10.10.0.1/24 ...

Before CNI ADD, cni0 did not exist.

The bridge also has a veth attached:

bridge link

On my machine:

12: veth6b96cdeb@cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master cni0 state forwarding priority 32 cost 2

The interface name and index will differ on another machine.

The important part is:

master cni0

Our topology is now:

                  Linux host

                    cni0
                10.10.0.1
                     |
               veth6b96cdeb
                     |
                    eth0
                10.10.0.2
                   pod-a

What did CNI automate?

This is almost the same network we built manually in Part 1.

Part 1	This time
Created the veth pair	`bridge` plugin created it
Moved one end into the namespace	`bridge` plugin moved it
Attached the host end to the bridge	`bridge` plugin attached it
Assigned an IP manually	`host-local` allocated one
Configured the namespace interface	plugin configured `eth0`

The abstraction changed. The Linux objects did not.

The resulting network still consists of familiar pieces:

namespace
   |
  eth0
   |
  veth
   |
  cni0

CNI automated their creation and configuration.

Step 5: Where did 10.10.0.2 come from?

We gave host-local this range:

10.10.0.0/24

In a clean lab, the first namespace received:

10.10.0.2

The allocator needs to remember that address before another namespace is added.

By default, host-local stores allocation state under:

/var/lib/cni/networks/<network-name>

For tiny-net:

sudo ls /var/lib/cni/networks/tiny-net

10.10.0.2
last_reserved_ip.0
lock

The file named after the IP represents the active allocation.

sudo cat /var/lib/cni/networks/tiny-net/10.10.0.2

On my lab:

cnitool-af0507dddb173175b8b2
eth0

The allocator also keeps bookkeeping about where allocation last stopped:

sudo cat /var/lib/cni/networks/tiny-net/last_reserved_ip.0

10.10.0.2

So IPAM is not simply calculating an address. It keeps local allocation state.

Step 6: Add pod-b

Create another namespace:

sudo ip netns add pod-b

Before CNI touches it:

sudo ip -n pod-b -br addr

There is no eth0.

Apply the same network configuration:

sudo env CNI_PATH=/opt/cni/bin \
  cnitool add tiny-net /var/run/netns/pod-b

The second allocation in my clean lab was:

10.10.0.3/24
gateway 10.10.0.1

Inside pod-b:

sudo ip -n pod-b -br addr

eth0@if13        UP             10.10.0.3/24 ...

IPAM now has two active allocations:

sudo ls /var/lib/cni/networks/tiny-net

10.10.0.2
10.10.0.3
last_reserved_ip.0
lock

The topology is now:

                    Linux host

                       cni0
                   10.10.0.1
                    /       \
                   /         \
              vethXXXX     vethYYYY
                 |             |
                eth0          eth0
             10.10.0.2     10.10.0.3
               pod-a         pod-b

This is essentially the network from Part 1, but the CNI plugins configured it for us.

Step 7: Test communication

From pod-a:

sudo ip netns exec pod-a ping -c 3 10.10.0.3

My output:

64 bytes from 10.10.0.3: icmp_seq=1 ttl=64 time=0.063 ms
64 bytes from 10.10.0.3: icmp_seq=2 ttl=64 time=0.149 ms
64 bytes from 10.10.0.3: icmp_seq=3 ttl=64 time=0.056 ms

The TTL is still 64.

The namespaces are in the same subnet and communicate through the bridge, so there is no router between them.

The neighbour table confirms that pod-a reaches pod-b directly:

sudo ip -n pod-a neigh

10.10.0.3 dev eth0 lladdr 76:03:7d:ef:02:52 REACHABLE

We can also inspect the bridge forwarding database:

bridge fdb show br cni0

The packet path is the same one we examined in Part 1. What changed is how that network was configured.

Step 8: Remove pod-b from the network

CNI also has to deal with network cleanup when a workload disappears.

Before removing pod-b:

sudo ip -n pod-b -br addr

eth0@if13        UP             10.10.0.3/24 ...

Run:

sudo env CNI_PATH=/opt/cni/bin \
  cnitool del tiny-net /var/run/netns/pod-b

Then inspect the namespace again:

sudo ip -n pod-b -br link

eth0 is gone.

The namespace itself is still present:

ip netns list

That is because we created the namespace ourselves. CNI only managed its network attachment.

namespace lifecycle
        !=
network attachment lifecycle

IPAM also released the address:

sudo ls /var/lib/cni/networks/tiny-net

10.10.0.2
last_reserved_ip.0
lock

The 10.10.0.3 allocation file is gone.

last_reserved_ip.0 still contains:

10.10.0.3

That does not mean the address is still allocated. The active allocation file has been removed; last_reserved_ip.0 is allocator bookkeeping.

The host-side veth belonging to pod-b is also gone, while pod-a remains connected to the shared bridge.

Where Kubernetes fits

So far, we have called CNI ourselves.

On a Kubernetes node, kubelet talks to the container runtime through the Container Runtime Interface, or CRI.

As part of setting up a Pod sandbox, the runtime is responsible for configuring its networking, commonly through CNI plugins.

A simplified view is:

kubelet
   |
   | CRI
   v
container runtime
   |
   | CNI
   v
network plugins
   |
   v
Linux networking

Our lab removed the upper layers:

Real Kubernetes node:

kubelet
   |
runtime
   |
  CNI
   |
plugins
   |
Linux


Our lab:

cnitool
   |
  CNI
   |
plugins
   |
Linux

That is the connection between this lab and the Linux networking from the first two articles.

The bridge, veth pairs, addresses, routes, neighbour entries, and packet forwarding are still Linux networking.

CNI gives the runtime a standard way to delegate network setup to plugins.

Cleaning up

Remove pod-a from the network:

sudo env CNI_PATH=/opt/cni/bin \
  cnitool del tiny-net /var/run/netns/pod-a

If pod-b is still attached for any reason:

sudo env CNI_PATH=/opt/cni/bin \
  cnitool del tiny-net /var/run/netns/pod-b

After both attachments were removed in my lab, cni0 was still present:

ip -br addr show cni0

cni0             DOWN           10.10.0.1/24 ...

IPAM also kept its bookkeeping files:

sudo ls /var/lib/cni/networks/tiny-net

last_reserved_ip.0
lock

The individual allocation files were gone.

Delete the namespaces:

sudo ip netns delete pod-a
sudo ip netns delete pod-b

Remove the CNI configuration:

sudo rm /etc/cni/net.d/10-tiny-net.conf

Remove the bridge:

sudo ip link delete cni0 2>/dev/null || true

Clear the remaining allocator state:

sudo rm -rf /var/lib/cni/networks/tiny-net

Verify:

ip link show cni0

Device "cni0" does not exist.

Final thoughts

In the first article, we built a Pod-like network ourselves.

In the second, we looked at what happens when traffic needs to move beyond that local network.

Here, we let CNI plugins create the local networking that we previously configured by hand.

The resulting Linux objects were the same:

veth
bridge
IP address
routes

The layers now fit together like this:

Kubernetes
    |
   CRI
    |
runtime
    |
   CNI
    |
plugins
    |
Linux

A Pod can now receive an interface, an IP address, and a network path without us manually configuring those pieces.

But a Pod IP is tied to that Pod. Pods can be replaced or rescheduled, and their replacements can receive different addresses.

If an application has several replicas:

10.10.0.12
10.10.0.18
10.10.0.27

another application should not have to know which individual Pod IP to use or track how those addresses change.

Kubernetes Services give us a stable way to reach a changing set of Pods.

That is where we will continue next. Stay tuned!

Beyond the Bridge: Routing Our Tiny Pod Network

Levent Anil Ozen — Sun, 09 Aug 2026 00:00:00 GMT

In the first part, we built a tiny Pod-like network using Linux network namespaces, veth pairs, and a bridge.

If you missed it, you can find it here: Build a Tiny Pod Network with Linux.

We ended up with two isolated network namespaces connected to the same Linux bridge:

pod-a
  |
veth pair
  |
Linux bridge
  |
veth pair
  |
pod-b

Both network namespaces belonged to the same subnet.

That made the setup relatively simple. When pod-a wanted to reach pod-b, it could use ARP to find the destination MAC address, and the bridge could forward the Ethernet frame directly.

But real networks rarely remain one large Ethernet segment forever.

Imagine a company where employee devices belong to one network and internal servers belong to another. Or an application network that is kept separate from the database network.

Machines inside each network can communicate through their own switches. Things get more interesting when a machine in one network needs to reach a machine in the other.

We will place pod-a and pod-b in two separate subnets. Once we do that, they will no longer share the same local Ethernet network, and a bridge will not be enough to carry traffic directly between them.

The packet will need a router: something connected to both networks that can inspect the destination IP address and decide where to send it next.

We will build that path ourselves, introducing gateways, routing tables, and IP forwarding as each one becomes necessary. Then we will extend the same network toward the internet, discover why an outbound route is not always enough, and introduce NAT and masquerading.

Finally, we will bring the model back to Kubernetes and use it to reason about communication between Pods on different nodes.

The setup will still be small enough to build by hand. We are just moving one layer beyond the bridge.

What are we building?

Our initial topology will look like this:

                     Linux host

              br-a              br-b
          10.10.0.1          10.20.0.1
               |                  |
        veth-a-host        veth-b-host
               |                  |
              eth0               eth0
          10.10.0.2          10.20.0.2
             pod-a              pod-b

pod-a will belong to 10.10.0.0/24.

pod-b will belong to 10.20.0.0/24.

The Linux host will be connected to both networks through br-a and br-b.

At first, the two network namespaces will not be able to reach each other. We will add each missing piece one at a time until traffic begins to flow.

After that, we will extend the path toward the outside world:

pod-a
  |
br-a
  |
Linux routing
  |
NAT / masquerading
  |
host external interface
  |
internet

We will use an IP address rather than a domain name for the internet test. DNS is a separate problem and deserves its own explanation.

Before starting

You need a Linux environment with root access.

The commands in this article change network interfaces, routes, kernel settings, and firewall rules. A disposable virtual machine is the safest place to follow along.

Before starting, check that 10.10.0.0/24 and 10.20.0.0/24 do not already overlap with a local, VPN, or container network on your machine. If they do, use two different private subnets throughout the article.

On Ubuntu or Debian, install the tools we will use:

sudo apt update
sudo apt install iproute2 iputils-ping tcpdump iptables

Before changing anything, check whether IPv4 forwarding is currently enabled:

cat /proc/sys/net/ipv4/ip_forward

You will see either:

or:

Linux exposes this kernel setting as a file under /proc/sys.

A value of 0 means the host will not forward IPv4 packets between its interfaces. A value of 1 means forwarding is enabled.

Make a note of the current value. We will restore it during cleanup.

This lab begins with forwarding disabled so that we can observe what fails before Linux starts acting as a router. If the current value is 1, temporarily disable it:

sudo sysctl -w net.ipv4.ip_forward=0

Expected output:

net.ipv4.ip_forward = 0

We will enable it again only after the packet reaches the host and gets stuck there.

Step 1: Build two separate networks

Start by creating two network namespaces:

sudo ip netns add pod-a
sudo ip netns add pod-b

Now create one bridge for each network:

sudo ip link add br-a type bridge
sudo ip link add br-b type bridge

Assign an IP address to each bridge:

sudo ip addr add 10.10.0.1/24 dev br-a
sudo ip addr add 10.20.0.1/24 dev br-b

Bring them up:

sudo ip link set br-a up
sudo ip link set br-b up

The host is now connected to two separate IP networks:

                     Linux host

              br-a              br-b
          10.10.0.1          10.20.0.1

The bridges still have no network namespaces connected to them.

Connect pod-a

Create a veth pair:

sudo ip link add veth-a-host type veth peer name veth-a

Move one end into pod-a:

sudo ip link set veth-a netns pod-a

Attach the host-side interface to br-a and bring it up:

sudo ip link set veth-a-host master br-a
sudo ip link set veth-a-host up

Configure the other side inside the namespace:

sudo ip -n pod-a link set veth-a name eth0
sudo ip -n pod-a addr add 10.10.0.2/24 dev eth0
sudo ip -n pod-a link set eth0 up
sudo ip -n pod-a link set lo up

Verify the result:

sudo ip -n pod-a -br addr

You should see something similar to:

lo      UNKNOWN    127.0.0.1/8
eth0    UP         10.10.0.2/24

Connect pod-b

Repeat the process for pod-b, this time using br-b and the second subnet:

sudo ip link add veth-b-host type veth peer name veth-b

sudo ip link set veth-b netns pod-b

sudo ip link set veth-b-host master br-b
sudo ip link set veth-b-host up

sudo ip -n pod-b link set veth-b name eth0
sudo ip -n pod-b addr add 10.20.0.2/24 dev eth0
sudo ip -n pod-b link set eth0 up
sudo ip -n pod-b link set lo up

Verify it:

sudo ip -n pod-b -br addr

Expected output:

lo      UNKNOWN    127.0.0.1/8
eth0    UP         10.20.0.2/24

Our topology is now complete:

                     Linux host

              br-a              br-b
          10.10.0.1          10.20.0.1
               |                  |
        veth-a-host        veth-b-host
               |                  |
              eth0               eth0
          10.10.0.2          10.20.0.2
             pod-a              pod-b

We can also verify the host-side addresses:

ip -br addr show br-a
ip -br addr show br-b

Expected output:

br-a    UP    10.10.0.1/24
br-b    UP    10.20.0.1/24

Step 2: Try to reach the other network

Before adding anything else, let us try to ping pod-b from pod-a:

sudo ip netns exec pod-a ping -c 2 10.20.0.2

The result should look similar to this:

ping: connect: Network is unreachable

This failure is useful. pod-a knows how to reach its own subnet, but nothing beyond it.

Inspect its routing table:

sudo ip -n pod-a route

Expected output:

10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.2

This route says:

Destination inside 10.10.0.0/24?
Send it directly through eth0.

But 10.20.0.2 belongs to a different subnet.

pod-a checks its routing table, finds no matching route, and stops before sending the packet.

The bridge never even sees it.

Step 3: Give unknown destinations somewhere to go

pod-a needs a next step for destinations outside 10.10.0.0/24.

The Linux host owns the address 10.10.0.1 on br-a, and that address is directly reachable from pod-a.

We can tell pod-a:

When none of your more specific routes match, send the packet to 10.10.0.1.

Add a default route:

sudo ip -n pod-a route add default via 10.10.0.1

pod-b needs a return path too:

sudo ip -n pod-b route add default via 10.20.0.1

Inspect the routing table inside pod-a again:

sudo ip -n pod-a route

Expected output:

default via 10.10.0.1 dev eth0
10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.2

And inside pod-b:

sudo ip -n pod-b route

Expected output:

default via 10.20.0.1 dev eth0
10.20.0.0/24 dev eth0 proto kernel scope link src 10.20.0.2

A default route is the fallback:

Does a more specific route match?
    |
    +-- Yes: use that route
    |
    +-- No: send the packet to the default gateway

For pod-a, that gateway is 10.10.0.1.

For pod-b, it is 10.20.0.1.

Both addresses belong to our Linux host.

Try the ping again:

sudo ip netns exec pod-a ping -c 2 10.20.0.2

This time, you should no longer get Network is unreachable.

In a typical setup, however, you still will not receive a reply:

2 packets transmitted, 0 received, 100% packet loss

We no longer fail inside pod-a. The packet reaches the Linux host, but it does not make it to the other network.

Step 4: Find where the packet stops

We can watch this with tcpdump.

In one terminal, listen on br-a:

sudo tcpdump -n -i br-a icmp

In another terminal, run the ping again:

sudo ip netns exec pod-a ping 10.20.0.2

You should see echo requests on br-a:

10.10.0.2 > 10.20.0.2: ICMP echo request

Now listen on br-b:

sudo tcpdump -n -i br-b icmp

Run the ping again.

You will probably see nothing on br-b.

The packet arrived at the host through br-a, but the host did not pass it to br-b.

Our packet currently gets this far:

pod-a
  |
eth0
  |
veth-a-host
  |
br-a
  |
Linux host
  X
br-b
  |
pod-b

The host is connected to both networks. It also has routes for both of them:

ip route show 10.10.0.0/24
ip route show 10.20.0.0/24

Expected output:

10.10.0.0/24 dev br-a proto kernel scope link src 10.10.0.1
10.20.0.0/24 dev br-b proto kernel scope link src 10.20.0.1

The host knows where both networks are, but having routes is not enough by itself.

Step 5: Turn the Linux host into a router

pod-a and pod-b belong to different networks.

The Linux host is the only machine connected to both, so it has to route packets between them.

In our lab, the Linux host is already connected to both networks:

10.10.0.0/24
      |
    br-a
      |
 Linux host
      |
    br-b
      |
10.20.0.0/24

It has the required interfaces.

It has routes for both subnets.

But the host is not forwarding packets between its interfaces yet.

Check the kernel setting again:

cat /proc/sys/net/ipv4/ip_forward

Expected output:

Enable forwarding:

sudo sysctl -w net.ipv4.ip_forward=1

Expected output:

net.ipv4.ip_forward = 1

This tells the kernel that it may forward IPv4 packets arriving through one interface and leaving through another.

We did not need this in the first article.

Back then, both network namespaces belonged to the same Layer 2 network. The bridge moved Ethernet frames between its ports.

Now the destination belongs to another IP network. The host must make a Layer 3 routing decision.

Try the ping again:

sudo ip netns exec pod-a ping -c 3 10.20.0.2

Expected output:

64 bytes from 10.20.0.2: icmp_seq=1 ttl=63 time=0.090 ms
64 bytes from 10.20.0.2: icmp_seq=2 ttl=63 time=0.071 ms
64 bytes from 10.20.0.2: icmp_seq=3 ttl=63 time=0.068 ms

On a typical Linux setup, the reply now arrives with a TTL of 63 rather than 64. That gives us another clue that the packet crossed a router, because a router decrements the TTL before forwarding it.

The complete path now works:

pod-a
  |
eth0
  |
veth-a-host
  |
br-a
  |
Linux routing
  |
br-b
  |
veth-b-host
  |
eth0
  |
pod-b

If the ping still does not work

Some Linux systems have firewall rules that block forwarded traffic.

Inspect the FORWARD chain:

sudo iptables -L FORWARD -n -v

You may see a default policy of DROP:

Chain FORWARD (policy DROP)

For this disposable learning environment, temporarily allow traffic between our two bridges:

sudo iptables -I FORWARD 1 -i br-a -o br-b -j ACCEPT
sudo iptables -I FORWARD 1 -i br-b -o br-a -j ACCEPT

Then try the ping again.

These rules are deliberately limited to the two bridges in our lab. Do not broadly disable the firewall on a real system just to make the example work.

Step 6: Follow the routed packet

With the ping working, let us follow the packet.

The packet begins inside pod-a:

Source IP:      10.10.0.2
Destination IP: 10.20.0.2

pod-a checks its routing table.

The destination does not match the local 10.10.0.0/24 route, so the default route wins:

default via 10.10.0.1 dev eth0

pod-a does not use ARP to find the MAC address of 10.20.0.2.

That address is not part of its local Ethernet network.

Instead, pod-a uses ARP to find the MAC address of its gateway, 10.10.0.1.

Inspect the neighbour table:

sudo ip -n pod-a neigh

You should see something similar to:

10.10.0.1 dev eth0 lladdr 2a:71:9c:40:18:44 REACHABLE

The MAC address will be different on your machine.

Before the host routes it, the packet looks roughly like this:

Ethernet source:      pod-a eth0 MAC
Ethernet destination: br-a MAC

IP source:            10.10.0.2
IP destination:       10.20.0.2

The Ethernet frame is addressed to the gateway.

The IP packet inside it is still addressed to pod-b.

When the host receives the frame, it removes the Ethernet header and checks the destination IP address.

Its routing table says:

10.20.0.0/24 dev br-b

The host now needs to deliver the packet through br-b.

If it does not already know the destination MAC address, it sends an ARP request on the second network.

Inspect the host's neighbour table:

ip neigh show dev br-b

Expected output:

10.20.0.2 lladdr 8e:b6:26:91:2f:70 REACHABLE

The host creates a new Ethernet frame:

Ethernet source:      br-b MAC
Ethernet destination: pod-b eth0 MAC

IP source:            10.10.0.2
IP destination:       10.20.0.2

The Layer 2 addresses changed because the packet entered a different Ethernet network.

The Layer 3 addresses stayed the same.

That is the key idea behind routing in this Ethernet lab:

Each routed hop carries the IP packet inside a new Layer 2 frame.

The source and destination IP addresses stay the same unless something such as NAT rewrites them.

Step 7: Give pod-a internet access

pod-a can now reach another private network.

Can it reach the internet too?

It already has a default route:

default via 10.10.0.1 dev eth0

The Linux host should also have its own default route, normally through its external interface.

Find it:

ip route show default

Example output:

default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.50

In this example:

External interface: eth0
Host IP:             192.168.1.50
Upstream gateway:    192.168.1.1

Your interface might be called ens3, enp0s3, eth0, or something else.

Store its name so we can reuse it in the next commands:

EXT_IF=$(ip route show default | awk '/default/ {print $5; exit}')
echo "$EXT_IF"

Example output:

eth0

This assumes the host has one usable default route.

If the command returns nothing or selects the wrong interface, inspect the output of ip route show default and set it manually:

EXT_IF=eth0

Use the actual external interface name from your system.

Now try to reach a public IP address from pod-a:

sudo ip netns exec pod-a ping -c 3 1.1.1.1

In a typical environment, this will still fail:

3 packets transmitted, 0 received, 100% packet loss

The route setup looks complete: the namespace has a default route, IP forwarding is enabled, and the host knows how to send traffic toward the internet. The missing part is the return path.

Step 8: Routing also needs a return path

Follow the outbound packet.

Inside pod-a, it starts like this:

Source IP:      10.10.0.2
Destination IP: 1.1.1.1

The packet follows the namespace's default route to 10.10.0.1.

The Linux host receives it, checks its own default route, and sends it through the external interface:

pod-a
  |
br-a
  |
Linux host
  |
external interface
  |
internet

Assuming the host firewall allows forwarding, the packet can reach the external interface.

But it still has its original source address:

10.10.0.2

That address belongs to the private network we created inside the Linux host.

The host has a route out, but the upstream network does not know that 10.10.0.0/24 exists behind it. It may drop the packet because of the private source address, and even if the request reaches its destination, the reply still has no practical route back to 10.10.0.2.

Networking is not only about getting the packet to the destination. The return path must work too.

We can observe the packet reaching the external interface with its original source address.

Start a capture on the external interface:

sudo tcpdump -n -i "$EXT_IF" 'icmp and host 1.1.1.1'

Then run:

sudo ip netns exec pod-a ping 1.1.1.1

Depending on your host firewall and upstream network, you may see:

10.10.0.2 > 1.1.1.1: ICMP echo request

The request reached the host's external interface.

That does not prove that it reached 1.1.1.1; it only shows how far we can see from this host.

Step 9: Add NAT and masquerading

One way to solve the return-path problem is to change the packet's source address before it leaves the host.

Instead of sending this:

10.10.0.2 → 1.1.1.1

the host can send this:

192.168.1.50 → 1.1.1.1

192.168.1.50 is only an example. The real value will be the IP address assigned to your external interface.

The upstream network already knows how to return traffic to that address.

This is source network address translation, usually shortened to source NAT or SNAT.

Add a masquerading rule for traffic leaving from 10.10.0.0/24:

sudo iptables -t nat -A POSTROUTING \
  -s 10.10.0.0/24 \
  -o "$EXT_IF" \
  -j MASQUERADE

MASQUERADE is useful when the external address may change, which is common with DHCP, virtual machines, laptops, and cloud instances.

If the external address is fixed, an explicit SNAT --to-source rule is usually more appropriate.

Inspect the rule:

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers

You should see something similar to:

num  pkts bytes target      source         destination
1       0     0 MASQUERADE  10.10.0.0/24  0.0.0.0/0

If the host's FORWARD policy is DROP, also allow outbound traffic from br-a and returning traffic from the external interface:

sudo iptables -I FORWARD 1 \
  -i br-a \
  -o "$EXT_IF" \
  -j ACCEPT

sudo iptables -I FORWARD 1 \
  -i "$EXT_IF" \
  -o br-a \
  -m conntrack \
  --ctstate ESTABLISHED,RELATED \
  -j ACCEPT

Try the ping again:

sudo ip netns exec pod-a ping -c 3 1.1.1.1

Expected output:

64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=11.9 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=12.1 ms

Our tiny network can now reach the internet.

Some networks block ICMP traffic. If the routing and NAT setup looks correct but ping still fails, that does not always mean the network path is broken.

Step 10: Watch NAT change the packet

NAT becomes much easier to understand when we observe the packet on both sides of the host.

In one terminal, listen on br-a:

sudo tcpdump -n -i br-a 'icmp and host 1.1.1.1'

In another terminal, listen on the external interface:

sudo tcpdump -n -i "$EXT_IF" 'icmp and host 1.1.1.1'

Run the ping again:

sudo ip netns exec pod-a ping 1.1.1.1

On br-a, you should see the original source:

10.10.0.2 > 1.1.1.1: ICMP echo request

On the external interface, you should see the host's external address instead:

192.168.1.50 > 1.1.1.1: ICMP echo request

The exact address will be different on your machine.

The packet changes as it crosses the host:

Inside the private network:

10.10.0.2 → 1.1.1.1
      |
      | NAT on the Linux host
      v

Outside the private network:

host external IP → 1.1.1.1

When the reply returns, Linux reverses the translation:

1.1.1.1 → host external IP
      |
      | reverse translation
      v
1.1.1.1 → 10.10.0.2

Linux keeps track of this state using conntrack. The namespace does not know its source address was changed, and the remote destination only sees the host's external address.

Three different packet paths

Put side by side, our three packet paths look like this.

Same bridge

pod-a
  |
veth
  |
bridge
  |
veth
  |
pod-b

Both endpoints belong to the same subnet.

The bridge forwards Ethernet frames.

No gateway, IP forwarding, or NAT is required for communication between these two endpoints.

Different private networks

pod-a
  |
br-a
  |
Linux routing
  |
br-b
  |
pod-b

The endpoints belong to different subnets.

Each side needs a route to the other subnet. In this lab, that route goes through a gateway.

The Linux host forwards IP packets between the networks.

No NAT is required because both private networks have a working return path through the same router.

Internet access

pod-a
  |
br-a
  |
Linux routing
  |
NAT / masquerading
  |
external interface
  |
internet

The private subnet is not known to the outside network.

The Linux host translates the source address so the reply can return through an address the upstream network already knows.

Scenario	Explicit route or gateway needed	Host IP forwarding needed	NAT on this host needed
Same bridge and subnet	No, for this path	No	No
Different private subnets	Yes	Yes	No
Internet access from a private subnet	Yes	Yes	Yes, in this lab

Routing and SNAT solve different problems here. Routing decides where the packet should go. SNAT changes the source address so the reply can return through an address the upstream network can reach.

How does this relate to Kubernetes nodes?

The same model carries over to Kubernetes.

Imagine a cluster with two nodes:

Node A                                  Node B

Pod network:                            Pod network:
10.10.0.0/24                            10.20.0.0/24

pod-a: 10.10.0.2                        pod-b: 10.20.0.2
       |                                       |
 local Pod network                       local Pod network
       |                                       |
Node IP: 192.168.50.10  <---------->  Node IP: 192.168.50.11

pod-a and pod-b are not connected to the same local bridge.

From Node A's perspective, 10.20.0.2 belongs to the Pod network behind Node B.

Node A needs to know where that network lives.

In a small lab, we could express that using a static route:

sudo ip route add 10.20.0.0/24 via 192.168.50.11

Node B would need the reverse route:

sudo ip route add 10.10.0.0/24 via 192.168.50.10

These simplified routes assume that both node IPs belong to the same directly connected underlay network, so each node can use the other node's IP as its next hop.

Both nodes would also need to forward traffic between their Pod-facing and node-facing interfaces.

The cross-node path would look roughly like this:

pod-a
  |
Node A local Pod network
  |
Node A routing table
  |
node network
  |
Node B routing table
  |
Node B local Pod network
  |
pod-b

The packet preserves its original Pod addresses:

Source IP:      10.10.0.2
Destination IP: 10.20.0.2

This matches the Kubernetes network model, where Pods are expected to communicate directly across nodes without NAT.

This is the same basic model as the two-subnet lab, only at a different scale and with a different implementation. The central question has not changed:

How does this machine know where the destination network lives?

Static routes may be enough for a tiny lab.

They are only one possible implementation. A real Pod network may use routes, encapsulation, eBPF, or a combination of them to maintain that reachability as nodes and Pods are added, removed, or moved.

Somebody still has to allocate Pod addresses, create interfaces, and keep the necessary network state up to date. Who performs that work when Kubernetes creates or removes a Pod is the subject of the next article.

Cleaning everything up

Only remove firewall rules that you actually added during the article.

If you opened a new shell since Step 7, set EXT_IF again:

EXT_IF=$(ip route show default | awk '/default/ {print $5; exit}')
echo "$EXT_IF"

Delete the NAT rule:

sudo iptables -t nat -D POSTROUTING \
  -s 10.10.0.0/24 \
  -o "$EXT_IF" \
  -j MASQUERADE

If you added the internet forwarding rules, remove them:

sudo iptables -D FORWARD \
  -i br-a \
  -o "$EXT_IF" \
  -j ACCEPT

sudo iptables -D FORWARD \
  -i "$EXT_IF" \
  -o br-a \
  -m conntrack \
  --ctstate ESTABLISHED,RELATED \
  -j ACCEPT

If you added the temporary bridge-to-bridge rules, remove those too:

sudo iptables -D FORWARD -i br-a -o br-b -j ACCEPT
sudo iptables -D FORWARD -i br-b -o br-a -j ACCEPT

Restore IPv4 forwarding to the value you saw at the beginning.

If it was originally 0:

sudo sysctl -w net.ipv4.ip_forward=0

If it was originally 1:

sudo sysctl -w net.ipv4.ip_forward=1

Delete the network namespaces:

sudo ip netns delete pod-a
sudo ip netns delete pod-b

Deleting the namespaces also removes their ends of the veth pairs. The host-side peers disappear with them.

Finally, delete the bridges:

sudo ip link delete br-a
sudo ip link delete br-b

Verify the cleanup:

ip netns list
ip link show type bridge

Final thoughts

In the first article, our packet never had to leave its local Ethernet network.

This time, we gave it somewhere else to go.

We created two separate subnets, gave each namespace a gateway, enabled Linux to forward packets between them, and watched the Ethernet frame change while the IP packet kept its original source and destination.

Then we sent the same packet toward the internet and ran into a different problem: the request had a route out, but the private source network had no usable route back. SNAT solved that by translating the source address into one the outside network already knew how to reach.

The important distinction is simple:

Routing decides the packet's next hop and outgoing interface.

In our internet path, SNAT changes the source address so the reply can return through an address the upstream network can reach.

None of this is specific to Kubernetes. But the same questions appear as soon as Pods need to communicate across nodes or leave the cluster.

The next article will look at who actually builds and maintains that Pod network.

Build a Tiny Pod Network with Linux

Levent Anil Ozen — Fri, 07 Aug 2026 00:00:00 GMT

Not long ago, I decided to go back to the fundamentals of Kubernetes and started preparing for the CKA certification.

I have been using Kubernetes for quite a while, but networking was always one of those areas I mostly understood through the abstractions Kubernetes provides. I knew enough to use it and debug common problems, but I never built a particularly strong mental model of what was happening underneath.

Preparing for the CKA gave me a good reason to slow down and look at that layer more closely. Part of the reason I had not done that before is simply how work tends to go. Between deadlines, incidents, meetings, and the next thing that needs to be shipped, fundamentals are often the first thing we stop making time for.

Abstractions exist for a reason, and nobody can understand every layer of every system they use. The problem begins when the abstraction becomes our only mental model. When something breaks outside the happy path, our understanding may end exactly where that abstraction does.

Okay, that is enough philosophy for an article about virtual Ethernet devices. Let us get into it!

In this article, we are going to build a small Pod-like network by hand using Linux network namespaces, virtual Ethernet devices, and a bridge.

There will be no Kubernetes cluster, container runtime, or CNI plugin involved.

For now, the goal is to build the smallest useful version of the idea, follow a packet through it, and make what happens under the hood a little less mysterious. From there, we can gradually work our way toward cross-node communication and the larger Kubernetes networking model built on top of these Linux primitives.

What are we building?

By the end of the article, we will have two isolated network environments communicating through a Linux bridge.

Our final setup will look like this:

                         Linux host

                    br0: 10.10.0.1
                     /           \
                    /             \
         veth-a-host               veth-b-host
              |                         |
              |                         |
             eth0                      eth0
        10.10.0.2                 10.10.0.3
   pod-a network namespace   pod-b network namespace

The two network namespaces will act as our fake Pods.

Each one will have:

its own network interfaces
its own IP addresses
its own routing table
its own neighbour table
its own isolated view of the network stack

They will be connected to a shared Linux bridge through virtual Ethernet pairs.

These are not real Kubernetes Pods, of course. Still, the Linux primitives we are going to use are closely related to the ones used by container networking.

Before starting

You need a Linux environment with root access.

I am using commands from the iproute2 package. On Ubuntu or Debian, you can install the tools we need with:

sudo apt update
sudo apt install iproute2 iputils-ping

The bridge command we will use later is also included in the iproute2 package.

We will use tcpdump to watch the traffic:

sudo apt install tcpdump

This setup will not work directly on macOS because network namespaces are a Linux feature. If you are using a Mac, the easiest option is to run the commands inside a Linux virtual machine.

Step 1: Create two isolated network worlds

Let us start by creating two network namespaces:

sudo ip netns add pod-a
sudo ip netns add pod-b

A network namespace gives processes an isolated view of the network stack.

We can list the network namespaces we just created:

ip netns list

The output should look similar to this:

pod-b
pod-a

Now let us inspect the interfaces inside the pod-a network namespace:

sudo ip netns exec pod-a ip link

You may also see the shorter form:

sudo ip -n pod-a link

It does the same thing here: runs the ip link command inside the pod-a network namespace. I will keep using ip netns exec for now because it makes the namespace boundary a little more explicit.

You should see only the loopback interface:

1: lo: <LOOPBACK> mtu 65536 state DOWN mode DEFAULT

The network namespace exists, but it is completely isolated.

It does not have a useful network interface, an IP address, or a route to anywhere.

Our current topology is basically this:

pod-a network namespace        pod-b network namespace

           lo                             lo
         DOWN                           DOWN

We have created two separate network worlds. Now we need a way to connect them.

Step 2: Create a virtual cable

We will begin with pod-a.

To connect a network namespace to something outside itself, we can use a virtual Ethernet pair, usually called a veth pair.

A veth pair consists of two connected interfaces. A packet entering one side appears on the other.

Create the pair:

sudo ip link add veth-a-host type veth peer name veth-a

We now have two connected interfaces:

veth-a-host <------------> veth-a

Both currently live in the host network namespace.

We want one side to remain on the host and the other side to belong to the pod-a network namespace.

Move veth-a into it:

sudo ip link set veth-a netns pod-a

Now the two ends of the pair live in different network namespaces:

Host network namespace             pod-a network namespace

veth-a-host  <----------------->           veth-a

We can verify both sides.

On the host:

ip link show veth-a-host

Inside pod-a:

sudo ip netns exec pod-a ip link

The output inside the network namespace should now contain both lo and veth-a:

1: lo: <LOOPBACK> mtu 65536 state DOWN
2: veth-a@if3: <BROADCAST,MULTICAST> mtu 1500 state DOWN

The interface numbers and the value after @if will probably be different on your machine.

At this point, pod-a has a connection to the host network namespace.

It still cannot communicate with anything, though. Both interfaces are down, and the host side is not connected to a network.

Step 3: Why do we need a bridge?

We could connect two network namespaces directly with a veth pair.

That might work for exactly two network namespaces, but it does not scale particularly well.

Imagine having five or ten of them. Connecting every network namespace directly to every other network namespace would quickly become a mess.

Instead, we can connect the host side of each veth pair to a shared bridge.

A Linux bridge behaves like a small virtual Layer 2 switch. It learns which MAC addresses are reachable through which ports and forwards Ethernet frames accordingly.

Create the bridge:

sudo ip link add br0 type bridge

One detail that can feel slightly confusing at first is that the bridge itself also appears as a network interface on the host.

That is why we can bring br0 up and assign an IP address to it just like we would with another interface. Its bridge ports, such as veth-a-host, are then attached underneath it.

Bring it up:

sudo ip link set br0 up

We will also assign an IP address to it:

sudo ip addr add 10.10.0.1/24 dev br0

The bridge does not need an IP address just to forward Ethernet frames between the network namespaces.

We are giving it one so the host can also communicate with them. It could also become their gateway later if we decided to add connectivity outside this small network.

Now attach the host side of our veth pair to the bridge:

sudo ip link set veth-a-host master br0
sudo ip link set veth-a-host up

Our topology now looks like this:

Host network namespace             pod-a network namespace

           br0
            |
      veth-a-host  <------------->         veth-a

We can verify that the interface belongs to the bridge:

bridge link

The output should contain veth-a-host with master br0.

A simplified version looks like this:

3: veth-a-host@if2: <BROADCAST,MULTICAST,UP,LOWER_UP>
    master br0 state forwarding

The important part is:

master br0

That tells us veth-a-host is now one of the bridge ports.

So we found another abstraction

At this point, after all that talk about looking underneath abstractions, it is probably worth admitting that we have already landed on another set of abstractions.

A veth pair gives us the behaviour of an Ethernet cable without an actual cable. A Linux bridge gives us the basic behaviour of a network switch without a physical switch sitting on the desk.

In a physical setup, we might connect two machines to a switch using real cables.

In our setup, the machines are network namespaces, the cables are veth pairs, and the switch is a Linux bridge.

So yes, we removed the Kubernetes abstraction only to find more abstractions underneath it.

Apparently, there is no final layer where everything suddenly stops being an abstraction and becomes obvious. There are just smaller pieces that are easier to inspect.

The good news is that we do not need to crawl under a desk and untangle any cables for this one.

Step 4: Finish configuring pod-a

The network namespace has an interface, but the interface is still called veth-a, has no IP address, and is down.

Inside a container, the primary network interface is normally called eth0.

Let us rename it:

sudo ip netns exec pod-a ip link set veth-a name eth0

Now assign an IP address:

sudo ip netns exec pod-a ip addr add 10.10.0.2/24 dev eth0

Bring the interface and loopback device up:

sudo ip netns exec pod-a ip link set eth0 up
sudo ip netns exec pod-a ip link set lo up

Instead of checking the result after every command, we can now inspect the final state:

sudo ip netns exec pod-a ip addr

The relevant part of the output should look similar to this:

1: lo: <LOOPBACK,UP,LOWER_UP>
    inet 127.0.0.1/8

2: eth0@if3: <BROADCAST,MULTICAST,UP,LOWER_UP>
    inet 10.10.0.2/24

Linux also created a route for the connected subnet automatically:

sudo ip netns exec pod-a ip route

Expected output:

10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.2

This route means that addresses in the 10.10.0.0/24 network are directly reachable through eth0.

We can now test communication between pod-a and the bridge:

sudo ip netns exec pod-a ping -c 3 10.10.0.1

You should receive replies:

64 bytes from 10.10.0.1: icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from 10.10.0.1: icmp_seq=2 ttl=64 time=0.048 ms
64 bytes from 10.10.0.1: icmp_seq=3 ttl=64 time=0.047 ms

We now have one isolated network namespace connected to the host through a veth pair and a Linux bridge.

                         Host network namespace

                              br0
                          10.10.0.1
                              |
                        veth-a-host
                              |
                              |
                             eth0
                          10.10.0.2
                   pod-a network namespace

Step 5: Add pod-b

The pod-b network namespace needs the same pieces:

a veth pair
one end moved into the network namespace
the host end attached to the bridge
an IP address from the same subnet

We already walked through each operation for pod-a, so we can configure pod-b in one go:

sudo ip link add veth-b-host type veth peer name veth-b

sudo ip link set veth-b netns pod-b

sudo ip link set veth-b-host master br0
sudo ip link set veth-b-host up

sudo ip netns exec pod-b ip link set veth-b name eth0
sudo ip netns exec pod-b ip addr add 10.10.0.3/24 dev eth0
sudo ip netns exec pod-b ip link set eth0 up
sudo ip netns exec pod-b ip link set lo up

Inspect the final state:

sudo ip netns exec pod-b ip addr

You should see:

1: lo: <LOOPBACK,UP,LOWER_UP>
    inet 127.0.0.1/8

2: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP>
    inet 10.10.0.3/24

Our tiny network is now complete:

                         Linux host

                    br0: 10.10.0.1
                     /           \
                    /             \
         veth-a-host               veth-b-host
              |                         |
              |                         |
             eth0                      eth0
        10.10.0.2                 10.10.0.3
   pod-a network namespace   pod-b network namespace

Step 6: Test communication

Let us send traffic from pod-a to pod-b:

sudo ip netns exec pod-a ping -c 3 10.10.0.3

Expected output:

64 bytes from 10.10.0.3: icmp_seq=1 ttl=64 time=0.080 ms
64 bytes from 10.10.0.3: icmp_seq=2 ttl=64 time=0.063 ms
64 bytes from 10.10.0.3: icmp_seq=3 ttl=64 time=0.067 ms

Try the opposite direction too:

sudo ip netns exec pod-b ping -c 3 10.10.0.2

If the ping does not work

If you do not receive a reply, check the final state before changing the setup:

sudo ip -n pod-a addr
sudo ip -n pod-b addr

sudo ip -n pod-a link
sudo ip -n pod-b link

sudo ip -n pod-a route
sudo ip -n pod-b route

bridge link

Make sure that:

both addresses include the /24 prefix
both eth0 interfaces are up
both host-side veth interfaces are up and attached to br0
both network namespaces have a connected route for 10.10.0.0/24

Host firewall or nftables rules can also interfere with bridged traffic on some systems. If the interfaces, addresses, and routes all look correct, inspect the host firewall rules next.

I would not recommend disabling the firewall blindly, especially outside a disposable learning environment.

The two isolated network namespaces can now communicate with each other.

There is no Kubernetes cluster here.

There is no container runtime.

There is no CNI plugin.

Linux is moving the packets.

The ping works, but the more interesting question is this:

What path did the packet actually take?

Step 7: Follow one packet

When pod-a sends a packet to 10.10.0.3, the packet follows this path:

pod-a eth0
    |
    v
veth-a-host
    |
    v
   br0
    |
    v
veth-b-host
    |
    v
pod-b eth0

Let us walk through it.

pod-a checks its routing table

Before sending anything, pod-a needs to decide where the packet should go.

Its routing table contains:

10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.2

The destination 10.10.0.3 belongs to the same subnet, so pod-a knows it can reach the destination directly through eth0.

No gateway is needed.

pod-a needs a MAC address

The IP address tells pod-a which destination it wants to reach, but Ethernet delivery requires a destination MAC address.

If pod-a does not already know the MAC address for 10.10.0.3, it sends an ARP request:

Who has 10.10.0.3?
Tell 10.10.0.2.

That ARP frame leaves through eth0.

The veth pair moves the frame to the host

eth0 inside pod-a is one side of a veth pair.

When the frame enters eth0, it appears on veth-a-host in the host network namespace.

The veth pair itself does not make routing decisions. It simply carries traffic from one end to the other.

The bridge forwards the frame

veth-a-host is connected to br0.

The bridge receives the Ethernet frame and forwards it through its ports.

Because an ARP request is a broadcast, the bridge sends it through the other relevant ports, including veth-b-host.

The second veth pair delivers it to pod-b

The frame enters veth-b-host and appears on eth0 inside the pod-b network namespace.

pod-b sees that the ARP request is asking about its IP address and replies with its MAC address.

After that exchange, pod-a can send the ICMP packet directly to pod-b.

We can inspect the neighbour table inside pod-a:

sudo ip netns exec pod-a ip neigh

You should see an entry similar to:

10.10.0.3 dev eth0 lladdr 8a:41:36:d5:92:c4 REACHABLE

The MAC address will be different on your machine.

The neighbour table is where Linux keeps the relationship between IP addresses and link-layer addresses learned through protocols such as ARP.

Step 8: What has the bridge learned?

Like a physical Ethernet switch, a Linux bridge learns which MAC addresses are reachable through which ports.

Because we have already generated traffic between the network namespaces, the bridge should now have learned their MAC addresses.

We can inspect its forwarding database:

bridge fdb show br br0

The output will contain entries associated with veth-a-host and veth-b-host.

A simplified example might look like this:

8a:41:36:d5:92:c4 dev veth-b-host master br0
d2:72:f4:e8:51:10 dev veth-a-host master br0

This tells the bridge which port it should use when forwarding frames to each MAC address.

The bridge did not need us to configure those MAC addresses manually. It learned them by observing the source addresses of frames passing through it.

If you run this command before generating any traffic, you may not see the same learned entries yet.

Step 9: Watch the traffic yourself

Diagrams and explanations are useful, but we do not have to trust them.

We can watch the packets moving through the network.

Start tcpdump on the bridge:

sudo tcpdump -n -i br0

In another terminal, run:

sudo ip netns exec pod-a ping 10.10.0.3

You should see ICMP traffic:

10.10.0.2 > 10.10.0.3: ICMP echo request
10.10.0.3 > 10.10.0.2: ICMP echo reply

If you clear the neighbour entry first:

sudo ip netns exec pod-a ip neigh flush all

and start the ping again, you should also see the ARP exchange:

ARP, Request who-has 10.10.0.3 tell 10.10.0.2
ARP, Reply 10.10.0.3 is-at 8a:41:36:d5:92:c4

You can observe the same traffic at different points in the path.

Inside pod-a:

sudo ip netns exec pod-a tcpdump -n -i eth0

On the host side of its veth pair:

sudo tcpdump -n -i veth-a-host

On the bridge:

sudo tcpdump -n -i br0

This becomes useful when debugging real container networking.

If you can see a packet inside the Pod network namespace but not on the host-side veth interface, the problem is somewhere near that boundary.

If you can see it on the bridge but not on the destination interface, the problem is further along the path.

Networking debugging often comes down to following the packet and finding the point where it disappears.

So where does Kubernetes fit?

When Kubernetes creates a Pod, it does not normally run these exact shell commands itself.

A simplified Pod creation flow looks like this:

Scheduler selects a node
          |
          v
Kubelet asks the container runtime
to create a Pod sandbox
          |
          v
A network namespace is prepared
          |
          v
The configured CNI plugin is called
          |
          v
Interfaces, addresses, and routes
are configured using Linux

The scheduler decides which node should run the Pod.

The kubelet on that node asks the container runtime to create the Pod sandbox.

The runtime and CNI integration then handle the network setup.

It helps to think of CNI as a contract rather than a particular networking technology. CNI defines how a runtime invokes networking plugins and how those plugins report the result. It does not require every plugin to build the network in the same way.

What we have done manually is roughly the kind of work a CNI plugin may automate:

create a veth pair
move one end into the Pod network namespace
rename it to eth0
assign the Pod IP address
configure routes
connect the host side to a bridge or another networking layer
bring the interfaces up
configure routing, encapsulation, policy, or eBPF programs when needed

The runtime invokes the configured plugin when a Pod is added to or removed from the network. The actual network design is left to the plugin.

A simple bridge-based plugin might create something close to what we built.

Other plugins work differently.

Calico may rely heavily on routing and BGP.
Flannel may use VXLAN to create an overlay network.
Cloud CNI plugins may assign addresses from the cloud virtual network directly to Pods.
Cilium can use eBPF for networking, load balancing, and policy enforcement.

So it would not be correct to say:

Kubernetes networking is a Linux bridge.

A better way to put it is:

Kubernetes networking is built using Linux networking primitives,
configured according to the model implemented by the CNI plugin.

Kubernetes defines the desired model.

The CNI plugin configures it.

Linux carries the packets.

What this tiny network does not cover

Our setup only demonstrates communication between two Pod-like environments on the same Linux machine.

A real Kubernetes network needs to solve several additional problems.

For example, what happens if pod-a runs on Node 1 and pod-b runs on Node 2?

Node 1                              Node 2

pod-a: 10.10.1.2                    pod-b: 10.10.2.3

Node 1 needs to know how to reach the Pod network on Node 2.

That might involve:

normal Linux routes
BGP route distribution
VXLAN encapsulation
IP-in-IP
cloud network routes
eBPF-based forwarding

We have also not covered:

Kubernetes Services
ClusterIP addresses
kube-proxy
NAT
DNS
NetworkPolicy
ingress traffic
internet access
conntrack
cross-node MTU problems

Our bridge solves the same-node part of the problem: two Pod-like network environments can reach each other directly on one Linux host.

The next layer is cluster-wide reachability. A Pod on one node must be able to reach a Pod on another node while preserving the Pod addressing model.

That is where Linux routing, overlays, VXLAN, BGP, cloud routes, and different CNI implementations begin to matter.

Before following a packet across nodes, though, it helps to understand how it leaves the Pod in the first place. That is the part we have built here.

Cleaning everything up

When you are finished, delete the network namespaces:

sudo ip netns delete pod-a
sudo ip netns delete pod-b

Deleting the network namespaces also deletes the interfaces inside them.

When one side of a veth pair is deleted, the other side disappears as well.

Finally, remove the bridge:

sudo ip link delete br0

You can verify that everything is gone:

ip netns list
ip link show

Final thoughts

In this article, we manually created:

two isolated network namespaces
two virtual Ethernet pairs
one Linux bridge
two Pod-like IP addresses
a working network path between them

We also followed a packet from one network namespace to the other:

pod-a eth0
    |
veth-a-host
    |
   br0
    |
veth-b-host
    |
pod-b eth0

This is not a complete Kubernetes network, but it gives us a useful mental model.

A Pod is not magically connected to the network.

It has a network namespace.

It has a virtual interface.

That interface connects to something on the node.

The node then needs to decide where the packet goes next.

Once those pieces become visible, Kubernetes networking starts to feel less like a collection of magic abstractions and more like automated Linux networking.

The next question is what happens when the destination Pod is not on the same bridge, or even on the same node.