Short answer: A BGP Large Community is a transitive route tag written as Global-Administrator:Local-Data-1:Local-Data-2. Its three 32-bit fields provide a practical namespace for policy signaling, including four-byte ASNs; the tag itself does not change forwarding unless a router or provider policy acts on it.[4]
Why Large Communities exist
Traditional communities are 32-bit values and commonly split into two 16-bit numbers. That convention cannot represent a four-byte ASN in the administrator field. Extended Communities have a different format and use cases. RFC 8092 defines Large Communities as a separate optional-transitive attribute made from 12-octet values, each containing a four-octet Global Administrator and two four-octet local data fields.[4]
Canonical text looks like 64496:100:20. Here, 64496 identifies the namespace owner; the meanings of 100 and 20 are defined by that operator. The format does not impose a universal meaning. Treat a provider's published community guide as the contract, not a guessed interpretation.
Design a readable policy namespace
A simple customer-side scheme might define 64496:100:10 as “learned from transit A, normal route,” 64496:100:20 as “learned from transit A, preferred class,” and 64496:900:1 as “request provider blackhole service.” These are illustrative values only—not standardized codes. Document assignment, propagation, and actions, and avoid giving one value ambiguous meanings.
Large Communities are an unordered set; their sequence in an update has no meaning. Duplicate values are removed by receivers. Aggregation behavior and attribute propagation should be tested against the deployed platform and policy design.[4]
How they affect traffic
- Outbound from your AS: Match a received Large Community and set local preference, select an egress, or filter a route. LOCAL_PREF and the routing policy perform the decision; the Large Community is the signal.
- Inbound toward your prefixes: Attach a provider-documented value requesting selective advertisement, lower remote preference, prepending, or blackholing. The neighboring network must explicitly support and honor it. RFC 8195 describes operational use cases and conventions, not a guarantee that every network implements them.[5]
- What it cannot do: A tag cannot force another AS to change its policy, guarantee symmetric paths, override your own route selection without a matching policy, or substitute for prefix filters and authorization controls.
FRRouting example: tag, match, and set local preference
The following is an illustrative FRR-style route-map pattern. Confirm exact syntax and feature support in the installed release before deployment; FRR documents Large Community list matching and route-map actions.[6]
! Define a locally assigned tag meaning “preferred upstream class”
route-map FROM-PEER permit 10
set large-community 64496:100:20 additive
! Match that tag on another policy boundary
bgp large-community-list standard PREFER-UPSTREAM permit 64496:100:20
route-map SELECT-EXIT permit 10
match large-community PREFER-UPSTREAM
set local-preference 200
route-map SELECT-EXIT permit 100
set local-preference 100Apply inbound/outbound route maps to the intended neighbor and address family. The sample values are private policy conventions. The additive behavior preserves existing tags on implementations that support that keyword; verify rather than assuming tags are retained.
Provider-facing inbound influence
Suppose your provider publishes a documented Large Community for “prepend twice toward peer group X.” You can attach that exact value to the exported prefix, then inspect the advertised route and ask the provider to confirm its policy action. This can influence inbound path selection, but Internet traffic sources and competing routes remain outside your control. Do not substitute an undocumented value or assume a value from another provider has the same meaning.
Verification logic
Check the received path, the exact three-part tag, and the policy result—not just whether BGP is Established. On FRR, inspect the BGP route and relevant large-community list; use the release-specific command reference for exact syntax.[6]
show bgp ipv4 unicast 203.0.113.0/24
show bgp ipv4 unicast large-community-list PREFER-UPSTREAM
show running-configExpected logic: the route shows the intended Large Community; the list matches it; the selected path has the policy-set LOCAL_PREF; and the advertised route to the provider contains only intended tags. Compare received, selected, and advertised views because policy may modify attributes between them.
Modern network use
In a dual-ISP edge, Large Communities can label route origin or customer intent and drive internal exit preference, while provider-defined tags may request external treatment. In a data-center or EVPN/VXLAN design, use them only where the BGP implementation and control-plane policy support the attribute; do not confuse them with Extended Communities such as Route Targets, which serve distinct VPN/EVPN import-export functions. In cloud/on-prem routing, confirm the cloud provider's supported attributes and documented policy actions rather than assuming arbitrary tags are honored.
Troubleshooting checklist
- Confirm both peers negotiate and propagate the attribute as expected.
- Check spelling and all three numeric fields; ensure the Global Administrator namespace is the intended one.
- Verify route-map attachment, direction, address family, sequence order, and match counters.
- Check whether a set action replaced or preserved existing Large Communities.
- Compare received, Loc-RIB/best path, and advertised route views.
- Check aggregation, route-reflector policy, and intermediate AS behavior for tag loss or modification.
- For provider requests, verify the exact current provider guide and confirm action with the provider.
Interview answer
“BGP Large Communities are optional-transitive 12-byte route tags with a 4-byte Global Administrator and two 4-byte local fields. They solve the namespace limitation of standard communities for four-byte ASNs. The values have operator-defined meaning; route policy must match them to change local preference, filtering, or provider behavior. They are requests/signals, not commands that force remote networks.”
Related reading
- BGP Communities Explained: Policy Tags, no-export and Blackhole Routing
- BGP MED Explained: Inbound Traffic Influence and Limits
- BGP Table Watch
Post a Comment