Linux Has More Network Interfaces Than You Think

Run this on almost any Linux server:

ip link

On a simple machine, you may only see lo and something like eth0 or enp5s0.

On a container host, hypervisor, VPN gateway, or Kubernetes node, the output can look very different:

veth..., docker0, br0, bond0, wg0, tap0, vxlan100, eth0.100, vrf-blue…

They all appear as network interfaces.

But they are definitely not all network cards.

That is the useful mental model to start with:

Linux treats a network interface as an abstraction through which packets or Ethernet frames can enter, leave, or move through the networking stack. Hardware is only one possible implementation of that abstraction.

Start with the interfaces that really are hardware#

An interface such as eth0, ens3, or enp5s0 commonly represents a physical or virtual NIC exposed to the operating system.

A driver connects that interface to an actual device, or to virtual hardware presented by a hypervisor.

This is the interface most people think about when they hear “network interface”:

Linux networking stack → NIC driver → network device → cable/network

But Linux uses the same interface model for many things that have no physical port at all.

That is where it gets interesting.

lo: networking without leaving the host#

The loopback interface is the simplest example.

Traffic sent to addresses such as 127.0.0.1 or ::1 does not leave the machine. Linux routes it internally through lo.

It still behaves like networking from the application’s point of view. Applications open sockets, TCP still has connections, and IP is still involved, but there is no physical network between the endpoints.

lo already tells us something important:

an interface can represent a networking path even when no physical device exists.

veth: a virtual Ethernet cable#

A veth interface is normally created as a pair.

Think of it as two Ethernet endpoints connected directly to each other. Whatever enters one side appears on the other.

This makes veth extremely useful with Linux network namespaces .

A container can have one end of the pair inside its own network namespace while the other end stays on the host.

Inside the container, the interface may simply be called eth0.

On the host, its peer may appear with a generated name such as veth8a2f....

This basic mechanism sits underneath a large amount of container networking:

container eth0 → veth pair → host networking → bridge/routing → physical network

The container thinks it has its own Ethernet interface. Linux is actually connecting two network namespaces using a virtual link.

bridge: a software Ethernet switch#

A Linux bridge is another interface, but its job is very different.

It acts roughly like a Layer 2 Ethernet switch implemented by Linux.

You can attach other interfaces to it:

• physical NICs
• veth interfaces
• TAP interfaces
• VXLAN interfaces

The bridge learns MAC addresses and forwards Ethernet frames between its ports.

This is why you frequently see bridges on container hosts and hypervisors.

For example, multiple containers can connect their host-side veth interfaces to the same bridge. From a Layer 2 perspective, they are now connected to the same virtual switch.

A VM can also connect through a TAP interface to that bridge.

The bridge is not pretending to be a physical NIC.

It is representing an entire switching function as a Linux network device.

TUN and TAP: giving packets to userspace#

TUN and TAP are particularly interesting because they connect the Linux networking stack to a userspace program.

They solve similar problems at different layers.

TUN#

A TUN interface exchanges Layer 3 IP packets with a userspace process.

This is useful for software that wants to receive IP packets from Linux, process or encapsulate them, and send them somewhere else.

VPN software is a common use case.

Linux may route a packet to tun0, but instead of placing that packet on Ethernet hardware, the kernel hands it to the userspace program attached to the TUN device.

TAP#

A TAP interface works at Layer 2.

Instead of IP packets, it exchanges Ethernet frames with userspace.

That makes TAP useful for virtual machines. Software such as QEMU can connect a VM’s virtual NIC to a TAP interface, and Linux can then attach that TAP interface to a bridge.

VLAN interfaces: one NIC, multiple Layer 2 networks#

Suppose a physical interface carries tagged traffic for VLAN 100.

Linux can create an interface such as:

eth0.100

or any explicitly named VLAN device.

The parent eth0 represents the underlying link, while the VLAN interface represents traffic associated with a particular IEEE 802.1Q VLAN.

Now Linux can configure addresses, routes, firewall rules, or services against the VLAN interface separately.

Again, no additional physical NIC was created.

Linux created another logical network interface on top of an existing one.

Bond: multiple physical links presented as one#

Sometimes the direction is reversed.

Instead of creating several virtual interfaces from one NIC, Linux can combine multiple links into a single logical interface using bonding .

For example:

eth0 + eth1 → bond0

Depending on the bonding mode and network design, this can provide link redundancy, load distribution, or both.

Applications and IP configuration can live on bond0, while the bond manages the member interfaces underneath.

So bond0 is a network interface, but it represents a relationship between several other interfaces.

macvlan and ipvlan: multiple network identities on one parent#

macvlan and ipvlan create virtual interfaces associated with another interface.

They are useful when workloads need to appear more directly on the surrounding network without going through a conventional Linux bridge.

macvlan can give virtual interfaces distinct MAC identities.

ipvlan shares more of the Layer 2 identity with the parent and separates traffic primarily at the IP layer.

These interfaces show an important pattern in Linux networking:

interfaces can be stacked on top of other interfaces.

A physical interface can therefore become the lower layer for VLAN, macvlan, ipvlan, tunnel, or other virtual devices.

VXLAN: an interface representing an overlay network#

VXLAN is where the abstraction becomes even more powerful.

A VXLAN interface can represent a Layer 2 segment that spans multiple Linux hosts, even though the physical network between those hosts is Layer 3.

An Ethernet frame can enter vxlan100.

Linux encapsulates that frame inside UDP/IP and sends it across the underlay network to another VXLAN endpoint.

The remote host decapsulates it and delivers the original Ethernet frame into its local virtual network.

To workloads, it can look like one Layer 2 network.

Underneath, the hosts may be separated by routers.

This idea is fundamental to many modern overlay networking designs.

The vxlan100 interface is therefore not a NIC and not just a tunnel in the casual sense. It is the Linux representation of an overlay endpoint.

WireGuard and GRE: tunnel interfaces#

Tunnel interfaces represent another logical path through the network.

A WireGuard interface such as wg0 behaves like a Layer 3 interface.

Linux can route traffic into it. WireGuard then encrypts and encapsulates the packets and transports them over the underlying network.

GRE follows the same broader idea, although the protocol and capabilities are different.

The important part for understanding Linux interfaces is the stacking:

An interface can therefore send traffic through another interface.

That is perfectly normal in Linux.

dummy: an interface with no real peer#

Linux can even create an interface that is intentionally not connected to physical hardware or another endpoint.

A dummy interface is useful when software or routing configuration needs a stable interface and address independent of a real NIC.

For example, routers and network services may place stable addresses on a dummy or loopback-style interface so that the address does not disappear when a particular physical link goes down.

It exists because sometimes the useful thing is the network identity, not the physical path.

VRF: one machine, multiple routing worlds#

A VRF device provides another kind of abstraction.

Rather than representing a cable, tunnel, or virtual Ethernet pair, a VRF helps associate interfaces with separate Layer 3 routing domains .

A host can therefore maintain traffic associated with different routing tables in a much cleaner way.

You may have interfaces attached to vrf-blue and others attached to vrf-red, each operating with separate routing policy.

This is common in routers, network appliances, service-provider systems, and more advanced multi-tenant designs.

At this point, the word interface clearly means much more than NIC.

The pattern behind all of them#

The easiest way to remember Linux interface types is not to memorise every name.

Ask what job the interface is doing.

Different jobs, same Linux networking abstraction.

That is why a single ip link command can show objects that represent hardware, software switches, containers, VMs, VPNs, overlays, and routing constructs side by side.

Next time you run ip link#

Try:

ip -details link show

Instead of looking only for the IP address or whether an interface is UP, look at the type of each interface and ask:

That one question makes many complicated Linux networking setups much easier to understand.

Because on Linux, an interface is not necessarily a network card.

It is a point in the networking graph.

If you want to see this same idea play out one layer down — where the abstraction being hidden from you is memory, not network topology — see Why the OS Never Lets Your Process Touch Real Memory .

References

• netdevice(7) — Linux manual page
• ip-link(8) — iproute2 manual page
• network_namespaces(7) — Linux manual page
• veth(4) — Linux manual page
• Linux kernel — Ethernet Bridging
• Linux kernel — Universal TUN/TAP device driver
• Linux kernel — Bonding driver HOWTO
• Linux kernel — Virtual Routing and Forwarding (VRF)
• Linux kernel — VXLAN documentation
• RFC 7348 — Virtual eXtensible Local Area Network (VXLAN)
• RFC 2784 — Generic Routing Encapsulation (GRE)
• WireGuard — Protocol & Cryptography
• IEEE 802.1Q