BGP community: Difference between revisions
imported>Howard C. Berkowitz No edit summary |
Pat Palmer (talk | contribs) m (Text replacement - "extranet" to "extranet") |
||
| Line 5: | Line 5: | ||
| date = August 1996 | | date = August 1996 | ||
| id = RFC1997 | | id = RFC1997 | ||
| url = http://www.ietf.org/rfc/rfc1997.txt}}</ref> There are both well-known communities that should be recognized by all BGP implementations, and various kinds of communities that are usually defined by an [[autonomous system]] <ref>There are communities, typically used in [[intranet]]s and | | url = http://www.ietf.org/rfc/rfc1997.txt}}</ref> There are both well-known communities that should be recognized by all BGP implementations, and various kinds of communities that are usually defined by an [[autonomous system]] <ref>There are communities, typically used in [[intranet]]s and extranets, where a prefix other than an autonomous system number is used to disambiguate</ref> | ||
To deal with Internet growth and the use of BGP in intranets and extranets (e.g., [[virtual private network]]s), various extended communities have been defined. <ref name=RFC4360>{{citation | To deal with Internet growth and the use of BGP in intranets and extranets (e.g., [[virtual private network]]s), various extended communities have been defined. <ref name=RFC4360>{{citation | ||
Revision as of 08:41, 22 June 2024
A BGP community is an attribute, attached to an announcement of a route to which the sender offers connectivity. Communities are most often identifiers for groups of routes/addresses to which some common policy applies. [1] There are both well-known communities that should be recognized by all BGP implementations, and various kinds of communities that are usually defined by an autonomous system [2]
To deal with Internet growth and the use of BGP in intranets and extranets (e.g., virtual private networks), various extended communities have been defined. [3] These primarily deal with internet operations issues, such as the scope of routing information distribution.
Basic structure of a community identifier
As first defined, a community is a 32-bit binary string, broken into two 16-bit fields. The first field's value is either all binary ones, indicating it is a "well-known" community, or contains the value of the autonomous system that defines the meaning of the second field.
By convention, a community is written:
ASN or 65535:specific meaningMany router implementations will allow the ASN field to be displayed in decimal rather than hexadecimal, corresponding to general practice in BGP routing.
Well-known communities
A BGP implementation supporting communities MUST understand the following well-known communities
| Name | Meaning | Value |
|---|---|---|
| NO-EXPORT | Do not advertise this route outside the current autonomous system | FFFF:1 |
| NO-ADVERTISE | Do not advertise this route to any other BGP router, even inside the same AS. | FFFF:2 |
| NO_EXPORT_SUBCONFED | All routes received carrying a communities attribute containing this value MUST NOT be advertised outside a BGP confederation boundary (a stand-alone autonomous system that is not part of a confederation should be considered a confederation itself). | FFFF:3 |
Since the ASNs from decimal 64512 through 65535 are reserved, these effectively are NO-EXPORT onto the Internet.
References
- ↑ Chandra R., Traina P., Li T. (August 1996), BGP Communities Attribute, RFC1997
- ↑ There are communities, typically used in intranets and extranets, where a prefix other than an autonomous system number is used to disambiguate
- ↑ Tappan D., Rekhter Y., Sangli I. (February 2006), BGP Extended Communities Attribute, RFC4360