BGP Communities

The BGP COMMUNITY PA provides a mechanism by which to group routes so that routing policies can be applied to all the routes with the same community. By marking a set of routes with the same COMMUNITY string, routers can look for the COMMUNITY string and then make policy decisions—like setting some PA that impacts the BGP decision process, or simply filtering the routes. BGP communities are powerful in that they allow routers in one AS to communicate policy information to routers that are one or more autonomous systems distant. In fact, because the COMMUNITY PA is an optional transitive PA, it can pass through autonomous systems that do not even understand the COMMUNITY PA, and then still be useful at another downstream AS.

Figure 13-12 shows an example of one way in which communities can be used. The goal with this design is to have the engineers in ASNs 4 and 5 work together to decide which of them has the best route to reach each prefix, and then somehow tell the routers in ASN 123. That may sound familiar—that is exactly the motivation behind using MED, as shown in Figure 13-11. However, MED is relatively far into the BGP decision process, even after shortest AS_PATH. A better design might be to set the COMMUNITY PA, and then let the routers in ASN 123 react to the COMMUNITY string and set LOCAL_PREF based on that value, because LOCAL_PREF is considered early in the BGP decision process.

Figure 13-12 Using COMMUNITY to Augment Routing Policies

Figure 13-12 Using COMMUNITY to Augment Routing Policies

Bgp Local Pref
^ Best Route ->- BGP Update ----BGP Peer

Figure 13-12 depicts the following steps:

1. The engineers at AS 4 and AS 5 agree as to which prefixes are best reached by each AS.

2. They then configure outbound route maps on their respective neighbor connections to AS 123, setting COMMUNITY to 1 for routes for which they are the best path, and setting COMMUNITY to 2 for some other routes.

3. R1 and R3 receive the Updates, match the NLRI based on the COMMUNITY, and set LOCAL_PREF to a large value for routes whose COMMUNITY was set to 1.

4. The LOCAL_PREF settings impact the BGP choice for the best routes.

This design includes several advantages over some of the options covered earlier in the chapter. It includes the best aspects of using LOCAL_PREF, helping AS 123 decide which neighboring AS to use to reach each prefix. However, it puts the choice of which routes should be reached through AS 4 and AS 5 into the hands of the folks running AS 4 and AS 5. If the AS 4 or AS 5 topology changes, link speeds increase, or other changes occur, the route maps that set the COMMUNITY in AS 4 and AS 5 can be changed accordingly. No changes would be required inside AS 123, because it already simply looks at the COMMUNITY string. Assuming that AS 123 is an enterprise, and AS 4 and AS 5 are ISPs, the ISPs can make one set of changes and impact the routing choices of countless customers.

Example 13-11 shows the configuration matching the scenario of Figure 13-12. The configuration follows mostly familiar commands and reasoning, with two additional features:

■ R4 and R5 (AS 4 and AS 5) must use the neighbor send-community BGP subcommand, which tells BGP to include the COMMUNITY PA in the Update. Without that command, the Update does not even include the COMMUNITY PA.

■ R1 and R3 (AS 123) need to match NLRI based on the received COMMUNITY values, so they must configure community lists that match the COMMUNITY, by using the ip community-list command.

Example 13-11 Setting COMMUNITY, and Reacting to COMMUNITY to Set LOCALPREF

! R4 must add the neighbor send-community command, otherwise it will not include ! the COMMUNITY PA in Updates sent to R3. The route-map matches 11/8, and sets ! COMMUNITY to 1, and matches 21/8 and sets COMMUNITY to 2. router bgp 4 neighbor 10.1.34.3 send-community both neighbor 10.1.34.3 route-map comm out

ip prefix-list 11 seq 5 permit 11.0.0.0/8 ip prefix-list 21 seq 5 permit 21.0.0.0/8 !

route-map comm permit 10 match ip address prefix-list 11 set community 1

Example 13-11 Setting COMMUNITY, and Reacting to COMMUNITY to Set LOCALPREF (Continued)

route-map comm permit 20 match ip address prefix-list 21 set community 2

route-map comm permit 30

! R5 has essentially the same configuration, except that R5 sets COMMUNITY to 1

! for 21/8 and

to

2 for 11/8 — the opposite of R4.

router bgp 5

neighbor 10.1

15

1 send-community

neighbor 10.1

!

15

1 route-map comm out

ip prefix-list

11

seq 5 permit 11.0.0.0/8

ip prefix-list

!

21

seq 5 permit 21.0.0.0/8

route-map comm

permit 10

match ip address

prefix-list 11

set community 2

1

route-map comm permit 20

match ip address

prefix-list 21

set community

!

1

route-map comm

permit 30

! R3 Config: Next, R3 matches on the received COMMUNITY strings and sets ! LOCAL_PREF using a route-map called react-to-comm. The only way to match the ! COMMUNITY is to refer to an ip community-list, which then has the matching ! parameters, router bgp 123 neighbor 10.1.34.4 route-map react-to-comm in

ip community-list 1 permit 1

ip community-list 2 permit 2

route-map react-to-comm permit 10 match community 1 set local-preference 300

route-map react-to-comm permit 20 match community 2 set local-preference 200

route-map react-to-comm permit 30

! Not shown — R1 Config. R1s config matches R3's in every way, except for the ! fact that the inbound route-map is applied for the neighbor command pointing ! to R5 (10.1.15.5).

! R3 chooses its best path to 11/8 with NEXT_HOP of R4 (10.1.34.4), as a result ! of R3's assignment of LOCAL_PREF 300, which in turn was a result of the Update

Example 13-11 Setting COMMUNITY, and Reacting to COMMUNITY to Set LOCALPREF (Continued)

! from R4 listing 11/8 as COMMUNITY 1. R3's best route to 12/8 points to NEXT_HOP ! R5 (10.1.15.1), which happens to point back through R1, because R1 received an ! Update from R5 for 21/8 listing COMMUNITY 1, and then set LOCAL_PREF to 300. R3# show ip bgp | begin Network

Network Next Hop Metric LocPrf Weight Path

*> 11.0.0.0

10.1

34

4

4294967294

300

0

4

1

33333

10

200 44

i

* i12.0.0.0

10.1

15

5

4294967294

100

0

5

1

33333

10

200 44

i

*>

10.1

34

4

4294967294

0

4

1

33333

10

200 44

i

*>i21.0.0.0

10.1

15

5

4294967294

300

0

5

1

404 303

202 i

*

10.1

34

4

4294967294

200

0

4

1

404 303

202 i

! R3 now lists its BGP table entries that have COMMUNITY settings that include ! 1 or 2. Note that both commands only list the routes learned directly from R4. ! If R1 had configured a neighbor 3.3.3.3 send-community command, R3 would have ! additional entries using COMMUNITY strings 1 and 2. However, for this design, ! the COMMUNITY strings do not need to be advertised to iBGP peers inside AS 123, ! as R1 and R3 have already reacted to the communities to set the LOCAL_PREF. R3# show ip bgp community 1

BGP table version is 37, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i — internal, r RIB-failure, S Stale Origin codes: i — IGP, e — EGP, ? — incomplete

Network Next Hop Metric LocPrf Weight Path

*> 11.0.0.0 10.1.34.4 4294967294 300 0 4 1 33333 10 200 44

R3# show ip bgp community 2 | begin Network

Network Next Hop Metric LocPrf Weight Path

* 21.0.0.0 10.1.34.4 4294967294 200 0 4 1 404 303 202 i

The COMMUNITY can be seen with the show ip bgp prefix command, as seen below. Note that the route learned from R1 (1.1.1.1) does not list a COMMUNITY, as R1

_did not configure a neighbor 3.3.3.3 send-community command.

BGP routing table entry for 21.0.0.0/8, version 35

Paths: (3 available, best #1, table Default-IP-Routing-Table)

Multipath: eBGP

Advertised to update-groups: 2

Origin IGP, metric 4294967294, localpref 300, valid, internal, best 4 1 404 303 202

Origin IGP, metric 4294967294, localpref 200, valid, external Community: 2 4 1 404 303 202, (received-only) 10.1.34.4 from 10.1.34.4 (4.4.4.4)

Origin IGP, metric 4294967294, localpref 100, valid, external Community: 2

Matching COMMUNITY with Community Lists

Cisco originally created communities as a proprietary feature, treating the 32-bit COMMUNITY as a decimal value (as shown in Example 13-11). When the COMMUNITY PA was added to the BGP standard RFC 1997, the 32-bit COMMUNITY was formatted as AA:NN, where AA is a 16bit number to potentially represent an ASN, and NN represents a value as set by that ASN. However, the COMMUNITY PA remained a 32-bit number.

Cisco routers can use either the original format or the RFC 1997 format for the COMMUNITY PA. By default, show commands list the decimal value; to use the AA:NN format, you should configure the global command ip bgp-community new-format. Also, the set command, as used with route maps, can use either the old decimal format or the newer AA:NN format; however, the absence or presence of the ip bgp-community new-format command dictates whether the output of a show route-map command lists the values as decimal or as AA:NN, respectively. For this reason, in practice it makes sense to choose and use a single format, typically the newer format today.

The COMMUNITY PA also supports multiple entries. For example, the set community 10 20 30 command, applied within a route map, would actually create a COMMUNITY with all three values. In that case, any existing COMMUNITY value would be replaced with 10, 20, and 30. However, the set community 10 20 30 additive command would add the values to the existing COMMUNITY string.

As a result of the multi-entry COMMUNITY, and as a result of the literal ":" inside the COMMUNITY string when using the new format, Cisco IOS requires some more sophisticated matching capabilities as compared with IP ACLs. For example, community lists can list multiple values on the same ip community-list command; to match such a command, the COMMUNITY must include all the values. (The COMMUNITY values are unordered, so the order in which the values are listed in the community list does not matter.) Also, extended community lists (numbered 100-199) allow matching of the COMMUNITY PA with regular expressions. Table 13-15 summarizes some of the key points related to community lists.

Table 13-15 Comparing Standard and Extended Community List

KEY POINT

Table 13-15 Comparing Standard and Extended Community List

Feature

Standard

Extended

List numbers

1-99

100-99

Can match multiple communities in a single command?

Yes

Yes

Can match the COMMUNITY PA with regular expressions

No

Yes

More than 16 lines in a single list?

No

Yes

Example 13-12 shows a few example community lists just to show the logic. In the example, R4 has set multiple COMMUNITY values for prefixes 11/8 and 12/8. The show ip bgp community-list list-number command is then used to show whether a match would be made. This command lists the entries of the BGP table that match the associated COMMUNITY PA, much like the show ip bgp regex command examines the AS_PATH PA.

Example 13-12 Example of Matching with IP Community Lists

R3# show ip community-list

Community standard list 2

permit 0:1234

Community standard list 3

permit 0:1212 8:9

Community (expanded) access list 111

permit 0:12.*

11/8's COMMUNITY string is listed next, followed by 12/8's COMMUNITY

string.

R3# show ip bgp 11.0.0.0 | include Community

Community: 0:1212 0:1234 8:9 8:12 12:9 12:13

R3# show ip bgp 12.0.0.0 | include Community

Community: 0:1212 8:12 8:13

List 2 should match only 11/8, and not 12/8, as only 11/8 has 0:1234

as one of

the values.

R3# show ip bgp community-list 2 | begin Network

Network Next Hop Metric LocPrf Weight Path

*> 11.0.0.0 10.1.34.4 4294967294 0 4 1 33333

10 200 44 i

Both 11/8 and 12/8 match the 0:1212 listed in list 3, but list 3 has

two

values configured. The list uses a logical AND between the entries, and only

11/8 has matching values for both communities.

R3# show ip bgp community-list 3 | begin Network

Network Next Hop Metric LocPrf Weight Path

*> 11.0.0.0 10.1.34.4 4294967294 0 4 1 33333

10 200 44 i

List 111 matches any COMMUNITY string with one entry beginning with

:12,

followed by any additional characters. 11/8 matches due to the 0:1234, and 12/8

matches due to the 0:1212. COMMUNITY values 0:12, 0:123, and other would also

have matched.

R3# show ip bgp community-list 111 | begin Network

Network Next Hop Metric LocPrf Weight Path

*> 11.0.0.0 10.1.34.4 4294967294 0 4 1 33333

10 200 44 i

*> 12.0.0.0 10.1.34.4 4294967294 0 4 1 33333

10 200 44 i

Removing COMMUNITY Values

In some cases, a routing policy may need to remove one string from the COMMUNITY PA, or even delete the entire COMMUNITY PA. This can be accomplished with a route map as well, using the set command. Removing the entire COMMUNITY is relatively simple: include the set community none command in a route-map clause, and all routes matched by that clause will have their COMMUNITY PA removed. For example, Example 13-11 lists a route-map react-to-comm route map on each router. In that design, once the received COMMUNITY string on R1 and R3 was used to match the correct routes and set the LOCAL_PREF values, the COMMUNITY

PA was no longer needed. The revised route map in Example 13-13 simply removes the COMMUNITY at that point.

Example 13-13 Removing the Entire COMMUNITY PA Once It Is No Longer Needed

route-map react-to-comm permit

10

match community 1

set local-preference 300

!

route-map react-to-comm permit

20

match community 2

set local-preference 200

!

route-map react-to-comm permit

30

A route map can also remove individual COMMUNITY strings by using the set comm-list community-list-number delete command. This command tells the route map to match routes based on the community list, and then delete the COMMUNITY strings listed in the community list. (The referenced community list can contain only one COMMUNITY string per ip communitylist command in this case.)

Filtering NLRI Using Special COMMUNITY Values

Routers can use route maps to filter NLRI from being added to the BGP table, or from being sent in Updates to other routers. These route maps can match a BGP route's COMMUNITY by using the match community {standard-list-number | expanded-list-number | community-list-name [exact]} command, which in turn references a community list.

Additionally, BGP includes several reserved values for the COMMUNITY PA that allow route filtering to occur, but with less effort than is required with community lists and route maps. These special COMMUNITY values, once set, affect the logic used by routers when making decisions about to which BGP peers they will advertise the route. The values are listed in Table 13-16.

Table 13-16 COMMUNITY Values Used Specifically for NLRI Filtering

KEY POINT

1 LOCAL_AS is the Cisco term; RFC 1997 defines this value as NO_EXPORT_SUBCONFED.

Table 13-16 COMMUNITY Values Used Specifically for NLRI Filtering

Name

Value

Meaning

NO_EXPORT

FFFF:FF01

Do not advertise outside this AS. It can be advertised to other confederation autonomous systems.

NO_ADVERT

FFFF:FF02

Do not advertise to any other peer.

LOCAL_AS*

FFFF:FF03

Do not advertise outside the local confederation sub-AS.

1 LOCAL_AS is the Cisco term; RFC 1997 defines this value as NO_EXPORT_SUBCONFED.

A route with COMMUNITY NO_EXPORT is not advertised outside an AS. This value can be used to prevent an AS from being a transit AS for a set of prefixes. For example, a router in AS 1 could advertise an eBGP route into AS 2 with NO_EXPORT set. The routers inside AS 2 would then advertise the route inside AS 2 only. By not advertising the route outside AS 2, AS 2 cannot become a transit AS for that prefix. Note that the routers inside AS 2 do not have to configure a route map to prevent the route from exiting AS 2. However, the iBGP peers inside AS 2 must enable COMMUNITY using the neighbor send-community command.

The LOCAL_AS COMMUNITY value performs a similar function as NO_EXPORT, put just inside a single confederation sub-AS.

The NO_ADVERT COMMUNITY string may seem a bit unusual at first glance. However, it allows one router to advertise a prefix to a peer, with the intent that the peer will not advertise the route.

Finally, there are a few operational considerations to note regarding these COMMUNITY values. First, a router receiving any of these special communities can match them using an ip communitylist command with obvious keywords for all three values. Additionally, a router can use a route map to match and then remove these COMMUNITY strings—in effect, ignoring the dictate to limit the scope of advertisement of the routes. Finally, routes with these settings can be seen with commands like show ip bgp community no-export, with similar options NO_ADVERT and LOCAL_AS.

Was this article helpful?

0 0

Post a comment