Blog

Illustration of BGP community tags steering global Internet traffic

BGP Communities: The Modern Traffic-Engineering Tool

Border Gateway Protocol (BGP) has always been the steering wheel of the Internet, but communities are the torque converter that lets operators shift routes with surgical precision. Roughly three-quarters of global prefixes now carry at least one community tag (RIPE Labs), and the number of distinct tags observed in global tables has tripled since the last decade. Those tiny integers are how sophisticated networks—ours included—tell upstream carriers exactly what to do with a route without ever touching a physical cable.

Below is a focused, outcome-driven look at three community techniques every multi-ISP architect should keep in the toolbox: setting local-preference, applying selective AS-path prepending, and issuing graceful-drain signals before planned work. Each section illustrates how documented tags from major Tier-1s can shape paths quickly where supported—plus the pitfalls to avoid.

Choose Melbicom

1,300+ ready-to-go servers

21 global Tier IV & III data centers

BGP sessions with BYOIP

Find your solution

Melbicom website opened on a laptop

Changing the Game with Local-Pref Communities

Problem: A primary link costs less or delivers lower latency, yet inbound traffic ignores it.

Classic workaround: Globally prepend your AS on the backup path and hope everyone respects AS-path length.

Modern fix: Tag the route with a community that lowers local preference inside the backup provider’s network.

Most Tier-1s expose at least three “priority” values. Telia’s 1299:50 drops a route to the bottom of its stack; 1299:150 sits midway; the default 200 wins. Lumen’s 3356:70 and 3356:80 perform a similar downgrade. When a Melbicom customer wants all inbound traffic to favor Telia over another upstream, we advise:

Step Action Result inside upstream
1 Announce prefix X to Telia without special tags Telia assigns default local-pref 200 (highest)
2 Announce prefix X to the backup provider with its documented low-pref tag That upstream lowers local-pref so its routers de-prefer the path

Traffic shifts almost instantly, and if the preferred carrier fails, the alternate already has the route—just at a lower rank—so fail-over is automatic. Because local-pref is evaluated before AS-path length, the outcome is deterministic and doesn’t rely on transit domains interpreting prepends the same way.

Pitfall to avoid: Mixing contradictory communities. If you accidentally tag the same route with both high- and low-pref codes, upstream automation may default to the safest (lowest) value, turning a primary link into backup without notice.

BGP Fine-Tuning with Selective Prepend

Diagram of targeted AS‑path prepending via community

Problem: A single eyeball network—or an entire continent—approaches your ASN on an expensive or long-latency route.

Classic workaround: Prepend your AS everywhere and accept collateral damage.

Modern fix: Use targeted prepend communities that instruct an upstream to lengthen the AS-path only when advertising to specific peers or regions.

Example: Lumen lets customers encode the number of prepends with the right-hand field of 3356:PP (PP = 70, 80, 90 …). Other carriers expose communities of the form <providerASN>:<peerASN> where the peer ASN selects exactly who sees the longer path. This means you can prepend three times only toward a latency-sensitive mobile carrier in Asia while leaving European paths untouched. Testing is reversible within a BGP re-advert interval—no need to wait for a maintenance window.

Melbicom guides clients to roll out targeted prepends in 3 phases: lab verify > announce to a /24 test prefix > extend to full production. Because our backbone links multiple upstreams in every POP, we can confirm prepend takes effect via looking-glass snapshots.

Pitfall to avoid: Prepending on top of a reduced local-pref tag. If the upstream already deprioritized your route via local-pref, the extra AS-path length adds no marginal value and complicates troubleshooting. Log all changes and keep the logic simple: lower local-pref OR prepend, rarely both.

Graceful-Drain Signals: Maintenance in the Age of Automation

Illustration of graceful shutdown draining traffic during maintenance

Problem: You need to upgrade optics at 3 a.m. without the drama of BGP flap storms.

Modern fix: RFC 8326’s 65535:0 Graceful Shutdown community. Tag all routes, wait a few minutes for neighbors to rank them lowest, then close the session cleanly.

For example, Arelion documents lowering local-pref to 20 for this tag; many IX route servers propagate it so peers proactively re-route. If your upstreams support RFC 8326 graceful shutdown, you can:

  • Tag 65535:0 toward the link under work.
  • Confirm traffic volume is near zero.
  • Shut down the BGP session or physical port.
  • Bring it back up, withdraw the tag, and watch traffic return.

The method beats “cold-turkey” shutdowns that cause transient route flutters. It also dovetails with DevOps pipelines: plug the tag into CI/CD jobs instead of ad-hoc CLI sessions.

Pitfall to avoid: Announcing Graceful Shutdown to an upstream that doesn’t support it; you’ll gain no relief and assume traffic drained when it didn’t. Always validate via neighbor logs or external looking glasses.

Tags, Tables, and Large Communities

Technique Why It Matters One-Line Best Practice
Local-pref tags Deterministic primary/backup Tag only one priority community per prefix
Selective prepend Regional cost or latency tuning Prepend narrowly—per ASN or per continent
Selective export / scope tags Limit who hears your routes (e.g., regional or peer-specific) Use documented no-export / regional communities; verify via looking glasses
65535:0 drain Hit-less maintenance Where supported, automate and verify before shutdown.

Large communities (RFC 8092) simply expand the namespace to 96 bits, avoiding overlap and supporting 32-bit ASNs. Every technique above works identically in large-community form; the field order just changes from ASN:value to ASN:action:modifier. If your AS > 65535, plan to migrate.

Common Pitfalls—The 90-Second Checklist

  • Assume Nothing. One provider’s backup tag could be another’s do-not-propagate.
  • Strip Unknowns. We sanitize incoming communities from peers to prevent remote policy bleed-through.
  • Harden Policy Changes. Require peer-review or approval before pushing community changes in automation.
  • Log Everything. Use commit-log diffs or NetConf/YANG to track community edits; rollback is your friend.
  • Monitor Results. Route-views, RIPE RIS, or our own looking glasses confirm a change propagated as planned.

Smart Communities, Smarter Routing

Instantly provision a BGP session and start shaping traffic with fine-grained community tags

BGP communities have grown from obscure metadata to a de-facto control plane for fine-grained routing policy. Set a single 32-bit integer and you can decide which carrier hauls your packets and how gracefully users ride out maintenance. The networks that master communities extract more value from every transit dollar and deliver steadier performance to every end user—even as traffic volumes and topologies evolve.

For engineers, the message is clear: treat communities as code. Document the intended outcome, tag the route, verify in near-real time, and roll back with confidence. The Internet already understands these cues; you only need to speak its language fluently.

Order Your BGP Session

Instantly provision a BGP session and start shaping traffic with fine-grained community tags.

Order now

 

Back to the blog

Get expert support with your services

Phone, email, or Telegram: our engineers are available 24/7 to keep your workloads online.




    This site is protected by reCAPTCHA and the Google
    Privacy Policy and
    Terms of Service apply.