802.1X with Nautobot, and what happens when Nautobot is down

This is the answer to the question every operator asks about a policy-server-backed 802.1X deployment: “what happens when the policy source goes down?” For l2trace, the short answer is nothing breaks — and it’s worth understanding why, because the reason is baked into the architecture, not bolted on.

Two modes

Standalone. l2trace does 802.1X with no Nautobot at all. The RADIUS server decides from its own local store (a MAC’s authorization, set by an operator in the Approvals UI, plus what l2trace has observed). This is the default; Nautobot is off.
Integrated. Nautobot becomes the source of truth for the authorization policy (which device is allowed, on which VLAN, with which profile). l2trace consumes that intent read-only and renders the RADIUS response from it.

The rest of this page is about the integrated mode, and specifically its failure behavior.

The architecture: cache, then decide locally

l2trace does not call Nautobot when a switch asks it to authenticate a device. That would make Nautobot a latency-critical dependency in the auth path, and a Nautobot blip would stall or fail every switch authentication in the building.

Instead, a periodic sync pulls Nautobot’s authorization intent into l2trace’s local store, and the RADIUS answer reads that store. So the store is a cache, and the decision is always local and socket-fast. Nautobot is a writer that shapes policy over minutes, not a lookup on the critical path.

Nautobot ──(periodic sync)──▶ l2trace local store ──(per-auth read)──▶ RADIUS reply
   intent           minutes            the cache        microseconds     to the switch

FAQ: what happens when Nautobot is unreachable?

l2trace keeps authenticating devices from the cached policy, indefinitely, until Nautobot comes back. Concretely:

The RADIUS answer never touches Nautobot, so a switch’s Access-Request is served from the last-synced data whether Nautobot is up or down.
The sync is best-effort and fail-safe. When Nautobot is unreachable the sync cycle raises (connection error / timeout), aborts, and keeps the prior beliefs. Nothing is deauthorized. A failed or empty fetch is never read as “deny everyone” — a bad poll can’t lock the building out.
When Nautobot recovers, the next sync cycle simply refreshes the cache.
l2trace does not hammer an unreachable Nautobot: it retries on its normal interval, logging the failure, and serves the cache in between.

No thundering herd, no manual intervention, and a bad sync can never lock the whole building out.

The one exception: posture-required endpoints

Serving the cache is the right default, but it is too permissive for one class of device. Some endpoints are flagged (per-device or per-class) as posture-required: they must pass a live or recently-completed assessment before their normal profile applies. For those, serving a stale accept during an outage would hand a device network access it may no longer deserve.

So the fail-safe splits in two, and both halves are safe:

Not posture-required (a printer on MAB, or any device whose cached intent is a complete answer): serve the cached decision, indefinitely. Unchanged.
Posture-required, assessment can’t be completed (Nautobot / the posture source unreachable, or the cached posture is older than its freshness bound): render the endpoint’s configured fallback profile instead of the cached one. That fallback is operator-set and conservative by default: a restricted quarantine VLAN (limited to DHCP / DNS / remediation) or an outright block.

This is not a contradiction of “never fail closed.” That guarantee is about a global fetch failure never denying everyone — and it still holds. This is a per-endpoint, opt-in degrade to a configured safe state, scoped to the subset that explicitly requires an assessment. The whole building keeps working; the posture-required devices drop to their known-safe fallback until the assessment can run again. Both the flag and the fallback profile are Nautobot-authored intent; l2trace decides locally when the fallback fires.

The certificate is a separate, local dependency

There’s a subtlety worth stating precisely, because it’s the real bound on availability during a Nautobot outage. A PEAP / EAP-TLS authentication has two independent needs:

Need	Depends on	During a Nautobot outage
The TLS tunnel (PEAP / EAP-TLS)	l2trace’s local server cert + CA	Works, as long as the cert is valid / not expired
The decision (which VLAN / profile)	the cached authorization data	Works, served from the local store
MAB (no tunnel)	neither	Works regardless

l2trace’s RADIUS server certificate is loaded from local files at startup; it is never fetched from Nautobot. So the crypto handshake and the policy decision fail independently. The practical consequence: 802.1X availability during a Nautobot outage is bounded by l2trace’s own certificate validity, not by Nautobot’s reachability. Keep the RADIUS server cert renewed, and a Nautobot outage of any length is invisible to the switches.

Nautobot never silently overrides an operator. An explicit operator approve/deny in l2trace is a sticky decision: a Nautobot intent that disagrees is flagged as a conflict, never auto-applied. This holds whether Nautobot is up or down.
Monitor mode still changes nothing. A synced Nautobot intent only moves a device under enforcement (triple-gated); in monitor mode l2trace records the belief and fires no Change-of-Authorization.
Bulk changes are storm-capped. When Nautobot returns after a long outage and a large batch of intents changed, l2trace does not blast the fabric with CoAs — over a per-cycle cap it records the beliefs, logs loudly, and lets devices converge on their next auth.