What a BGP Multiline Datacenter Really Is: Telling Single, Dual, BGP, and Pseudo-Multiline Apart
The word "lines" appears on countless product pages, but it describes a facility's interconnection relationships, not a quality grade. Single-homed means one carrier, dual-homed usually means one carrier plus another, triple adds a third, and multiline generally means three or more. Every one of those phrases only answers "how many carriers are connected", never "what happens after they are connected".
What actually decides the experience is that second half: whether the multiple carriers are scheduled by one shared routing decision. That is exactly where BGP multiline and pseudo-multiline split apart. There is a single hard test: whether one and the same IP is reachable optimally from every carrier.
This article covers mechanism only. It walks through the access structure of single, dual, triple, and multi-homed setups, the components a real BGP setup needs, the ways pseudo-multiline is usually implemented, how to verify with AS numbers and return paths, and what BGP can and cannot fix. The spectrum of specific route products and how to measure them belongs to another layer and is not repeated here.
1. Taking the Word "Lines" Apart
1.1 Routes, Carriers, and Autonomous Systems Are Not the Same Thing
These three terms are mixed up constantly, yet they sit at different levels. A carrier is a company that owns a network, an autonomous system is that network's identity in the global routing table, and a route is the actual chain of links that traffic traverses. Asking "is this route good" is a question about the third layer; asking "how many lines" is a question about the first.
Once separated, most claims stop being ambiguous. A facility can connect to a single carrier while that carrier internally offers several exits and many paths; it can also connect to five carriers while buying so little capacity from each that every one of them is congested. Quantity and quality have never been the same thing, and mixing them prevents any discussion from converging. For a fuller treatment of route layers and how to read them, see the route spectrum guide.
The autonomous system concept comes up repeatedly below. Each one has a globally unique AS number and announces the IP blocks it is responsible for. Whoever holds an AS number has the standing to negotiate routes with other autonomous systems, and that standing is the precondition for BGP multiline. Without it, a facility can rearrange anything inside its own network, while the outward path remains whatever the upstream decides.
1.2 "Lines" Describes Interconnection, Not Quality Grade
"Dual-homed facility" and "triple-homed facility" sound like tiers, but they only state how many carriers are connected. A dual-homed facility whose two uplinks are both tiny can perform far worse than a single-homed facility with generous capacity. In the other direction, a single-homed facility on a premium product with loose capacity can beat a multiline facility on that same carrier's direction.
Likewise, "BGP multiline" is not a grade but an access method. It says the facility holds its own AS number, announces the same block to several carriers at once, and lets inter-carrier route selection pick the path. It promises no capacity, no latency, and no loss-free delivery. Those three depend on bandwidth purchasing, route tier, and backbone congestion respectively, none of which BGP touches.
Understanding this changes how you ask questions. Do not ask "how many lines do you have". Ask "what is your AS number, how many upstreams do you peer with, how much capacity does each uplink carry, and do you optimize both directions". The first question usually returns adjectives; the second returns facts.
2. What Single, Dual, Triple, and Multi Actually Differ In
2.1 Single-Homed: One Carrier Only
A single-homed facility interconnects with one carrier. Its path is the most predictable and its cost the lowest, because only one carrier's bandwidth has to be bought rather than several interconnection deals. The price is that users on other carriers must cross an inter-carrier interconnect to arrive, and the capacity of that interconnect is not yours to control, so evening queues are visible.
Single-homed is not automatically unusable. If your audience is concentrated on one carrier, for instance a regional corporate intranet, or if you have already put a CDN in front and pushed most return traffic off the origin, single-homed can beat multiline on value. The point of choosing it is not saving money but confirming audience structure and the origin's actual role.
2.2 Dual and Triple: Covering the Mainstream
Dual usually means Telecom plus Unicom, and triple adds Mobile. The idea is to cover the mainstream user base rather than chase an optimum in every direction. That is a sensible cost structure: three carriers account for the large majority of broadband and mobile users, and further additions return diminishing benefits.
How "triple" is implemented, however, varies enormously. Some facilities genuinely buy capacity from each carrier and arrange outward announcements so the network computes the path; others simply buy IP blocks from three carriers and let users or DNS pick one. Both implementations literally qualify as "triple-homed", yet they differ by an entire layer in practice. The difference is the subject of the next chapter: who makes the routing decision.
2.3 Multi-Homed and BGP Multi-Homed: Owning an AS Number
Multiline generally means three or more carriers. BGP multiline adds one critical condition on top: the facility holds its own AS number and IP block, establishes BGP sessions with several carriers, and announces the same block to all of them simultaneously.
The effect is that when a user on any carrier reaches that IP, the path is computed by inter-carrier route selection rather than assigned by a splitting device inside the facility. It also means the facility controls its own addressing far more directly: swapping an uplink, adding a carrier, or engineering failover all happen inside its own routing policy without any change on the customer side.
| Access model | Carriers connected | IP and AS ownership | Who decides the path | Typical failure behaviour |
|---|---|---|---|---|
| Single-homed | One | Usually assigned by upstream | The only uplink | Uplink loss means total outage |
| Dual-homed | Commonly two | Often upstream-assigned, sometimes facility-owned | Policy routing or announcements | Partial unreachability from some sources |
| Triple-homed | Commonly three | Mixed, depends on implementation | Policy routing, DNS, or BGP | Splitting rules fail and it degrades to single |
| BGP multiline | Three or more | Facility owns AS number and IP block | Inter-carrier route selection | Sessions drop and routes converge on the rest |
This table compares access structure only, not quality. Judging quality still requires the capacity and tier of each uplink.
3. What a Real BGP Setup Requires
3.1 AS Number and IP Block: Who Holds the Right to Announce
The first requirement for real BGP is the right to announce. The facility must hold its own AS number and own an IP block it can announce to the outside world. If a facility merely uses a block its upstream was assigned, then that block's announcement right sits with the upstream, and the facility can at best rearrange traffic inside its own network without ever expressing "we have several paths" outward.
The check is direct: look up which AS the IP belongs to. If it belongs to the facility's own AS, the facility is the origin; if it belongs to a carrier or a reseller, the facility has no routing autonomy over that block. This single test filters out a good share of self-declared BGP facilities.
Worth stating plainly: holding an AS number has a threshold but is not exotic. Applying, maintaining it, and running sessions with upstreams all cost money and operational skill. A small facility with one AS number and two uplinks is therefore entirely normal; it meets the definition of BGP, it is simply small.
3.2 BGP Neighbors and Route Selection: Who Picks the Path
The second requirement is neighbor relationships. The facility must establish BGP sessions with several upstreams and exchange reachability information. Once established, the path is no longer set by hand: the selection process compares local preference and AS path length first, then the remaining attributes in order, and writes the best path into the forwarding table.
This is the key to understanding pseudo-multiline. If a design lets the facility's policy routing, static routes, or DNS decide the path, then the real routing decision never happens between carriers; traffic is merely distributed across uplinks inside the facility. The user-to-facility direction may look well tuned, while the facility-to-user direction still hangs off a single carrier.
A second implication of the selection process is that BGP picks the best path by attributes, not the lowest latency. The default calculation can pick a path that detours compared with another reachable option. That is why some facilities have to add routing policy on top before a given direction behaves well.
4. Three Common Shapes of Pseudo-Multiline
4.1 Shape One: Policy Routing and Static Splitting
The first shape applies policy routing inside the facility, by source address or destination prefix. Traffic arrives, the device pushes it toward a chosen uplink by rule. Viewed from outside, the facility does connect several carriers and does route different sources through different exits, and a traceroute even looks convincing.
The problem is the return direction. Policy routing shapes what the facility sends out, while the return path is chosen by the receiving carrier's selection. If the facility's block is announced by only one carrier, users on the others still cross an inter-carrier interconnect on the way back, and whatever the forward path saved is eaten by the return.
One variant is directional optimization: forward on carrier A, return on carrier B. Such asymmetry is common and can even be a paid optimization. But if only one of A and B is genuinely premium while the marketing describes the better one, the experience will not match the description.
4.2 Shape Two: Multiple IPs With Per-Carrier DNS
The second shape buys IP blocks from several carriers and uses per-carrier DNS: Telecom users resolve to address A, Unicom users to B, Mobile users to C. This is the hardest shape to spot from outside, because a user testing from their own broadband really does see the right path.
The cost lands in operations. Multiple IPs multiply certificates, allowlists, monitoring, logs, and firewall rules; DNS caching slows switching, so during an outage users may keep resolving to a dead address; and any third party that pins a fixed IP is locked onto one carrier forever. It suits cost-sensitive scenarios that can tolerate that operational complexity, but it is not BGP.
Per-carrier DNS is a genuinely useful mechanism, the same family of idea as CDN steering, and smart DNS and route splitting covers where its limits lie. The distinction is simple: DNS decides which IP a user connects to, while BGP decides how the path to one IP is chosen. The former selects at the resolution layer, the latter at the network layer.
4.3 Shape Three: Two NICs, Two IPs, and a Choice for the User
The third shape is the crudest: two network cards and two addresses on one machine, each attached to a different carrier, with the user left to pick. This is sometimes marketed as "dual-line access" and occasionally as a "multiline facility".
Its flaw is obvious. The choice sits with the user, and almost no user knows which one to pick or which carrier their own broadband actually exits through; even when they do, a single hostname returns only one address from DNS. The approach does not solve cross-carrier reachability at all, it just moves the problem onto the user.
| Test | Real BGP multiline | Pseudo-multiline |
|---|---|---|
| IP and AS ownership | Facility owns AS number and block | Usually upstream-assigned, or scattered carrier blocks |
| Outward announcement | Same IP announced to every neighbor | No announcement, or a different IP per line |
| Where routing is decided | Between carriers, by selection attributes | Inside the facility, by policy or DNS |
| Return path quality | Return path also participates in selection | Return path usually stays on one carrier |
| Failover mechanism | Sessions drop, routes reconverge | Scripts rewrite policy or DNS, or manual switching |
| Client complexity | One IP is enough | Multiple IPs, hostnames, or dial-up profiles |
The table doubles as a question list for procurement. A seller who answers the first four rows clearly is very likely describing a genuine announcement structure; dodging any of them deserves a follow-up.
5. How to Verify Whether a Facility Runs Real BGP
5.1 Check the AS Number: whois and Route Lookups
The first step is to find which AS the address belongs to. There are two routes to that answer: query the registration data for the address with whois, or use a public routing lookup to see which AS currently originates the prefix and which upstreams the prefix is visible through. Read both, because registration records the assignment while the routing table reflects today's announcement.
If the origin AS of the prefix is the facility's own AS and the routing table shows several upstream paths to it, the facility is at least announcing for real. If the origin AS is a carrier, the facility is merely using someone else's block. Vendor documentation on network structure is a useful cross-reference too; pages from platforms such as Zenlayer list interconnection and access details.
whois 203.0.113.10
mtr -rwzc 100 203.0.113.10
traceroute 203.0.113.10
These three commands answer different questions. whois returns registration and assignment data, traceroute returns the actual forwarding path, and mtr layers per-hop statistics on top of that path. Registration data can lag; the live path is the current truth.
5.2 Walk the Hops, and Always Check the Return Path
The second step is to read the AS number at every hop. Each hop in a traceroute or mtr run can be resolved back to an AS, and listing the AS sequence reveals how many carriers the traffic crosses, whether it detours through somewhere unrelated to the destination, and whether it suddenly drops into a low-priority backbone partway through.
The critical part is the return direction. Tracing from your own machine only shows the forward path, while the user experience is dominated by the return path, because pages, API responses, and video streams all travel that way. To judge it, run a reverse traceroute from the server back to your own address and compare it side by side with the forward result. Concluding from the forward path alone is the most common mistake in this kind of analysis.
If you operate the service yourself, this step is entirely within your reach. If you are buying, ask the seller for forward and return path captures per carrier and per time window, and check the timestamps. A path capture without a timestamp is of limited value, because paths change with time of day.
5.3 Why Forward and Return Paths Often Diverge
On one machine it is perfectly normal for the forward direction to ride one carrier and the return direction another. The interconnect between two carriers is bidirectional, but capacity, policy, and settlement terms are not symmetric on both sides, so the return may take a quieter route. This is especially common on cross-border links.
The asymmetry is not a defect and is sometimes the result of optimization. The trouble is that it makes one-sided measurements misleading: the latency number you see may describe a path no real user ever takes. That is why judging multiline quality has to be based on the return path, per carrier. For how route tiers differ within one direction, the path-reading method in the CN2 GIA line guide is a useful companion.
6. What BGP Solves and What It Does Not
6.1 BGP Is Not Speed
The value of BGP is path selection, not lower latency. Its job is to choose a currently best path among reachable ones, where "best" means best by routing attributes, not necessarily the lowest latency and not necessarily the one with spare capacity.
A facility running BGP merely shows it has an alternative path when something fails; it does not show it is faster than a single-homed facility under normal conditions. Treating BGP as an accelerator is a common misunderstanding. Real speed comes from route tier and capacity: two BGP multiline facilities, one on premium routes and one on plain transit, behave completely differently, and that difference has nothing to do with the BGP mechanism.
6.2 BGP Is Not Zero Loss, and "BGP Facility" Is Not a Quality Endorsement
Congestion happens on carrier backbones. All BGP can do is switch when a path becomes unreachable, and the alternative may be just as congested, sometimes more so at peak. Convergence exists to preserve connectivity, not to remove the loss and jitter congestion causes.
For the same reason, the sentence "we are a BGP facility" is not a quality promise. A small facility may hold one AS number, run two uplinks, buy modest capacity, and fully meet the definition of BGP multiline while performing far worse than a dual-homed facility with real capacity. Judging quality still comes back to three things: capacity per uplink, route tier, and behaviour at evening peak.
7. Turning the Mechanism Into Selection Criteria
7.1 The Value of Multiline Is Stability, Not Latency
The honest reason to pay for multiline is failover: when one uplink jitters or dies, routes converge onto another and the service does not go dark as a whole. Single-homed cannot do this, and it is the most concrete return on the premium. Any latency benefit is a by-product and may not exist at all.
If continuous availability matters to your workload, for example online transactions, a public API, or real-time communication that holds long-lived connections, the redundancy is meaningful. If you run a presentational site with a CDN absorbing user requests so the origin only serves cache misses, the marginal value of multiline drops sharply.
7.2 Uplink Bandwidth Is Shared, So Read the Egress Number Carefully
The "XX Gbps egress" advertised by a BGP multiline facility is normally the total capacity shared by every customer on site, not the bandwidth allocated to one machine. The two can differ by orders of magnitude, and treating the site total as your usable bandwidth is the most common misreading. Colocation-oriented providers can pile up very large site totals while per-machine limits stay in the tens of Mbps or lower; ColoCrossing is a useful reference point for how that kind of facility product is described.
Three questions prevent the mistake: what limit actually applies to this machine, whether the limit is enforced at the facility edge or on the switch port, and whether exceeding the sold value causes drops or throttling. Those answers determine your real experience at peak far more than any site total does. For how shared egress is metered and how bandwidth pools work, continue with the bandwidth billing models guide.
Back to the opening question: single, dual, triple, and multi describe interconnection, BGP describes routing autonomy, and only the combination yields "BGP multiline". What it buys is a path the network computes itself and an uplink failure that switches automatically, not more speed, less loss, or a lower price. For regional trade-offs see how to read Hong Kong server routes; if you are still shaping the requirement, the basic decision order for server selection starts from audience structure; more coverage lives in the cloud server category.
Source: 16IDC original, billing rules, routing and terms are subject to each provider's official documentation and contract.
Original source: 16IDC ↗