In the previous article (Networking: BGP – The Invisible Protocol That Decides Where Your Traffic Goes), we talked about BGP as the protocol that runs the Internet.
But many engineers think:
“That’s interesting, but I don’t run an ISP. Why should I care?”
If you work with Azure, you are already using BGP—whether you realize it or not.
It’s quietly sitting behind:
- Site-to-site VPNs
- ExpressRoute
- Hybrid cloud networks
- Multi-region connectivity
And when something breaks, the error message won’t say:
“Network issue.”
It will say:
“BGP session down.”
A real-world DevOps scenario
Imagine this setup:
- Your company has an on-prem data center
- You moved your application to Azure
- The database still lives on-prem
- You connect them using a site-to-site VPN
Everything works fine for months.
Then one morning:
- The app cannot connect to the database
- Health checks start failing
- The deployment pipeline fails
You check:
- The VM → running
- The database → running
- The VPN tunnel → shows “connected”
But traffic still doesn’t flow.
The problem?
The BGP session inside the VPN is down, so no routes are being exchanged.
The tunnel exists.
But the networks don’t know how to reach each other.
Where BGP appears in Azure
You usually see BGP in three main scenarios.
1. Site-to-Site VPN with BGP
This is the most common hybrid setup.
On-prem Network
AS65010
+------------------+
| On-prem Router |
+--------+---------+
|
| VPN Tunnel
| + BGP session
|
+--------+---------+
| Azure VPN Gateway|
| AS65515 |
+--------+---------+
|
v
+------------------+
| Azure VNet |
| App + Services |
+------------------+
What BGP does here:
- On-prem announces:
- Internal networks (e.g.,
10.1.0.0/16)
- Internal networks (e.g.,
- Azure announces:
- VNet subnets (e.g.,
10.2.0.0/16)
- VNet subnets (e.g.,
Result:
- Azure can reach on-prem
- On-prem can reach Azure
- No manual route configuration needed
2. ExpressRoute (private dedicated connection)
This is used for:
- High bandwidth
- Low latency
- Enterprise hybrid networks
On-prem Data Center
AS65010
+--------------------+
| Core Router |
+---------+----------+
|
| BGP
|
+---------+----------+
| ExpressRoute Edge |
| Microsoft AS12076|
+---------+----------+
|
v
+--------------------+
| Azure VNet |
| Production Apps |
+--------------------+
In ExpressRoute:
- BGP is mandatory
- All routing is dynamic
- Routes are exchanged automatically
This is how:
- Azure learns your on-prem networks
- Your data center learns Azure networks
3. VNet-to-VNet connections with BGP
Used in:
- Multi-region architectures
- Hub-and-spoke networks
Region A Region B
VNet A (AS65515) VNet B (AS65515)
+------------------+ +------------------+
| Azure Gateway A |------- | Azure Gateway B|
| BGP | | BGP |
+--------+---------+ +--------+---------+
| |
v v
App Tier A App Tier B
BGP allows:
- Automatic route exchange between VNets
- Easier scaling when networks grow
What BGP actually does in Azure
Without BGP, you would need:
- Manual route tables
- Static routes
- Constant updates when networks change
With BGP:
- Each side announces its networks.
- Routes are exchanged automatically.
- Changes propagate without manual intervention.
Example
On-prem adds a new subnet:
10.5.0.0/16
With BGP:
- On-prem router advertises it
- Azure learns it automatically
- No manual changes required
Without BGP:
- You must update:
- Azure route tables
- VPN configuration
- Possibly multiple environments
What a healthy Azure BGP session looks like
On-prem Router Azure VPN Gateway
AS65010 AS65515
+---------------+ +----------------+
| BGP: ESTABLISHED <-------> |BGP: ESTABLISHED|
+---------------+ +----------------+
| |
| Routes exchanged |
v v
10.1.0.0/16 10.2.0.0/16
Traffic flows normally.
What happens when BGP fails
The tunnel may still be up:
VPN Tunnel: CONNECTED
BGP Session: DOWNDiagram:
On-prem Router Azure VPN Gateway
+---------------+ +----------------+
| BGP: DOWN | | BGP: DOWN |
+---------------+ +----------------+
| |
| No routes exchanged |
v v
(No knowledge of (No knowledge of
Azure networks) on-prem networks)
From the application’s perspective:
- Database unreachable
- API calls fail
- Timeouts increase
Even though:
- VMs are running
- Tunnel is “connected”
Common BGP-related issues in Azure
1. ASN mismatch
Each side must use a valid Autonomous System Number.
Example:
- On-prem: AS65010
- Azure: AS65515 (default)
If misconfigured:
- BGP session won’t establish
2. Wrong advertised prefixes
If on-prem only advertises:
10.1.0.0/24
But the database is in:
10.1.5.0/24
Azure won’t know how to reach it.
Result:
- Partial connectivity
- Strange, inconsistent failures
3. Route conflicts
If both sides advertise overlapping ranges:
Azure: 10.2.0.0/16
On-prem: 10.2.0.0/16
Routing becomes unpredictable.
What DevOps engineers should remember
You don’t need to memorize BGP attributes.
But you should know:
The practical mental model
On-prem network
|
(BGP)
|
Azure gateway
|
Azure VNet
|
Your application
If connectivity breaks, check:
- Is the VPN or ExpressRoute up?
- Is the BGP session established?
- Are routes being exchanged?
Quick checklist during incidents
If Azure can’t reach on-prem:
- Check VPN or ExpressRoute status.
- Check BGP session state.
- Verify advertised prefixes.
- Confirm no overlapping IP ranges.
Why this matters for DevOps and developers
Understanding BGP helps you:
- Debug hybrid connectivity issues
- Design reliable multi-region systems
- Communicate with network teams
- Interpret cloud networking errors
Instead of saying:
“The network is broken.”
You can say:
“The VPN tunnel is up, but the BGP session is down, so routes aren’t being exchanged.”
That’s a very different level of diagnosis.