Nine episodes. Thirteen-plus blog posts. A lot of bourbon.
If you’ve followed the Bourbon & BGP series from the beginning, you’ve covered the full foundation of BGP. Not the survey-level “BGP is an EGP protocol that uses TCP port 179” kind of coverage. The real stuff. The stuff that actually matters when you’re building networks or troubleshooting them at 2am.
Quick recap of where the series went and what to go build next.
What We Covered
BGP: What It Is and Why It Exists
BGP is a path-vector routing protocol. It’s been routing traffic between autonomous systems since 1994 and it shows up in enterprise networks, data centers, cloud connectivity, and SD-WAN far more than people expect. The key mental model: BGP applies policy to choose between paths. Not metrics. That policy control is both its power and the reason it’ll ruin your day if you misconfigure it.
Do You Actually Need BGP?
Most networks don’t need it. Single-ISP, single-site, simple topology? Static routes. The moment you add a second ISP and want real traffic engineering, you need BGP. Touch dedicated cloud connectivity and you’re already in it. Build or manage a spine-leaf data center fabric and BGP is on the floor whether you planned for it or not. The real question is whether you’re exchanging routes with more than one external network and need policy control over that exchange.
eBGP vs iBGP
External BGP is between routers in different autonomous systems. TTL defaults to 1. The advertising router sets its own IP as the next-hop. eBGP prepends the AS number on transit. Internal BGP is between routers in the same AS. TTL is 255. iBGP doesn’t change the next-hop. iBGP doesn’t modify the AS path. The iBGP split horizon rule means you can’t re-advertise a route from one iBGP peer to another. That rule is why full mesh is required and why route reflectors exist.
The iBGP Full Mesh Problem
n(n-1)/2 sessions. Three routers need three. Ten routers need 45. Fifty routers need 1,225. Full mesh is manageable in a lab. In a production network that grows, you’ll be back here adding route reflectors on a live network. Do it before you need to.
Autonomous System Numbers
ASNs identify autonomous systems and appear in the AS_PATH for loop prevention and traffic engineering. Public ASNs require registration with a regional internet registry. Private ASNs (64512-65534 in the 2-byte range, 4200000000-4294967294 in the 4-byte range) are for internal use. 4-byte ASNs expanded the pool from 65,535 to over four billion. ASdot vs asplain is a style choice. Pick one and stay consistent.
BGP Best Path Selection
Weight, Local Preference, Locally Originated, AS Path Length, Origin Code, MED, eBGP over iBGP, IGP metric to next-hop, oldest eBGP route, then router-id and other tiebreakers. Weight is Cisco-only and local to the router. Local preference is your primary tool for outbound traffic engineering and propagates to all iBGP peers. AS path length is the most commonly manipulated attribute for influencing inbound traffic. MED behavior varies by vendor. Know the algorithm cold. BGP is deterministic. If you know the attributes and the order, you can always explain why it made the decision it made.
Your First eBGP Config
Minimum viable session: router bgp, neighbor with remote-as, network command. The network command only works if the prefix is already in the routing table. Always filter. Prefix-lists are clean and fast. Route-maps handle filtering plus attribute manipulation. Soft resets preserve the session while triggering policy re-evaluation. Know your show commands: bgp summary, bgp neighbors, bgp ipv4 unicast.
Route Reflectors
Route reflectors bypass the iBGP split horizon rule with loop prevention built in via CLUSTER_LIST and ORIGINATOR_ID. Clients peer only with the RR. The RR re-advertises between them. Configure the same cluster ID on redundant RRs or the loop prevention breaks in failure scenarios. Place RRs in the core of your topology. Two RRs minimum.
Next-Hop Self
eBGP-learned routes carry the external peer’s IP as the next-hop. When those routes get reflected into iBGP, your internal routers can’t reach that external IP. The route’s in the table. Traffic still fails. neighbor x.x.x.x next-hop-self rewrites the next-hop to the edge router’s own address. Verify with show bgp ipv4 unicast x.x.x.x/y and confirm the next-hop is reachable in the IGP.
BGP Confederations
Confederations split a single AS into sub-ASes internally. Sub-ASes run eBGP-like sessions with each other, which allows route re-advertisement without a full iBGP mesh. Externally, the whole confederation still looks like a single AS. Internal sub-AS numbers get stripped before advertising to external peers. More complex than route reflectors, less commonly deployed, but used in large carrier environments that need clean administrative separation between internal domains.
BGP Address Families
MP-BGP extends BGP to carry routing information for multiple protocol families over a single session. IPv4 unicast, IPv6 unicast, VPNv4, EVPN. Each address family has its own routing table. Policies apply per address family. IPv6 BGP sessions should run over IPv6 transport for clean next-hop behavior. If you’re doing VXLAN/EVPN, MPLS L3VPN, or dedicated cloud connectivity, you’re already working with address families whether you realize it or not.
Self-Assessment
If you’ve absorbed this series, you should be able to answer these questions without looking anything up:
What’s the difference between the default TTL behavior on an eBGP session vs an iBGP session, and why?
Why does iBGP require full mesh by default, and what rule creates that requirement?
If you have three paths to the same prefix and all three have the same local preference and AS path length, what’s the next attribute BGP compares?
Your internal router has a route in show bgp but not in show ip route. Name two possible reasons.
What happens to the CLUSTER_LIST when a route reflector reflects a route to its clients?
Why does a route learned via eBGP and then redistributed into iBGP sometimes cause reachability problems, and what single command fixes it?
If you can answer all of those, you’re ready for production BGP. If some of them made you reach for the scroll bar, go back to those posts and spend more time with the concepts.
Where to Go Next
This series covered the foundation. There’s a second layer that matters for anyone operating BGP at real scale.
BGP Communities. The mechanism for tagging routes with metadata that influences how they’re treated at other points in the network. Large communities (RFC 8092) have made this even more powerful. Community-based routing policies are how large networks do traffic engineering at scale without maintaining massive per-prefix route-map entries.
BGP Route Policies at Scale. Building scalable filtering and manipulation policies. Policy inheritance. Template-based neighbor configuration. How to manage BGP policy across hundreds of peers without losing your mind.
BFD for BGP. Bidirectional Forwarding Detection gives BGP sub-second failure detection. Default BGP timers are measured in seconds or minutes. BFD changes that. Essential for any network where BGP convergence time matters.
BGP in the Data Center. BGP as the underlay fabric protocol in spine-leaf designs. RFC 7938. Unnumbered BGP. EVPN as the overlay control plane. This is the entire data center networking stack built on BGP concepts.
BGP with SD-WAN. How enterprise SD-WAN solutions interact with BGP at the edge. Route redistribution between the SD-WAN overlay and BGP underlay. Traffic engineering across hybrid WAN environments.
BGP Security. RPKI and Route Origin Validation. BGPSEC. Prefix filtering best practices that actually prevent route leaks and hijacks. The reason the internet occasionally has very bad days and how the industry is trying to fix that.
The foundation is solid. The advanced topics are where BGP gets genuinely interesting.
Pour one more. You’ve earned it.