Why architecture matters here
Incidents at the BGP layer take the Internet with them. AS7007 in 1997 leaked a full table. Facebook in 2021 lost DNS through a BGP config. These are architectural failures, not bugs. The architecture matters because BGP's design assumes trust between peers and prioritizes policy over correctness.
Understanding the pieces means understanding how to configure filters, RPKI, communities, and dampening to protect yourself and your peers. It also means knowing what to expect during convergence — the seconds or minutes when a change ripples through the network.
With the architecture in your head, you can plan multi-homing, incident playbooks, and safety measures with intent.
The architecture: every piece explained
The top strip is the peering plane. Local AS is your autonomous system. eBGP peer is an external neighbor you exchange routes with — usually a provider, a peer at an IX, or a customer. iBGP mesh distributes external routes within your AS; every internal router must learn each external route. Route Reflector is a scaling trick — a central router that reflects iBGP routes to clients, avoiding full mesh.
The middle row is decision and policy. Best-path algo chooses which route to install: local preference (highest), AS path (shortest), origin, MED (lowest), etc. Policy filters routes on import and export — accept from customer, reject non-customer advertisements to peers. Communities are numeric tags routes carry, letting you steer preferences downstream ("do not export to Asia", "prepend three times"). Convergence uses keepalives (default 60s), hold time (180s), and route flap dampening.
The lower rows are safety. RPKI + prefix filters validate that the AS announcing a prefix is authorized to (ROA). Observability means route views, looking glasses, and BGPMon-style monitoring. The bottom strip lists the failure modes: leaks, hijacks, dampening incidents, and convergence blackholes.
End-to-end flow
End-to-end: your AS receives a route to 8.8.8.0/24 from two providers. Import policy accepts both, tagging one with local pref 200 and the other 100. The best-path algorithm picks the 200 route. iBGP distributes it to all internal routers via a route reflector. Export policy applied on peering session strips certain communities and does not advertise your customer's routes to other peers. A minute later, provider A withdraws the route. Your BGP session detects the withdrawal, promotes the provider B route, and iBGP converges within seconds. RPKI validated both routes at import. Route views show the update propagating globally within minutes.