How does a BGP provider use communities set on import so its export policy never sends peer-learned routes to an upstream?
answer
- tag at the edge you learned it
- optional transitive, crosses iBGP
- export only customer-tagged routes
- scrub your own namespace inbound
basics
~20 sEach eBGP session's import policy tags routes with a community recording the relationship they came from; export policy toward peers and upstreams permits only customer-tagged and own routes, and inbound scrubbing stops neighbours forging those tags.
solid answer
~40 sThe router that learns a route knows whether it came from a customer, a peer or an upstream; the router that exports it may not. So the **import** policy on every session adds a community from the AS's own namespace, such as `64500:100` for customer and `64500:200` for peer. `COMMUNITIES` is optional transitive, so the tag rides iBGP to every border router. The **export** policy toward peers and upstreams permits only routes tagged customer or own and denies the rest; toward customers it sends everything. Inbound, scrub any community in your own namespace a neighbour sent, as RFC 7454 recommends, or a peer could label its routes customer. Four-octet ASNs need large communities (RFC 8092), and RFC 9234's roles and OTC attribute enforce the same rule in-protocol.
go deeper
Recall that a community is a label attached to a BGP route that other routers' policies can match on.
Explain the tag-on-import, act-on-export pattern, the classic, extended and large formats, and the three RFC 1997 well-known communities.
Show the customer, peer and upstream export table, why inbound scrubbing is essential, and how action communities let customers request treatment.
Weigh relationship tagging against per-session prefix lists, and argue when to adopt RFC 9234 roles across a fleet that peers with non-compliant networks.
## The problem communities solve A provider, AS 64500, has three kinds of eBGP neighbour: **customers** who pay it, **peers** it exchanges traffic with for free, and **upstreams** it pays. Its export rule is the core of how it earns money and avoids carrying other people's traffic for free: | Route learned from | Export to customers | Export to peers | Export to upstreams | |---|---|---|---| | a customer | yes | yes | yes | | its own network | yes | yes | yes | | a peer | yes | **no** | **no** | | an upstream | yes | **no** | **no** | Sending a peer-learned route to an upstream offers the upstream a path through you that you are not paid to carry; that is a route leak, whose propagation and history belong with leak analysis. The question here is the tooling that makes the table above hold. ## Tag where the knowledge exists, act where the decision is made The router that learns a route knows which kind of session it came from. The router that exports it, possibly on the other side of the AS, does not. **Communities** carry that knowledge across: 1. **On import**, every session's policy adds a community from the AS's own namespace saying where the route was learned. For AS 64500 a convention might be `64500:100` for customer, `64500:200` for peer, `64500:300` for upstream. The values are local convention; nothing in an RFC assigns them. 2. Own prefixes get their own tag where they are originated. 3. **iBGP carries the tag** to every border router, because `COMMUNITIES` is an optional transitive attribute (RFC 1997, type code 8). 4. **On export to peers and upstreams**, the route map permits only routes carrying the customer or own tag and denies the rest. On export to customers it permits everything. The export rule now depends on a relationship, not on a list of prefixes that changes every time a customer is added. Many operators still keep a prefix list on top as a safety net. ## Scrubbing: do not trust a tag you did not set If a peer can attach `64500:100` to its routes, it can make them look customer-learned. RFC 7454 §11 says networks SHOULD scrub inbound communities "with their number in the high-order bits" and allow only those a customer or peer may use for signalling, while keeping other communities intact — in particular not removing `NO_EXPORT`. ## The formats - **Classic communities** (RFC 1997): a 32-bit value, conventionally an ASN in the first two octets and a local value in the last two. The ranges `0x00000000`–`0x0000FFFF` and `0xFFFF0000`–`0xFFFFFFFF` are reserved. - **Well-known communities** (RFC 1997): `NO_EXPORT` (`0xFFFFFF01`) must not be advertised outside the AS or confederation; `NO_ADVERTISE` (`0xFFFFFF02`) must not be advertised to any peer; `NO_EXPORT_SUBCONFED` (`0xFFFFFF03`) must not go to any external peer, including other member ASes of a confederation. - **Extended communities** (RFC 4360): 8-octet values with a type field, some transitive and some not. - **Large communities** (RFC 8092): 12-octet values — a four-octet Global Administrator and two four-octet local parts — because a four-octet ASN (RFC 6793) cannot fit the two-octet half of a classic community. An AS numbered 65540 tags with values like `65540:1:200`. ## Action communities for customers The same mechanism runs the other way. A provider publishes communities its **customers** may set to request treatment: do not announce this route to a given upstream, prepend it toward one, or set a lower `LOCAL_PREF` inside the provider. The customer tags, the provider's import policy matches the tag and acts. This is how a customer engineers traffic beyond its own edge without access to the provider's routers. ## Protocol help: roles and Only to Customer RFC 9234 adds what used to be pure convention. Each eBGP session declares a **BGP Role** — Provider, Customer, Peer, RS or RS-Client — confirmed through a capability in the OPEN message, and an **Only to Customer (OTC)** attribute (optional transitive, type code 35, four octets) is attached when a route is sent to a customer, peer or RS-client, or received from a provider, peer or RS. A route carrying OTC "MUST NOT be propagated to Providers, Peers, or RSes". Where both sides implement it, the protocol enforces the export table above even if a tagging policy is missing.
- Why not just put a prefix list of all customer prefixes on every upstream session?It works but scales badly: every customer added or changed means editing every upstream and peer session, and one missed edit either leaks or blackholes. Tagging on import makes the export decision depend on the relationship, so adding a customer touches only that customer's session. Many operators keep the prefix list as a second check rather than the only one.
- How do BGP Roles and the OTC attribute in RFC 9234 change this picture?They move the relationship into the protocol. Roles are declared and confirmed in the OPEN message, and the OTC attribute is added when a route is sent to a customer, peer or RS-client, or received from a provider, peer or RS. A route with OTC must not be propagated to providers, peers or route servers, so the rule holds even when a local tag is missing, and a leak can be detected hops away.
Airport baggage tags: the check-in desk, which knows where a bag is going, attaches a tag, and every sorter downstream routes by the tag without opening the bag. A sorter would never accept a tag written by the passenger, just as a BGP network scrubs its own communities arriving from neighbours.
saying these in an interview costs you the question
- Communities are non-transitive, so they vanish at the first iBGP hop.
- RFC 1997 assigns standard values meaning customer, peer and upstream.
- Accept every community a peer sends, including ones in your own namespace.
- NO_EXPORT means the route must not be advertised to any BGP peer.
- A four-octet ASN fits in the first half of a classic community.