Border Gateway Protocol (BGP) is often described as the routing protocol of the Internet. That is accurate, but it can suggest that every enterprise network needs to run it. Many do not. BGP becomes relevant when an organization wants direct control over how its IP networks connect to multiple carriers, data centers, cloud environments, or other external networks.
That is where a relatively simple routing concept turns into an infrastructure decision. A hosting provider, SaaS platform, content network, or enterprise may use BGP to reduce dependence on a single upstream provider, influence traffic paths, and maintain alternative routes when connectivity fails. The same control also introduces operational risk. A routing policy can be technically valid and still make healthy infrastructure difficult or impossible to reach.
For a network and colocation service provider such as 3W Infra, BGP sits close to day-to-day operations. 3W Infra provides Layer 2 and Layer 3 connectivity from its own Autonomous System (AS) and connects redundantly to multiple upstream networks, so external routing policy is part of operating the network rather than an optional enterprise feature.
That difference is important. Redundant servers, power feeds, routers, and data centers do not automatically provide Internet availability if external routing still depends on one carrier, one physical path, one border router, or one poorly understood routing policy.
BGP is therefore less a protocol decision than a question of how much routing control an organization needs - and whether it can operate that control safely.
BGP Routing Control, Autonomous Systems, and Internet Reachability
Border Gateway Protocol exchanges reachability information between independently managed networks called Autonomous Systems. Each Autonomous System is identified by an Autonomous System Number, or ASN.
An organization running BGP might advertise an IPv4 or IPv6 prefix to two transit providers. Those providers propagate the route onward, eventually contributing to the distributed collection of routes commonly called the global routing table.
The important word is distributed. There is no central internet router calculating an objectively optimal path.
BGP chooses routes according to policy.
That makes it fundamentally different from internal routing protocols such as OSPF or IS-IS. Those protocols are normally concerned with finding paths through infrastructure controlled by the same organization. BGP is designed to exchange routes across administrative boundaries where every network may have different technical and commercial priorities.
External BGP, or eBGP, handles those inter-AS relationships. Internal BGP, or iBGP, can distribute externally learned routes between routers inside the same AS.
For an enterprise with two edge routers and two providers, that sounds straightforward. At larger scale, the implications spread quickly.
BGP Path Selection, AS_PATH, Latency, and Routing Policy
One of the most persistent misconceptions about BGP is that it sends traffic over the geographically shortest or lowest-latency Internet path.
It does not.
The AS_PATH attribute records the Autonomous Systems through which a route advertisement has traveled. Shorter AS paths are often preferred, but AS_PATH is only part of route selection. Operators can override that preference through attributes such as local preference, and equipment vendors may introduce additional decision steps.
That means a route traversing fewer autonomous systems can still have higher latency, worse congestion, or poorer real-world performance.
For infrastructure architects, this changes how network performance should be evaluated. A traceroute and an AS path describe where packets are going. They do not by themselves establish why that path was chosen or whether it performs well.
An operator may deliberately prefer a particular transit carrier because it offers better reachability into an important market. Another path may cost less. A third may be retained primarily for failure scenarios.
BGP gives the network team the ability to express those preferences. It does not decide what the business prefers.
BGP Multihoming, Carrier Diversity, and Physical Path Redundancy
The obvious enterprise use case for BGP is multihoming.
An organization connects to multiple providers and advertises its prefixes through both. If one upstream fails, traffic can use another network route.
But two BGP sessions do not necessarily create two independent failure domains.
Both carriers may enter the building through the same duct. Cross-connects may eventually converge on the same metro fiber. Two logical uplinks can terminate on the same physical router. Separate border routers can depend on the same power distribution. Multiple internet providers may even share upstream infrastructure farther away from the data center.
This is where networking and colocation stop being separate design exercises.
If internet availability matters, carrier diversity should be evaluated alongside physical path diversity, router placement, cross-connect routing, fiber entry, data center topology and inter-site connectivity.
The same principle applies across facilities. Moving the secondary router into another data center provides little protection if both locations remain dependent on the same interconnect or upstream failure domain.
In the Amsterdam region, for example, 3W Infra operates across maincubes, Equinix AM11 and Iron Mountain, with a DWDM ring running over redundant, maintenance-protected dark fiber between the three facilities. Its network can deliver L2 connectivity between sites and L3 connectivity through its own AS.
The value of that architecture is not simply having three addresses. It is the ability to decide deliberately which dependencies should be shared and which should remain independent.
Layer 2 vs. Layer 3 for Multi-Data-Center Network Design
Multi-data-center architecture often creates another decision: how much of the network should stretch between sites?
A Layer 2 interconnect can make workload mobility easier. Systems in different facilities can remain within the same Ethernet domain or subnet. That can be useful for some clustering platforms, migrations, legacy applications and specific storage designs.
It can also extend failure domains.
Broadcast behavior, spanning-tree assumptions, accidental loops, MAC learning issues and application dependencies can now cross data center boundaries. A configuration problem that once affected a rack can affect a metro network.
Layer 3 boundaries generally make failure containment clearer. Each site can have its own routed network, with BGP or an internal routing protocol controlling reachability between them.
The trade-off is that applications need to tolerate routed boundaries. Addressing, service discovery, load balancing and failover must be designed accordingly.
There is no universal answer. A stretched L2 domain may be completely reasonable for a controlled migration. Making it the permanent architectural default is a different decision.
3W Infra's Amsterdam interconnect supports 10G, 25G, 40G and 100G Layer 2 links as well as Layer 3 connectivity, which makes that distinction an architectural choice rather than a facility limitation.
Inbound vs. Outbound BGP Failover and Traffic Engineering
BGP redundancy also becomes more complicated because inbound and outbound traffic are controlled differently.
For outbound traffic, the organization has considerable influence. Local preference can determine which upstream is preferred. Routing policy can steer specific destinations toward different carriers.
Inbound traffic is less deterministic.
The organization advertises routes and attempts to influence how external networks reach them. AS_PATH prepending, selective advertisements and provider-specific BGP communities can help, but the final decision belongs to networks outside the organization's control.
This matters during failover.
A network team may verify that its routers immediately switch outbound traffic to the backup provider, while inbound traffic continues arriving through the failed or degraded path until route withdrawals propagate.
For stateful applications, firewalls and DDoS mitigation systems, asymmetric routing introduces another layer of complexity. Traffic arriving through one path and returning through another may be perfectly valid from BGP's perspective while breaking a stateful security architecture.
The routing policy therefore has to be designed with the application and security layers, not afterward.
BGP Security, RPKI, Route Filtering, and Route Hijack Protection
BGP was created around cooperation between networks. Historically, a network announcing a route was largely trusted to have the authority to announce it.
That assumption has obvious weaknesses.
A route leak can accidentally propagate prefixes somewhere they should not go. A route hijack can cause another network's addresses to be advertised from the wrong origin. Either can redirect or blackhole traffic.
RPKI and Route Origin Authorizations improve this by allowing networks to cryptographically validate whether a particular AS is authorized to originate a prefix. They reduce one important class of routing error, but they do not make BGP inherently trustworthy.
Operators still need disciplined route filtering.
That includes controlling which prefixes customers and peers may advertise, defining maximum prefix limits, maintaining prefix and AS-path filters where appropriate, validating routes, and preventing internal mistakes from becoming external incidents.
BGP security is therefore partly protocol security and partly change management.
A syntactically valid routing policy can still be operationally disastrous.
BGP Monitoring, Network Observability, and Routing Automation
BGP is increasingly managed through automation, but automation magnifies policy quality.
If an engineer manually deploys a bad route-map to one router, the problem may remain local. If an automation system distributes it across every edge router in several locations, consistency has simply made the outage consistent.
Before automating routing policy, teams need visibility into what the policy actually does.
That means collecting more than interface status.
Operators need BGP session state, advertised and received prefixes, AS paths, route changes, next-hop reachability, traffic volumes, packet loss and latency. Configuration state should be versioned. Physical dependencies should be documented alongside logical ones.
In a multi-data-center environment, asset management and network observability also intersect. When a BGP session disappears, the cause may be a routing problem, an optic, a patch cable, a cross-connect, a failed line card, power loss to a router, or planned work nobody correlated with the alert.
Good monitoring reduces the search space. Accurate operational records reduce it further.
This is one reason the boundary between network management and physical data center operations matters more than architecture diagrams usually suggest. 3W Infra, for example, combines network design and monitoring with physical Remote Hands capabilities in its Amsterdam locations, including rack installation, cabling, optics and cross-connect work.
BGP Operational Responsibility, ASN Management, and Routing Independence
Running your own ASN, prefixes and BGP policy can provide meaningful independence from a single carrier. It can also create permanent operational responsibilities.
Someone must maintain prefix registrations, routing policies, filters, ROAs, monitoring, upstream relationships and incident procedures. Someone must understand what happens when one provider is withdrawn, another becomes degraded, a prefix is advertised incorrectly, or a router replacement alters routing behavior.
For hosting providers and large SaaS platforms, that responsibility may be entirely justified. Internet routing is part of the product.
For a smaller enterprise, accepting provider-managed routing may be the more sensible architecture even when running BGP internally would provide greater theoretical control.
The strongest technical design is not always the best business design.
Before adopting BGP, the useful question is not simply whether multiple carriers are available. Determine which failure domains genuinely become independent, who owns routing policy during an incident, how physical interconnects map to logical redundancy, and whether the organization can observe and operate the resulting topology when one part of it behaves differently from the diagram.
Strategic Insights FAQ
When does BGP become a business continuity issue rather than a routing choice?
When Internet reachability depends on multiple providers, sites, or external paths, BGP policy directly influences service continuity, customer access, and incident recovery.
Why can multihoming still leave an organization exposed?
Multiple upstreams add options, but resilience remains weak when carriers, fiber routes, routers, power feeds, or inter-site links share hidden physical dependencies.
How should executives think about Layer 2 versus Layer 3 across data centers?
Layer 2 can simplify migration and legacy dependencies, while Layer 3 usually creates clearer failure boundaries, stronger routing control, and more scalable multi-site operations.
What makes inbound BGP failover harder to control than outbound routing?
Organizations can influence inbound paths, but external networks make the final routing decision, making convergence, asymmetry, security controls, and customer impact less predictable.
Where does BGP automation create the greatest operational risk?
Automation becomes dangerous when weak policy, incomplete validation, or poor observability allows a single routing mistake to propagate rapidly across multiple routers and locations.
When is running your own ASN and BGP policy commercially justified?
It makes sense when routing independence, provider diversity, traffic engineering, and continuity materially affect revenue, customer experience, or strategic control over network operations.
What separates real network resilience from a diagram full of redundant links?
Execution. 3W Infra combines BGP expertise, multi-carrier connectivity, Amsterdam interconnection, dark-fiber infrastructure, and Remote Hands to align logical routing with physical resilience.
Discuss Your BGP Redundancy Strategy with 3W Infra
Want to discuss how BGP policy, carrier diversity, physical path separation, and multi-site connectivity should work together? Talk to the networking experts at 3W Infra. Contact us at [email protected].
