Summary

  • 0.0.0.0/0 and ::/0 contain no destination-specific prefix bits, yet they match every address left after longest-prefix selection. A default is therefore not knowledge of every destination; it is a next-hop promise for the unresolved remainder.
  • Default origination, receipt, import, RIB selection, FIB installation and packet delivery are separate states. An unconditional advertisement can remain healthy after the advertiser loses the upstream service that gave the promise meaning.
  • Leadership should permit last-resort delegation only through explicit neighbor scope, a condition tied to the promised service, receiver-controlled acceptance, diverse packet canaries, measured withdrawal and a complete rollback record.

At 09:41, AS 64520 loses the transport carrying most of its external routes. The failure does not touch the customer-facing router or its EBGP session with AS 64580. Keepalives continue. Several regional prefixes remain reachable through a second path. The provider's per-neighbor default advertisement also continues because it was configured unconditionally.

AS 64580 still sees 0.0.0.0/0, still selects AS 64520 as next hop and still programs that choice into forwarding hardware. Its dashboard tests the provider loopback, a regional DNS resolver and two addresses covered by surviving more-specific routes. All four pass. Traffic to other destinations follows the default into AS 64520 and dies where the missing upstream should have carried it.

This incident is synthetic. The mechanism is not. Nothing in a stable BGP session requires a default route to disappear when a different upstream fails. Nothing in /0 lists the destinations the neighbor can actually deliver. The route can be correctly encoded, accepted, selected and installed while its operating premise is false.

The useful question is therefore not “is the default up?” It is: what promise caused the route to be created, which running evidence keeps that promise true, who can stop relying on it, and how quickly does loss of the evidence become a withdrawal?

Zero bits, residual authority

A prefix is a statement about an address range. The longer its prefix length, the more narrowly it identifies destinations. A /24 fixes 24 leading bits. A /0 fixes none. It is the least descriptive route possible within an address family.

That absence of detail does not make the route inert. The forwarding rule in RFC 1812 first retains routes whose prefix matches the destination, then chooses the longest match. Because every address shares the zero-bit prefix, 0.0.0.0/0 matches every IPv4 destination. ::/0 plays the same role for IPv6. Any usable more-specific wins before later preference or metric comparisons matter.

The default therefore governs a residual set, not a fixed list. If the receiver learns 198.51.100.0/24, packets for that block do not use /0. If the /24 is withdrawn, those same addresses immediately fall under the default without the default changing at all. A route whose bytes are stable can acquire new practical scope as other routes appear and disappear.

This is the first authority boundary. The advertiser does not enumerate all destinations it undertakes to carry. The receiver delegates whatever its more-specific routing leaves unresolved at that instant. Both sides influence the resulting set: one publishes the broad fallback, the other determines which specifics override it.

RFC 4098 keeps the terminology honest. A default route is not a full default-free table. The latter is a collection of destination-specific BGP routes and itself varies by time and observation point. A network can use a default instead of receiving a full table, receive a default alongside selected specifics, or hold multiple defaults from different providers. Those are different information and failure models.

Explicit publication is the first safety control

RFC 4632 calls 0.0.0.0/0 the degenerate default prefix and requires implementations to accept it. It then sets an important inter-domain boundary: to prevent accidental advertisement, a router should send the route to another routing domain only when explicitly configured to do so, never as a non-configured default option.

RFC 7454 supplies the relationship policy. IPv4 and IPv6 defaults are normally not meant to be accepted or advertised outside specific customer/provider arrangements, and general filtering elsewhere is recommended. The same document recognizes a legitimate design in which a customer requests only a default from a provider rather than the full table.

Those statements are compatible. /0 is a valid route. Its use can be efficient and intentional. Its scope is not presumptively global. The fact that one customer asked for it does not authorize the provider to send it to a peer, an upstream, an exchange route server or every tenant in a shared routing instance.

The advertiser needs an explicit per-neighbor decision. The receiver needs an explicit import rule permitting exactly /0 from an authorized relationship in the correct AFI/SAFI and routing instance. Export and import are independent: a provider error should meet a customer filter, and a customer error should not make the provider's intent universal.

RFC 8212 strengthens the adjacent rule that external BGP should not exchange routes in the absence of policy. But the presence of a policy object is not semantic proof. An explicit route map can still authorize the wrong neighbor, accept /0 from a peer, or keep an unconditional default alive through a forwarding failure. “Policy configured” proves only that the system did not fall through an empty policy slot.

One route passes through six different states

Operational language often collapses several acts into “we have a default.” That phrase is too coarse for an incident record.

First, the provider creates or selects a candidate route. On some systems this is a synthetic per-neighbor advertisement; on others it is a static, generated or BGP route eligible for export. Second, outbound policy permits it toward a particular neighbor. Third, the customer receives the UPDATE. Fourth, inbound policy accepts it. Fifth, local BGP selection compares it with other defaults. Sixth, the routing system programs the winning next hop into the FIB.

Packet delivery is a seventh state, outside the route object. The FIB can point to a live interface and recursively resolved next hop that cannot carry the destination beyond the adjacent network. A forwarding entry proves what the local router will attempt, not what every downstream system will complete.

Each boundary can fail independently. A route can be generated but filtered. It can be received but rejected. It can be accepted but lose to a preferred default. It can win in the RIB but wait for hardware programming. It can enter the FIB while the data plane beyond the neighbor is broken. Monitoring that reads only one layer can report a technically accurate fact and a materially false service conclusion.

The distinction also clarifies withdrawal. RFC 4271 allows the provider to withdraw /0 in an UPDATE while preserving the session. The customer can then select an alternate default or declare the destination unresolved. Tearing down the entire EBGP session is unnecessary if the failed promise is only the last-resort route.

“Default originate” is not one portable behavior

Current Cisco IOS documentation describes neighbor ... default-originate as a per-neighbor mechanism and says the local router does not need a 0.0.0.0 entry. Cisco Nexus documentation makes the separation even more visible: the artificial default need not exist in the routing table and is not created in the local BGP RIB. An optional route map can make origination conditional on a matching installed route.

FRRouting documents a different default boundary. It does not announce 0.0.0.0/0 merely because the route exists in the routing table. The operator explicitly enables neighbor ... default-originate; an optional route map supplies conditions.

Junos uses its routing-policy model. BGP normally exports active BGP routes. Static, aggregate, generated or other explicitly configured routes can be exported when policy permits. Its documented conditional-route examples make active routing state and export policy part of one decision chain.

These are not trivial syntax differences. On one platform, deleting a local static /0 may have no effect on an unconditional synthetic neighbor advertisement. On another, route activity may be the very thing that makes export possible. A runbook copied across products can therefore preserve a default when its author expected automatic withdrawal, or withdraw it when the author expected a separate synthetic object.

Deployed behavior must be established by release-specific tests: inspect the local RIB, BGP RIB, advertised-route view and receiver; remove the supporting route or condition; record reevaluation and withdrawal; restore it and verify re-advertisement. Documentation describes a model. Only the running test proves which model controls this neighbor today.

A condition is evidence, not the service itself

Conditional origination sounds like a complete repair: advertise /0 only while another route, tracked object or health check exists. It is better than an unconditional promise only if the predicate represents what the default is supposed to mean.

Matching one provider loopback proves reachability to one provider loopback. Matching a static route proves that configuration or recursion kept the static route active. Matching a full-table count proves that a threshold was met, not that the selected egress forwards. An interface-up signal proves local carrier state. A BFD session proves continuity to a particular peer on a particular path. None alone proves all destinations behind /0.

The predicate should be derived from the commercial and operational promise. If the default promises broad transit, the evidence should cover independent external destinations, more than one downstream dependency and the actual forwarding path used by customer traffic. If it promises access only to a private service domain, the probes and route state should reflect that narrower set rather than an imagined public Internet.

Multiple signals reduce one kind of error and create another design decision. Requiring every canary to pass can withdraw useful connectivity when one measurement target fails. Requiring only one can preserve a blackhole while a narrow island remains reachable. Quorum, hysteresis and hold-down choices allocate the cost between premature withdrawal and late withdrawal. They are policy, not neutral tuning.

The predicate itself needs a state history. Record which component changed, when the combined decision changed, when /0 was withdrawn and when the receiver's FIB followed. Without those epochs, operators can see a later healthy route but cannot explain the customer's outage interval.

The path belongs to the advertisement, not every destination

A default carries BGP attributes like other routes. AS_PATH helps prevent loops and describes propagation of the /0 announcement. NEXT_HOP tells the receiver where to send traffic selected by that route. LOCAL_PREF or other local policy may choose among competing copies.

Those fields do not transform the default into a destination-level map. An AS_PATH of 64520 does not mean every unmatched destination is one AS away. It means the neighbor sent a default whose advertised path has that form. Behind AS 64520 may be several upstreams, partial routes, tunnels, filters and failures that the UPDATE does not expose.

Similarly, a reachable NEXT_HOP proves only that the receiver can resolve and address the adjacent forwarding choice. The neighbor can accept the packet and still have no usable onward path. A high local preference expresses the customer's decision to trust one default before another. It does not measure which provider is currently healthier.

Multiple defaults are therefore options, not independence proof. Two sessions may terminate on different routers but share a metro fibre, upstream transit, controller or conditional probe. A failover test that withdraws one session may succeed while the real common-mode failure leaves both defaults present and both paths unusable.

More-specifics can hide failure in both directions

The synthetic incident produced partial success because surviving more-specific routes overrode the broken default. This can make a provider appear mostly healthy if monitoring targets cluster inside those specifics. The residual set may contain the majority of customer demand even though only a minority of probes fail.

The reverse failure also matters. A healthy default does not rescue a broken more-specific. Longest-prefix matching sends the destination into the narrower route first. An accidental or stale /24 can blackhole one service while /0 continues to carry the rest of the Internet. A single “default reachability” metric cannot detect that diversion.

This means availability must be classified by the selected route, not merely by destination success. For every canary, record which prefix won, which next hop entered the FIB and which egress carried the packet. Otherwise a passing test may validate a more-specific while the team believes it validated the default.

Route churn changes the test surface. When a specific is withdrawn, its destinations move under /0; when the specific returns, they leave it. The default's operational responsibility expands and contracts without a new default UPDATE. Monitoring should detect these scope changes even when the last-resort route's hash is unchanged.

A leaked default is an unauthorized delegation

A default accepted from the wrong relationship can attract every destination the receiver does not know more specifically. The damage depends on the receiver's other routes: a full-table router may expose little residual traffic, while a small customer with no specifics may transfer nearly everything.

Provider-side export control should identify the exact customers entitled to a default and prevent propagation toward peers, upstreams and route servers. Customer-side import control should permit exactly /0, not “any prefix length up to zero” expressed through an ambiguous filter, and should reject default advertisements from all other external roles.

Address families and routing instances need separate checks. Authorization for IPv4 does not silently include IPv6. A default intended for one VRF must not appear in another. Shared configuration inheritance, peer groups and automation can widen scope more quickly than an engineer reading one neighbor stanza expects.

Audit both intent and result. The configuration tells which neighbors should receive the route. Adj-RIB-Out or advertised-route views show which neighbors did receive it. Receiver-side Adj-RIB-In proves arrival. Route collectors can provide external evidence if the route escaped, but absence at a collector is not proof that no unintended neighbor received it.

Build an evidence chain from configuration to packets

For every default relationship, the evidence ledger should begin with the promise: public Internet transit, selected external services, private WAN exit or another bounded purpose. Then name the advertiser, receiver, address family, routing instance, neighbor role and approval owner.

Record the generation model: unconditional synthetic origination, conditional neighbor command, static or generated route plus export policy, or received default re-advertised under an explicit design. Store the exact predicate, its inputs, quorum, hold timers and failure behavior. A screenshot of the command is not enough.

At runtime, preserve the candidate route, post-policy advertised route, receiver's pre-policy and accepted views, selection reason, RIB entry, recursive next hop and hardware FIB. Timestamp each transition. Track alternative defaults and the more-specifics used by canaries.

Packet tests should originate on the receiving side, where reliance becomes action. Use destinations that are reachable only through /0, not merely addresses with known more-specific routes. Spread probes across independent networks and services. Include the expected packet path or at least the selected egress so a success through another route is not misattributed.

Then test failure deliberately. Remove the real support on which the condition depends while leaving the customer session up. Measure predicate failure, default withdrawal, alternate RIB selection, FIB programming and packet recovery separately. If there is no alternate, prove that the receiver stops forwarding into the dead provider instead of maintaining a silent blackhole.

The rollback record must restore generation mode, predicate, timer, neighbor scope, attributes, customer import preference and monitoring. Reinstating the configuration while a receiver still prefers a stale alternative is not complete rollback. Neither is restoring the route without proving packets.

Thin coordination requires a strong local exit

The default route is a striking example of minimum shared specification. The two networks do not exchange a full description of every destination. One publishes a compact statement. The other voluntarily uses it as a fallback under local policy. That design preserves autonomy and reduces state.

Minimal information, however, cannot justify maximal institutional interpretation. The provider label does not certify delivery. The route's presence does not create a right to keep the customer's traffic. The customer's initial acceptance does not waive its authority to change preference or reject the route. The arrangement remains legitimate because both sides keep local control and a protocol-level exit.

Running-code primacy sets the order of proof. A contract can describe the service. Configuration can describe intent. An UPDATE can prove that a route was sent. A RIB and FIB can prove local selection. Only packets, observed across the promised scope, test whether the operating claim remains true. None of these layers should be asked to prove what belongs to the next.