For IT leaders
BGP shows up anywhere your team interacts with another routing domain; misconfiguration causes outages that often cross team and vendor boundaries.
Why IT teams care
Where this shows up at the team level
- Internet edge designs, multi-cloud connectivity, and SD-WAN overlays all rely on BGP.
- Cloud landing zones in AWS, Azure, and Google Cloud expose BGP to network engineers via virtual gateways and Direct Connect / ExpressRoute.
- Outages traced to route leaks or path attribute mistakes often require senior engineers; team training reduces blast radius.
In production
Where teams encounter it
- Internet edge routers peering with ISPs
- Site-to-site cloud connectivity and SD-WAN underlays
- Inside the enterprise core for route reflectors and MPLS L3VPN deployments
How it works
How BGP actually works
- 01Every BGP speaker belongs to an autonomous system (AS) identified by an AS number; routers exchange routes with peers over TCP port 179.
- 02External BGP (eBGP) peers across AS boundaries; internal BGP (iBGP) carries those routes through the local AS without changing the AS path.
- 03BGP is a path-vector protocol: it picks routes by walking through path attributes such as local preference, AS path length, MED, and origin, in a deterministic order.
- 04Operators shape traffic by manipulating those attributes and applying route policies inbound and outbound on each peer.
In practice
Common team use cases
- Multi-homed internet edge with two or more ISPs
- Connecting on-prem to AWS, Azure, and Google Cloud over Direct Connect, ExpressRoute, or Cloud Interconnect
- Service provider backbones and large enterprise WANs
Build the capability
Related CBT Nuggets training
Each link routes to a hub that goes deeper than this definition.
Related concepts