Find the export boundary
03A BGP confederation groups member ASes behind one external boundary. NO_EXPORT and NO_EXPORT_SUBCONFED stop advertisements at different boundaries. The illustrated peers understand and retain the communities.
A new comparison uses NO_EXPORT_SUBCONFED. Internal peers in the same member are not prohibited by this tag, but the advertisement to the other member AS stops. It is not the next phase of the NO_EXPORT route.
Source for this drawing: RFC 1997 · Read RFC source: Well-known Communities · p.3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
With NO_EXPORT (0xFFFFFF01), received tagged routes MUST NOT be advertised outside the BGP confederation. A stand-alone AS counts as its own confederation.
- For community-attribute-aware speakers, with NO_EXPORT (0xFFFFFF01), received tagged routes MUST NOT be advertised outside the BGP confederation. A stand-alone AS counts as its own confederation.
- NO_EXPORT_SUBCONFED (0xFFFFFF03) MUST NOT be advertised to external BGP peers, including peers in other member ASes of the same confederation.
- These restrictions do not require an advertisement inside the allowed scope. Reachability, other policy and other communities can still prevent it; all examples assume the well-known tag remains on the route.
Fictional routes and private AS numbers. These are bounded teaching examples, not a complete BGP implementation. Display a tag as AS:local only to help read its two 16-bit parts; the wire contains four octets.
Read the RFC section ↗