You’ve been reading about BGP. You understand what it does. You have a rough handle on path selection and the difference between eBGP and iBGP. Now someone in your organization is asking whether your network needs BGP, or maybe you’re the one asking.
Let’s settle this properly.
The answer is almost always simpler than people want it to be. BGP solves specific problems. If your network has those problems, BGP belongs in your design. If it doesn’t, BGP is complexity you’re adding for no return.
The Decision Framework
Go through these questions. The first one that gets a “yes” probably ends the conversation.
Are you connecting to more than one upstream network and exchanging routing information with both?
This is the clearest indicator. If you have two ISPs and you want to do anything more sophisticated than “fail over to the backup when the primary dies,” you need BGP. Load balancing inbound traffic, traffic engineering, influencing which ISP handles which prefixes, all of that requires BGP.
If you have two ISPs and you’re fine with simple failover, you can probably do that with static routes and IP SLA. Painful to manage at scale but functional.
Do you have provider-independent IP space and your own public ASN?
If ARIN or your regional registry has given you your own address block and your own ASN, BGP is required. You’ll need to announce your prefixes to your ISPs and that requires a BGP session.
Are you building or managing a data center fabric?
Spine-leaf architectures using BGP as the underlay protocol are the current standard for large-scale data centers. If you’re touching data center infrastructure at a company that has actual scale, BGP is on the floor whether you invited it or not.
Are you terminating dedicated cloud connectivity?
AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, they all use BGP. The cloud provider’s physical equipment at the colocation facility runs BGP and expects to peer with your equipment. If you’re managing that connection, BGP is part of the job.
Are you running an SD-WAN overlay that needs to exchange routes with the underlay?
Most SD-WAN solutions use BGP or a proprietary version of BGP to communicate route information between the overlay and whatever sits at the edge. The product might abstract it from you, but understanding BGP is still valuable when something breaks.
When the Answer Is Clearly No
Single ISP, single uplink.
You have one ISP. They give you a default route. Your traffic goes out through them and comes back the same way. There is no traffic engineering to do because you have no decisions to make. BGP cannot help you here.
Campus or branch network that doesn’t touch the internet directly.
Branch offices connecting to a hub site via MPLS or SD-WAN don’t need BGP internally unless the WAN provider is already running BGP between them and you’re integrating with that. Your internal routing between sites is an IGP problem.
You want to use BGP because it looks better on a resume or architecture diagram.
This is more common than people admit, especially in organizations going through a “modernization” phase. A BGP session on a network diagram signals complexity and sophistication. But complexity without purpose is a liability, not an asset.
If someone asks why you chose BGP for a design and the honest answer involves any combination of the words “industry standard,” “best practice,” and “future-proof,” but you can’t name a specific problem BGP is solving, that’s a sign you’re solving an ego problem, not a network problem
The Gray Areas
Small multi-homed enterprise.
You have two ISPs. You don’t have your own public ASN or address space. Your ISPs have given you their IP blocks. Should you run BGP?
Maybe. It depends on how much traffic engineering you actually need. If you’re genuinely doing load balancing and want influence over inbound path selection, yes. If you really just want failover and could live with a static route pointing to the secondary ISP with a higher metric, skip the BGP session and save yourself the operational overhead.
Private peering between two companies.
If your company has a direct private connection to a partner or subsidiary and you want to exchange routes, BGP is the cleanest way to do it with proper policy control. But if the topology is static and the route table is small, a few static routes might be perfectly adequate.
EVPN/VXLAN fabric.
If you’re deploying VXLAN with EVPN as the control plane, you’re running BGP. EVPN is a BGP address family. This isn’t optional. Start learning BGP before you start building the fabric.
A Practical Test
If you’re still unsure, try this. Write down exactly what problem you’re trying to solve. One or two sentences, concrete and specific.
Now answer: can static routes solve this? If yes, do you also need traffic engineering that static routes can’t provide? If the answer to the second question is no, you probably don’t need BGP.
Does the problem involves exchanging routing information with a network you don’t control, influencing how external networks send traffic toward you, or scaling route distribution across a large network where an IGP isn’t appropriate, BGP is likely the right answer.
The Real Cost
BGP is not free. It adds operational complexity. It requires engineers who understand it to build it, maintain it, and troubleshoot it. BGP needs to be documented properly because six months from now whoever’s on call at 2am needs to understand why that route-map is there.
Every tool you add to a network has a cost. BGP’s cost is high enough that it should only be paid when the problem genuinely requires it.
When BGP is the right answer, there’s nothing better for the job. When it’s the wrong answer, you’ve just added something that takes real expertise to maintain, breaks in non-obvious ways, and requires documentation your on-call engineer will definitely not read at 2am.