Network & Infrastructure / BGP Policy & Internet Edge
BGP community contracts across provider boundaries
An enterprise tags a route with an internal community that it expects a transit provider to interpret. The provider ignores it or strips it at a boundary, leaving traffic unchanged.
Environment and inputs: BGP speakers and route reflectors; policy syntax, RPKI integration and address-family behavior depend on the implementation. Diagnostic/design example; not tested on production equipment.
Collect the evidence
Capture community values on advertised routes, the provider's current documented meanings and downstream observations. Check standard, extended and large-community support separately where applicable.
Explain the result
A community is metadata whose effect comes from policy. Its presence alone does not request a universally standardized action, except for specifically defined well-known meanings.
Plan the fix
Translate internal routing intent into the provider's supported community contract and limit who can attach privileged tags. Document stripping and preservation behavior at every administrative boundary.
Check the result and rollback
Confirm the provider's applied policy through an approved observation point and compare a control prefix. Revert if tags escape unintended peers or affect a larger route set than the change requires.