This document is not restricted to specific software and hardware versions. However, the information in this document is based on these software and hardware versions:

Cisco IOS® Software Release 12.2(27)

Cisco 2500 Series Routers

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

While communities themselves do not alter the BGP decision making process, communities can be used as flags in order to mark a set of routes. Upstream service provider routers can then use these flags to apply specific routing polices (for example, local preference) within their network.

Providers establish a mapping between customer configurable community values and the corresponding local preference values within the provider network. The idea is that customers with specific policies that require the modification of LOCAL_PREF in the provider network set the corresponding community values in their routing updates.

A community is a group of prefixes that share some common property and can be configured with the BGP community attribute. The BGP Community attribute is an optional transitive attribute of variable length. The attribute consists of a set of four octet values that specify a community. The community attribute values are encoded with an Autonomous System (AS) number in the first two octets, with the remaining two octets defined by the AS. A prefix can have more than one community attribute. A BGP speaker that sees multiple community attributes in a prefix can act based on one, some or all the attributes. A router has the option to add or modify a community attribute before the router passes the attribute on to other peers. In order to learn more about the community attribute, refer to BGP Case Studies.

The local preference attribute is an indication to the AS which path is preferred in order to reach a certain network. When there are multiple paths to the same destination, the path with the higher preference is preferred (the default value of the local preference attribute is 100). For more information, refer to Local Preference Attribute.

For simplification, this mapping of the community attribute and local preference attribute is assumed to be established between the upstream service provider (AS 100) and the customer (AS 30).

Local Preference

Community Values

130

100:300

125

100:250

If the customer announces the prefixes with a community attribute equal to 100:300, then the upstream service provider sets the local preference of those routes to 130 and 125 if the community attribute equals 100:250.

This gives you the potential to control the routing policy within the service provider network if you change the community values of the prefixes announced to the service provider.

In the network diagram, customer AS 30 wishes to achieve this routing policy with the community attributes.

The traffic inbound from AS 100 destined to network 6.6.6.0/24 comes through the R1-R3 link. In case the R1-R3 link fails, all traffic comes in through R2-R3.

The traffic inbound from AS 100 destined to network 7.7.7.0/24 comes through the R2-R3 link. In case the R2-R3 link fails, all traffic comes in through R1-R3.

In order to achieve this routing policy, R3 announces its prefixes as follows:

To R1:

6.6.6.0/24 with a community attribute 100:300

7.7.7.0/24 with a community attribute 100:250

To R2:

6.6.6.0/24 with a community attribute 100:250

7.7.7.0/24 with a community attribute 100:300

Once BGP neighbors R1 and R2 receive the prefixes from R3, R1 and R2 apply the preconfigured policy based on mapping between the community and local preference attributes (shown in this table), and thus achieve the routing policy dictated by customer (AS 30). R1 installs the prefixes in the BGP table.

6.6.6.0/24 with a local preference of 130

7.7.7.0/24 with a local preference of 125

R2 installs the prefix in its BGP table:

6.6.6.0/24 with a local preference of 125

7.7.7.0/24 with a local preference of 130

Since a higher local preference is preferred in the BGP path selection criteria, the path with a local preference of 130 (130 is greater than 125) is selected as the best path within AS 100, and is installed in the IP routing table of R1 and R2. For more information on BGP path selection criteria, refer to BGP Best Path Selection Algorithm.

R1 receives prefixes 6.6.6.0/24 and 7.7.7.0/24 with communities 100:300 and 100:250, as shown in bold in the show ip bgp output of this section.

Note: Once these routes are installed into the BGP table based on the configured policy, prefixes with community 100:300 are assigned local preference 130 and prefixes with community 100:250 are assigned local preference 125.

The show ip bgp command on R1 confirms that the best path selected on R1 are with local preference(LoclPrf) = 130.

Similarily, R2 receives prefixes 6.6.6.0/24 and 7.7.7.0/24 with communities 100:250 and 100:300, as shown in bold in the show ip bgp command output of this section.

Note: Once these routes are installed into the BGP table, based on the configured policy, prefixes with community 100:300 are assigned local preference 130 and prefixes with community 100:250 are assigned local preference 125.

This show command output shows that the route to prefixes 6.6.6.0/24 and 7.7.7.0/24 points to the next hop 10.10.12.2, (R2), which is expected. Now take a look at the IP routing table on R2to check next-hop of prefix 6.6.6.0/24 and 7.7.7.0/24. The next hop must be R3 for the configured policy in order to work successfully.