Circuit and WAN Management Guide: Tracking MPLS, DIA, and Broadband Circuits

Your team probably has a rough idea of how many circuits connect your sites, but ask anyone in the organization to tell you the contract end date for the MPLS circuit at your Chicago data center, the carrier escalation contact for the DIA link at your Denver office, or even which physical port that broadband backup circuit terminates on at your headquarters, and the answers will range from “let me check a spreadsheet” to “I think Mark knew that before he left.” Circuit management occupies an uncomfortable middle ground in most network operations. It is not complex enough to demand dedicated tooling at the outset, so it gets tracked in spreadsheets and carrier portals, but the cost of managing it poorly compounds quietly until your team is making procurement decisions without accurate data, missing contract renewal windows that cost thousands in inflated rates, and spending hours during an outage trying to locate carrier contact information that should be accessible in seconds. The problem is not that your team is disorganized. It is that circuit management spans disciplines that rarely share the same tooling. Procurement tracks contracts, the network team tracks configuration, the finance team tracks costs, and each group produces its own partial view of the same circuits, with no mechanism to reconcile the conflicting versions into a single source of truth that everyone can trust.

The transition from a handful of circuits to a network portfolio that requires systematic management happens gradually and without a clear trigger. A second data center comes online, and suddenly your MPLS footprint includes a new hub site with redundant circuits from two different carriers. An SD-WAN rollout adds DIA circuits to every branch location, with broadband backup links layered on top for failover. Remote sites that were previously connected via VPN tunnels become site to site VPN or dedicated circuit endpoints because your traffic volume outgrew what the internet link could sustain. Each addition is individually justified and seems small on its own, but the cumulative result is a circuit inventory that spans multiple carriers, circuit types, contract terms, and SLA structures, managed through a collection of spreadsheets that are never quite synchronized and carrier web portals that all require different credentials and have different ways of representing the same data. The operational friction does not appear as a single catastrophic failure. It appears as a thousand small delays. A five minute search for a circuit ID during an outage. A thirty minute research effort before a renewal call because you cannot trust the cost data in your spreadsheet. An hour long audit of carrier invoices because you suspect you are paying for a circuit that was decommissioned six months ago but never removed from billing.

What a Circuit Inventory Actually Needs

The gap between how most teams track circuits and what they actually need from a circuit inventory is visible in the questions that arise during routine operations that should be straightforward. When a carrier notifies you of a maintenance window for a circuit at a specific location, you need to know immediately which sites and which applications are affected, whether that circuit is the primary or backup path for the location, and who the secondary carrier contact is in case the maintenance extends beyond the scheduled window. When you are negotiating a contract renewal, you need a complete picture of your current spend per carrier, per site, and per circuit type, with utilization data that tells you whether you are overprovisioned or approaching capacity. When an outage occurs and the carrier NOC asks for the circuit ID, you need to find it from your own records in under a minute, not spend fifteen minutes logging into the carrier portal while your users are down and the ticket is aging because the SLA clock started ticking the moment you opened the case. These are not edge cases. They are the recurring, predictable interactions that define whether your circuit management practice is functional or dysfunctional, and the difference between the two outcomes depends almost entirely on whether the data you need exists in a single queryable location or is distributed across a network of spreadsheets, portals, and mental models that break down under pressure.

The fields that matter go beyond circuit ID and bandwidth. You need carrier account numbers, contract start and end dates with auto renewal terms, monthly recurring costs broken out per circuit rather than aggregated into a single carrier invoice line, SLA guarantees with documented uptime commitments and credit claim procedures, A side and Z side termination details that include the specific building, floor, rack, and port, carrier NOC contact information with escalation paths, and utilization data that tells you whether the bandwidth you are paying for matches the bandwidth you are actually using. Every field that is missing or inaccurate in your inventory creates friction that your team absorbs during incidents and planning cycles, and that friction accumulates across every circuit and every interaction until managing your circuit portfolio consumes more time and energy than the circuits themselves justify. The teams that invest in complete circuit data at the point of entry, rather than treating documentation as a retrospective activity that happens when someone has spare time, are the teams that can answer any question about their WAN in seconds rather than minutes, and the compounding effect of those seconds across dozens of circuits and hundreds of interactions per quarter is the difference between a network team that feels in control of its WAN and one that feels perpetually reactive.

MPLS Circuits Demand the Most Discipline

MPLS circuits carry a level of operational and financial commitment that distinguishes them from other circuit types. A typical MPLS contract runs three to five years, involves significant monthly recurring costs that scale with bandwidth and mileage, and ties your entire WAN architecture to a specific carrier’s network and SLA framework. When an MPLS circuit fails, the impact is rarely limited to a single site, because MPLS topologies typically route traffic through hub sites or carrier backbone nodes that serve multiple locations, and a failure at the hub can take down connectivity for every spoke site depending on that hub for transport. The provisioning timeline for a new MPLS circuit, typically thirty to ninety days depending on the carrier and the location, means that planning errors or missed renewal dates have consequences that cannot be resolved within a standard change window and often require costly expedite fees or bridge solutions that add complexity and cost to an already constrained situation. A three month provisioning window means that if you discover a capacity gap today, the circuit to address it will not be available until next quarter, and any growth or migration plan that depends on that circuit is blocked until the carrier completes its installation cycle.

The data you need to track for MPLS circuits reflects this complexity. Beyond the basics, you need the carrier’s circuit identifier, which differs from your internal circuit name and is the reference the carrier NOC uses to look up your service. You need the local exchange carrier responsible for the local loop at each end of the circuit if the provider uses third party last mile infrastructure, because trouble reporting through a third party LEC adds an extra layer of coordination and delay that your escalation plan must account for. You need the handoff type and media, fiber or copper, with or without carrier provided CPE, because the difference between a carrier managed handoff and a direct fiber connection determines who is responsible for hardware failures and how replacement cycles are handled. You need the VLAN or VRF assignments that map the circuit to your routing topology, so that an engineer troubleshooting an MPLS connectivity issue can trace from the circuit to the routing context without reconstructing the configuration from device logs. And you need the MTU configuration to ensure consistency across the path, because an MTU mismatch at the carrier handoff is one of the most common sources of intermittent performance issues that generate months of fruitless troubleshooting before someone discovers that the carrier configured its interface for a different MTU than your router expects.

MPLS circuits also typically involve a demarcation point where the carrier’s responsibility ends and yours begins. Documenting that demarc clearly for every circuit is essential for troubleshooting, because the first question in any carrier outage is whether the fault is on their side of the demarc or yours, and answering that question requires knowing exactly where the demarc is, what type it is, and what evidence the carrier will accept as proof that the fault is on their side. Without a documented demarcation for each circuit, your team wastes time proving the obvious to the carrier NOC while the outage clock ticks and your users wait for a resolution that depends on an escalation that has not been initiated because nobody is certain whose problem it is yet. The demarc documentation should include the physical location of the handoff, the device and port number on both sides, and the expected light levels or signal metrics that differentiate a carrier side fault from a customer side fault, so that your team can provide the carrier with the specific evidence they require to initiate a dispatch rather than spending the first hour of every outage in a verification loop that neither side finds productive.

DIA Circuits and the Public IP Tracking Problem

Dedicated Internet Access circuits introduce a set of tracking requirements that MPLS circuits do not. Every DIA circuit comes with a block of public IP addresses that the carrier allocates to your organization, and those IPs need to be tracked with the same rigor as your internal IP space because they carry your public facing services, peer with your BGP sessions, and represent your organization’s external presence on the internet. Losing track of which public IPs belong to which DIA circuit at which site creates problems that extend beyond network operations into security monitoring, reverse DNS management, and abuse handling. When a security team receives an abuse report for an IP address, they need to know immediately which circuit it belongs to, which site, which carrier, and which device is using that address, so they can respond within the response window that the abuse report imposes. A circuit inventory that links public IP allocations to specific DIA circuits and interfaces eliminates the escalation delay that occurs when the security team has to start from zero and work through multiple teams to trace an IP back to its source circuit, a process that can stretch into hours when the only record of the allocation is in the carrier portal that requires a different login than the one the security team uses.

The interaction between DIA circuits and your BGP peering architecture is another dimension that demands structured documentation. The ASN you use for peering, the carrier’s ASN, the prefix you advertise, the MED and local preference settings, and any community strings you apply to control route propagation are configuration details that should be referenced from your circuit inventory rather than buried in device configurations that only exist on the routers themselves. When a DIA circuit is replaced or a new carrier is added, having the BGP peering details documented alongside the circuit record in your inventory means the provisioning engineer has everything they need in one place rather than searching through old router configs and ticket history to reconstruct the peering setup that needs to be migrated or modified. This consistency prevents the configuration errors that occur when peering details are reconstructed from memory or from partial documentation that misses a critical community string or prefix filter, errors that are notoriously difficult to diagnose because BGP session failures rarely produce clear error messages that point to the root cause.

DIA circuits also tend to have more variable bandwidth utilization patterns than MPLS circuits, because internet traffic is inherently bursty and your utilization at any given moment depends on user behavior, application traffic patterns, and external factors like DDoS attacks or traffic from partners and customers that you do not control. Tracking utilization trends over time for your DIA circuits, and correlating those trends with the bandwidth you are paying for, is essential for right sizing your circuits at renewal time. The number of teams that pay for 1 Gbps DIA circuits that consistently run at 15 percent utilization is surprising, and the wasted spend across dozens of DIA circuits is a budget line item that could be redirected to more impactful initiatives if the utilization data were visible in the same tool where renewal dates and costs are tracked.

Broadband and Cellular Backup Are Underdocumented

The broadband circuits that many teams use for backup connectivity are consistently the most underdocumented assets in the network inventory. A cable modem or LTE router gets installed as a failover path, tested once to confirm it works, and then forgotten until the primary circuit fails and someone needs to find the modem in a wiring closet where the labels have fallen off and nobody remembers which outlet it is connected to. The irony is that broadband backup circuits become most critical at the moment when your primary monitoring and communication channels are compromised, and the documentation you need to activate the backup is stored in the same tools that are unreachable because they depend on the connection that just failed. A printed contact card in the server room helps in that scenario, but it is a partial solution at best because it cannot capture the changing data like ISP account credentials that rotate or SIM card ICCIDs that were replaced during a hardware refresh that nobody logged.

Broadband and cellular circuits require their own tracking fields that differ from MPLS and DIA in meaningful ways. For cable or DSL broadband, you need the modem MAC address, the ISP account credentials, the dynamic DNS hostname or static IP if one is assigned, and the maximum achievable bandwidth which is almost always lower than the advertised speed for the connection and varies with time of day and neighborhood utilization patterns. For cellular backup, you need the ICCID of the SIM card, the carrier and APN configuration, the data cap and throttling policy, and the coverage quality at the specific location which can vary significantly based on building construction and carrier tower placement. The bandwidth asymmetry of consumer broadband, often 300 Mbps down and 10 Mbps up, means that your backup path may support download traffic but fail to carry upload dependent applications like VoIP or video conferencing during a failover event, and your inventory should flag this limitation prominently so that engineers do not assume symmetric capacity during failover planning.

A secondary consideration for broadband backup circuits is physical path diversity. It is surprisingly common for a broadband circuit to share the same physical conduit, riser, or even the same demarcation room as the primary MPLS or DIA circuit, which means that a physical cut or building access issue that takes out the primary circuit is equally likely to take out the backup. Documenting the physical path and entry point for every circuit, including broadband, allows your team to identify diversity risks during the planning phase rather than discovering during an outage that your “redundant” connectivity is routing through the same building entry point and therefore provides no actual redundancy. Teams that document physical path diversity alongside their circuit inventory are the teams that discover these conflicts during a design review, when the solution is a simple reroute or carrier change, rather than during an active outage when every minute of failover delay translates directly to user impact and revenue loss.

Contract Costs and Renewal Dates

The financial dimension of circuit management is the area where poor data quality has the most direct and measurable impact on your organization’s bottom line. MPLS and DIA circuits are expensive, typically ranging from a few hundred to several thousand dollars per month per circuit, and the cumulative spend across dozens of circuits represents a significant line item in any network operations budget. Carrier pricing is negotiable at contract renewal time, but negotiating effectively requires a complete picture of your current spend, utilization, and market alternatives for each circuit, and that picture is almost impossible to assemble when your circuit cost data is scattered across invoices, procurement systems, and spreadsheets that have not been reconciled since the last major renewal cycle. A carrier account manager will never volunteer that your current rate is above market. They will present the renewal as a “competitive” offer that assumes you have no baseline for comparison, and if your cost data is not structured and accessible, you have no way to validate their claim.

The most common and costly mistake in circuit contract management is the missed renewal notification window. Carriers typically require thirty to sixty days notice before a contract expiration if you want to renegotiate terms or cancel without penalty. If that window passes without action, most contracts auto renew for an additional term at the standard rate, which is typically higher than the negotiated rate from the previous term. The result is that a team that missed the notification window due to poor contract date tracking effectively locks itself into another multi year commitment at unfavorable pricing, because the alternative is paying early termination fees that are structured to make cancellation financially prohibitive. Tracking contract end dates with automated renewal reminders is the single highest ROI activity in circuit management, and the tools that make this automatic rather than dependent on a calendar entry that someone has to remember to create and update for every circuit are the tools that save organizations real money on every renewal cycle. If your circuit inventory does not surface upcoming renewals at least sixty days in advance, you are making a financial bet that your team will remember every contract date manually, and that bet will lose at least as often as it wins.

Beyond renewal dates, you need the monthly recurring cost for each circuit broken out separately rather than aggregated into a single carrier invoice line that covers multiple circuits under the same account. Aggregated billing hides per circuit cost variation that signals pricing inequities, and it makes it impossible to compare the cost of circuits at different sites or from different carriers on an apples to apples basis. A site location that pays significantly more for the same bandwidth from the same carrier as another site is a renewal negotiation opportunity that only exists if your circuit inventory surfaces the difference, and it will not surface as long as both costs are buried in a single line item on a monthly invoice that nobody reads because reading it would require cross referencing against a circuit inventory that does not exist. The financial impact of this kind of pricing inequity across a portfolio of thirty or forty circuits can easily reach tens of thousands of dollars per year in excess spend that is invisible to everyone except the carrier’s account team, who have every incentive to maintain the status quo.

Provisioning Status and Circuit Lifecycle Tracking

One of the most commonly overlooked aspects of circuit management is tracking the lifecycle state of each circuit through its provisioning, active operation, migration, and eventual decommissioning phases. A circuit that is in provisioning status represents a future operational commitment that will need to be documented, tested, and integrated into your monitoring and routing configuration before it can serve production traffic. The provisioning phase is also where the most circuit documentation errors originate, because the engineer who ordered the circuit and the engineer who installs it are rarely the same person, and the handoff between them is usually an email thread or a ticket comment rather than a structured data transfer that populates the inventory with the carrier circuit ID, handoff details, and test results that the installing engineer discovers during the turn up process.

Tracking the provisioning status of each circuit in your inventory means you can see at a glance how many circuits are in the carrier’s provisioning queue, which sites are waiting for new connectivity, and whether any circuits have been in provisioning status for longer than the carrier’s stated lead time, which is an early indicator that the carrier is behind schedule and your project timeline depends on a date that is no longer accurate. A provisioning status workflow that moves a circuit from ordered to provisioning to testing to active, with status change dates and notes recorded at each transition, gives your team visibility into the carrier delivery pipeline that is otherwise invisible until the carrier misses a commit date and your project manager is trying to explain to stakeholders why the site launch is delayed.

The decommissioning phase deserves the same structured attention. When a circuit is replaced by a new carrier or a different technology, the decommissioning process includes steps that are easy to forget when the documentation is informal. The old circuit needs to be removed from router configurations, the interface references in your monitoring system need to be updated, the billing relationship with the carrier needs to be terminated with written confirmation that no further charges will accrue, and the physical equipment at the site needs to be returned or disposed of if it is carrier owned. A circuit inventory that tracks decommissioning status and includes a checklist of decommissioning steps ensures that each of these actions is completed before the circuit record is archived, preventing the common scenario where a decommissioned circuit continues to appear in monitoring alerts and invoice line items for months after it was physically removed, generating noise and confusion that degrade trust in the data across your entire inventory.

Circuit Diversity and Redundancy Planning

Circuit diversity planning is the practice of ensuring that your redundant connectivity paths are truly independent, which requires a level of documentation that most teams do not maintain. Two circuits from different carriers that enter the building through the same conduit, terminate in the same demarcation room, or route through the same carrier hotel are not redundant in any meaningful sense, because a single physical event like a construction dig up, a building power outage, or a fire in the provider common area can take both circuits down simultaneously regardless of which carrier owns them. Documenting the physical path, building entry point, and carrier aggregation points for every circuit in your inventory allows your team to assess diversity at a glance and identify hidden single points of failure that undermine your redundancy architecture.

The same diversity analysis applies at the carrier level. Two MPLS circuits from AT&T and Verizon that both backhaul through the same carrier neutral data center or interconnect facility are sharing infrastructure at the aggregation layer, which means a failure at that facility affects both circuits regardless of the carrier label on the service contract. Understanding your carrier interconnection topology, where different carriers hand off traffic to each other and where your circuits converge onto shared physical infrastructure, is essential for designing a WAN that actually survives the failure scenarios you are planning for. The telemetry to assess diversity exists in your circuit records and carrier documentation, but it only translates to actionable insight if your circuit inventory captures the intermediate termination points and carrier handoff locations rather than just the A and Z site names.

The teams that invest in circuit diversity documentation are the teams that discover single points of failure during a planning exercise rather than during an outage, and that discovery alone justifies the documentation effort across your entire circuit portfolio. When a critical site has two circuits that appear redundant on paper but share a common physical path that you identified through your inventory analysis, you have the information you need to request a route change from one of the carriers or add a third circuit on a genuinely diverse path before the shared infrastructure fails and takes both connections down at the worst possible moment.

Carrier Management and SLA Accountability

The relationship between your organization and each of your circuit carriers is a recurring operational responsibility that needs structure and documentation. Every carrier has its own support portal with unique credentials, NOC contact number that routes differently during business hours versus after hours, ticket escalation path that varies by severity level, and SLA credit claim process with specific documentation requirements and filing deadlines. Maintaining carrier documentation in your circuit inventory ensures that anyone on your team can initiate a carrier escalation during an incident without first searching through email threads, portal credentials stored in a password manager that requires its own authentication, or the mental map of whoever handled the last outage for that carrier. Carrier NOCs do not make exceptions to their SLA response times based on the fact that your team could not find the correct escalation contact. The SLA clock starts when the ticket is opened, and every additional minute you spend locating the right contact consumes the resolution time that the SLA guarantees you.

SLA tracking is another area where most teams leave money on the table because they do not track carrier uptime against SLA guarantees in a systematic way. Industry estimates suggest that sixty to eighty percent of eligible SLA credits go unclaimed because teams do not have the data to file a claim within the carrier’s filing window, which is typically thirty to ninety days from the outage date. To claim a credit, you need the circuit ID, the start and end time of the outage, and evidence that the outage breached the SLA threshold. If your circuit inventory captures the SLA parameters for each circuit and your incident tracking system captures outage start and end times, the data to file claims is sitting in your tools, but it only translates to carrier credits if someone has the visibility to connect the two. A circuit inventory that surfaces SLA commitments alongside outage history makes the claim process routine rather than exceptional, and the credits you recover directly offset your circuit costs in a way that is entirely dependent on documentation quality. The teams that consistently claim SLA credits are not the teams with more outages. They are the teams that have the data to file claims within the filing window, and the difference between them and the teams that leave credits unclaimed is a structured circuit inventory that captures SLA parameters as a standard field rather than an afterthought.

The operational value of carrier documentation extends beyond SLA credits and directly affects your mean time to resolution during circuit related incidents. Every documented carrier contact, escalation path, and account reference that your team can access from the same tool where the circuit is defined is a step removed from the troubleshooting process. The aggregate effect across a team that handles multiple circuit incidents per quarter is a measurable reduction in MTTR that compounds as the documentation becomes more complete and your team becomes more practiced at finding the information they need without searching. When every circuit record includes the carrier NOC phone number, the account number the carrier uses to identify you, the circuit ID in the carrier’s system, the maintenance window schedule, and the escalation contacts for each severity level, your team can open a carrier ticket with complete information in the first interaction rather than spending the first fifteen minutes of every incident gathering the data that the carrier will ask for anyway.

Centralized Circuit Lifecycle Management with Obelinf

Obelinf treats circuits as a core entity in your infrastructure data model alongside circuit providers, circuit types, and circuit groups, each with structured fields and full CRUD interfaces available through both the dashboard and the REST API. Every circuit you add is stored with its provider, type, group assignment, status (active, planned, or decommissioned), and links to two sites representing the A and Z termination points of the connection. Providers and types are fully configurable entity types of their own, so you can model AT&T, Verizon, Lumen, and any regional carrier alongside circuit classifications like MPLS, DIA, broadband, dark fiber, or wavelength, all within a consistent schema that your entire team shares rather than maintaining separate lists in spreadsheets that diverge over time. Circuit groups support hierarchical nesting, which means you can organize your circuits into functional categories like WAN circuits, internet circuits, and cross connects, with subgroups for regional or departmental subdivisions that mirror your actual operational structure.

Circuits in Obelinf are linked directly to sites through the A and B site fields on each circuit record, and they appear in the site topology view alongside devices and other infrastructure, so you can see every circuit that terminates at a given location from a single site focused view. This eliminates the disconnect between your circuit registry and your physical site topology that drives troubleshooting delays during carrier outages, because an engineer investigating a site connectivity issue can see all associated circuits without switching between a separate circuit spreadsheet and the site documentation. The changelog on every circuit record captures field level diffs with user identity and precise timestamps, giving you a complete audit trail of who created, modified, or decommissioned each circuit and what changed at each step, without requiring manual logging that would otherwise fall through the cracks during busy change windows.