16 mins
BGP Routing and DIA: What Network Engineers Need to Know When Buying Dedicated Internet
Most network engineers buying dedicated internet assume that adding a second circuit and running BGP across it solves redundancy. It doesn't, not automatically, and the gap between that assumption and what actually happens during a failure event is where a lot of expensive procurement mistakes live.
The assumption holds up on a whiteboard. Two circuits, two BGP sessions, automatic failover if one goes down. In practice, redundancy depends on what's underneath the BGP session: whether the two circuits share a conduit, a point of presence, or an upstream carrier several hops away from either provider's edge. BGP will happily fail over between two paths that both go dark at the same time, because BGP has no visibility into physical infrastructure. It only sees what it's told.
This matters because outages tied to IT and networking issues rose to 23% of impactful outages in 2024, and configuration, change management, and third-party network provider failures are consistently named as leading causes (Source: Uptime Institute, 2025). A BGP session that fails over correctly cannot compensate for a physical design that was never actually redundant.
This post walks through what BGP changes about a DIA purchase, why a second circuit doesn't guarantee the outcome engineers assume it does, what routing policy and security controls a provider should support, how SLA language does and doesn't map to BGP behavior, and what to require in an RFP before signing.
What BGP Actually Changes in a DIA Deployment (ASN, IP Space, and Multihoming)
BGP changes a DIA deployment by giving the customer, rather than the provider, control over how its IP prefixes are announced and how inbound and outbound traffic is routed across one or more upstream connections. Static routes or a single default route work fine for a single circuit with no failover requirement. The moment an organization wants automated failover, load distribution across providers, or portable IP space, BGP peering becomes a requirement rather than an option.
Buying a BGP-enabled DIA circuit is a different procurement conversation than buying a standard internet handoff. The provider must establish a BGP neighbor relationship, running external BGP between the customer's router and the provider's edge, exchange routing information across separate IP networks according to agreed policy, and, in a multihomed design, coordinate with a second provider that may have entirely different peering practices. Internal BGP, run between multiple local routers on the customer's own network, may also be required if the customer operates more than one router advertising the same prefixes.
ASN and IP Allocation Requirements for BGP-Enabled DIA
A customer running BGP over DIA needs a registered autonomous system number and provider-independent IP space, or an agreement to use provider-assigned space that stays tied to that one provider. Provider-independent (PI) address space, made up of public IP addresses obtained through a Regional Internet Registry such as ARIN or RIPE NCC, is portable across providers and is required for any multihomed design where the customer wants to keep the same IP block if it switches or adds providers. Provider-assigned (PA) space is simpler to obtain but locks the customer into that provider's numbering, which defeats the purpose of multihoming for redundancy. Engineers should also confirm whether the provider requires a stable loopback address for the BGP session, and whether the circuit will carry the entire internet routing table or only a default route plus a partial set of routes, since accepting the entire internet routing table demands meaningfully more router memory and CPU than accepting a default route alone.
For technical teams: confirm during procurement whether the provider requires the customer to already hold an ASN and PI space, or whether the provider will facilitate the ASN application. Some providers will not peer via BGP without PI space in place, which can add weeks to a deployment timeline if the customer hasn't started the RIR registration process.
Single-Homed vs Multihomed BGP Configurations
Single-homed BGP, sometimes described as a single ISP design, means running BGP with one ISP over a single connection through a single router, which gives a customer control over route advertisement and inbound traffic engineering but provides no protection against that provider's failure. Multihomed BGP, also called dual-homed when exactly two ISPs are involved, means running BGP sessions with multiple ISPs simultaneously, often through two routers or more, which is the configuration required for actual circuit-level redundancy.
Single-homed BGP is common for organizations that want route control or plan to migrate providers without renumbering, not for organizations expecting failover protection if their single ISP fails. Multihomed BGP is the baseline requirement for any DIA purchase where redundancy is the stated goal, and it's the configuration the rest of this post assumes.
Why a Second DIA Circuit Doesn't Guarantee Redundancy
A second DIA circuit doesn't guarantee redundancy because BGP-level failover only protects against failures BGP can see, and physical infrastructure failures, shared upstream dependencies, and slow convergence all sit outside what a BGP session detects. Two circuits from two different service providers can still share a conduit, a point of presence, or a Tier 1 upstream several hops upstream of either provider's network edge, and BGP has no mechanism to know that.
This is the gap between logical redundancy and physical redundancy. Logical redundancy means two BGP sessions exist and traffic can theoretically move between them. Physical redundancy means the underlying paths, from the customer's router through the local loop to each provider's network core, don't share a single point of failure. A DIA contract that delivers logical redundancy without physical redundancy will pass every acceptance test and still fail during the one event it was purchased to survive.
How to Verify Physical Path Diversity Before Signing
Verifying physical path diversity requires the provider to disclose last-mile provider identity, conduit or duct bank routing, and points of presence for both circuits, not just a statement that the circuits are "diverse." Two circuits ordered from two different DIA providers frequently ride the same underlying fiber for the last mile, because both providers lease capacity from the same regional carrier into the building. In some cases, both circuits terminate through the same ISP's regional network even when sold under two different brand names, or ride a shared dark fiber connection that runs along the same physical route, using the same service provider network for the final segment into the building. If that shared segment is cut, both circuits go down regardless of how the BGP sessions are configured.
Ask the provider directly whether it owns the last-mile fiber or leases it, and from whom. Request documentation of the physical route, including which conduit or duct bank each circuit uses inside the building's entry point. A demarcation point diagram is not sufficient; engineers need the direct path from the customer router through to each ISP's routers, not just a diagram, because "diverse carriers" and "diverse paths" are not the same claim, and only one of them protects against a backhoe event or a fiber cut.
BGP Failover and Convergence Timing in Multihomed Designs
BGP failover timing in a multihomed design depends on default protocol timers, and without tuning, BGP can take well over a minute to detect a failed session and reconverge on an alternate path. BGP's default Minimum Route Advertisement Interval (MRAI) of 30 seconds between routers in different autonomous systems limits how quickly a new best path can propagate after a failure, and current research on large-scale BGP networks confirms that this timer remains one of the primary drivers of convergence delay even in modern topologies (Source: Computer Networks, 2024).
The combined effect of session-failure detection plus MRAI-limited route propagation means BGP convergence without additional tuning commonly runs from tens of seconds to several minutes, depending on network size and how many autonomous systems sit between the failure and the customer's edge (Source: Computer Networks, 2024). When a single ISP fails, the affected BGP routers must first detect the adjacency loss before BGP chooses an alternate best path, and that best-path recalculation only happens after the failure is confirmed, not the instant the physical link drops. Pairing BGP with Bidirectional Forwarding Detection (BFD) can cut failure detection down to sub-second levels, but BFD has to be explicitly requested and supported by the provider; it is not a default feature of a DIA circuit.
For technical teams: if sub-minute failover matters to your application, confirm BFD support in writing before signing, and test actual failover time during a maintenance window rather than trusting the provider's stated convergence figures.
Active/Active vs Active/Passive BGP Designs in DIA
Active/active BGP designs route production traffic across both circuits simultaneously, while active/passive designs keep one circuit idle until the primary fails, and the choice between them affects both cost efficiency and failover behavior. Active/active designs make use of both circuits' capacity continuously across multiple routers and can reduce the perceived impact of a single-circuit failure, since traffic is already distributed. Active/passive designs are simpler to reason about operationally but leave paid-for capacity idle until a failure occurs, and they depend entirely on BGP correctly detecting the primary's failure and shifting traffic in time.
The tradeoff is traffic engineering complexity versus cost efficiency. Active/active requires careful route preference and local preference configuration to avoid asymmetric routing or unpredictable path selection, while active/passive requires less ongoing tuning but pays for standby capacity that does nothing until a failure event.
For technical teams: an active/active design typically depends on configuring parallel equal cost paths, using a command such as maximum-paths to permit multiple paths, sometimes exactly two equal cost paths, to share traffic volume through load sharing across multiple links rather than routing everything over a single connection. Active/passive keeps the second circuit as a backup path only, which is less cost effective in terms of utilized bandwidth but simpler to validate during a failover test.
How BGP Routing Policy, Security, and Traffic Engineering Affect DIA Reliability and Performance
BGP routing policy, security controls, and traffic engineering capability affect DIA reliability and performance through three specific mechanisms a buyer should evaluate before signing: how the provider supports communities for traffic steering, whether the provider validates route origins through RPKI, and what safeguards exist against route leaks and hijacks originating on the provider's network or its peers. Each of these sits outside the basic circuit specification and rarely appears in a standard DIA quote, but each has caused real outages when absent.
BGP Communities and Traffic Engineering for DIA Circuits
BGP communities let a customer tag route advertisements with metadata that influences how a provider handles those routes, including local preference, geographic scope of advertisement, and preferred exit points. A provider that supports a documented, well-maintained community set gives the customer real traffic engineering control; a provider that doesn't leaves the customer with no lever beyond accepting whatever path the provider's own policy selects. Communities are typically applied through a route map on the customer's own router to control outbound traffic toward the provider and, combined with AS path prepend, to influence how much incoming traffic a given circuit attracts from the rest of the internet. The same tools also shape outgoing traffic flows when a customer wants to prefer one circuit for certain destinations over another, which matters most for engineers managing multiple connections across more than one upstream, where inconsistent community support between providers can quietly break the traffic engineering design the customer thought it had.
For technical teams: request the provider's published BGP community documentation during evaluation, not after signing. A provider unwilling to share this, or one whose community set only covers basic blackholing, offers materially less traffic engineering flexibility than one with a full no-export, no-advertise, and regional preference community set.
RPKI and Route Origin Validation Support
RPKI (Resource Public Key Infrastructure) lets a network cryptographically certify which autonomous systems are authorized to originate its IP prefixes, and route origin validation (ROV) is the practice of a provider rejecting or deprioritizing routes that fail that certification check. Adoption has grown steadily but remains incomplete: more than half of announced IPv4 and IPv6 routes are now covered by valid Route Origin Authorizations, yet only around a third of autonomous systems globally have valid ROAs of their own, and full ROV enforcement lags further behind ROA coverage (Source: MANRS, 2025). The 2024 White House roadmap on internet routing security explicitly recommends that large transit networks implement ROV and filter invalid BGP announcements, underscoring that this is now a baseline expectation for providers, not an advanced feature (Source: White House Office of the National Cyber Director, 2024). A provider enforcing ROV will reject invalid internet routes before they ever enter its BGP table, rather than propagating them as accepted BGP routes to the customer's network.
A DIA provider that doesn't support ROV will accept and propagate an invalid route announcement just as readily as a valid one, meaning a misconfiguration or hijack elsewhere on the public internet can still reach the customer's network through that provider. Buyers should ask directly whether the provider filters inbound routes based on RPKI validity, not just whether the provider "supports RPKI" in general terms, since the latter can mean nothing more than accepting ROA registrations without enforcing them.
How Providers Handle BGP Route Leaks and Hijacks
Providers handle BGP route leaks and hijacks through a combination of RPKI-based filtering, prefix and AS-path filtering at peering points, and monitoring that alerts on unexpected origin changes for the customer's announced prefixes. The consequences of inadequate handling are well documented: a route leak combined with a hijack disrupted roughly 300 networks across 70 countries during the June 2024 Cloudflare 1.1.1.1 incident, when a Brazilian network mistakenly originated a more specific route for Cloudflare's resolver space and another network leaked the associated /24, and at least one Tier 1 provider accepted the invalid announcement (Source: Cloudflare, 2024).
A similar dynamic played out in the January 2024 Orange Spain outage, where a compromised RIPE account was used to modify the carrier's AS number and enable an invalid RPKI configuration, disrupting roughly half of Orange Spain's traffic for about three hours (Source: Data Center Dynamics, 2024). Neither incident required a sophisticated attack, and neither would have been prevented by the affected customers' own BGP configuration; the protection has to exist at the provider and peering level. Ask the DIA provider whether it participates in MANRS (Mutually Agreed Norms for Routing Security) and what specific filtering it applies to routes learned from peers and customers, not just routes it originates itself.
How DIA SLAs Map (and Don't Map) to BGP Behavior
DIA SLAs map to BGP behavior only partially, because standard service level agreements typically guarantee data-plane metrics like uptime, latency, jitter, and packet loss, while leaving control-plane behavior, meaning how quickly BGP detects and reacts to a failure, entirely outside the guaranteed terms. This is the gap that makes the redundancy assumption from the introduction so persistent: engineers read an SLA that guarantees 99.99% uptime and 30ms latency and reasonably assume it also guarantees fast, automatic failover. It usually doesn't say anything about failover at all.
Latency, Jitter, and Packet Loss Thresholds That Matter for BGP Sessions
Latency, jitter, and packet loss thresholds matter for BGP sessions because sustained packet loss or jitter above a provider's threshold can cause a BGP session to flap, tearing down and rebuilding the adjacency repeatedly rather than failing cleanly to a backup path. A flapping session is often worse for network performance than a clean failure, since traffic bounces between partially degraded paths instead of settling on a stable alternate route.
For technical teams: request the specific packet loss and jitter thresholds the provider considers within normal operating range for the circuit, and separately confirm what packet loss level triggers the provider's own alerting. A circuit that stays "up" by SLA definition while sustaining 2 to 3 percent packet loss will still degrade a BGP session's stability well before it counts as an SLA breach.
What SLAs Don't Cover: Control Plane vs. Data Plane
Standard DIA SLAs don't cover control-plane behavior: BGP convergence time, failover detection speed, route filtering accuracy, and RPKI enforcement are control-plane functions, and none of them typically appear as measurable, penalized commitments in a provider's standard SLA. The SLA measures whether the circuit is passing traffic within acceptable parameters; it does not measure whether the routing layer sitting on top of that circuit behaves the way the customer assumed it would during a failure, which is the actual business continuity outcome the purchase was meant to deliver.
This is the direct mechanism behind the opening claim of this post. A customer can hold a provider to a strict data-plane SLA, receive full compliance, and still experience an extended outage because the control-plane failover took four minutes instead of the sub-minute figure assumed during design. Neither event breaches the contract as written.
Credits vs. Actual Risk: Why SLA Penalties Don't Offset Downtime Impact
SLA credits don't offset the actual business risk of downtime because credits are typically calculated as a percentage of the monthly circuit cost, while the cost of an outage to the customer's business, in lost revenue, support burden, or SLA penalties owed to the customer's own customers, is usually calculated independently and at a much larger scale. A provider crediting a customer 10 percent of a $4,000 monthly circuit fee for a two-hour outage is not compensating for the revenue or reputational impact of that outage on the customer's own operations.
Engineers who have been through an actual outage recognize this pattern: the credit arrives, the postmortem gets filed, and the production impact already happened. SLA credits should be treated as a minor cost recovery mechanism, not as evidence that the redundancy design in place was adequate.
What to Ask a Provider About BGP Session Monitoring and Notification
Providers should be asked whether they monitor customer BGP sessions proactively, what specific events trigger a notification, and how quickly that notification reaches the customer after a session state change. A provider that only notifies customers after a support ticket is opened offers materially less operational value than one with automated alerting tied to BGP session down events, route flap detection, and unexpected AS-path changes.
Confirm whether monitoring and notification are included in the base DIA contract or sold as an add-on, since this is a common place where the base quote looks competitive precisely because it excludes a capability engineers assumed was standard.
What Network Engineers Should Include in a DIA RFP for BGP Peering
Network engineers evaluating DIA providers for BGP peering should require documented answers to eleven specific items before signing, covering physical path diversity, convergence behavior, routing security, and SLA scope, rather than relying on a provider's general claims about redundancy and reliability. Structure these as explicit requirements in the RFP, not open-ended questions:
Provider must disclose the last-mile carrier and physical routing, including conduit or duct bank path, for each proposed circuit.
Provider must confirm whether proposed circuits share any upstream carrier, point of presence, or fiber segment within the first three hops from the customer premise.
Provider must state its default BGP configuration, including hold timer, keepalive interval, and MRAI settings, and confirm BFD availability and any associated cost.
Documented proof of RPKI ROV enforcement on inbound routes, not just ROA registration support.
Provider must disclose MANRS participation status, if any, and the specific route filtering applied at customer and peer connections.
Provider must provide its full BGP community documentation, including traffic engineering and blackholing communities.
Customer should require a written definition of what the SLA measures (data-plane only, or data-plane and specific control-plane events).
Provider must state the SLA credit calculation methodology and confirm whether credits are capped or uncapped per incident.
Provider must disclose whether BGP session monitoring and automated notification are included in the base contract or sold separately, and the target notification latency after a session state change.
Customer should require a test failover during a scheduled maintenance window, with documented convergence time, as a condition of acceptance.
Provider must confirm ASN, IP space requirements (PI vs. PA), and the router bgp configuration expected at the customer edge, in writing before the customer begins RIR registration, to avoid deployment delays.
Sourcing BGP-Ready DIA Through Inflect
Network engineers evaluating DIA providers for BGP peering face a research problem before they face a technical one: finding providers who can actually speak to physical path diversity, RPKI enforcement, and BGP community support, and getting comparable pricing across them without a separate sales cycle for each. Inflect is a digital infrastructure marketplace built for exactly this kind of side-by-side evaluation, giving buyers instant pricing and specification comparison across 6,000+ data centers and network facilities in 100+ countries, without a sales call required to see what's available.
For DIA and network buyers specifically, Inflect's platform surfaces internet service providers including Lumen, GTT, Colt, Zayo, Megaport, and hundreds of others, so engineers can compare BGP peering support, physical diversity options, and pricing across different providers in one search rather than running separate RFPs with each. Inflect's free expert advisory is available at no cost to buyers who want a second technical opinion on redundancy design or provider selection before committing, and every quote reflects real provider pricing rather than a placeholder that requires a follow-up call to confirm.
Get a BGP-Ready DIA Quote Without the Sales Cycle
If your organization is evaluating dedicated internet providers for a BGP-based redundancy design, the criteria in this post, physical path diversity, convergence behavior, RPKI enforcement, and SLA scope, are worth confirming in writing before you sign, not after an outage forces the conversation.
Compare DIA providers and BGP peering support side by side with instant, no-call pricing.
Get specification-level answers on physical diversity and routing security before committing to an RFP.
Talk to Inflect's free expert advisory team about your specific multihoming or failover design.
Search live availability across 6,000+ facilities in 100+ countries in one place.
Start your DIA comparison on Inflect and get pricing without the sales call.
About the Author
Haley Rogers
Content & Social Media Specialist
Haley Rogers is the Content & Social Media Specialist at Inflect, bringing over two years of experience in social media, marketing, and content strategy — including time at a fast-paced tech company before joining the Inflect team. She specializes in translating complex digital infrastructure topics into clear, engaging content, with a particular focus on blog writing and brand storytelling across channels.
Contact:
