BGP Large Communities for Traffic Engineering

Every provider network above a certain size runs on route tagging, and for two decades that meant 32-bit communities encoded as ASN:value. Four-byte ASNs broke that encoding: a two-octet word cannot hold a four-octet ASN, and extended communities cannot carry four-octet ASNs in both the global and local administrator fields. Large communities solve it by making each tag a 96-bit value displayed as three colon-separated 32-bit integers. The operational benefit is more than extra width — it gives network engineers a namespace large enough to encode the peer, the action and the parameter in a single readable tag.

The format and the guarantees

A large community is an unordered set of 12-octet values, each consisting of a four-octet Global Administrator and two four-octet operator-defined fields. The canonical representation is three unsigned decimal integers separated by colons: 64496:4294967295:2. The global administrator should be an ASN, and reserved ASNs are not recommended for it. Duplicates must not be transmitted and a receiver silently removes redundant values; an attribute whose length is not a nonzero multiple of twelve octets is malformed and treated as withdrawn. There are no well-known large communities, unlike standard communities.

Designing the convention: ASN:action:parameter

The convention that has become standard practice is Me:Action:You: the global administrator is the ASN that defines the meaning of the value, the second field is the function identifier, and the third carries the parameter — often a neighbour ASN. Informational tags describe where a route was learned (peer type, region), while action tags request behaviour such as selective no-export, pre-pending, or a local preference class.

64497:4:64498     Do not export this route to AS 64498
64497:6:64499     Prepend 64497 once when advertising to AS 64499
64497:9:0         Assign the LOCAL_PREF class for customer backup routes
64497:1:X142XXX   Informational: learned in the Asian region

Two practical rules keep the scheme maintainable. First, make informational and action tags distinguishable by shape — different field patterns or lengths — so a regular expression cannot accidentally match both. Second, publish the order in which action tags are processed, because a route carrying several conflicting requests is otherwise resolved by undocumented behaviour. Be careful with functions that lower local preference: the choice strongly influences the decision process and can produce durable, hard-to-diagnose preferencing as described in the BGP wedgie literature.

Matching and setting on Cisco IOS XE

router bgp 64497
 neighbor 192.0.2.1 remote-as 64498
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
  neighbor 192.0.2.1 send-community both

ip large-community-list standard CUST-A permit 64497:100:1
ip large-community-list expanded BAD-PREPEND permit 64499:.*:.*

route-map FROM-CUST-A permit 10
 match large-community CUST-A
 set local-preference 110

route-map CLEAN-INFO deny 5
 match large-community BAD-PREPEND
route-map CLEAN-INFO permit 10
 set large-community 64497:100:1 additive

exact-match is available on standard (non-expanded) lists and demands that the route carry exactly the listed set — useful when you need certainty, dangerous when a transit provider adds its own tags upstream. Match with matches-any semantics for action tags, and be explicit about additive when setting: without it, the existing large communities are replaced rather than appended.

Verification and hygiene

show bgp ipv4 unicast 192.0.2.0/24
show bgp large-community community-list exact-match 64497:100:1
show ip large-community-list
show route-map FROM-CUST-A

The route detail output prints the large community set attached to a prefix, which is the fastest way to confirm a policy fired. On the hygiene side: strip informational tags received from customers and peers, since only the network that defines them should set them, and never accept a large community in another operator's namespace as proof of anything. Large communities are optional transitive, so any AS in the path can add, alter or delete them, and no integrity protection exists — the trust model is the same as standard communities.

For policy fundamentals that apply to both attribute types, see BGP communities configuration examples and community and AS-path filtering on IOS XE; for how tag-driven local preference plays out in the decision process, BGP best path selection is the reference.

原文链接：https://datatracker.ietf.org/doc/html/rfc8092