Policies, communities and best path

Theoretical foundations and architecture

BGP Communities are numerical tags attached to route prefixes to automate traffic engineering and policy enforcement. Standard Communities are 32-bit values (formatted as ASN:Value, RFC 1997), Extended Communities span 64 bits (fundamental for Route Targets in L3VPNs, RFC 4360), and Large Communities provide 96 bits (4-byte ASN compliant, RFC 8092). Operators rely heavily on communities to adjust Local Preference (governing outbound traffic selection), initiate AS_PATH prepending for inbound traffic shaping, limit announcement scopes via well-known communities (NO_EXPORT, NO_ADVERTISE), and trigger upstream Remotely Triggered Black Hole (RTBH) filtering (e.g., 65535:666). Edge boundary ingress policies must strictly sanitize and strip unauthorized customer communities to safeguard internal routing decisions.

Three community formats

A community is an optional transitive attribute that does not influence path selection by itself, but serves as a label for policies. There are three formats:

A 4-byte AS does not fit into the 16-bit field of a standard community, which is why Large communities are used for 4-byte ASNs. Extended communities contain a type, a subtype and a value: a Route Target is carried as target:65000:100 in the 2-byte AS plus 4-byte number format, while a network with 4-byte ASNs uses a different encoding type. Extended and large communities are carried as separate attributes, and set community does not touch the extcommunity.

Well-known communities

The values are reserved by IANA and work without any configuration on the neighbors:

• NO_EXPORT (65535:65281, 0xFFFFFF01): the route is not sent to eBGP neighbors outside the AS (in a confederation, outside the confederation).
• NO_ADVERTISE (65535:65282): the route is not sent to any BGP neighbor at all.
• NO_EXPORT_SUBCONFED / LOCAL_AS (65535:65283): the route does not leave the sub-AS.
• BLACKHOLE (65535:666, RFC 7999): a request to drop traffic to the prefix (RTBH).
• GRACEFUL_SHUTDOWN (65535:0, RFC 8326): the neighbor asks to move traffic to another path before maintenance.

Informational and action labels

An operator builds a scheme from two classes of labels:

• Informational (tagging on ingress): region, neighbor type, entry point, for example 65000:100 for customer A. They are used in export policies: customer routes go to everyone, provider routes only to customers.
• Action: the customer itself requests a behaviour through the label, for example 65000:80 sets LOCAL_PREF 80 (a backup entry), 65000:666 enables blackhole, 65000:1001 asks for a prepend towards upstream 1.

The labels must be described and published to customers; any scheme without documentation turns into an unmanageable set of numbers.

Ingress policy: filter, do not trust

Customer communities must not be let in without checks. The rules: (1) accept only the customer's own prefixes (prefix-list), (2) remove or replace foreign communities (set community 65000:100 without additive overwrites the list in Cisco/Huawei; in Junos community set behaves the same way), (3) process action labels only when both the prefix and the label match. Mistake (2) is especially dangerous in Junos: communities and Route Targets are stored in a single list in Junos, and community set CUST in a vrf-export policy will delete the RT, after which the VPN route is imported into no VRF at all.

Carrying communities across the network

By default Cisco does not send communities to neighbors: you need send-community (standard), send-community extended or both. On Huawei this is peer ... advertise-community (for extended, advertise-ext-community), in Junos communities are sent by default, and in RouterOS BGP connections they are sent by default, but filters can change them. If sending is not enabled on the RR or a PE, the label disappears at the nearest node and the policies on remote PEs stop working, even though everything looks correct on PE1.

RTBH: the blackhole community step by step

1. Customer A under DDoS announces the victim /32 203.0.113.77/32 with the label 65000:666.
2. PE1 checks against a prefix-list that the /32 lies inside the customer block (203.0.113.0/24 le 32); otherwise any customer could take down someone else's network.
3. The policy changes the next hop to 192.0.2.1 (an address from TEST-NET-1 with a static route to Null0/discard), sets a high LOCAL_PREF and NO_EXPORT.
4. The route spreads over iBGP, and every edge PE that receives it resolves the next hop to the discard route: traffic to the victim is dropped at the network ingress rather than reaching the customer.

Acceptance of the /32 must be allowed specifically for this label: an ordinary filter limits the prefix length to /24.

The best path algorithm

Cisco IOS-XE and similar platforms compare attributes in this order:

1. Weight (Cisco only; Huawei's equivalent is preferred-value) - higher is better.
2. LOCAL_PREF - higher is better (default 100; the Junos preference 170 is a different thing).
3. A locally originated route (network, redistribute, aggregate).
4. The shortest AS_PATH.
5. The lowest Origin (IGP < EGP < incomplete).
6. The lowest MED, compared only between paths from the same neighboring AS (unless always-compare-med is set).
7. eBGP is better than iBGP.
8. The lowest IGP metric to the next hop.
9. The oldest eBGP path, then the lowest router-id (ORIGINATOR_ID), the shortest CLUSTER_LIST, the lowest neighbor address.

Communities affect the choice through policies that change LOCAL_PREF, AS_PATH (prepend) or MED; they are not compared by themselves.

Typical mistakes

A forgotten send-community; a policy without a final term (the implicit deny drops all other routes); overwriting communities instead of additive; accepting blackhole without checking the prefix owner; LOCAL_PREF set on one PE and overridden by an RR policy on another; comparing MED between different ASes; spreading no-export inside a VPN without understanding the AS boundary.

Architecture Diagram & Topology