LFCE 28 🐧 Virtual Networking — VETH Pairs - KandZ

⏱️ Estimated read: 13 min | |

A veth pair is a virtual Ethernet cable with exactly two ends. A packet transmitted on one end is immediately received on the other. This simplicity is the entire mechanism, and it is also the reason veth pairs are the foundation of every modern Linux virtualization and container network. Unlike a TUN or TAP device, which connects the kernel to a userspace program, a veth pair connects two points inside the kernel. Both ends can live in the same network namespace, or one end can be placed in a different namespace, creating a link between isolated network stacks .

The previous chapter covered TUN and TAP as the boundary between kernel networking and userspace logic. Veth pairs are the boundary between kernel namespaces. They are the cables that connect a container to the host bridge, the link between two network namespaces in a test topology, and the transport for a VPN process that runs in its own isolated stack. Understanding the veth pair is prerequisite to understanding how containers get their network identity.

Key point: A veth pair is always created as a connected pair. The two interfaces are peers: traffic sent on one is received on the other, and bringing one end down brings the link state of the pair down . The pair has no meaning as a single interface; it is a two-ended cable, and its purpose is to connect two network stacks that would otherwise be isolated.

Why veth pairs exist

The namespace-connection problem.

A network namespace is isolated. It has its own interfaces, routing table, and firewall rules. A process inside the namespace cannot see the host’s network unless an interface exists inside the namespace that connects to something outside. The veth pair is that interface. One end is placed inside the namespace, and the other end remains in the host namespace (or another namespace). The veth pair is the cable that crosses the namespace boundary. Without it, the namespace is a sealed box .

The bridge-port problem.

A bridge forwards frames between its ports. For a container or a virtual machine to participate in a bridge, it needs an interface that can be attached to the bridge as a port. A veth pair provides this: one end is the container’s interface, and the other end is attached to the bridge in the host namespace. The bridge sees the host-side veth end as a normal port, and the container sees its side as a normal Ethernet interface. The veth pair is the transparent link between the two .

The testing problem.

A network namespace can simulate a router, a host, or a switch. To test a routing protocol or a firewall configuration, multiple namespaces must be connected. A veth pair connects two namespaces directly. For more than two, a bridge is used, with a veth pair for each namespace. The veth pair is the building block of every namespace topology, from a simple two-node test to a multi-router lab on a single machine.

a. Creating and inspecting a veth pair

The ip link add command creates a veth pair. The type veth keyword specifies the device type, and peer name names the second end. The first end is named by the first argument.

# Create a veth pair: veth0 and veth1
ip link add veth0 type veth peer name veth1

# Verify both ends exist
ip link show type veth
# Output: veth0@veth1 and veth1@veth0
# The @ notation indicates the peer relationship

The @ in the output is not part of the interface name. It is the kernel’s way of showing which interface is the peer. veth0@veth1 means that veth0 is connected to veth1. The peer relationship is permanent; the interfaces are created together and destroyed together .

# Inspect the peer of a veth interface
ethtool -S veth0 | grep peer_ifindex
# Output: peer_ifindex: 12

# Use the index to identify the peer in ip link output
ip link | grep '^12:'
# Output: 12: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> ...

The ethtool command reveals the peer’s interface index, which can be used to confirm the connection when the naming convention is not obvious .

b. Moving one end to a network namespace

The primary use of veth pairs is connecting namespaces. One end is created in the default namespace and then moved into the target namespace. The other end remains in the default namespace or is attached to a bridge.

# Create a network namespace
ip netns add container1

# Create the veth pair
ip link add veth-host type veth peer name veth-container

# Move the container end into the namespace
ip link set veth-container netns container1

# The host end remains in the default namespace
ip link show veth-host
# The container end is now inside the namespace
ip netns exec container1 ip link show veth-container

The ip link set ... netns command moves the interface across the namespace boundary. The interface keeps its identity and its connection to its peer. The host end (veth-host) is now a normal interface in the default namespace, and the container end (veth-container) is a normal interface inside the namespace. They are still connected; a packet sent on one is received on the other .

# Configure the host end
ip addr add 10.0.0.1/24 dev veth-host
ip link set veth-host up

# Configure the container end inside the namespace
ip netns exec container1 ip addr add 10.0.0.2/24 dev veth-container
ip netns exec container1 ip link set lo up
ip netns exec container1 ip link set veth-container up

# Test connectivity
ping -c 2 10.0.0.2
# The ping succeeds because the veth pair connects the two stacks

The host can reach the container directly through the veth pair without any bridge or routing configuration. The veth pair is a point-to-point link, and the two addresses are on the same subnet. The container can reach the host at 10.0.0.1. This is the simplest possible container network: one namespace, one veth pair, two addresses.

c. Veth pairs with bridges and containers

For multiple containers to communicate with each other and with the outside world, a bridge is required. Each container gets its own veth pair. One end is placed in the container’s namespace, and the other end is attached to the bridge in the host namespace. The bridge forwards frames between all attached veth ends.

# Create a bridge
ip link add br0 type bridge
ip link set br0 up

# Create a namespace and a veth pair
ip netns add container1
ip link add veth1-host type veth peer name veth1-container
ip link set veth1-container netns container1

# Attach the host end to the bridge
ip link set veth1-host master br0
ip link set veth1-host up

# Configure the container end
ip netns exec container1 ip addr add 10.0.1.10/24 dev veth1-container
ip netns exec container1 ip link set lo up
ip netns exec container1 ip link set veth1-container up

# The bridge must have an address to act as the gateway
ip addr add 10.0.1.254/24 dev br0

The container’s traffic enters the bridge through veth1-host and is forwarded to any other port on the bridge. If another container is attached, the bridge forwards frames between them based on MAC addresses. The bridge does not need to know that the ports are veth ends; it treats them as normal Ethernet interfaces .

The container’s default route points to the bridge address. This allows the container to reach destinations beyond its subnet, provided the host is configured to forward and translate traffic (NAT), as covered in the previous chapters.

Complete Example Session

# ============================================
# PART 1: CREATE A VETH PAIR
# ============================================
ip link add veth-a type veth peer name veth-b
ip link show type veth
# Output: veth-a@veth-b and veth-b@veth-a

# ============================================
# PART 2: INSPECT THE PEER RELATIONSHIP
# ============================================
ethtool -S veth-a | grep peer_ifindex
ip link | grep '^[0-9]*: veth-b'

# ============================================
# PART 3: CREATE A NAMESPACE AND MOVE ONE END
# ============================================
ip netns add testns
ip link set veth-b netns testns

# ============================================
# PART 4: CONFIGURE BOTH ENDS
# ============================================
ip addr add 192.168.100.1/24 dev veth-a
ip link set veth-a up

ip netns exec testns ip addr add 192.168.100.2/24 dev veth-b
ip netns exec testns ip link set lo up
ip netns exec testns ip link set veth-b up

# ============================================
# PART 5: VERIFY CONNECTIVITY
# ============================================
ping -c 2 192.168.100.2
ip netns exec testns ping -c 2 192.168.100.1

# ============================================
# PART 6: CREATE A BRIDGE FOR MULTIPLE NAMESPACES
# ============================================
ip link add br0 type bridge
ip link set br0 up
ip addr add 10.0.1.254/24 dev br0

# ============================================
# PART 7: CONNECT A SECOND NAMESPACE TO THE BRIDGE
# ============================================
ip netns add ns2
ip link add veth2-host type veth peer name veth2-ns
ip link set veth2-ns netns ns2
ip link set veth2-host master br0
ip link set veth2-host up

ip netns exec ns2 ip addr add 10.0.1.20/24 dev veth2-ns
ip netns exec ns2 ip link set lo up
ip netns exec ns2 ip link set veth2-ns up

# ============================================
# PART 8: VERIFY BRIDGE CONNECTIVITY
# ============================================
# The first namespace (testns) is not on the bridge
# To connect it, create a new veth pair and attach to br0
# This demonstrates that each namespace needs its own veth pair

# ============================================
# PART 9: CLEAN UP
# ============================================
ip netns pids testns | xargs -r kill
ip netns pids ns2 | xargs -r kill
ip netns delete testns
ip netns delete ns2
ip link delete br0
ip link delete veth-a

The nine parts demonstrate the veth pair lifecycle: creation, peer inspection, namespace migration, address configuration, connectivity verification, bridge attachment, and cleanup. The critical distinction is that the veth pair is a direct link for two endpoints, and a bridge is required for more than two.

Quick Reference

Veth Commands

Task	Command
Create pair	`ip link add <p1> type veth peer name <p2>`
Show veth interfaces	`ip link show type veth`
Find peer index	`ethtool -S <if> \| grep peer_ifindex`
Move to namespace	`ip link set <if> netns <name>`
Attach to bridge	`ip link set <if> master br0`
Delete pair	`ip link delete <p1>`

Veth Properties

Property	Value
Device type	Virtual Ethernet
Creation	Always in pairs
Peer relationship	Permanent; created together
Link state	Down if either end is down
Namespace support	Yes; one end can be moved
Bridge support	Yes; either end can be a bridge port

Use Cases

Use Case	Configuration
Two namespaces	One veth pair, one end per namespace
Multiple namespaces	Bridge + one veth pair per namespace
Container networking	Host end on bridge, container end in namespace
Point-to-point test	Both ends in default namespace

Best Practices

✅ Do This:

# Create the pair with descriptive names
ip link add veth-host type veth peer name veth-container   # ✅

# Move one end to the namespace before configuring
ip link set veth-container netns myns                       # ✅

# Bring up loopback inside the namespace
ip netns exec myns ip link set lo up                        # ✅

# Attach the host end to a bridge for multi-namespace
ip link set veth-host master br0                            # ✅

# Verify the peer relationship with ethtool
ethtool -S veth-host | grep peer_ifindex                    # ✅

# Delete the pair by deleting one end
ip link delete veth-host                                    # ✅

❌ Don’t Do This:

# Try to create a single veth interface
ip link add veth0 type veth    # Error: peer is required        # ❌

# Assume the @ in ip link output is part of the name
# It is the kernel's peer notation                               # ❌

# Forget to bring up the host end
ip link set veth-host up    # Required before traffic flows     # ❌

# Use a veth pair for three namespaces
# A veth pair connects exactly two endpoints                    # ❌

# Delete the namespace without killing processes
# The veth end may be trapped until the process exits           # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Cannot create single veth	Veth devices are always pairs	Use `peer name`
Peer relationship unclear	`@` notation is not obvious	`ethtool -S` reveals index
Namespace cannot reach host	Host end is down	`ip link set veth-host up`
Bridge does not forward	Veth host end not attached	`ip link set veth-host master br0`
Namespace has no connectivity	Loopback down or no address	Bring up `lo`; assign `/24`

Real-World Examples

1. Create a veth pair

ip link add veth0 type veth peer name veth1

2. Move one end to a namespace

ip link set veth1 netns myns

3. Attach host end to bridge

ip link set veth0 master br0

4. Find the peer

ethtool -S veth0 | grep peer_ifindex

5. Configure both ends

ip addr add 10.0.0.1/24 dev veth0
ip netns exec myns ip addr add 10.0.0.2/24 dev veth1

6. Bring up interfaces

ip link set veth0 up
ip netns exec myns ip link set veth1 up

7. Test connectivity

ping -c 2 10.0.0.2

8. Delete the pair

ip link delete veth0

9. List veth interfaces

ip link show type veth

10. Create pair directly in namespaces

ip link add veth-a netns ns1 type veth peer veth-b netns ns2

Visual

Veth Pair as a Virtual Cable

┌──────────────────────────────────────────────────────────────┐
│  A VETH PAIR IS A TWO-ENDED CABLE                            │
│                                                              │
│  ┌─────────────────────┐    ┌─────────────────────┐          │
│  │ Default Namespace   │    │ Target Namespace    │          │
│  │                     │    │                     │          │
│  │  ┌───────────────┐  │    │  ┌───────────────┐  │          │
│  │  │ veth-host     │  │    │  │ veth-container│  │          │
│  │  │ 10.0.0.1/24   │  │    │  │ 10.0.0.2/24   │  │          │
│  │  └───────┬───────┘  │    │  └───────┬───────┘  │          │
│  │          │          │    │          │          │          │
│  │          └──────────┼────┼──────────┘          │          │
│  │                     │    │                     │          │
│  │              veth pair (virtual cable)          │          │
│  └─────────────────────┘    └─────────────────────┘          │
│                                                              │
│  Packet sent on veth-host is received on veth-container.     │
│  Bringing one end down brings the link state of both down.   │
└──────────────────────────────────────────────────────────────┘

Veth Pair with Bridge

┌──────────────────────────────────────────────────────────────┐
│  BRIDGE + VETH PAIRS = MULTI-NAMESPACE CONNECTIVITY          │
│                                                              │
│  ┌─────────┐    ┌─────────┐    ┌─────────┐                   │
│  │ ns1     │    │ ns2     │    │ ns3     │                   │
│  │ veth1   │    │ veth2   │    │ veth3   │                   │
│  └────┬────┘    └────┬────┘    └────┬────┘                   │
│       │              │              │                        │
│       │  (veth pair) │  (veth pair) │  (veth pair)           │
│       │              │              │                        │
│       ▼              ▼              ▼                        │
│  ┌─────────────────────────────────────────────┐             │
│  │              br0 (bridge)                   │             │
│  │         (virtual switch in host)            │             │
│  └─────────────────────────────────────────────┘             │
│                                                              │
│  Each namespace has one end of a veth pair.                  │
│  The other end is attached to br0.                           │
│  The bridge forwards frames between all ports.               │
└──────────────────────────────────────────────────────────────┘

Peer Notation

┌──────────────────────────────────────────────────────────────┐
│  ip link OUTPUT SHOWS THE PEER WITH @                        │
│                                                              │
│  # ip link show type veth                                    │
│  10: veth-a@veth-b: <BROADCAST,MULTICAST,M-DOWN> mtu 1500   │
│  11: veth-b@veth-a: <BROADCAST,MULTICAST,M-DOWN> mtu 1500   │
│                                                              │
│  veth-a@veth-b  means veth-a is connected to veth-b          │
│  veth-b@veth-a  means veth-b is connected to veth-a          │
│                                                              │
│  The @ notation is NOT part of the interface name.           │
│  It is the kernel's display of the peer relationship.        │
│                                                              │
│  To find the peer index:                                     │
│  ethtool -S veth-a | grep peer_ifindex                       │
│  → peer_ifindex: 11                                          │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Device type	Virtual Ethernet pair
Creation	`ip link add <p1> type veth peer name <p2>`
Peer relationship	Permanent; packets on one received on the other
Link state	Both ends down if either is down
Namespace support	One end can be moved to a namespace
Bridge support	Either end can be attached to a bridge
Use case	Connecting network namespaces, container networking
Peer discovery	`ethtool -S <if> \| grep peer_ifindex`
Deletion	`ip link delete <p1>` removes both ends

Key takeaways:

A veth pair is always created as a connected pair. There is no such thing as a single veth interface. The two ends are peers, and a packet sent on one is immediately received on the other .
The pair is the cable between namespaces. One end stays in the host namespace (or is attached to a bridge), and the other end is moved into the isolated namespace. This is the fundamental mechanism that gives containers their network connectivity .
The @ notation in ip link shows the peer. veth0@veth1 means veth0 is connected to veth1. The @ is not part of the name. ethtool -S reveals the peer’s interface index .
Bringing one end down brings the link down. The pair is a single logical link. If either end is administratively down, traffic cannot flow in either direction.
A bridge is required for more than two namespaces. A veth pair connects exactly two endpoints. For three or more namespaces, each gets its own veth pair, and the host ends are all attached to a bridge .
Deleting one end deletes the pair. The veth interfaces are created together and destroyed together. ip link delete veth0 removes both veth0 and its peer.

Remember: A veth pair is a virtual cable with exactly two ends. It connects two network stacks, whether they are two namespaces or a namespace and a bridge. The pair is created together, exists together, and is deleted together. One end can be moved into an isolated namespace, and the other end stays in the host or is attached to a bridge. The veth pair is the invisible link that makes container networking possible: the container sees an Ethernet interface, the host sees a bridge port, and the pair is the cable between them.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!