Understanding Network Interfaces With iproute2

Every packet that leaves or enters your machine passes through a network interface. Before you can reason about routing, DNS, or firewalls, you have to be able to answer a deceptively simple question: which interfaces does this host have, what state are they in, and which one actually carries traffic? On a modern Kali or Linux server that question is rarely trivial — a single host can easily present a dozen interfaces once Docker, virtual machines, and VPNs get involved.

In Networking Fundamentals we built the mental model of the troubleshooting stack. This lesson zooms in on the bottom of that stack — the interface layer — and teaches you to read it fluently with the modern iproute2 toolkit. That is the ip command, which has replaced the older ifconfig on every current distribution. If you still reach for ifconfig, this is the lesson to retrain that habit.

What You Will Learn

• How to list interfaces and their link state with ip link
• How to see assigned IPv4 and IPv6 addresses with ip addr
• The compact ip -br addr view for fast triage
• What UP vs DOWN, the MAC address, and the address scope tell you
• How to recognize loopback, physical, and virtual interfaces on sight
• How to tell Docker’s docker0 bridge and veth pairs apart from real NICs
• A repeatable workflow for the four most common interface problems

Listing Interfaces With ip link

Start with the link layer — the physical (or virtual) network devices themselves, before any IP addressing is considered.

ip link

You will see a numbered list of interfaces. A typical entry looks like this:

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    link/ether 00:0c:29:ab:cd:ef brd ff:ff:ff:ff:ff:ff

What does this output tell us? Read it left to right. The leading 2: is the kernel’s interface index. ens160 is the interface name. The angle-bracket flags are the interface’s state, and they are the most important part. link/ether is followed by the interface’s MAC address — a 48-bit hardware identifier unique to that NIC, written as six hex bytes. The brd value is the broadcast MAC (all ffs), which addresses every device on the local segment at once.

The two flags to watch are UP and LOWER_UP. UP means an administrator has enabled the interface. LOWER_UP means the physical link is actually live — a cable is plugged in and a carrier signal is present, or the virtual link is connected. An interface can be UP (administratively enabled) while missing LOWER_UP (no carrier). That distinction alone resolves a surprising number of “the server is on the network but nothing works” tickets.

🔎 Troubleshooting Tip — UP without LOWER_UP means “I turned the interface on but nothing is on the other end of the wire.” On a VM that usually points at a detached virtual NIC or a downed host bridge, not a problem inside the guest.

Seeing Addresses With ip addr

ip link shows the wire; ip addr adds the IP addresses layered on top of it.

ip addr

Each interface now gains inet and inet6 lines:

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    link/ether 00:0c:29:ab:cd:ef brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.42/24 brd 192.168.1.255 scope global ens160
    inet6 fe80::20c:29ff:feab:cdef/64 scope link

The inet line is the IPv4 address in CIDR notation — 192.168.1.42/24 means this host is .42 on a network whose first 24 bits are fixed. (If /24 is unfamiliar, IP Addresses, Subnets, and CIDR covers it next.) The inet6 line is IPv6. A single interface routinely carries both an IPv4 and one or more IPv6 addresses simultaneously.

Pay attention to scope. scope global means the address is routable and usable for normal traffic — this is the address other hosts reach you on. scope link means link-local: valid only on the directly attached segment and never routed off it. An IPv6 address beginning fe80:: is always link-local and is auto-generated for every interface; seeing only an fe80:: address and no scope global address means the interface has no usable routable IP yet.

🛠️ DevOps Perspective — When you SSH into a cloud VM and something can’t reach a service, ip addr is the first command to run. It answers “does this box even have the IP I think it has?” in one screen — before you waste time on firewalls or DNS.

The Fast View: ip -br addr

The full ip addr output is thorough but noisy on a busy host. The -br (brief) flag collapses each interface to a single line, which is what you want for triage.

ip -br addr

lo       UNKNOWN  127.0.0.1/8 ::1/128
ens160   UP       192.168.1.42/24 fe80::20c:29ff:feab:cdef/64
docker0  DOWN     172.17.0.1/16

Three columns: interface name, operational state, and addresses. This is the single most useful command for the question “what interfaces exist and which are live?” The state column here is the operational state (UP, DOWN, or UNKNOWN), which is a summary — the loopback interface reports UNKNOWN by design and that is normal, not a fault. You can run ip -br link for the same compact view without the addresses when you only care about link state.

Reading the Interfaces You Will Actually See

On a real DevOps host you will meet a recurring cast of interfaces. Learning to identify each on sight is the whole skill:

lo        loopback — always 127.0.0.1 / ::1
eth0      classic physical NIC name (older / containers)
ens160    predictable name (VMware-style PCI slot)
enp0s3    predictable name (bus/slot, e.g. VirtualBox)
docker0   Docker's default bridge (gateway 172.17.0.1)
veth1a2b  one end of a container's virtual pair

Loopback (lo) is the software interface a host uses to talk to itself. It always holds 127.0.0.1/8 and ::1/128, and it is never connected to any physical network. If lo is missing or down, local services that bind to 127.0.0.1 break in confusing ways.

Physical / primary interfaces are your real NICs. The name depends on the naming scheme. The classic scheme uses eth0, eth1, and so on — simple, but the number could change between boots depending on device probe order. Modern distributions use predictable network interface names derived from the hardware’s firmware or PCI location: ens160 (PCI slot 160), enp0s3 (PCI bus 0, slot 3). The en prefix means Ethernet; the rest encodes where the card physically sits. The point of the scheme is stability — the name stays the same across reboots and kernel updates, so your network config and firewall rules do not silently bind to the wrong device.

Virtual interfaces are created by software: bridges, tunnels (tun0 for a VPN), bonds, and container plumbing. They behave like real interfaces to the kernel but have no physical card behind them.

Docker’s Interfaces: docker0 and veth

Once you install Docker, ip addr gets busier. Docker creates a bridge interface named docker0, typically holding 172.17.0.1/16. That address is the gateway every container on the default bridge network uses to reach the outside world — the bridge is a virtual switch inside your host.

Each running container gets a veth (virtual Ethernet) interface on the host, with a name like veth1a2b3c. A veth is one half of a pair: the other half lives inside the container and appears there as eth0. Think of the pair as a virtual patch cable — one plug on the host bridge, the other inside the container’s network namespace.

  container ns          host
 ┌──────────┐        ┌─────────┐
 │  eth0    │========│ vethXXXX│
 └──────────┘        └────┬────┘
                          │
                     ┌────┴────┐
                     │ docker0 │  172.17.0.1
                     └─────────┘

So when you see a fistful of veth* interfaces, each one corresponds to a running container. They appear and vanish as containers start and stop, which is why the interface list on a busy container host is never static. Container networking has its own dedicated lesson in the Kali on Docker series — for now the goal is simply recognition: docker0 is the bridge, veth* are the container legs, and neither is a physical NIC.

🏭 Why This Matters in Production — On a Kubernetes or container host you may see dozens of veth and bridge interfaces. Mistaking a veth for the node’s real uplink, or firewalling the wrong interface, is a classic self-inflicted outage. Identify the physical NIC first — usually the one with a scope global address on your node subnet.

Common Problems

Each of these is a symptom → what to check → what the output means.

1. Interface is down

Symptom: No connectivity from a specific interface. Check:

ip -br link

If the interface shows DOWN, it is administratively disabled. You can enable it with ip link set ens160 up (requires root), then re-check. If it comes up but you still see no LOWER_UP in ip link, the carrier is missing — the problem is below Linux (unplugged cable, detached virtual NIC, downed host bridge), not in your config.

2. Missing IP address

Symptom: Interface is UP but nothing can reach it. Check: ip addr show ens160. If you see only an fe80:: link-local address and no inet ... scope global, the interface has no routable IPv4. That usually means DHCP failed or static config was not applied. The interface is healthy; the addressing is the missing piece.

3. Unexpected IP address

Symptom: The host answers on an address you did not configure. Check: ip -br addr and read every line. A second inet on the same interface, or a 172.x/10.x address you did not set, is often a leftover DHCP lease, a VPN (tun0), or a container bridge. The output tells you which interface owns the surprise address — that is your lead.

4. Multiple interfaces — which one carries traffic?

Symptom: The host has several UP interfaces and you need to know which one real traffic uses. ip addr alone cannot answer this — an interface having an address does not mean the default route points at it. Check:

ip route get 1.1.1.1

This asks the kernel which interface and gateway it would use to reach an external address, and prints dev <interface>. That is the interface carrying your outbound traffic. Interface identity plus routing is the full picture; routing gets its own treatment in Linux Routing and the Default Gateway.

Troubleshooting Workflow

Work the interface layer in a fixed order so you never guess:

Observe    ip -br addr   (what exists, what's up)
   │
Link up?   ip link       (UP + LOWER_UP present?)
   │
Has IP?    ip addr show  (inet scope global?)
   │
Carries    ip route get  (which dev handles traffic?)
traffic?

Each step tests one hypothesis and produces evidence before you touch anything. This is the interface-layer slice of the wider stack — Application → TLS → Port → DNS → Gateway → Route → Interface — and you resolve it bottom-up: no live interface, no point checking DNS.

Try It Yourself

🧪 Try It — On your Kali host, run ip -br addr and list every interface you see. For each one, name its type: loopback, physical, or virtual. Then start a container with docker run -d --rm nginx, run ip -br link again, and find the new veth interface that appeared. Stop the container and confirm the veth disappears. Finally, run ip route get 1.1.1.1 and confirm the dev it reports matches the interface holding your scope global address.

🔐 Security Note — Every command in this lesson is read-only inspection of your own host, which is always safe. Only enable, disable, or reconfigure interfaces on systems you own or are authorized to administer — bringing an interface down over the same connection you are using will lock you out.

What You Learned

• Interfaces are the bottom of the troubleshooting stack; nothing works until one is live.
• ip link shows link state and MAC; ip addr adds IPv4/IPv6; ip -br addr is the fast triage view.
• UP is administrative; LOWER_UP means a real carrier — the difference matters.
• scope global addresses are routable; fe80::/scope link are link-local only.
• Loopback (lo) is always 127.0.0.1; predictable names like ens160/enp0s3 encode hardware location and are stable across reboots.
• docker0 is Docker’s bridge gateway; each veth* is one leg of a running container, appearing and vanishing with it.
• Use ip route get to prove which interface actually carries traffic when several are up.

You can now read any Linux host’s interface list and say exactly what each device is and whether it is healthy. Next, in Part 3: IP Addresses, Subnets, and CIDR, we decode the 192.168.1.42/24 notation you have been seeing — what the /24 means, how subnets divide a network, and why two hosts on the same wire still cannot talk when their masks disagree.