When the WAN drops, who do you call and what's the circuit ID?

It's 2:14 a.m. and your primary WAN link at the Aarhus site just dropped. Monitoring is screaming. The on-call engineer knows one thing for certain: this is a carrier circuit, not your gear. So the real work begins — not fixing anything, but finding out who to call.

Which provider owns this link? What's the circuit ID they'll ask for the moment you reach the NOC? What's the NOC number in the first place? And which rack does the handoff even land in, so someone can go put hands on the demarcation box if it comes to that?

If the answer to all of that lives in a forwarded email from 2023, a shared spreadsheet nobody trusts, and one person's memory, you don't have a network problem. You have an inventory problem.

The "who do I call and what's the ID" problem

Circuits are the part of the network you don't own but absolutely depend on. That makes them exactly the thing people forget to document properly, because the install happened once, it worked, and everyone moved on.

The information you need during an outage is boringly predictable:

• The provider and their NOC contact — a phone number and an email, not a name someone vaguely remembers.
• The circuit ID the carrier uses to identify the link on their side.
• The type and commit rate so you know whether you're troubleshooting a 1 Gbps dedicated wave or a best-effort broadband backup.
• The termination — the site, the rack, the device, and the port where this circuit actually lands.

None of that is exotic. It's just data that needs a home. Danbyte gives it one.

Model providers and provider networks first

Start with the carriers themselves. In Danbyte you model each provider once — the carrier, ISP, or transit vendor — and attach the details that matter at 2 a.m.: the NOC phone number, the support email, an account number, and a portal link.

Providers can also carry provider networks, so if a carrier runs multiple distinct networks or transit products (a DIA product, an L2 backbone, a peering fabric), you can represent those as first-class objects rather than cramming them into a circuit description.

The payoff is simple: every circuit points back to a provider, and the provider is the single place your NOC contacts live. Update the phone number once and every circuit inherits it.

Model the circuit with an ID, type, commit, and status

A circuit in Danbyte is the actual service you buy. Each one records:

• A circuit ID — the carrier's identifier, the string you'll read aloud to the NOC.
• A type — DIA, MPLS, dark fiber, broadband, wavelength, whatever the vendor sells.
• A commit rate and bandwidth, so the contracted speed is documented, not guessed.
• A status — active, provisioning, decommissioning, offline — so the lifecycle is visible.

Now the outage question "what is this thing and how fast is it supposed to be" has an answer that anyone on the team can pull up, not just the person who signed the contract.

Terminate the circuit at a real port

Here's where a lot of tooling stops short. Knowing a circuit exists is half the story; knowing where it physically lands is the other half.

A circuit termination in Danbyte attaches one end of the circuit to a specific site, and can go deeper — down to a specific device and port. A circuit typically has two terminations, an A side and a Z side, so you can model both ends of a point-to-point link between your sites, or the single hand-off where a carrier drops service into one facility.

Because the termination lands on a real interface, the circuit stops being an abstract line item and becomes part of your actual cabling. When you look at the edge router's uplink port, you can see it's carrying circuit DK-ARH-104829 from your transit provider — not just "WAN, do not touch."

Model the demarcation so cable traces stop where they should

Every carrier circuit has a point where their responsibility ends and yours begins: the demarcation — the NID, the handoff box, the smartjack in the rack. Everything on your side of the demarc is yours to fix. Everything past it belongs to the carrier, and the fix is a phone call.

Modeling the demarc explicitly matters for two reasons. First, it tells the person walking the floor exactly which box is the boundary. Second, it lets a cable trace run cleanly from your equipment to the demarc and stop there — the trace doesn't pretend to know what happens inside the carrier's network, because you don't.

  your edge router          patch /            carrier
   ge-0/0/3  ─────────────  demarc (NID)  ─────────────►  provider network
  [ you own & fix ]      [ handoff / boundary ]      [ their problem, their NOC ]

The value of that little boundary line at 2 a.m. is enormous. It's the difference between dispatching someone to reseat a cable versus opening a carrier ticket with the right circuit ID in the first sentence.

Track commit, bandwidth, and contracts with custom fields

Circuits carry commercial baggage that your NOC eventually needs: contract term, renewal date, monthly cost, a service-order number, an SLA tier. Danbyte's custom fields let you attach exactly those attributes to circuits and providers without bending the model.

That means the same object that answers "who do I call" during an outage also answers "when does this contract renew" during budget season — and "are we paying for 10 Gbps of commit we've never used" during a capacity review.

Bringing it together

Good circuit management isn't glamorous. It's the quiet discipline of writing down the boundary between your network and someone else's, once, in a place the whole team can reach. Done right, WAN circuit tracking turns a 2 a.m. scavenger hunt into a thirty-second lookup: provider, circuit ID, NOC number, termination port, demarc location — all on one page.

Danbyte models provider management and telecom circuit inventory the same way it models the rest of your infrastructure — as real objects that link to your sites, racks, devices, and ports, not as notes in a spreadsheet.

You can self-host Danbyte today, to get started.

The best time to document a circuit is the day it's installed. The second best time is before the next outage.