Someone on your team suggested BGP. Or you read an article. Or you watched a conference talk where the speaker made it sound like BGP was the answer to everything. And now you’re wondering if your network actually needs it.
For most networks, the answer is still no
That’s not a knock on BGP, it is a precision tool for a specific set of problems. When those problems exist, it’s exactly the right answer. When they don’t, you’re adding complexity that will hurt you at 2am six months from now.
Let’s figure out which situation you’re in.
When BGP Is the Right Answer
You have more than one ISP and you want real control over how traffic flows.
This is the number one reason enterprises end up running BGP. Two ISPs, active-active or active-standby, and you want to actually manage which traffic goes out which link. You want to do load balancing, traffic engineering, maybe AS path prepending to influence which ISP gets your inbound traffic.
With static routes and policy-based routing you can handle basic failover. But the moment you want real control over inbound traffic paths, you need BGP. Your ISPs advertise your prefixes to the internet. The only way to influence how other networks route toward you is through BGP attributes that you’re propagating outward. Static routes don’t have that reach.
You’re running a data center fabric.
Spine-leaf fabrics using BGP as the underlay have become the standard way large-scale data centers are built. BGP handles the IP fabric, EVPN handles the overlay. If you’re building or managing a serious data center environment, it is on the table whether you planned for it or not.
You need to connect to the internet and you’re big enough to have your own ASN and address space.
If you’re a large enough organization that you have provider-independent IP space and your own autonomous system number, you’re probably running BGP to announce your prefixes to your ISPs. That’s the whole point of having your own address space.
You’re integrating with cloud providers.
AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect all use BGP sessions to exchange routing information. If you’re doing dedicated connectivity to a cloud provider rather than VPN tunnels, you’re doing BGP. The cloud provider’s equipment on the other end of that connection will try to establish a BGP session with you.
You have an application that needs to know about network reachability in real time.
BGP can be used for things beyond internet routing. In data centers and automation platforms, BGP is sometimes used to distribute routing information that service discovery or load balancers care about. This is a more advanced use case but it’s worth knowing it exists.
When BGP Is the Wrong Answer
You have one ISP.
Seriously. If you have one ISP connection and no plans to add another, you do not need BGP. Your ISP gives you a default route. Your traffic goes out. Done. The complexity you’d add with BGP buys you nothing.
You’re running a small or medium enterprise with a simple topology.
Single site, maybe two or three branch offices, MPLS WAN or SD-WAN connecting them. OSPF or EIGRP handles internal routing. Static defaults point toward the internet. This is completely appropriate for a huge number of organizations and there’s nothing wrong with it.
You want to use BGP because it sounds more professional.
This is a real thing that happens. An engineer inherits a network, wants to modernize it, and somewhere along the way decides BGP will make the environment more enterprise-grade. It won’t. It’ll make it harder to hire for, harder to troubleshoot, and harder to explain to management when something breaks.
You’re trying to solve a problem that a static route or policy-based routing would handle fine.
BGP is not the right answer for “I want traffic to this specific subnet to go out a different path.” That’s a static route or a PBR policy. Adding a full peering to solve a point-to-point routing problem is the networking equivalent of using a sledgehammer to hang a picture frame.
The Real Question to Ask
Before you decide on BGP, answer these three questions:
- Do you have more than one upstream network you’re exchanging routing information with?
- Do you need to apply outbound or inbound traffic policy across those connections?
- Is the routing problem you’re solving something that scales beyond what static routes can manage?
If the answer to all three is yes, BGP belongs in the conversation.
If the answer to any of them is no, slow down. Figure out exactly what you’re trying to accomplish and work backward from there.
A Note on Learning vs. Production
There’s an important distinction between running BGP in your lab to learn it and deploying it in production to solve a problem that doesn’t require it.
Learning BGP is absolutely worth your time. Understanding how it works, how path selection behaves, how to filter and manipulate attributes, all of that makes you a better network engineer even if you never deploy it in your environment. The concepts transfer. The troubleshooting methodology transfers.
Deploying BGP because you want to learn it on a live network is a different story. That’s a liability, not an asset.
Learn it in the lab. Deploy it when the problem actually calls for it.