BGP Communities for Multi-Provider Networks: A Traffic-Policy Guide

BGP communities attach policy information to route announcements. A provider can use documented values to adjust route preference, limit advertisements, or apply other agreed actions. They help us influence routing, but they do not give us control over every network along a path.

Using BGP communities for traffic engineering starts with three questions: which traffic direction needs to change, which network must act, and which documented control supports that goal?

This guide helps you prepare those requirements for Atal Netzwerke, compare provider policies, and test changes before relying on them.

Match the Routing Goal to the Right Control

A multi-provider design gives us alternative connections. Routing policy determines how we use them.

Our objective	Control to assess	Detail to confirm
Choose a connection for outbound traffic	Our import policy and local preference	Available routes and policy order
Influence traffic arriving through a provider	Provider local-preference community	Supported values and alternative paths
Limit advertisements to selected neighbors	Selective export community	Targets, exceptions, and precedence
Make an advertised path less attractive	Targeted AS-path prepending	Scope and which ASN the provider repeats
Drain traffic before maintenance	Graceful-shutdown support	Receiver behavior and backup capacity
Discard traffic during an incident	Authorized blackhole service	Activation, prefix rules, and removal

Treat this table as a planning checklist. Confirm each feature for the actual service, location, session, and address family.

1. Understand the Information a BGP Community Carries

A community labels a BGP route. It does not label each packet or reserve bandwidth.

We can attach several communities to an announcement. A receiving router then applies policies that match those values.

Two uses matter most:

• Informational communities describe a route, such as its entry location or whether the provider learned it from a customer or peer.
• Action communities request a documented change, such as lowering preference or suppressing an advertisement.

An informational tag can help us choose an outbound route. An action tag on our own prefix can influence how a provider handles traffic toward us.

The value itself does not create a custom action. The receiving network must support a matching policy.

2. Compare Community Formats and Provider Definitions

Standard, extended, and large communities describe different encodings. Provider-defined describes meaning.

Format	Size per value	Common use
Standard	32 bits	Two 16-bit fields commonly displayed as A:B
Extended	64 bits under RFC 4360	Typed policy information, including route targets
Large	96 bits	Three 32-bit fields displayed as A:B:C

Large communities allow a full four-octet ASN in the administrator field. A network with a four-octet ASN can still use standard communities through a documented numbering scheme, but that full ASN cannot fit in a 16-bit field. [1][2][3]

Read the Meaning, Scope, and Exceptions

For every value, record the requested action, eligible session, target neighbors, geographic scope, and address-family support.

Also check how the provider handles conflicting communities. The order in which values appear does not establish policy priority.

Router behavior matters too. Confirm whether the session sends the required community types and whether a policy adds to or replaces existing values. Do not assume identical defaults across platforms.

Providers may remove action communities after processing them. A tag does not need to remain visible across the Internet for the intended action to have occurred.

3. Separate Our Local Preference From the Provider’s

Traffic direction causes many routing-policy mistakes. Always name the network whose inbound or outbound traffic we mean.

Our Local Preference Influences Our Outbound Traffic

Suppose we receive a route through Providers A and B. Our import policy can assign a higher local preference to A’s route, making it preferred within our AS when other eligibility conditions permit.

This controls our route choice for traffic leaving our network. It does not directly choose the return path.

LOCAL_PREF stays within an AS under ordinary external BGP operation. We cannot send our preferred value to an unrelated provider and expect it to adopt that value. [4]

Provider Communities Can Influence Traffic Toward Us

A provider may accept a community that lowers its local preference for our announced prefix.

That can make another eligible route more attractive inside the provider’s network. The result depends on the available alternatives and the provider’s policy.

For example, lowering a route below another customer route differs from lowering it below routes learned from peers. Ask which preference class the community selects.

Remote networks still make their own choices. A provider accepting our community does not guarantee a particular global traffic split.

Prepending and MED Have Different Limits

AS-path prepending makes a path appear longer. It may influence a network that considers path length after higher-priority decisions, but it may do nothing when local preference already decides the outcome.

MED can express a preferred entry point under applicable comparison rules. Do not treat it as a universal control across unrelated providers.

We should choose the mechanism that matches the routing problem, then measure the result. Adding more prepends without checking the selected path can leave the original problem unchanged. [5]

4. Plan Selective Route Advertisement

Selective export communities can ask a provider to advertise a prefix to some neighbors and withhold it from others.

Possible targets include peers, customers, transit providers, individual ASNs, or route-server clients. Each provider defines the available groups.

An instruction to stop advertising to one direct neighbor does not guarantee that the neighbor’s ASN disappears from every possible Internet path.

Distinguish NO_EXPORT From NO_ADVERTISE

These standard communities have different boundaries:

• NO_EXPORT: Do not advertise the route beyond the BGP confederation boundary. For a standalone AS, that means its AS boundary.
• NO_ADVERTISE: Do not advertise the route to any BGP peer. [1]

Provider-specific commands such as “do not announce to this upstream” offer a different scope.

Before restricting exports, check which backup routes remain. Suppressing the only usable advertisement can remove reachability rather than improve a path.

Check Rule Precedence

An allow instruction may override a broader suppress instruction, or the reverse. Follow the provider’s documented order.

NTT, for example, publishes precedence rules for overlapping customer communities. GTT states that certain prepend communities affect peering partners but not customers. These differences make copying a policy between providers unreliable. [6][7]

For exchange connections, distinguish the route server from the forwarding path. A route server normally exchanges routing information without carrying the resulting user traffic.

5. Map Regional and Upstream Policies

“Prefer this location” and “advertise only from this location” are different requests.

The first may leave other paths available with lower preference. The second may remove advertisements that would otherwise provide a fallback.

A regional tag also uses the provider’s definition of a region. It does not guarantee that every packet remains within that geography or establish data residency.

A Two-Provider Planning Example

Consider this fictional network:

• Customer: AS64496.
• Provider A: AS64497.
• Provider B: AS64498.
• Example prefix: 192.0.2.0/24.

These values serve documentation only. Do not announce this prefix on the public Internet.

Our goal is to influence selected inbound traffic toward A while retaining B as a backup.

We first confirm that B offers a suitable preference-reduction community. Then we check whether B can learn an eligible alternative path through A and whether that path has enough capacity.

We apply B’s documented action to the intended announcement and inspect B’s route choice. External observations and traffic measurements show whether the change achieves our goal.

Finally, we test loss of A and restoration of A. A policy that works during normal operation may behave differently after a failure.

Use the actual provider’s documented value during deployment. A label such as PROVIDER_B_BACKUP_ACTION is only a planning placeholder.

Keep Maintenance and Incident Controls Separate

The graceful-shutdown community, 65535:0, supports planned traffic draining when the receiving network implements the relevant policy and usable alternatives exist. It does not promise interruption-free maintenance. [8]

The BLACKHOLE community, 65535:666, requests discard behavior under an agreed service. Confirm authorization, accepted prefix lengths, and scope before use. Blackholing drops legitimate traffic along with unwanted traffic; it differs from attack scrubbing. [9]

Ask whether incident handling can override location or export restrictions.

6. Check IPv4 and IPv6 Independently

A successful IPv4 test does not prove that IPv6 behaves the same way.

Confirm community support, route filters, session configuration, and next-hop reachability for each address family. Large communities are not specific to IPv6.

Prefix acceptance also needs separate checks. Many networks filter ordinary IPv4 routes longer than /24 and IPv6 routes longer than /48, but these are common practices rather than universal guarantees. Confirm your providers’ current policies and test visibility. [10]

Blackhole services may accept host routes under separate rules. Do not assume those exceptions apply to normal advertisements.

Also examine aggregates and more-specific routes. Packet forwarding uses the longest matching prefix, so a more-specific route can change the result even when the aggregate has a different preference.

7. Confirm ASN and Prefix Prerequisites

Community policy only matters after a provider accepts the route.

Identify the intended origin ASN, any different session ASN, and your authority to announce each prefix. Confirm the provider’s authorization and onboarding requirements.

An IP lease or ASN arrangement does not automatically establish announcement rights through every upstream.

For independent public multihoming, confirm a suitable public ASN and prefix arrangement. Review our IPv4, IPv6, and ASN services as part of that discussion.

Prepare these details:

• Authorized IPv4 and IPv6 prefixes.
• Required IRR route, route6, or AS-set records.
• Default, partial, or full routing needs.
• Router capacity and maximum-prefix limits.
• Session addresses and authentication requirements.
• Handoff locations, port capacity, and traffic commitments.
• Operational contacts and change ownership.

Two providers may still share facilities or physical paths. Review failure independence and the capacity remaining after one connection stops.

8. Check RPKI and Filtering Before Policy Changes

A correct community does not repair an unauthorized or rejected announcement.

Check Origin Authorization

A Route Origin Authorization, or ROA, states which ASN may originate a prefix and can specify an allowed maximum length.

RPKI origin checks produce three main states:

State	Meaning
Valid	At least one applicable authorization matches the route’s origin and length
Invalid	An authorization covers the prefix, but none matches the route
NotFound	No applicable authorization covers the prefix

NotFound and Invalid are different states. Provider handling depends on its routing policy. RPKI origin checks do not authenticate community values or the complete AS path. [11]

Check the intended origin and prefix lengths before changing advertisements. Avoid expanding a ROA’s maximum length simply to accommodate an unplanned more-specific route.

Check Both Prefix and Community Filters

Confirm IRR filters, accepted lengths, authorized origins, and session limits.

Use export policies that permit only intended prefixes. At policy boundaries, reject or remove unauthorized action tags and protect internal-only controls.

Also check whether adding a community removes existing values. An accidental replacement can erase a required export restriction or maintenance signal.

9. Test the Action, the Traffic, and the Rollback

A routing change needs evidence at more than one point.

Capture a Baseline

Record the prefix, address family, selected paths, existing communities, traffic by interface, packet loss, latency, and available alternatives.

Save the previous policy and define success before making the change.

Confirm Each Stage

Test	Evidence to collect
Route acceptance	Provider’s received-route view
Community delivery	Our export attributes and provider receipt
Policy execution	Provider route selection or export behavior
Traffic result	Interface counters, flow data, and active probes
Failover	Behavior after the preferred path stops
Restoration	Behavior after the path returns

Looking glasses and route collectors provide useful external views, but they do not see every route or source network. Use several viewpoints relevant to your users.

A visible community proves that a tag reached an observation point, not that a particular policy executed. Conversely, a provider may process a tag and remove it before exporting the route.

Keep the Initial Change Limited

Start in a lab, then use an authorized prefix or a controlled production scope. Change one policy objective at a time.

Use the platform’s supported method to re-evaluate policy. Check IPv4 and IPv6, and allow for the network’s observed convergence behavior rather than promising a fixed recovery time.

Prepare the Reversal

Keep exact rollback steps, out-of-band access, and an operator responsible for restoring service. Use confirmed commits or equivalent safeguards where the platform supports them.

Set rollback triggers for lost reachability, excessive packet loss, overloaded backup capacity, or an unexpected path.

After reversal, check both route visibility and traffic. Restoring configuration text alone does not prove that the service has recovered.

10. Bring Your Routing Requirements to Atal Networks

A useful provider discussion starts with the outcome you need.

Share your ASN, authorized prefixes, upstream design, target markets, deployment locations, traffic volumes, and recovery requirements with us.

Describe the direction clearly. “Prefer Provider A for traffic leaving our network” requires a different discussion from “reduce traffic entering through Provider B.”

Use this checklist before committing to a deployment:

Requirement	Request confirmation
Community support	Current catalogue, formats, and revision date
Scope	Supported services, locations, sessions, and address families
Preference	Available levels and their relationship to other route classes
Export controls	Neighbor groups, regional actions, and exceptions
Conflicts	Rule precedence and unsupported combinations
Third-party tags	Pass-through, stripping, or translation behavior
Route acceptance	Authorization, IRR, RPKI, and prefix-length requirements
Operations	Testing visibility, change process, and support ownership
Commercial terms	Setup requirements, charges, commitments, and fallback capacity

Keep unanswered items marked as unconfirmed. Do not substitute another carrier’s community list for deployment-specific documentation.

Discuss your ASN, prefixes, upstream design, target markets, and routing-policy requirements with Atal Networks.

Häufig gestellte Fragen

Can BGP communities control traffic across every provider?

No. A community requests an action from a network that recognizes and permits it. Other networks apply their own policies. Confirm the scope with each provider and measure the resulting traffic paths.

Does local preference control inbound or outbound traffic?

Local preference influences route choice inside the AS that sets it. Our local preference helps choose our outbound path. A community that changes a provider’s local preference can influence that provider’s traffic toward us.

Can a four-octet ASN use standard communities?

Yes, through a suitable documented numbering scheme. The full four-octet ASN cannot fit in the conventional 16-bit administrator field of a standard community. Large communities provide three 32-bit fields.

Does NO_EXPORT stop every BGP advertisement?

No. NO_EXPORT restricts advertisement beyond the BGP confederation boundary, which is the AS boundary for a standalone AS. NO_ADVERTISE prevents advertisement to any BGP peer.

Can a community override an RPKI-invalid route?

Do not assume so. A provider may reject the route before the requested action matters. Correct the origin authorization or announcement problem and confirm the provider’s acceptance policy.

Does a regional community keep all traffic inside that region?

No. It controls the documented routing action within the provider’s scope. Other networks and physical links can take different paths. Regional advertisements do not establish data residency by themselves.

Can Atal Networks pass upstream communities unchanged?

Confirm that requirement for the proposed deployment. We need to establish the service, upstream policy, supported community types, and any filtering or translation before relying on pass-through behavior.

Technical References

1. RFC 1997: BGP Communities.
2. RFC 4360: BGP Extended Communities.
3. RFC 8092: BGP Large Communities.
4. RFC 4271: BGP-4.
5. Cloudflare: Communities and AS-path prepending.
6. NTT routing policies.
7. GTT community documentation.
8. RFC 8326: Graceful BGP Session Shutdown.
9. RFC 7999: BLACKHOLE Community.
10. RFC 7454: BGP Operations and Security.
11. RFC 6811: BGP Prefix Origin Checks.