BGP Fundamentals: AS Paths, Communities, MED, Local-Pref

BGP Fundamentals: AS Paths, Communities, MED, Local-Pref

Border Gateway Protocol (BGP) is how independent networks tell each other which IP prefixes they can reach and which paths they prefer. If you’re comfortable with routing basics and want to understand how providers and enterprises actually steer traffic on the open internet, mastering BGP’s session types and path attributes is the next step.

At its core, BGP is a path-vector protocol. That means every route advertisement carries not just a destination, but a path history through autonomous systems (ASes). Operators then apply policy—business rules, security filters, and performance preferences—through attributes such as LOCAL_PREF, MED, and communities.

We’ll walk through how sessions come up, how the decision process picks a single “best” path, what AS paths and communities really do, and practical knobs you’ll use daily. We’ll finish with a small lab you can run in a container lab or virtual routers, plus safe change practices so you don’t surprise production.

BGP Sessions: eBGP vs. iBGP

Two routers form a TCP session (port 179), exchange OPEN messages with capabilities, and then trade routes via UPDATEs while keeping the session alive with KEEPALIVEs. Between different AS numbers, the session is external BGP (eBGP); within the same AS, it’s internal BGP (iBGP).

Why We Need Both

eBGP connects your AS to upstreams, peers, or customers. iBGP carries the externally learned routes across your own AS without altering AS_PATH. Because iBGP does not re-advertise routes learned from one iBGP neighbor to another by default (the “split horizon” rule), you solve reachability with route reflectors or confederations.

Common Session Options

You’ll often set next-hop-self on route reflectors so iBGP leafs don’t chase external next hops, enforce TTL security or GTSM to pin expected hop counts, and enable MD5 or TCP-AO for transport authentication. Graceful Restart and Route Refresh help avoid churn during maintenance and policy changes.

How BGP Selects the Best Path

BGP keeps many candidate paths per prefix but installs only one “best” into the RIB. The typical order is: highest vendor-specific weight (if implemented), highest LOCAL_PREF, locally originated routes, shortest AS_PATH, lowest origin type (IGP over EGP over Incomplete), lowest MED (often only compared when paths are from the same neighboring AS unless you explicitly “always compare MED”), eBGP over iBGP, lowest IGP cost to next hop, oldest path, lowest router ID, then lowest neighbor address.

LOCAL_PREF: Intra-AS Traffic Engineering

LOCAL_PREF is a non-transitive attribute used only inside your AS. Higher wins. Operators use it to prefer one upstream over another for outbound traffic. Because it’s evaluated early, it beats AS_PATH and MED. Typical patterns include setting a high LOCAL_PREF for customer routes (to send traffic toward customers) and a lower one for peers, lower still for transits, or using communities from neighbors to mark and lift specific routes.

AS_PATH: Loop Prevention and Preference

AS_PATH lists the sequence of ASes a route has traversed. BGP uses it to prevent loops and as a heuristic for path quality: shorter typically means preferred. You can influence it with AS path prepending, where you deliberately repeat your own AS number to make a path look longer and less attractive. Prepend sparingly; overdoing it can backfire if upstreams ignore long prepends or if global path diversity is limited.

MED: Inter-AS Inbound Hints

MULTI_EXIT_DISC (MED) is a hint to neighbors about which ingress point you prefer for traffic into your AS. Lower wins. Most implementations only compare MEDs if the routes come from the same neighboring AS, preventing noisy comparisons across unrelated peers. MED is weaker than LOCAL_PREF because it’s evaluated later and because neighbors can override or ignore it.

Communities: Tagging Routes for Policy

Communities are 32-bit or “large” 96-bit tags you attach to routes to drive policy at scale. Well-known communities include no-export (don’t send beyond eBGP) and no-advertise (don’t send at all). Most practical power comes from provider-defined communities: for example, “set LOCAL_PREF 120,” “prepend twice to peer A,” or “blackhole /32 on ingress.” Publish and consume a route policy document so both sides agree on meanings. Large Communities avoid ASN collisions and are easier to scope when you operate multiple ASNs or want structured tagging.

Extended and Large Communities

Extended communities carry additional semantics such as route targets for VPNs or traffic-action signals. Large Communities (three 32-bit fields) are popular on the public internet because they’re simple, readable, and survive AS merges. You’ll often see a format like “AS:Function:Value” where the first field is the owner of the namespace.

Putting Attributes Together: Common Policies

To prefer one upstream for all outbound traffic, raise LOCAL_PREF on routes learned from that upstream. To shift specific destinations, match community-tagged prefixes and raise or lower LOCAL_PREF selectively. For inbound control, ask your upstream to honor your communities that trigger AS path prepends on their side, or advertise more specific prefixes toward the path you want favored (while observing filtering and aggregation policies).

Customer, Peer, Transit Defaults

A sane baseline is: accept customers’ more specifics up to a max length (for example /24 in IPv4 and /48 in IPv6), tag them with high LOCAL_PREF, and advertise them widely; accept peers’ routes but don’t transit traffic between your peers and other upstreams unless that’s your business; from transits, accept broadly but with lower LOCAL_PREF and tight max-prefix and sanity filters to avoid leaks.

Security and Hygiene

Deploy RPKI origin validation so you drop or de-prefer invalids, maintain prefix-lists and as-path filters per neighbor type, and use max-prefix limits to keep leaks from filling your table. Route flap damping is usually kept off on the internet edge because it can punish recovery, but it can make sense in controlled domains. Always log policy changes and tie them to change tickets.

Worked Example: Small Two-Upstream Design

Imagine AS 65001 with two transits, AS 64501 and AS 64502, and a customer AS 65010. You want outbound to prefer 64501 but keep 64502 as hot standby, and inbound to prefer 64501 for your aggregate while keeping some heavy CDN prefixes coming via 64502.

Outbound Policy Sketch

On the edges toward both transits, set a route-map that assigns LOCAL_PREF 200 to routes learned from 64501 and 150 to 64502. Announce your aggregates to both. Optionally activate multipath if you need ECMP for capacity while still tilting with LOCAL_PREF.

Inbound Policy Sketch

Tag your announcements to 64501 with a community your provider documents as “no prepend,” and to 64502 with “prepend 2.” For the CDN heavy hitters, advertise a more specific (for example a /23 split from your /22) to 64502 so remote networks that prefer specificity will steer those flows there. Track traffic and roll back if upstreams ignore hints.

Lab: Minimal BGP Topology

You can reproduce these behaviors in a three-router lab using containers or VMs running FRRouting or similar. Topology: R1 (AS 65001) peers eBGP with R2 (AS 64501) and R3 (AS 64502). R1 also runs a loopback prefix 203.0.113.0/24 and an IPv6 2001:db8:100::/48. Set LOCAL_PREF on inbound from R2 to 200 and from R3 to 150. Verify that R1’s best path to remote prefixes selects R2. Then enable a route-map on announcements toward R3 that prepends “65001 65001.” From R2 and R3, inspect the AS_PATH and observe how remote best paths change after timers and propagation.

Useful Show and Debug Checks

Confirm TCP 179 is established, review negotiated capabilities (add-path, 4-byte ASN, graceful-restart), list received prefixes vs accepted after policy, and check next hop reachability in your IGP. If a route looks perfect but won’t install, check BGP best-path reasons and IGP cost to next hop.

ASCII Diagram

Use a simple sketch to keep the mental model clear: [AS 64501]──eBGP──[AS 65001 R1]──eBGP──[AS 64502]. Inside AS 65001, if you add R4 and R5 as route-reflector clients, set next-hop-self on the reflector and verify that iBGP re-advertisement works as intended.

Safe Change Practices

Stage policy in a lab first, then deploy to one edge, observe counters and traffic for at least one full BGP timer cycle, and only then roll out to the second edge. Use maintenance safeguards: max-prefix with reasonable thresholds, soft reconfiguration and route refresh instead of hard resets, graceful shutdown communities during planned maintenance, and clearly scoped prefix filters. Document the intent of each route-map and community so on-call peers can reason under pressure.

What Usually Backfires

Relying solely on MED for inbound control seldom works across many upstreams, hostile prepending can create asymmetric return paths that break stateful firewalls, and advertising excessive more specifics can get you filtered. Prefer simple, explainable policy that aligns with how neighbors actually treat attributes.

Checklist for Production

Verify 4-byte ASN support, enable RPKI validation, define customer, peer, and transit templates, publish your community policy sheet, set max-prefix and as-path filters, ensure next-hop reachability, and monitor best-path changes with alerts on dramatic shifts in path length or next hop.

BGP Fundamentals and Best Practices (FAQ)

Run an ASN Lookup on the prefix or origin AS you observe in the AS_PATH to see ownership and upstream relationships.

Validate next hop reachability and run a quick DNS Lookup on peer hostnames if you rely on names in templates, then review best-path reasons like LOCAL_PREF, AS_PATH length, and MED.

Raise LOCAL_PREF for that upstream and keep both sessions up with sane max-prefix limits; ECMP can be enabled later if links match, and you can verify your public egress with a simple Instant Public IP Check from test hosts.

It’s usually compared only among paths learned from the same neighboring AS unless you enable global comparison; if you need stronger control, use communities that change LOCAL_PREF or apply selective prepends and confirm mask lengths with an IP Calculator.

Use more specifics sparingly and within common filters (for example /24 in IPv4, /48 in IPv6), test reachability from multiple vantage points, and verify dual-stack exposure with an IPv6 Test when applicable.

Many providers honor a blackhole community that discards traffic at their edge; confirm their documented values and consider advertising only the attacked /32 or /128 while monitoring return paths from a traceroute and checking peer identities with Domain to IP.

If every iBGP speaker can full-mesh you don’t, but beyond a handful of nodes you’ll want reflectors; when you add them, set next-hop-self and confirm client propagation, and map which edge is primary with an internal label or a structured community plan.

Stage changes in a lab, push to one edge with soft reconfiguration and route refresh, monitor traffic for a timer cycle, then roll to the second edge; keep a backout route-map ready and alert on big shifts in AS_PATH length or next hop.