Interface Configuration Order: Link State, Address Assignment, and Route Installation

A host that reports an address on an interface has satisfied one of at least four independent conditions required to exchange a packet with a peer. The link must be able to carry frames, the address must be usable rather than merely present, the peer must be resolvable to a link-layer address, and a route must select this interface for the destination. Configuration tools present all four as one line of state, which is why the failure of any single condition is routinely misread as the failure of the address.

Four pieces of state, installed by different mechanisms

Link state comes from the driver and the physical layer. An Ethernet interface reports carrier when the far end’s transmitter is powered and the medium is intact, and the kernel exposes that as a flag separate from the administrative up/down setting. An interface can be administratively up with no carrier, which is the normal condition when a cable is unplugged: the kernel queues nothing, transmits nothing, and the address assigned to it remains perfectly valid. Frames are simply discarded at the point where the driver would hand them to hardware.

Address state comes from manual configuration, DHCP, or stateless autoconfiguration, and it carries a prefix length that is not a routing decision. The prefix length tells the host which destinations are considered directly reachable on the link, a determination the neighbour discovery code makes before the routing table is consulted for a gateway. Two hosts can share a subnet while disagreeing about its width, and the narrower host will send traffic for the wider host’s addresses to its default gateway instead of resolving them on the link.

Neighbour state is a cache of bindings between network-layer and link-layer addresses, populated by ARP for IPv4 and by Neighbor Solicitation and Advertisement for IPv6. A route that points at an on-link destination is not sufficient for delivery: the packet still needs a link-layer destination, and if the cache holds no entry the host must resolve one, and if the resolution goes unanswered the packet is dropped with an unreachable error rather than a routing error.

Route state is a separate table, and the entry that makes an interface usable for its own subnet is usually derived from the address assignment rather than configured. The derivation is convenient and it is also the reason that address removal silently breaks forwarding to peers on the same link.

The diagnostic consequence is an ordering: each condition can be true while a later one is false, and checking them out of order produces misleading conclusions. A host with a valid address, a correct default route, and a dead neighbour cache entry will report that the destination is routed through the right interface and that the destination is nonetheless unreachable, which is accurate and unhelpful.

Duplicate address detection suspends usability after assignment

IPv6 addresses pass through a tentative phase before they become usable. After an address is formed, the node joins the solicited-node multicast group for it and sends Neighbor Solicitations from the unspecified address, asking whether any other node already claims the address. Until that exchange completes, the address is present in the interface’s list but must not be used as a source for ordinary traffic, and a node that receives traffic destined to it during the tentative period is required to discard rather than answer. Only after the detection completes without a defending response does the address transition to preferred and become a valid source.

This produces the characteristic operational symptom of an interface that is up, configured, and silent for a short interval after boot. The interval is not a fixed constant: it is derived from the retransmission timers used for the solicitations and from a random delay applied to the first transmission, so the address becomes usable somewhere around a second after configuration on a quiet link and later on a lossy one. Implementations may also count the address as duplicated and refuse to use it, at which point the address stays on the interface in a failed state and the host continues to source traffic from a link-local address only.

IPv4 has an equivalent but optional procedure defined for address conflict detection. A host may probe with ARP before claiming an address, and if a reply arrives it must select a different one. Because the procedure is optional and often skipped, an IPv4 address conflict usually surfaces as intermittent connectivity shared between two machines rather than as a clean failure at configuration time. The signature is a neighbour cache entry that flips between two link-layer addresses for the same network address.

A related failure appears when the link does not pass the probe. If the switch filters multicast, or the virtual switch drops the frames that carry Neighbor Solicitation, detection never receives a defence and the address is declared unique even though another node holds it. The absence of a negative answer is treated as a positive result, which is the only available interpretation but is not the same as proof.

On-link determination runs before the routing table

For IPv6, the host decides whether a destination is on-link by comparing it against the prefixes advertised for the interface, falling back to an assumption of on-link reachability when no prefix is known. If the destination is on-link, the host resolves the destination’s link-layer address directly. If it is not, the host selects a router from the default router list and resolves the router’s address instead.

This ordering means a missing or wrong prefix produces a specific and diagnosable behaviour: traffic to a peer in the same subnet leaves through the default gateway, and the gateway either routes it back onto the same link, which works but doubles the hop count, or drops it because it has no route for a directly connected network it does not own. The failure looks like a routing problem at the gateway and is actually a prefix-length error at the host.

IPv4 behaves differently because the mask is carried with the address and the derived route is materialised in the table. There, an incorrect mask produces a route that covers too much or too little, and the error is visible as an unexpected connected route. Either way, the check is the same: confirm that the prefix the interface believes it has matches the prefix its peers believe they are in.

Ordering failures during unattended boot

Configuration of an interface is usually driven by an event, and the events do not arrive in a fixed order. Carrier detection may lag the administrative up operation by a noticeable interval on copper, and considerably longer on links that negotiate or authenticate. An address assigned before carrier arrives is still valid; an address assigned by a protocol that requires the link to be up will not be attempted until carrier appears.

Services that bind to an address before the address exists fail, and the failure outlives the condition that caused it: a bind to an address that is not yet assigned returns an error rather than waiting, so a listener started too early exits and never serves the address that appears a moment later. A listener bound to the wildcard does not have this problem, which is why the failure is usually specific to a service configured with an explicit address. This is why startup ordering has to be expressed as a dependency on the address being usable, not merely on the interface existing, and why a supervisor that restarts the process is the practical fix.

The reverse ordering failure is more expensive. A route installed while an address is tentative or absent can persist after the address is removed, and the kernel may then hold a route whose output interface no longer has a source address for the destination. Packets matching it are dropped during source selection, with an error that names the route rather than the missing address.

A fixed inspection sequence

The sequence that terminates fastest is: link flags, then address state including validity, then neighbour reachability for the specific peer, then the route the kernel would actually choose for that peer.

ip -br link                       # carrier and operstate, separate from admin up
ip -br addr                       # flags on each address: tentative, dadfailed, deprecated
ip route get 192.0.2.10           # which interface and source the kernel selects
ip neigh show dev eth0            # binding state for the next hop

ip route get is the important one, because it reports the source address and output interface the kernel would use for a specific destination rather than the contents of the table in the abstract. A route that exists in the table but loses the lookup, or a route that wins the lookup but yields an unusable source, both show up here and nowhere else.

The neighbour cache adds one more layer of state that outlives the conditions that created it, and its staleness is a frequent cause of failures that appear and disappear without any configuration change. That behaviour has its own set of timers and probe rules, covered in neighbour cache staleness and unreachable peers.

What the ordering does not explain

A host can satisfy all four conditions and still fail to exchange traffic with a peer, because reachability is a property of the path rather than of one endpoint. Filtering on the intermediate device, an asymmetric return path that bypasses the stateful device, and a maximum transmission unit smaller than the sender’s are all invisible to the local checks above. They are distinguishable from configuration faults by one property: the local state is correct, and the failure is reproducible for a specific destination or packet size rather than for the interface as a whole. Establishing where the packet stops requires observing it at more than one point on the path, which is a different technique with its own artifacts. The counters that would otherwise attribute the loss are worth reading first, and they are not as self-explanatory as their names suggest; interface drop counters covers what each one actually records.