RFC 1998 INFORMATIONAL BGP · ROUTING · POLICY
BGP Communities Usage: An Application of the BGP Community Attribute in Multi-home Routing
Using BGP community attributes to manage routing policy in multihomed networks.
RFC EDITOR
Chen, E. and T. Bates, "An Application of the BGP Community Attribute in Multi-home Routing", RFC 1998, DOI 10.17487/RFC1998, August 1996, <https://www.rfc-editor.org/info/rfc1998>.
BIBTEX
@misc{rfc1998,
series = {Request for Comments},
number = 1998,
howpublished = {RFC 1998},
publisher = {RFC Editor},
doi = {10.17487/RFC1998},
url = {https://www.rfc-editor.org/info/rfc1998},
author = {E. Chen and T. Bates},
title = {{An Application of the BGP Community Attribute in Multi-home Routing}},
pagetotal = 9,
year = 1996,
month = aug,
} RFC text
Contents
Network Working Group E. Chen
Request for Comments: 1998 MCI
Category: Informational T. Bates
cisco Systems
August 1996
An Application of the BGP Community Attribute
in Multi-home Routing
Status of This Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document presents an application of the BGP community attribute
[2] in simplifying the implementation and configuration of routing
policies in the multi-provider Internet. It shows how the community
based configuration can be used to replace the AS-based customization
of the BGP "LOCAL_PREF" attribute, a common method used today. Not
only does the technique presented simplifies configuration and
management at the provider level, it also represents a paradigm shift
in that it gives the potential for the customer to control its own
routing policy with respect to its service provider, as well as
providing the ability for policy configuration to be done at a prefix
based granularity rather than the more common AS based granularity.
1. Introduction
In the multi-provider Internet, it is common for a service subscriber
(i.e., customer) to have more than one service provider, or to have
arrangements for redundant connectivity to the global connected
Internet. As discussed in [3], routing strategies in these cases
usually require coordination between the service subscriber and its
providers, which typically leads to customization of router
configurations (e.g., BGP "LOCAL_PREF") not only by the subscriber,
but also by its providers. Due to the large number of customers a
provider serves, customization of router configurations at the
provider level may present management and scalability problems.
This document presents an application of the BGP community attribute
in simplifying the implementation of routing strategies in the
multi-provider Internet. More specifically, the technique presented
uses a community-based, rather than the common AS-based,
configuration of the BGP "LOCAL_PREF". It essentially removes the
need for customized configuration of the BGP "LOCAL_PREF" attribute
at the provider level while maintaining the same level of routing
functionality and flexibility.
It also represents a paradigm shift in that it gives the potential
for the customer to control its own routing policy with respect to
its service provider, as well as providing the ability for policy
configuration to be done at a prefix based granularity rather than
the more common AS based granularity in use today.
2. AS-based Configuration and its Drawbacks
As discussed in [3], in today's multi-provider Internet, customized
configuration of the BGP "LOCAL_PREF" attribute is often required to
implement common routing strategies such as load-sharing or backup.
There are two main reasons:
o Lack of available implementations and deployment of routing
software that supports the "Destination Preference Attribute"
(DPA) as specified in [4].
DPA allows one to specify a globally transitive preference so
that return traffic favors certain path. As discussed in [3],
the attribute will be very useful in influencing route selection
for routes with identical "LOCAL_PREF" and equal AS-path length.
o In the multi-provider Internet, it is common for a provider
to assign higher BGP "LOCAL_PREF" values for routes from its
customers than from other service providers. This practice
provides some degree of protection for its customer routes,
and it facilitates implementation of certain routing
strategies. It, however, also complicates other routing
implementations such as backup arrangement, thus, requiring
customized "LOCAL_PREF" configuration.
Figure 1 shows a typical case of a backup arrangement in the multi-
provider Internet. In Figure 1, AS1 and AS2 are both providers, and
AS3 and AS4 are customers of AS1 and AS2, respectively. AS3 has
entered a bilateral agreement with AS4 to provide backup to each
other. That is, AS3 would use its direct link to AS4 to reach only
AS4 in the normal circumstance, and for transit in the case of a
failure between AS3 and AS1. To realize this routing agreement, AS3
requests that its provider AS1 adjust its BGP "LOCAL_PREF"
configuration so that AS1 reaches AS4 via AS2.
+------+ +------+
| AS1 |------| AS2 |
+------+ +------+
| |
+------+ +------+
| AS3 |------| AS4 |
+------+ +------+
Figure 1: Typical Backup Scenario
Primarily due to scalability and management concerns, most providers
only perform "LOCAL_PREF" customization based on ASs, not on IP
prefixes. If IP prefix-based "LOCAL_PREF" configuration is needed, a
technique known as as the BGP AS-path manipulation can be used.
However, it is currently only available in certain vendor's products.
There are several drawbacks with the the practice of AS-based BGP
"LOCAL_PREF" configuration at the provider level:
o The implementation tends to less efficient due to the process
of coordination and configuration. More importantly, the
process needs to be repeated each time a change (e.g., adding
a new AS) occurs.
o The AS-based customization complicates router configuration
and increases complexity of network operation. It has become
a serious scalability issue for providers.
o It can not implement prefix-based configuration without the
AS-path manipulation (i.e., using fake AS).
o Keeping configuration up-to-date is some times problematic.
3. How the BGP Community Attribute Can Help
3.1 Overview of the Community Attribute
The BGP community path attribute is an optional transitive attribute
of variable length [1,2]. The attribute consists of a set of four
octet values, each of which specify a community. The community
attribute values are encoded using an AS number in the first two
octets, with the remaining two octets defined by the AS. As defined
in [2], a community is a group of destinations (i.e. prefixes) that
share some common attribute. Each destination can belong to multiple
communities. All prefixes with the community attribute belong to the
communities listed in the attribute.
The BGP community allows one to group a set of prefixes and perform
routing decisions based on the identity of the group.
The well-known communities NO_EXPORT (0xFFFFFF01) and NO_ADVERTISE
(0xFFFFFF02) are intuitive, and can be used for optimizing routing
and for improving route aggregation.
3.2 Community-based Configuration
With the BGP community attribute [2], a provider can now use
community-based, rather than AS-based, configuration of BGP
"LOCAL_PREF". The provider first needs to coordinate with its
customers a set of communities to be mapped to certain BGP
"LOCAL_PREF" values. The provider can then apply a uniform BGP
configuration to all its customers that would capture routes with the
community values, and set up the appropriate BGP "LOCAL_PREF" values
accordingly. A customer that requires customization in its provider
BGP "LOCAL_PREF" configuration can simply send the appropriate
community values in its routing announcements.
The major advantages of using this technique include:
o The customer has full control in the process, which makes a
lot of sense as the customer is in a position to have better
understanding about its own topology and routing policy
requirement.
o The effect of route-based customization in BGP "LOCAL_PREF"
configuration by providers can now be achieved, thus, removing
the need of AS-Path manipulation in certain cases.
o It addresses the scalability issue facing providers as it
distributes the configuration work to the customer that
requires customization.
4. A Real-World Implementation Example
MCI currently makes heavy use of the BGP "LOCAL_PREF" attribute value
as part of its routing policy configuration process. Different BGP
"LOCAL_PREF" values are assigned for routes from different sources.
Table 1 details these values:
+-------------------------+------------+
| Category | LOCAL_PREF |
+-------------------------+------------+
|Customer Routes | 100 |
|Customer backup Routes | 90 |
|Other ISP Routes | 80 |
|Customer-Provided backup | 70 |
+-------------------------+------------+
Table 1: Defined LOCAL_PREF Values
Note:
o The value '100' is the default value used within our network
configuration.
o In most cases, the MED attribute set by a customer is
sufficient for customer backup routes (e.g., T1 backs up T3).
However, in certain cases configuration of "LOCAL_PREF" will
still be necessary until the BGP DPA attribute is available.
To make use of the BGP community attribute, several community values
(MCI's AS number: 3561 = 0x0DE9) have been defined that can be used
by customers to tag routes so that the appropriate "LOCAL_PREF"
values are configured. Table 2 lists the appropriate community
attribute values (and the mappings of community to LOCAL_PREF):
+---------------------+------------+
| community | LOCAL_PREF |
+---------------------+------------+
|3561:70 (0x0DE90046) | 70 |
|3561:80 (0x0DE90050) | 80 |
|3561:90 (0x0DE9005A) | 90 |
+---------------------+------------+
Table 2: Community to LOCAL_PREF Mapping
A customer requiring MCI to configure BGP "LOCAL_PREF" values other
than the default can tag their routes with the defined communities.
The community values can be configured either based on an AS path
list or an IP address access list. A cisco systems software specific
configuration example is given in Appendix A to show how this can be
achieved.
A uniform BGP configuration (see Appendix B, again cisco systems
software specific) is applied by MCI to peers with customers that
configure the appropriate "LOCAL_PREF" values based on the
communities received.
This technique has been tested and is in use with several customers,
and the response has been very positive. We are in the process of
migrating all other customized BGP "LOCAL_PREF" configurations to
this uniform community based configuration approach.
5. References
[1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[2] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996.
[3] Chen, E., and T. Bates, "Current Practice of Implementing
Symmetric Routing and Load Sharing in the Multi-Provider
Internet", Work in Progress.
[4] Chen, E., and T. Bates, "Destination Preference Attribute for
BGP", Work in Progress.
[5] Chen, E., and T. Bates, "Application of the BGP Destination
Preference Attribute in Implementing Symmetric Routing",
Work in Progress.
[6] cisco systems, cisco IOS Software Version 10.3 Router Products
Configuration Guide (Addendum), May 1995.
6. Security Considerations
Security issues are not discussed in this memo.
7. Acknowledgments
The authors would specifically like to thank Ravi Chandra, Tony Li
and Paul Traina of cisco systems for devising and implementing the
community attribute.
8. Authors' Addresses
Enke Chen
MCI
2100 Reston Parkway
Reston, VA 22091
Phone: +1 703 715 7087
EMail: enke@mci.net
Tony Bates
cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: +1 408 527 2470
EMail: tbates@cisco.com
Appendix
These appendices list cisco systems software specific configuration
examples for configuring communities, and for uniform route-map
definition that sets up the appropriate "LOCAL_PREF" values based on
the corresponding community values. These examples are given purely
to show a working example of how the desired effect discussed in this
document can be achieved. Please refer to [6] for more specific
information on cisco configuration and syntax.
Appendix A. Community Configuration
The community values can be configured either based upon an AS path
list or based an IP address access list. Here is an example that
includes both cases:
!!
router bgp xxxx
neighbor x.x.x.x remote-as 3561
neighbor x.x.x.x filter-list 20 out
neighbor x.x.x.x route-map config-community out
neighbor x.x.x.x send-community
!
!!# match all
ip as-path access-list 1 permit .*
!
!!# list of customer ASs
ip as-path access-list 20 permit ^$
ip as-path access-list 20 permit ^64700_
ip as-path access-list 20 deny .*
!
!!# AS path based matching, backup for another ISPs customer
ip as-path access-list 40 permit _64710_
ip as-path access-list 40 permit _64711_
ip as-path access-list 40 deny .*
!
!!# route-map
route-map config-community permit 10
match as-path 40
set community 0x0DE90046
route-map config-community permit 20
match as-path 1
!
Note: The community can also be configured based on IP prefixes
instead of AS numbers. For example,
!
access-list 101 permit ip 192.160.154.0 0.0.0.0 255.255.255.0 0.0.0.0
!
route-map config-community permit 10
match ip address 101
set community 0x0DE90046
route-map config-community permit 20
match as-path 1
!
Appendix B. Uniform Route-map Configuration
Here is the uniform route-map that can be used for all BGP
customers:
!!# routes primary via another ISP
ip community-list 70 permit 0x0DE90046
ip community-list 70 deny
!
!!# routes also homed to another ISP, but with DPA or
!!# AS-path length as the tie-breaker
ip community-list 80 permit 0x0DE90050
ip community-list 80 deny
!
!!# customer backup routes
ip community-list 90 permit 0x0DE9005A
ip community-list 90 deny
!
!!# the route-map applied to BGP customers
route-map set-customer-local-pref permit 10
match community 70
set local-preference 70
route-map set-customer-local-pref permit 20
match community 80
set local-preference 80
route-map set-customer-local-pref permit 30
match community 90
set local-preference 90
route-map set-customer-local-pref permit 40
match as-path 1
set local-preference 100
!
AI ELI5
On this page
PROBLEMIn multihomed networks where customers connect to multiple providers, providers need to customize BGP routing policies for each customer. Configuring this on a per-AS basis creates scalability and management problems.
MECHANISMInstead of having providers customize LOCAL_PREF values for each customer AS, customers can tag their route announcements with community values. Providers apply uniform community-to-LOCAL_PREF mappings, letting customers control their own routing policy without requiring provider customization.
PRACTICAL POLICY SIMPLIFICATIONCommunity-based configuration is easier to manage and scale, lets customers control their routing directly, and enables per-prefix granularity instead of just per-AS. MCI demonstrated successful deployment with positive customer response.
§1Introduction and Problem Statement
In the multihomed Internet, it is common for customers to have connections to multiple service providers or redundant paths for reliability. Achieving desired routing policies requires coordination between customers and providers, typically resulting in customized BGP LOCAL_PREF configuration at the provider routers.
When many customers require customization, this becomes a scalability and management burden for providers. Customization is often done on a per-AS basis for efficiency, but this prevents prefix-level policy granularity. RFC 1998 shows how the BGP community attribute can simplify this by shifting the responsibility for policy configuration from the provider to the customer.
Large ISPs struggle when each customer wants their traffic routed differently. Communities let customers handle their own preferences without the ISP having to change everything.
§2The BGP Community Attribute
The BGP community path attribute is an optional transitive attribute consisting of four-octet values, each specifying a community. Community values are encoded using an AS number in the first two octets with the remaining two octets defined by that AS. A community is a group of destination prefixes that share some common attribute. Each prefix can belong to multiple communities.
Well-known communities like NO_EXPORT (0xFFFFFF01) and NO_ADVERTISE (0xFFFFFF02) have predefined meanings. The community attribute allows routers to group prefixes and make routing decisions based on community membership, providing a flexible mechanism for expressing routing policy.
A community is a tag you attach to routes: it is a number that encodes an AS number plus a policy code. Routers can then look for routes with specific tags and handle them accordingly.
§3Community-Based Configuration Approach
With community-based configuration, a provider first coordinates with its customers to establish a mapping between community values and BGP LOCAL_PREF values. The provider applies a uniform BGP configuration to all customers that matches routes by community values and sets LOCAL_PREF accordingly.
Customers requiring customized LOCAL_PREF configuration simply tag their route announcements with the appropriate community values. This can be done based on AS paths or IP address access lists. The major advantages include customer control over their own routing policy, ability to achieve per-prefix customization (without AS-path manipulation), addressing provider scalability by distributing configuration work to customers who need customization, and simpler provider configuration.
The provider says: if you tag routes with community 3561:70, I'll set LOCAL_PREF to 70. Customers tag their routes, and the provider's uniform configuration does the rest.
Customer ASProvider (ISP)
- Route with community 3561:90Customer tags backup route with community value
- Apply LOCAL_PREF 90Provider's uniform config matches community and sets preference
| Approach | Configuration at | Granularity | Provider scalability | Customer control |
|---|---|---|---|---|
| AS-based (old) | Provider routers | Per-AS | Poor (per-customer config needed) | Limited (need provider coordination) |
| Community-based (new) THIS RFC | Customer routers | Per-prefix | Good (uniform provider config) | Full (customer chooses communities) |
§4Real-World Implementation at MCI
MCI implemented this technique with several community-to-LOCAL_PREF mappings: community 3561:70 (0x0DE90046) maps to LOCAL_PREF 70 (primary via another ISP), 3561:80 (0x0DE90050) maps to LOCAL_PREF 80 (dual-homed), and 3561:90 (0x0DE9005A) maps to LOCAL_PREF 90 (customer backup routes). The default LOCAL_PREF of 100 is applied to untagged customer routes.
Customers can configure community tagging based on either AS path lists or IP address access lists, enabling them to apply different policies to different portions of their network. MCI applies a uniform route-map to all customers, creating a highly scalable approach. The technique was tested in production with positive customer response and MCI has been migrating existing AS-based customizations to this community-based approach.
MCI says: use community 3561:90 for backup routes, 3561:80 for dual-homed routes, 3561:70 for using another ISP first. Each customer picks which communities to use on their own routes.
§5References
[1]RFC 1771Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.March 1995[2]RFC 1997Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.August 1996
[3]Chen, E., and T. Bates, "Current Practice of Implementing Symmetric Routing and Load Sharing in the Multi-Provider Internet", Work in Progress.
[4]Chen, E., and T. Bates, "Destination Preference Attribute for BGP", Work in Progress.
[5]Chen, E., and T. Bates, "Application of the BGP Destination Preference Attribute in Implementing Symmetric Routing", Work in Progress.