BGP ISP Traffic-Engineering Networking Security DDoS

BGP communities: the traffic engineering tool most Latin American ISPs don't use well

Ariel Weher
BGP communities: the traffic engineering tool most Latin American ISPs don't use well

BGP has a feature that many operators know in theory but few exploit to its full potential: BGP communities. They are optional attributes attached to announced prefixes that enable sophisticated routing decisions without modifying the physical topology or manually adjusting metrics like MED or local-preference on each router.

In practice, what we see in Latin American networks is one of three scenarios: communities not implemented, communities partially implemented without coherent documentation, or communities leaking to peers and upstreams when they shouldn’t. All three scenarios have real operational consequences.

This article covers what they are, what they’re for, how to design a coherent scheme, and how to configure them on Huawei VRP.

What BGP communities are and why three types exist

A BGP community is a 32-bit attribute transported as part of a BGP update. It has no effect on its own: its value only matters when the routers receiving the prefix have policies configured to act on that value.

There are three variants:

Standard communities (RFC 1997): The classic format, represented as ASN:value where each field is 16 bits. For example, 65001:100. The limitation is that the ASN field is restricted to 16 bits, which creates ambiguity in networks with 32-bit ASNs (4-byte AS). They remain the most interoperable standard and the one virtually all routers understand.

Extended communities (RFC 4360): 64 bits long, with a type field that defines how to interpret the remaining bits. They’re primarily used in specific contexts such as MPLS VPN (Route Targets and Route Distinguishers) and in some QoS implementations. For general traffic engineering between ISPs, they’re less common than standard communities.

Large communities (RFC 8092): The modern format for networks with 32-bit ASNs. Represented as three 32-bit fields: ASN-global:function:parameter. For example, 65001:1:200 could mean “route learned from upstream 200.” They are the recommended format for new schemes and are well supported in current software (Huawei VRP, Juniper Junos, FRR, BIRD).

The choice between standard and large communities mainly depends on the equipment fleet. Networks using relatively modern hardware can adopt large communities from the start. Networks with legacy equipment or peers that don’t support large communities typically stick with standard communities for compatibility.

The problem they solve: traffic influence without topology changes

Imagine your network has two upstreams: transit provider A with good connectivity to Brazil and transit provider B with better coverage to Europe. Without communities, influencing which traffic exits through each upstream requires manually modifying the local-preference in the route-maps of each border router, for each prefix or group of prefixes.

With communities, the process can be centralized: every prefix received from any source is tagged with a community indicating its origin. Local-preference policies (and therefore outbound path selection) are applied based on that tag. When you want to change the policy (for example, because transit provider B improved its coverage to Brazil), you modify the policy in one place instead of reconfiguring router by router.

In the reverse direction, communities also serve to influence how upstreams and peers send traffic to you. Many transit providers accept well-known communities that instruct them to modify the BGP local-preference or AS-PATH prepending with which they propagate your prefixes to the rest of the internet. This gives you control over inbound traffic without changing anything in your physical infrastructure.

Practical use cases for ISPs

Traffic engineering: prefer routes via upstream A vs B

The most common case. If your AS is 65001 and you have two upstreams (AS 1234 and AS 5678), you can define a community scheme to indicate exit preference:

  • 65001:200 on a customer prefix: prefer exit via upstream 1234
  • 65001:201 on a customer prefix: prefer exit via upstream 5678
  • 65001:100 on a customer prefix: high-priority internal routes (local-preference 200)

The import route-map on each upstream evaluates these communities and assigns the corresponding local-preference. The result is that you can adjust outbound routing for different customer blocks by simply changing which community is attached to the prefix, without touching the topology.

It can also work in reverse: use the communities offered by your upstreams to control how they propagate your prefixes. For example, many large transit providers accept X:0 to indicate a prefix should not be propagated globally, or X:Y to limit propagation to a specific region. Documenting which communities each of your upstreams accepts is part of the traffic engineering work that distinguishes a reactive network from a managed one.

Remote blackholing (RTBH) to mitigate DDoS

Remote Triggered Blackhole (RTBH) is one of the most valuable uses of communities for operators under DDoS attack pressure. The mechanism is conceptually simple: you announce a specific prefix (the attacked IP or block) with a community that instructs your upstreams and peers to discard traffic destined to that prefix in their infrastructure, before it reaches yours.

The standard community for RTBH is defined in RFC 7999 — BLACKHOLE Community: 65535:666. This RFC, published in October 2016, standardized a practice that already existed informally among operators, establishing 65535:666 as the universal well-known community for signaling blackhole. Before RFC 7999, each transit provider and each IXP defined its own community for RTBH (for example, transit-asn:666), which created fragmentation and operational complexity. With standardization, a single announcement with 65535:666 is recognized by most major transit providers, IXPs, and content networks.

When you announce a /32 (or /128 in IPv6) with this community attached, you’re asking your BGP neighbors to install a route toward that destination pointing to Null0 or Discard. Traffic is dropped at the upstream’s edge, not in your network. RFC 7999 also recommends that the blackhole route be announced with the NO_EXPORT attribute (65535:65281) to prevent it from propagating further than necessary.

The operational sequence is:

  1. Detect the destination under attack (ideally with NetFlow/sFlow or anomaly detection systems)
  2. Generate the BGP announcement for the attacked prefix with 65535:666 attached
  3. Propagate it to upstreams that support RTBH
  4. Monitor the attack volume drop

The cost is that the attacked IP or block becomes unreachable (legitimate traffic is also discarded). But in a serious volumetric attack, that’s better than losing all network connectivity. Many ISPs implement this manually and late. Those with automated mechanisms can react in seconds.

RTBH can also be configured internally (iBGP blackhole) to discard traffic at the edge of your own network, before it reaches the attacked service. Both variants are complementary.

Route tagging by origin: customer, peer, upstream, internal

This is the foundation of a well-designed routing policy. Every prefix entering your network should carry a tag identifying its origin:

Origin Example community
Customer 65001:1000
Peer (IXP or bilateral) 65001:2000
Upstream / transit 65001:3000
Internal route 65001:4000

With this scheme, export decisions become simple, auditable policies: “to my upstreams, only export prefixes with community 65001:1000 (customers) and my own prefixes.” No peer or upstream route should propagate to another upstream. This prevents route leaks (which we describe in detail in our article on BGP configuration mistakes).

No-export, no-advertise and blackhole policies

RFC 1997 and RFC 7999 define well-known communities with standardized semantics that all BGP routers must respect:

  • NO_EXPORT (65535:65281): Do not propagate this prefix outside the confederation or AS. Used for routes that must remain local to your network.
  • NO_ADVERTISE (65535:65282): Do not propagate this prefix to any BGP neighbor. The prefix is used locally for routing decisions but is not redistributed.
  • NO_EXPORT_SUBCONFED (65535:65283): Similar to NO_EXPORT but applies at the sub-confederation level.
  • BLACKHOLE (65535:666): Defined by RFC 7999, indicates that traffic toward this prefix should be discarded (blackholed). It is the standard community for RTBH and is recognized by most major transit providers and Internet Exchange Points (IXPs).

The first three are especially useful for controlling the propagation of internal infrastructure routes (management loopbacks, network equipment IP ranges) that should not be visible outside your AS. The fourth is the foundation of the RTBH mechanism described above. The common mistake is not attaching them and discovering that those routes are being propagated to peers or upstreams when they shouldn’t be.

How to document a coherent community scheme (RFC 8195)

RFC 8195 (“Use of BGP Large Communities”) doesn’t just define the technical format: it also establishes documentation conventions so community schemes are readable and auditable. The recommended structure for large communities is:

<Global Administrator>:<Function>:<Parameter>

Where:

  • Global Administrator: Your ASN (32 bits)
  • Function: A number identifying the action type or information (defined by you)
  • Parameter: The specific value within that function

A documented scheme example for AS 65001:

Community Meaning
65001:1:1 Route learned from direct customer
65001:1:2 Route learned from IXP peer
65001:1:3 Route learned from upstream transit
65001:2:100 Set local-preference to 100
65001:2:200 Set local-preference to 200
65001:3:1 Do not export to upstreams
65001:3:2 Do not export to peers
65001:9:666 RTBH: discard traffic to this prefix

The key is that this scheme lives in a versioned document (Git is the right place), is known by the entire NOC and engineering team, and is updated when the policy changes. A community that nobody remembers the meaning of is worse than none: it generates false confidence.

Common mistakes: communities that propagate when they shouldn’t

The most frequent error we find when auditing ISP networks is uncontrolled propagation of internal communities. When your network assigns its own communities to prefixes (for example, to indicate origin or priority), those communities should be stripped before propagating the prefix to peers and upstreams. If you don’t, you’re exposing your internal routing policy to external operators, which at best generates confusion and at worst exposes sensitive operational information.

The mechanism to prevent this is simple: in export route-maps toward peers and upstreams, apply a community strip before announcing the prefix.

The second common mistake is not documenting which communities your network accepts from customers. If a customer sends prefixes with communities attached and you don’t have an explicit policy for what to do with them, the router accepts and propagates them. This can result in a customer accidentally (or deliberately) influencing your routing policy.

The third mistake is more subtle: not filtering communities on IXP peering sessions. At an Internet Exchange Point, you receive prefixes from dozens of ASes. Some may carry communities that have meaning in your network (by numbering coincidence). Without explicit filters, those communities can affect your routing decisions in unexpected ways.

Configuration example on Huawei VRP

The following example shows the configuration of a basic community scheme on Huawei VRP: customer route tagging, local-preference assignment, and internal community stripping when exporting to an upstream.

# Define community-filter to identify customer routes
ip community-filter basic CUSTOMERS permit 65001:1000

# Import route-policy from customer: tag with origin community
route-policy CUSTOMER-IN permit node 10
 apply community 65001:1000 additive

# Import route-policy from upstream: tag and adjust local-pref
route-policy UPSTREAM-IN permit node 10
 apply community 65001:3000 additive
 apply local-preference 100

# Export route-policy toward upstream: only export customers and own prefixes
# and strip internal communities before exporting
route-policy UPSTREAM-OUT permit node 10
 if-match community-filter CUSTOMERS
 apply community none

route-policy UPSTREAM-OUT permit node 20
 if-match ip-prefix MY-OWN-PREFIXES
 apply community none

# BGP session with customer
bgp 65001
 peer 203.0.113.1 as-number 64500
 peer 203.0.113.1 route-policy CUSTOMER-IN import
 peer 203.0.113.1 route-policy CUSTOMER-OUT export

# BGP session with upstream
 peer 198.51.100.1 as-number 1234
 peer 198.51.100.1 route-policy UPSTREAM-IN import
 peer 198.51.100.1 route-policy UPSTREAM-OUT export

To configure RTBH on Huawei VRP, the attacked prefix is announced with the 65535:666 community via a static route to Null0 redistributed through BGP:

# Static route to Null0 for the IP under attack
ip route-static 203.0.113.100 255.255.255.255 NULL0

# Route-policy to redistribute RTBH routes with the correct community
route-policy RTBH-OUT permit node 10
 if-match ip-prefix RTBH-PREFIXES
 apply community 65535:666 additive

# In the BGP process, import static routes with the RTBH policy
bgp 65001
 import-route static route-policy RTBH-OUT

This basic scheme can be extended to support automated RTBH integrated with anomaly detection systems.

Relationship with RPKI and routing security

BGP communities and RPKI solve different but complementary problems. RPKI validates that the origin AS of a BGP announcement has cryptographic authorization to announce that prefix. Communities influence how prefixes are propagated and prioritized once they enter the network.

A prefix can be valid from an RPKI standpoint (the AS has authorization) but still need communities to route correctly within and out of your network. And a well-designed community scheme complements RPKI by facilitating route tagging and propagation control that prevents route leaks.

If you haven’t implemented RPKI in your network yet, the article RPKI vs Social Engineering: How to protect your BGP when the human firewall fails is a good complementary read. Both tools are part of a mature routing policy.

Our field experience

In the ISP networks we audit in Latin America, the most frequent pattern is: communities were configured at some historical point, but the original scheme was never documented, the person who designed it is no longer at the organization, and nobody knows for certain what each active community does. The NOC team learns not to touch them for fear of breaking something.

That’s not traffic engineering: it’s technical debt accumulating silently.

A well-designed community scheme should be explainable in a single table, documented in the same repository as the router configurations, and modifiable by any engineer on the team without needing to consult the resident “expert.”

If your network runs BGP with multiple upstreams or peers and you want to review how your communities are configured (what’s propagated, what’s filtered, what’s documented), we can do that review with you.

Want to design or audit your network’s BGP community scheme?

We work with ISPs and operators in Latin America on routing policy design, traffic engineering implementation, and BGP configuration audits.

See our network engineering services →

Contact the team →

Have questions about BGP communities or traffic engineering in your network? Write to us at [email protected]

References