skip to content

On a Linux host, `ip link show` prints an interface as `<NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 ... state DOWN`. Explain how the `UP` flag differs from `LOWER_UP`/`NO-CARRIER`, and what that combination is telling you.

level: middleimportance: should knowfreq 55%

answer

  1. two independent states, not one
  2. who asked versus what the wire says
  3. flags list versus the state word
  4. the driver owns one of them
  5. enabled with the cable unplugged

basics

~20 s

UP is the administrative state you requested with ip link set dev X up; LOWER_UP is the driver reporting a live carrier. NO-CARRIER plus state DOWN means the interface is enabled but the physical layer is dead.

solid answer

~50 s

Linux tracks two independent things per interface. `UP` in the flag list is the **administrative** state — somebody ran `ip link set dev eth0 up`, or the network manager did, and that stays set whether or not anything is plugged in. `LOWER_UP` is the **carrier**: the driver telling the kernel the lower layer is live. `NO-CARRIER` is the negation of that, which is why the `state` field still reads `DOWN` even though `UP` appears among the flags. So this output says: the interface is enabled, and the wire is dead. On copper that is an unplugged or faulty cable, a disabled or dead switch port, or a failed autonegotiation; on a virtual device such as a veth it almost always means the peer end was never brought up. Addresses and routes on that interface will not move a single packet until the carrier appears.

go deeper

for a junior

Know that an interface can be switched on and still have no cable signal. Be able to run ip link show and point at which part is the flag list and which part is the state.

for a middle

Explain that UP is IFF_UP set by the administrator while LOWER_UP is carrier reported by the driver, and that the state field comes from operstate in sysfs. Name what LOWERLAYERDOWN implies.

for a senior

Use the split as your first triage step: prove layer 1 before touching addresses, routes or firewalls, and recognise that DHCP and address application often wait on the carrier-up event.

for a principal

Own how this state is exposed to monitoring and automation: carrier flaps are the signal worth alerting on, and configuration tooling must be written to converge on carrier events rather than assume a link is live at boot.

## The output you are reading ```bash ip link show enp3s0 # 2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000 # link/ether 52:54:00:1a:2b:3c brd ff:ff:ff:ff:ff:ff ``` There are three separate pieces of state on that line and candidates routinely fuse them into one idea of "is it up?". The angle-bracket list is the kernel's interface **flags**. The word after `state` is the **operational state**. `mtu`, `qdisc` and `qlen` are unrelated properties. ## Administrative state: the UP flag `UP` corresponds to the kernel flag `IFF_UP`. It means an administrator or a userspace network manager asked the kernel to activate the device — `ip link set dev enp3s0 up`, a NetworkManager connection activation, a systemd-networkd `.network` match, or a netplan-rendered config. It is a *request*, and it persists in exactly the state you set it. Unplugging the cable does not clear it. That is the entire source of the confusion: people see `UP` in the flags, conclude the link is working, and start debugging the wrong layer. The same word also appears at the end of the line as `mode DEFAULT` neighbours; do not read `mode` as state — it distinguishes normal devices from *dormant*-capable ones (used by things like wireless supplicants). ## Carrier: LOWER_UP and NO-CARRIER `LOWER_UP` corresponds to `IFF_LOWER_UP` and is set by the **driver**, not by you. It means the layer beneath the interface reports a signal: an Ethernet PHY has completed link training with the partner, a virtual device's peer is available, a bond has at least one usable member. When the driver clears carrier, iproute2 shows `NO-CARRIER` instead. The raw bit is visible as `/sys/class/net/enp3s0/carrier`, which reads `1` or `0` (and returns an error when the interface is administratively down, because carrier is only meaningful on an enabled device). ## The state field: operstate The `state` word is the kernel's operational state, exported at `/sys/class/net/<iface>/operstate`. The values you will actually meet are: - `UP` — administratively up **and** carrier present. This is the healthy case. - `DOWN` — administratively up but no carrier, or administratively down. Combine with the flags to tell which. - `LOWERLAYERDOWN` — the device depends on another device that is itself down. Typical for a VLAN sub-interface whose parent is down, or one half of a veth pair whose peer was never brought up. - `UNKNOWN` — the driver does not report carrier at all. Loopback and many tunnel and TUN/TAP devices sit here permanently; `UNKNOWN` is not a fault. That last value trips people up: a WireGuard or GRE tunnel showing `state UNKNOWN` is perfectly normal, because there is no physical layer to report on. ## Why the distinction earns interview time It is the fastest triage split there is. If the flags show `UP` and `NO-CARRIER`, nothing above layer 1 can help — no address, route, firewall rule or DNS change will make traffic flow, and you should be looking at cabling, the switch port, transceiver/SFP seating, or autonegotiation. If instead the flags lack `UP` entirely, the machine's own configuration is at fault: nobody activated the interface, or the manager that owns it has the connection disabled. If the state is `UP` and traffic still fails, layer 1 is proven good and you move up the stack. A second, subtler reason: services and configuration tools react to carrier. A DHCP client normally waits for carrier before soliciting a lease, and address configuration applied while the link is down may only take effect on the carrier-up event. "I configured it and nothing happened" is often just "there is no carrier yet". ## Bringing it back up `ip link set dev enp3s0 up` sets the administrative flag; it cannot manufacture a carrier. Toggling down/up is still worth one attempt because it forces the PHY to renegotiate, which occasionally clears a stuck duplex mismatch — but if `NO-CARRIER` returns immediately, the problem is physically outside the host or in the peer device. On virtual topologies the fix is usually inside the host: bring the veth peer up, bring the VLAN parent up, or give the bond a member with a carrier. ## Concise reading rule Flags answer "what did we ask for?"; `state` answers "what do we actually have?". Read both, in that order, before touching anything else.

  • Where would you read the carrier and operational state without parsing the output of ip?
    Both are exported in sysfs per interface: `/sys/class/net/<iface>/carrier` reads 1 or 0, and `/sys/class/net/<iface>/operstate` gives the same word the `state` field prints — up, down, lowerlayerdown or unknown. Reading carrier on an administratively down interface returns an error, which is itself informative. Those files are the stable interface for scripts and exporters, since iproute2's text output is not a contract.
  • A VLAN sub-interface reports LOWERLAYERDOWN. What does that tell you to check?
    That the sub-interface itself is fine and its parent is not. A VLAN device is stacked on a physical NIC, so it can never be operationally up while the parent is administratively down or has no carrier. Bring the parent up and give it a live link; the sub-interface follows automatically. The same reasoning applies to one half of a veth pair whose peer is still down.
  • Why might a DHCP-configured interface sit with no address even though the configuration looks correct?
    Because the client normally waits for carrier before soliciting a lease. With NO-CARRIER there is nothing to send a DISCOVER onto, so the interface stays addressless and the manager appears to have done nothing. The same is true of static configuration applied by a manager that defers until the carrier-up event. Fix layer 1 first, and the address usually appears without touching the configuration at all.

saying these in an interview costs you the question

  • Sees UP in the flag list and declares the link healthy
  • Thinks NO-CARRIER means the interface is administratively disabled
  • Debugs routing or DNS while carrier is down
  • Believes ip link set up can force a carrier to appear
  • Treats state UNKNOWN on a tunnel device as a fault

context

resolving links…