Read four-octet values and reserved ranges
02Each community is a 32-bit value. For the non-reserved range, the first two octets identify an AS and the final two have AS-defined meaning.
FF FF FF 01 is NO_EXPORT. Its global rule differs from the local meaning of 64512:80; other reserved values do not inherit that rule.
Source for this drawing: RFC 1997 · Read RFC source: COMMUNITIES encoding and well-known values · 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.
The ordinary example 64512:80 encodes as FC 00 00 50 in network byte order: two octets for the AS, then two for the local value.
- The ordinary example 64512:80 encodes as FC 00 00 50 in network byte order: two octets for the AS, then two for the local value.
- RFC 1997 reserves 0x00000000–0x0000FFFF and 0xFFFF0000–0xFFFFFFFF. The rest uses the two-octet AS and two-octet local assignment.
- The well-known NO_EXPORT value is 0xFFFFFF01. Not every reserved value is well-known or assigned; 0:0 must not be inferred to be a formally registered well-known community.
- Two community values take eight attribute-value octets. Attribute headers and the enclosing UPDATE are separate. This classic layout does not hold a four-octet AS number in its two-octet AS part.
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 ↗