Large-Scale BGP
Large-scale BGP is something of a subjective term. You decide when your BGP topology grows large enough to justify the use of the tools discussed in this section. As a rule, however, peer groups and communities are used in moderate-sized to larger internetworks. Route reflectors can also be found in moderate-sized and larger internetworks, but confederations generally are found only in the largest of BGP topologies, such as that of a large ISP. The following case studies discuss each of these tools.
Case Study: BGP Peer Groups
The preceding case study presented a BGP topology in Figure 3-24 in which an autonomous system is multihomed to several other autonomous systems. Suppose, however, that the router Colorado has 150 EBGP peers rather than five. In addition to the standard configuration, each neighbor connection has an outgoing and an incoming route filter. So for each neighbor, there are five BGP configuration statements:
A neighbor remote-as statement A neighbor ebgp-multihop statement, because the connections are between loopback addresses A neighbor update-source statement, for the same reason A neighbor filter-list out statement A neighbor filter-list in statement
For 150 EBGP peers, this translates into 750 configuration statements.
When the same routing policies are applied to many BGP peers, a router's BGP configuration can be greatly simplified by designating the peers as members of a single peer group. Most of the configuration options and routing policies that otherwise would be defined for each neighbor can instead be defined once, for the peer group. A peer group is relevant only to the router on which it is defined and is not communicated to the router's peers. You follow three steps to create a peer group:
- Step 1.
Designate the peer group name.
- Step 2.
Designate the routing policies and configuration options common to all members of the peer group.
- Step 3.
Designate the neighbors that belong to the peer group.
The configuration in Example 3-122 creates a peer group named CLIENTS on the router Colorado in Figure 3-24.
Example 3-122 Creating a Peer Group, CLIENTS, on the Router Colorado
router bgp 100
network 10.1.11.0 mask 255.255.255.0
network 10.1.12.0 mask 255.255.255.0
neighbor CLIENTS peer-group
neighbor CLIENTS ebgp-multihop 2
neighbor CLIENTS update-source Loopback2
neighbor CLIENTS filter-list 2 in
neighbor CLIENTS filter-list 1 out
neighbor 10.1.255.2 remote-as 200
neighbor 10.1.255.2 peer-group CLIENTS
neighbor 10.1.255.3 remote-as 300
neighbor 10.1.255.3 peer-group CLIENTS
neighbor 10.1.255.4 remote-as 400
neighbor 10.1.255.4 peer-group CLIENTS
neighbor 10.1.255.5 remote-as 500
neighbor 10.1.255.5 peer-group CLIENTS
neighbor 10.1.255.6 remote-as 600
neighbor 10.1.255.6 peer-group CLIENTS
no auto-summary
!
ip as-path access-list 1 permit ^$
ip as-path access-list 2 permit ^[2-6]00$
The neighbor CLIENTS peer-group statement creates the peer group, and the next four statements define options and policies common to all members of the group. The EBGP neighbors are then designated as usual with neighbor remote-as, and a single statement is added designating the neighbor as a member of the peer group CLIENTS.
By consolidating shared options and policies, peer groups can significantly shorten a BGP configuration. Returning to the scenario in which Colorado has 150 EBGP peers, if all the peers are members of peer group CLIENTS, the configuration is reduced from 750 statements to 305. The configuration also becomes much easier to interpret. All options are configured in one place, and all that is necessary is to know which neighbors are members of which peer group.
When all the members of a peer group belong to the same AS, you can shorten the configuration even more by specifying the common AS under the peer group configuration. All the members could be EBGP peers in the same remote AS, but in most cases a large number of peers in the same AS will be IBGP peers. In Figure 3-25, routers NewMexico and Idaho have been added as IBGP peers of Colorado.
Example 3-123 shows the configuration for Colorado.
Example 3-123 Configuring Colorado with a Peer Group for Its Internal Peers
router bgp 100
no synchronization
network 10.1.11.0 mask 255.255.255.0
network 10.1.12.0 mask 255.255.255.0
neighbor CLIENTS peer-group
neighbor CLIENTS ebgp-multihop 2
neighbor CLIENTS update-source Loopback2
neighbor CLIENTS filter-list 2 in
neighbor CLIENTS filter-list 1 out
neighbor LOCAL peer-group
neighbor LOCAL remote-as 100
neighbor LOCAL next-hop-self
neighbor LOCAL filter-list 3 out
neighbor 10.1.255.2 remote-as 200
neighbor 10.1.255.2 peer-group CLIENTS
neighbor 10.1.255.3 remote-as 300
neighbor 10.1.255.3 peer-group CLIENTS
neighbor 10.1.255.4 remote-as 400
neighbor 10.1.255.4 peer-group CLIENTS
neighbor 10.1.255.5 remote-as 500
neighbor 10.1.255.5 peer-group CLIENTS
neighbor 10.1.255.6 remote-as 600
neighbor 10.1.255.6 peer-group CLIENTS
neighbor 10.1.255.7 peer-group LOCAL
neighbor 10.1.255.8 peer-group LOCAL
no auto-summary
!
ip as-path access-list 1 permit ^$
ip as-path access-list 2 permit ^[2-6]00$
ip as-path access-list 3 permit ^[246]00$
NewMexico and Idaho have been added to the peer group LOCAL. Their common AS number is specified under the peer group configuration, as is a common outgoing routing policy.
NOTE
AS_PATH list 3 permits any route from AS 200, 400, or 600. Routes from AS 300 and AS 500 are implicitly denied, as are local routes originated from Colorado.
Incoming routing policies that are defined for a single peer group member take precedence over incoming routing policies defined for the peer group. Suppose, for example, that Colorado should accept only subnet 10.1.5.0/24 from EBGP peer California, but all other peer group policies and options apply. Example 3-124 shows the new configuration for Colorado.
Example 3-124 Applying a Routing Policy to a Single Neighbor in a Peer Group
router bgp 100
no synchronization
network 10.1.11.0 mask 255.255.255.0
network 10.1.12.0 mask 255.255.255.0
neighbor CLIENTS peer-group
neighbor CLIENTS ebgp-multihop 2
neighbor CLIENTS update-source Loopback2
neighbor CLIENTS filter-list 2 in
neighbor CLIENTS filter-list 1 out
neighbor LOCAL peer-group
neighbor LOCAL remote-as 100
neighbor LOCAL next-hop-self
neighbor LOCAL filter-list 3 out
neighbor 10.1.255.2 remote-as 200
neighbor 10.1.255.2 peer-group CLIENTS
neighbor 10.1.255.3 remote-as 300
neighbor 10.1.255.3 peer-group CLIENTS
neighbor 10.1.255.4 remote-as 400
neighbor 10.1.255.4 peer-group CLIENTS
neighbor 10.1.255.4 distribute-list 10 in
neighbor 10.1.255.5 remote-as 500
neighbor 10.1.255.5 peer-group CLIENTS
neighbor 10.1.255.6 remote-as 600
neighbor 10.1.255.6 peer-group CLIENTS
neighbor 10.1.255.7 peer-group LOCAL
neighbor 10.1.255.8 peer-group LOCAL
no auto-summary
!
ip as-path access-list 1 permit ^$
ip as-path access-list 2 permit ^[2-6]00$
ip as-path access-list 3 permit ^[246]00$
access-list 10 permit 10.1.5.0
Distribute list 10 has been added to the neighbor configuration for California (10.1.255.4). Although Colorado's configuration defines California as a member of the CLIENTS peer group, the distribute list overrides the incoming filter list 2 for that peer.
You can display details about the peer groups defined on a router with the command show ip bgp peer-groups, as demonstrated in Example 3-125. You also can use the command to observe the details of a single peer group, by specifying the name of the group at the end of the command.
Example 3-125 The show ip bgp peer-groups Command Displays Details About a Router's Peer Groups
Colorado#show ip bgp peer-group
BGP neighbor is CLIENTS, peer-group leader
Index 1, Offset 0, Mask 0x2
BGP version 4
Minimum time between advertisement runs is 5 seconds
Incoming update AS path filter list is 2
Outgoing update AS path filter list is 1
BGP neighbor is LOCAL, peer-group leader, remote AS 100
Index 0, Offset 0, Mask 0x0
NEXT_HOP is always this router
BGP version 4
Minimum time between advertisement runs is 5 seconds
Outgoing update AS path filter list is 3
Colorado#
Case Study: BGP Communities
Whereas peer groups enable you to apply common policies to a group of neighbors, communities enable you to apply policies to a group of routes. A community is a route attribute and therefore is communicated from one BGP speaker to another.
You follow three steps to configure a community attribute:
- Step 1.
Use a route map to identify the routes in which the attribute is to be set.
- Step 2.
Use the set community command to set the attribute.
- Step 3.
Use the neighbor send-community command to specify the neighbors to which the attribute is sent.
In Figure 3-26, AS 100 is connected across a NAP to AS 2000. A routing policy in AS 2000 states that subnet 10.2.2.0/24 should be advertised to AS 100, but not to any of the EBGP peers connected to Colorado. To implement this policy, the NO_EXPORT community attribute is used. This attribute allows a route to be advertised throughout a neighboring AS but does not allow that AS to advertise the route to other autonomous systems. Example 3-126 shows router Austria's configuration.
Example 3-126 Restricting a Subnet in AS 2000 from Being Advertised Beyond AS 100
router bgp 2000
network 10.2.1.0 mask 255.255.255.0
network 10.2.2.0 mask 255.255.255.0
network 10.2.3.0 mask 255.255.255.0
neighbor 10.1.255.8 remote-as 100
neighbor 10.1.255.8 ebgp-multihop 2
neighbor 10.1.255.8 update-source Loopback0
neighbor 10.1.255.8 send-community
neighbor 10.1.255.8 route-map AUSTRIA out
no auto-summary
!
access-list 1 permit 10.2.2.0
!
route-map AUSTRIA permit 10
match ip address 1
set community no-export
!
route-map AUSTRIA permit 20
Example 3-127 shows the results of the configuration in Example 3-126. Colorado's BGP table includes the route to 10.2.2.0/24, indicating that Idaho has advertised the route to its IBGP peers. But Nevada's BGP table does not contain the route; Colorado has honored the NO_EXPORT attribute and has suppressed the route to its EBGP peers.
Example 3-127 The Route to 10.2.2.0 Has the NO_EXPORT Community Attribute Set, So Colorado Does Not Advertise the Route to Its EBGP Peers Such as Nevada
Colorado#show ip bgp 10.2.2.0
BGP routing table entry for 10.2.2.0/24, version 42
Paths: (1 available, best #1, not advertised to EBGP peer)
2000
10.1.255.8 from 10.1.255.8
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: no-export
Colorado#
_______________________________________________________________________
Nevada#show ip bgp 10.2.2.0
% Network not in table
Nevada#
Of course, an autonomous system would not be truly autonomous if another AS could tell it what to do. Suppose AS 100 wants to override the NO_EXPORT attribute set by Austria and advertise 10.2.2.0/24 to Colorado's EBGP peers. Example 3-128 shows the configuration for Idaho to implement such a policy.
Example 3-128 Configuring Idaho to Delete Communities Advertised by AS 2000
router bgp 100
no synchronization
network 10.1.12.0 mask 255.255.255.0
neighbor 10.1.255.1 remote-as 100
neighbor 10.1.255.1 update-source Loopback0
neighbor 10.1.255.1 next-hop-self
neighbor 10.1.255.1 route-map IDAHO out
neighbor 10.1.255.7 remote-as 100
neighbor 10.1.255.7 update-source Loopback0
neighbor 10.2.255.1 remote-as 2000
neighbor 10.2.255.1 ebgp-multihop 2
neighbor 10.2.255.1 update-source Loopback0
no auto-summary
!
access-list 1 permit 10.2.2.0
!
route-map IDAHO permit 10
match ip address 1
set community none
!
route-map IDAHO permit 20
The set community none statement in Idaho's configuration does not set a community attribute; rather, it deletes existing community attributes. That is why no neighbor send-community statement is necessary in this configuration. Example 3-129 shows the results at Colorado and Nevada.
Example 3-129 Colorado No Longer Sees a NO_EXPORT Community Attribute for the Route to 10.2.2.0/24 and Advertises the Route to Its EBGP Peers
Colorado#show ip bgp 10.2.2.0
BGP routing table entry for 10.2.2.0/24, version 90
Paths: (1 available, best #1, advertised over EBGP)
2000
10.1.255.8 from 10.1.255.8
Origin IGP, metric 0, localpref 100, valid, internal, best
Colorado#
_______________________________________________________________________
Nevada#show ip bgp 10.2.2.0
BGP routing table entry for 10.2.2.0 255.255.255.0, version 325
Paths: (1 available, best #1)
100 2000
10.1.255.1 from 10.1.255.1
Origin IGP, valid, external, best
Nevada#
The NO_ADVERTISE community attribute sends the same message as NO_EXPORT—it tells routers to not advertise the route to any peers. The difference is that NO_ADVERTISE is sent to IBGP peers rather than EBGP peers. Suppose that Idaho in Figure 3-26 wants to advertise subnets 10.2.1.0/24 and 10.2.3.0/24 to Colorado but does not want that peer to advertise the routes to any of its own IBGP or EBGP peers. Example 3-130 shows the configuration for Idaho.
Example 3-130 Setting the NO_ADVERTISE Community at Idaho for Selected Prefixes
router bgp 100
no synchronization
network 10.1.12.0 mask 255.255.255.0
neighbor 10.1.255.1 remote-as 100
neighbor 10.1.255.1 update-source Loopback0
neighbor 10.1.255.1 next-hop-self
neighbor 10.1.255.1 send-community
neighbor 10.1.255.1 route-map IDAHO out
neighbor 10.1.255.7 remote-as 100
neighbor 10.1.255.7 update-source Loopback0
neighbor 10.2.255.1 remote-as 2000
neighbor 10.2.255.1 ebgp-multihop 2
neighbor 10.2.255.1 update-source Loopback0
no auto-summary
!
ip as-path access-list 2 permit ^2000$
!
access-list 1 permit 10.2.2.0
!
route-map IDAHO permit 10
match ip address 1
set community none
!
route-map IDAHO permit 20
match as-path 2
set community no-advertise
!
route-map IDAHO permit 30
Recall that Austria is configured to advertise 10.2.2.0/24 with the NO_EXPORT community and the other two subnets of AS 2000 with no community attributes. Idaho has now completely reversed that policy. Subnet 10.2.2.0/24 has no community attribute, and the subnets 10.2.1.0/24 and 10.2.3.0/24 have the NO_ADVERTISE attribute, preventing them from being advertised outside of AS 100. Example 3-131 shows the results of this configuration.
Example 3-131 Colorado Has Knowledge of All Three Routes from AS 2000 But Advertises Only 10.2.2.0/24 to Its Peers
Colorado#show ip bgp regexp 2000
BGP table version is 138, local router ID is 10.1.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i10.2.1.0/24 10.1.255.8 0 100 0 2000 i
*>i10.2.2.0/24 10.1.255.8 0 100 0 2000 i
*>i10.2.3.0/24 10.1.255.8 0 100 0 2000 i
Colorado#
___________________________________________________________________________________________________________
Nevada#show ip bgp regexp 2000
BGP table version is 355, local router ID is 10.1.255.5
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.2.2.0/24 10.1.255.1 0 100 2000 i
Nevada#
NOTE
Example 3-131 also shows yet another way to use the show ip bgp command. Here, a regular expression is used to display all routes that have a 2000 in their AS_PATH.
A community attribute called LOCAL_AS is something of a hybrid of the NO_EXPORT and NO_ADVERTISE attributes. This attribute is used in conjunction with BGP confederations, in which subautonomous systems are configured within an AS. A route with a LOCAL_AS attribute can be advertised to peers in other subautonomous systems within a confederation but cannot be advertised outside of the AS that forms the confederation.
The well-known community attributes that have been demonstrated so far are acted upon automatically by a BGP speaker. However, you also can configure community attributes that have only the meaning you define. You can designate communities in two ways:
The decimal format, using a number between 1 and 4294967200 The AA:NN format, in which AA is a 16-bit AS number between 1 and 65535 and NN is an arbitrary 16-bit number between 1 and 65440
In Figure 3-26, each of the "client" autonomous systems of AS 100 has two subnets. Suppose AS 100 applies a certain policy to one of the two subnets of each client AS and a different policy to the other subnet. The policies could be applied by using a lengthy access list at Colorado to identify each route by its NLRI (remember the scenario in which there are not five client autonomous systems, but 150). Another way is to have each client AS assign each subnet to one of two predetermined communities. For example, each client could assign one subnet to community 5 and the other to community 10. The configuration in Example 3-132 shows what Utah's configuration might look like.
Example 3-132 Assigning Subnets to Communities in Utah
router bgp 200
network 10.1.1.0 mask 255.255.255.0
network 10.1.2.0 mask 255.255.255.0
neighbor 10.1.255.1 remote-as 100
neighbor 10.1.255.1 ebgp-multihop 2
neighbor 10.1.255.1 update-source Loopback0
neighbor 10.1.255.1 send-community
neighbor 10.1.255.1 route-map UTAH out
no auto-summary
!
access-list 1 permit 10.1.1.0
access-list 2 permit 10.1.2.0
!
route-map UTAH permit 10
match ip address 1
set community 5
!
route-map UTAH permit 20
match ip address 2
set community 10
All the other EBGP peers of Colorado have similar configurations, as demonstrated in Example 3-133. In addition to making it much easier for Colorado to identify the routes for each policy, this approach gives the administrators of the client autonomous systems the leeway to decide which route is used for which policy.
Example 3-133 Each of the Routes Advertised by Colorado's EBGP Peers Is a Member of Either Community 5 or Community 10
Colorado#show ip bgp community 5
BGP table version is 60, local router ID is 10.1.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.255.2 0 0 200 i
*> 10.1.3.0/24 10.1.255.3 0 0 300 i
*> 10.1.5.0/24 10.1.255.4 0 0 400 i
*> 10.1.7.0/24 10.1.255.5 0 0 500 i
*> 10.1.9.0/24 10.1.255.6 0 0 600 i
Colorado#show ip bgp community 10
BGP table version is 60, local router ID is 10.1.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.2.0/24 10.1.255.2 0 0 200 i
*> 10.1.4.0/24 10.1.255.3 0 0 300 i
*> 10.1.6.0/24 10.1.255.4 0 0 400 i
*> 10.1.8.0/24 10.1.255.5 0 0 500 i
*> 10.1.10.0/24 10.1.255.6 0 0 600 i
Colorado#
A community list is used to identify routes by their community attributes. This list is a special adaptation of an access list: There are possibly multiple lines in the list, each of which has a "permit" or "deny" action. The list is identified by a number between 1 and 99, and there is an implicit "deny any" at the end. In the configuration in Example 3-134, Colorado uses community lists to assign LOCAL_PREF attributes to routes according to their community.
NOTE
Such a policy might be used if the client autonomous systems were multihomed to AS 100. For simplicity, such a topology is not shown in this example.
Example 3-134 Using Community Lists to Assign LOCAL_PREF Attributes to Routes According to Their Community Values
router bgp 100
no synchronization
network 10.1.11.0 mask 255.255.255.0
network 10.1.12.0 mask 255.255.255.0
neighbor CLIENTS peer-group
neighbor CLIENTS ebgp-multihop 2
neighbor CLIENTS update-source Loopback2
neighbor CLIENTS next-hop-self
neighbor CLIENTS send-community
neighbor CLIENTS route-map COMM_PREF in
neighbor LOCAL peer-group
neighbor LOCAL remote-as 100
neighbor LOCAL next-hop-self
neighbor 10.1.255.2 remote-as 200
neighbor 10.1.255.2 peer-group CLIENTS
neighbor 10.1.255.3 remote-as 300
neighbor 10.1.255.3 peer-group CLIENTS
neighbor 10.1.255.4 remote-as 400
neighbor 10.1.255.4 peer-group CLIENTS
neighbor 10.1.255.5 remote-as 500
neighbor 10.1.255.5 peer-group CLIENTS
neighbor 10.1.255.6 remote-as 600
neighbor 10.1.255.6 peer-group CLIENTS
neighbor 10.1.255.7 peer-group LOCAL
neighbor 10.1.255.8 peer-group LOCAL
no auto-summary
!
ip community-list 1 permit 5
ip community-list 2 permit 10
!
route-map COMM_PREF permit 10
match community 1
set local-preference 150
!
route-map COMM_PREF permit 20
match community 2
set local-preference 200
Incoming routes from the members of peer group CLIENTS are sent to a route map named COMM_PREF. Sequence 10 of the route map uses community list 1 to identify routes with a community of 5 and assigns them a LOCAL_PREF of 150. Sequence 20 uses community list 2 to identify routes with a community of 10 and assigns them a LOCAL_PREF of 200. Example 3-135 shows the results in Colorado's BGP table.
Example 3-135 The Routes Belonging to Community 5 as Shown in Example 3-31 Have Been Assigned a LOCAL_PREF of 150, and the Routes Belonging to Community 10 Have Been Assigned a LOCAL_PREF of 200
Colorado#show ip bgp
BGP table version is 16, local router ID is 10.1.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.255.2 0 150 0 200 i
*> 10.1.2.0/24 10.1.255.2 0 200 0 200 i
*> 10.1.3.0/24 10.1.255.3 0 150 0 300 i
*> 10.1.4.0/24 10.1.255.3 0 200 0 300 i
*> 10.1.5.0/24 10.1.255.4 0 150 0 400 i
*> 10.1.6.0/24 10.1.255.4 0 200 0 400 i
*> 10.1.7.0/24 10.1.255.5 0 150 0 500 i
*> 10.1.8.0/24 10.1.255.5 0 200 0 500 i
*> 10.1.9.0/24 10.1.255.6 0 150 0 600 i
*> 10.1.10.0/24 10.1.255.6 0 200 0 600 i
*>i10.1.11.0/24 10.1.255.7 0 100 0 i
*>i10.1.12.0/24 10.1.255.8 0 100 0 i
*>i10.2.1.0/24 10.1.255.8 0 100 0 2000 i
*>i10.2.2.0/24 10.1.255.8 0 100 0 2000 i
*>i10.2.3.0/24 10.1.255.8 0 100 0 2000 i
Colorado#
RFC 1997 and RFC 1998, which describe the BGP community attribute, specify the use of the AA:NN format. By default, Cisco IOS uses the older, decimal format. To use the newer format, you add the command ip bgp-community new-format to the global router configuration. When entering communities in this format, you can type the community directly in the AA:NN format, in hexadecimal, or in decimal. For example, any of the following three entries specify the community 400:50 (AS 400, number 50):
set community 400:50 set community 0x1900032 set community 26214450
All these commands specify a 32-bit number in which the first 16 bits is 400 in decimal and the second 16 bits is 50 in decimal. Regardless of which of the three commands are used, the community displays in the router configuration file and the BGP tables as 400:50.
Example 3-136 shows the configuration for Utah using this format.
Example 3-136 Configuring Utah to Display Communities in the AA:NN Format
router bgp 200
network 10.1.1.0 mask 255.255.255.0
network 10.1.2.0 mask 255.255.255.0
neighbor 10.1.255.1 remote-as 100
neighbor 10.1.255.1 ebgp-multihop 2
neighbor 10.1.255.1 update-source Loopback0
neighbor 10.1.255.1 send-community
neighbor 10.1.255.1 route-map UTAH out
no auto-summary
!
ip bgp-community new-format
!
access-list 1 permit 10.1.1.0
access-list 2 permit 10.1.2.0
!
route-map UTAH permit 10
match ip address 1
set community 200:5
!
route-map UTAH permit 20
match ip address 2
set community 200:10
Just as there are standard and extended access lists, there are also standard and extended community lists. And like IP access lists, standard community lists are numbered 1 through 99, and extended community lists are numbered 100 through 199. The difference between the two community list types is that extended lists enable you to use regular expressions to specify the community (very useful when using the AA:NN format). To implement the same LOCAL_PREF policy at Colorado as previously described, but using the AA:NN format, enter the configuration for Colorado as shown in Example 3-137.
Example 3-137 Using Extended Community Lists
router bgp 100
no synchronization
network 10.1.11.0 mask 255.255.255.0
network 10.1.12.0 mask 255.255.255.0
neighbor CLIENTS peer-group
neighbor CLIENTS ebgp-multihop 2
neighbor CLIENTS update-source Loopback2
neighbor CLIENTS next-hop-self
neighbor CLIENTS send-community
neighbor CLIENTS route-map COMM_PREF in
neighbor LOCAL peer-group
neighbor LOCAL remote-as 100
neighbor LOCAL next-hop-self
neighbor 10.1.255.2 remote-as 200
neighbor 10.1.255.2 peer-group CLIENTS
neighbor 10.1.255.3 remote-as 300
neighbor 10.1.255.3 peer-group CLIENTS
neighbor 10.1.255.4 remote-as 400
neighbor 10.1.255.4 peer-group CLIENTS
neighbor 10.1.255.5 remote-as 500
neighbor 10.1.255.5 peer-group CLIENTS
neighbor 10.1.255.6 remote-as 600
neighbor 10.1.255.6 peer-group CLIENTS
neighbor 10.1.255.7 peer-group LOCAL
neighbor 10.1.255.8 peer-group LOCAL
no auto-summary
!
ip community-list 101 permit .*:5
ip community-list 102 permit .*:10
!
route-map COMM_PREF permit 10
match community 101
set local-preference 150
!
route-map COMM_PREF permit 20
match community 102
set local-preference 200
The configuration in Example 3-137 is identical to Colorado's previous configuration in Example 3-134, except that extended community lists are used. If standard community lists were used, a separate line would be needed to match each community from each AS, as demonstrated in Example 3-138.
Example 3-138 Using Standard Community Lists
ip community-list 1 permit 200:5
ip community-list 1 permit 300:5
ip community-list 1 permit 400:5
ip community-list 1 permit 500:5
ip community-list 1 permit 600:5
With the extended community lists, a match is specified with a single line. The regular expression .* matches any AS number, and the 5 matches the common part of the community number.
Example 3-139 displays the routes matching community lists 101 and 102 at Colorado. The combination of community list and show ip bgp community-list commands becomes very useful in large-scale BGP implementations, which might have tens of thousands of BGP route entries. Finding routes with particular community attributes becomes a simple matter of entering a community list and then displaying the routes that match the list.
Example 3-139 The show ip bgp community-list Command Displays BGP Routes Matching a Specified Community List
Colorado#show ip bgp community-list 101
BGP table version is 19, local router ID is 10.1.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.255.2 0 150 0 200 i
*> 10.1.3.0/24 10.1.255.3 0 150 0 300 i
*> 10.1.5.0/24 10.1.255.4 0 150 0 400 i
*> 10.1.7.0/24 10.1.255.5 0 150 0 500 i
*> 10.1.9.0/24 10.1.255.6 0 150 0 600 I
Colorado#show ip bgp community-list 102
BGP table version is 19, local router ID is 10.1.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.2.0/24 10.1.255.2 0 200 0 200 i
*> 10.1.4.0/24 10.1.255.3 0 200 0 300 i
*> 10.1.6.0/24 10.1.255.4 0 200 0 400 i
*> 10.1.8.0/24 10.1.255.5 0 200 0 500 i
*> 10.1.10.0/24 10.1.255.6 0 200 0 600 i
Colorado#
A route can have multiple community attributes. Suppose router Austria in Figure 3-26 advertises all of its subnets to Idaho with a community of 2000:100. At Idaho, the routes from Austria are also to be made members of community 100:2000. Example 3-140 shows the configuration for Idaho.
Example 3-140 Configuring Idaho to Add an Additional Community Value to the Routes from Austria
router bgp 100
no synchronization
network 10.1.12.0 mask 255.255.255.0
neighbor 10.1.255.1 remote-as 100
neighbor 10.1.255.1 update-source Loopback0
neighbor 10.1.255.1 next-hop-self
neighbor 10.1.255.1 send-community
neighbor 10.1.255.1 route-map IDAHO out
neighbor 10.1.255.7 remote-as 100
neighbor 10.1.255.7 update-source Loopback0
neighbor 10.1.255.7 next-hop-self
neighbor 10.2.255.1 remote-as 2000
neighbor 10.2.255.1 ebgp-multihop 2
neighbor 10.2.255.1 update-source Loopback0
no auto-summary
!
ip as-path access-list 2 permit ^2000$
!
route-map IDAHO permit 10
match as-path 2
set community 6555600 additive
!
route-map IDAHO permit 20
This configuration presents two points of interest. First, the community set by statement 10 of route map IDAHO is 6555600. The command ip bgp-community new-format is supported in IOS 12.0 and later; router Idaho is running IOS 11.0 and therefore does not understand the AA:NN format. However, a quick calculation reveals that the decimal number 6555600 is equivalent to the 32-bit number 100:2000 (or 0x6407d0). Colorado, which is running IOS 12.0, correctly interprets this 32-bit number in the AA:NN format. The important point here is that although the community attribute can be represented in AA:NN, decimal, or hex format, it is still in reality a 32-bit number.
The other point of interest is the keyword additive used with the set community command. If the command set community 6555600 is used without the additive keyword Idaho replaces the existing community attribute of any matching routes with the community 100:2000. In this case, the goal is to add an additional community, not replace the community sent by Austria. Example 3-141 shows the results at Colorado.
Example 3-141 The Community Attribute 2000:100 Is Added by Austria, and the Community Attribute 100:2000 Is Added by Idaho
Colorado#show ip bgp 10.2.1.0
BGP routing table entry for 10.2.1.0/24, version 49
Paths: (1 available, best #1, advertised over EBGP)
2000
10.1.255.8 from 10.1.255.8
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 100:2000 2000:100
Colorado#
When a route has multiple communities, community lists and match statements are used slightly differently. The statement ip community-list 1 permit 2000:100 matches any route that has 2000:100 as one of its communities. On the other hand, the statement ip community-list 1 permit 2000:100 100:2000 matches any route that has either or both communities. If you want to match only those routes that are members of both communities 2000:100 and 100:2000, no more and no less, the exact-match keyword is used in the matching statement, as demonstrated in Example 3-142. With this keyword, routes that have only 2000:100 or 100:2000, and routes that have both communities but also have other communities, are not matched.
Example 3-142 The exact-match Keyword Returns Routes That Exactly Match the Specified Community List
Colorado#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Colorado(config)#ip community-list 10 permit 2000:100 100:2000
Colorado(config)#^Z
Colorado#
%SYS-5-CONFIG_I: Configured from console by console
Colorado#show ip bgp community-list 10 exact-match
BGP table version is 52, local router ID is 10.1.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i10.2.1.0/24 10.1.255.8 0 100 0 2000 i
*>i10.2.2.0/24 10.1.255.8 0 100 0 2000 i
*>i10.2.3.0/24 10.1.255.8 0 100 0 2000 i
Colorado#
If a route can be assigned multiple community attributes, there should also be a way to remove some community attributes without removing them all, as the set community none statement does. This is the job of the set comm-list delete command.
In the previous configurations, the routes to the subnets in AS 2000 of Figure 3-26 have the community attributes 2000:100 and 100:2000. At AS 400, the community 100:2000 should be retained, but not the community 2000:100. Example 3-143 shows the configuration for California.
Example 3-143 Configuring California to Selectively Delete Community Values
router bgp 400
network 10.1.5.0 mask 255.255.255.0
network 10.1.6.0 mask 255.255.255.0
neighbor 10.1.255.1 remote-as 100
neighbor 10.1.255.1 ebgp-multihop 2
neighbor 10.1.255.1 update-source Loopback0
neighbor 10.1.255.1 send-community
neighbor 10.1.255.1 route-map DROP_COMM in
!
ip bgp-community new-format
!
ip community-list 1 permit 2000:100
!
route-map DROP_COMM permit 10
set comm-list 1 delete
The route map DROP_COMM refers to community list 1 and deletes the community specified by the list. Example 3-144 shows the results. In a previous configuration, you saw that multiple community attributes can be specified in a single community list line. When the list is being used by the set comm-list delete command, however, each line of the list can specify only a single community. Therefore, if you want to delete the communities 2000:100, NO_EXPORT, and 300:5 from routes, you must configure a community list with three separate lines.
Example 3-144 No Matches Can Be Found in California's BGP Table for Routes with Both 2000:100 and 100:2000 Community Attributes, But the Routes from AS 2000 All Have Single Community Attributes of 100:2000
California#show ip bgp community 2000:100 100:2000 exact-match
California#show ip bgp community 100:2000 exact-match
BGP table version is 16, local router ID is 10.1.255.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.2.1.0/24 10.1.255.1 0 100 2000 i
*> 10.2.2.0/24 10.1.255.1 0 100 2000 i
*> 10.2.3.0/24 10.1.255.1 0 100 2000 i
California#
Case Study: Private AS Numbers
You are familiar with private IP addresses, as specified by RFC 1918. These addresses, in the range 10.0.0.0–10.255.255.255, 172.16.0.0–172.31.255.255, and 192.168.0.0–192.168.255.255, are designed to help alleviate the depletion of IP addresses. When an internetwork has a need for IP addresses, but the addresses do not need to be known publicly (that is, they do not need to be reachable from the Internet), you can use private addresses rather than public addresses. Because anyone can use any private IP address, the addresses are not unique and must never be advertised into the public Internet.
Private AS numbers also exist, and like private IP addresses, they are designed to alleviate the depletion of public AS numbers. AS numbers 64512 to 65535 are reserved for private use. If a BGP-speaking subscriber is homed to a single ISP, the subscriber can and is encouraged to use a private AS number.
For example, previous case studies have depicted the autonomous systems connected to router Colorado in Figure 3-26 as "client" autonomous systems of AS 100. AS 2000, connected across a NAP to AS 100, represents the public Internet. AS 100 might be an ISP and the connected autonomous systems its subscribers, or AS 100 might be the publicly connected part of a large corporate internetwork, and the other autonomous systems its private divisions. Whatever the case, the five "client" autonomous systems in Figure 3-26 are reachable only across the NAP and through AS 100. The only reason they have individual AS numbers is so that EBGP can be used to connect them to AS 100; AS 100 can advertise their routes to the Internet without including their AS numbers. Figure 3-27 shows the same internetwork as Figure 3-26, but here the "client" autonomous systems use AS numbers out of the private pool.
Remember that like private IP addresses, private AS numbers must not be advertised to the Internet, because they are not unique. Example 3-145 shows that without further configuration, the AS numbers of AS 100's clients are advertised across the NAP to router Austria.
Example 3-145 Austria's BGP Table Shows Private AS Numbers in the AS_PATHs of Some of the Routes from AS 100; if Austria Is Part of the Public Internet, Connected to AS 100 Across a NAP, These AS Numbers Must Not Be Included in the AS_PATHs
Austria#show ip bgp
BGP table version is 189, local router ID is 10.2.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.255.8 0 100 65001 i
*> 10.1.2.0/24 10.1.255.8 0 100 65001 i
*> 10.1.3.0/24 10.1.255.8 0 100 65002 i
*> 10.1.4.0/24 10.1.255.8 0 100 65002 i
*> 10.1.5.0/24 10.1.255.8 0 100 65003 i
*> 10.1.6.0/24 10.1.255.8 0 100 65003 i
*> 10.1.7.0/24 10.1.255.8 0 100 65004 i
*> 10.1.8.0/24 10.1.255.8 0 100 65004 i
*> 10.1.9.0/24 10.1.255.8 0 100 65005 i
*> 10.1.10.0/24 10.1.255.8 0 100 65005 i
*> 10.1.11.0/24 10.1.255.8 0 100 i
*> 10.1.12.0/24 10.1.255.8 0 0 100 i
*> 10.2.1.0/24 0.0.0.0 0 32768 i
*> 10.2.2.0/24 0.0.0.0 0 32768 i
*> 10.2.3.0/24 0.0.0.0 0 32768 i
Austria#
In Example 3-146, Idaho is configured to prevent the private AS numbers from being advertised across the NAP.
Example 3-146 Filtering Private AS Numbers
router bgp 100
no synchronization
network 10.1.12.0 mask 255.255.255.0
neighbor 10.1.255.1 remote-as 100
neighbor 10.1.255.1 update-source Loopback0
neighbor 10.1.255.1 next-hop-self
neighbor 10.1.255.1 send-community
neighbor 10.1.255.7 remote-as 100
neighbor 10.1.255.7 update-source Loopback0
neighbor 10.1.255.7 next-hop-self
neighbor 10.2.255.1 remote-as 2000
neighbor 10.2.255.1 ebgp-multihop 2
neighbor 10.2.255.1 update-source Loopback0
neighbor 10.2.255.1 remove-private-AS
no auto-summary
The neighbor remove-private-AS command is reasonably self-explanatory. It removes private AS numbers from the AS_PATH of routes before advertising them to the specified neighbor. In Example 3-147, you can see that all the AS_PATH attributes of all the routes advertised from Idaho to Austria now contain only AS 100. The routers within AS 100 still have the full path information for the client autonomous systems and can forward packets to the correct destination AS. In this regard, advertising the client subnets as if they are part of AS 100 is a form of summarization at the autonomous system level.
Example 3-147 After the neighbor remove-private-AS Command Has Been Added to Idaho's BGP Configuration, the Private AS Numbers of AS 100's Client Autonomous Systems Are Hidden from Austria
Austria#show ip bgp
BGP table version is 214, local router ID is 10.2.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.255.8 0 100 i
*> 10.1.2.0/24 10.1.255.8 0 100 i
*> 10.1.3.0/24 10.1.255.8 0 100 i
*> 10.1.4.0/24 10.1.255.8 0 100 i
*> 10.1.5.0/24 10.1.255.8 0 100 i
*> 10.1.6.0/24 10.1.255.8 0 100 i
*> 10.1.7.0/24 10.1.255.8 0 100 i
*> 10.1.8.0/24 10.1.255.8 0 100 i
*> 10.1.9.0/24 10.1.255.8 0 100 i
*> 10.1.10.0/24 10.1.255.8 0 100 i
*> 10.1.11.0/24 10.1.255.8 0 100 i
*> 10.1.12.0/24 10.1.255.8 0 0 100 i
*> 10.2.1.0/24 0.0.0.0 0 32768 i
*> 10.2.2.0/24 0.0.0.0 0 32768 i
*> 10.2.3.0/24 0.0.0.0 0 32768 i
Austria#
Case Study: BGP Confederations
BGP confederations make large transit autonomous systems more manageable by enabling the administrator to break the AS into subautonomous systems. The subdivided AS itself becomes the confederation, and the subautonomous systems are the member autonomous systems. Autonomous systems outside of the confederation see the entire confederation as a single AS and do not see the member autonomous systems. Because the member autonomous systems are hidden from the outside, they may use either public or private AS numbers, although best practice suggests using private AS numbers.
The advantage of confederations is that they sharply reduce the number of IBGP peering sessions. IBGP is used normally within each member AS, but a special version of EBGP known as confederation EBGP is run between the autonomous systems. No IBGP sessions are configured from a BGP speaker in one AS to a BGP speaker in another AS within the confederation.
Figure 3-28 shows an example of a confederation. AS 1200 has been subdivided into three confederation autonomous systems: AS 65533, AS 65534, and AS 65535. From the perspective of outside autonomous systems, such as AS 1000 and AS 1500, the confederation is a single autonomous system: AS 1200. These external autonomous systems have no knowledge of the confederation member autonomous systems.
Confederation EBGP is run between Panorama and Sunshine, between Sunshine and Talisman, and between Talisman and Whitetooth. Example 3-148 shows the configuration for Talisman.
Example 3-148 Configuring Talisman as a Confederation Router
router ospf 65534
network 10.34.0.0 0.0.255.255 area 65534
network 10.255.0.0 0.0.255.255 area 0
!
router bgp 65534
no synchronization
bgp confederation identifier 1200
bgp confederation peers 65533 65535
neighbor Confed peer-group
neighbor Confed ebgp-multihop 2
neighbor Confed update-source Loopback
neighbor Confed next-hop-self
neighbor MyGroup peer-group
neighbor MyGroup remote-as 65534
neighbor MyGroup update-source Loopback0
neighbor 10.33.255.1 remote-as 65533
neighbor 10.33.255.1 peer-group Confed
neighbor 10.34.255.2 peer-group MyGroup
neighbor 10.35.255.1 remote-as 65535
neighbor 10.35.255.1 peer-group Confed
Talisman is configured so that its local AS is 65534. Its peer connections to Whitetooth and Sunshine are set up like any other EBGP session, and the connection to Lakeridge is IBGP. The bgp confederation identifier command tells the router that it is a member of a confederation and the confederation ID. The bgp confederation peers command lists the member autonomous systems to which Talisman is connected. This command tells the BGP process that the EBGP connection is confederation EBGP rather than normal EBGP.
A confederation may run BGP only, a common IGP throughout the entire confederation, or different IGPs within each member AS. In Figure 3-28, all the routers within AS 1200 run OSPF. The OSPF permits local communication within the confederation and tells the BGP processes how to find their various neighbors. In the configuration in Example 3-148, no routes are redistributed between OSPF and BGP at any router. Subsequent configuration examples do not show the OSPF configuration.
Example 3-149 shows configurations of Lakeridge and Sugarloaf.
Example 3-149 Configuring EBGP Between Confederation Router Lakeridge and External Router Sugarloaf
Lakeridge
router bgp 65534
no synchronization
bgp confederation identifier 1200
neighbor 10.34.255.1 remote-as 65534
neighbor 10.34.255.1 update-source Loopback0
neighbor 10.34.255.1 next-hop-self
neighbor 192.168.255.1 remote-as 1500
neighbor 192.168.255.1 ebgp-multihop 2
neighbor 192.168.255.1 update-source Loopback0
____________________________________________________________________________________________________________
Sugarloaf
router bgp 1500
network 192.168.1.0
network 192.168.2.0
neighbor 10.34.255.2 remote-as 1200
neighbor 10.34.255.2 ebgp-multihop 2
neighbor 10.34.255.2 update-source Loopback0
At Lakeridge, the bgp confederation peers command is not used because Lakeridge is not running confederation EBGP. It does, however, have a normal EBGP connection to Sugarloaf. Notice that from the perspective of Sugarloaf, Lakeridge is in AS 1200, not AS 65534. Sugarloaf, being outside of the confederation, has no knowledge of the member autonomous systems.
Confederation EBGP is something of a hybrid between normal BGP and IBGP. Specifically, within a confederation, the following applies:
The NEXT_HOP attribute of routes external to the confederation is preserved throughout the confederation. MULTI_EXIT_DISC attributes of routes advertised into a confederation are preserved throughout the confederation. LOCAL_PREF attributes of routes are preserved throughout the entire confederation, not just within the member AS in which they are assigned. The AS numbers of the member autonomous systems are added to the AS_PATH within the confederation but are not advertised outside of the confederation. By default, the member AS numbers are listed in the AS_PATH as AS_PATH attribute type 4, AS_CONFED_SEQUENCE. If the aggregate-address command is used within the confederation, the as-set keyword causes member AS numbers behind the aggregation point to be listed as AS_PATH attribute type 3, AS_CONFED_SET. The confederation AS numbers in an AS_PATH are used for loop avoidance but are not considered when choosing a shortest AS_PATH within the confederation.
Most of these characteristics are due to the fact that from the outside, the confederation appears to be a single autonomous system. The following discussion provides examples of each of these characteristics.
In Figure 3-28, the routes in AS 1000 are advertised from Bridger to Nakiska with a NEXT_HOP attribute of 172.17.255.1. This attribute is preserved when the routes are advertised via IBGP from Nakiska to Sunshine. If Sunshine were connected to Talisman with a normal EBGP connection, Sunshine would change the NEXT_HOP of the routes to 10.33.255.1 before advertising them to Talisman. Because the connection is confederation EBGP, however, the original NEXT_HOP attribute is preserved. As a result, Lakeridge could have route entries for 172.17.0.0 and 172.18.0.0 with a next-hop address of 172.17.255.1. Lakeridge's connection to Sugarloaf is normal EBGP, so the routes are advertised to Sugarloaf with a NEXT_HOP attribute of 10.34.255.2.
The neighbor next-hop-self command is used throughout the confederation of Figure 3-28 so that all next-hop addresses are known via the IGP. You can observe these commands in the configurations of Talisman and Lakeridge.
Bridger is configured to advertise its routes with a MED of 50, and Nakiska is configured to set the LOCAL_PREF of the same routes to 200. You can observe the results in Example 3-150. In a normal EBGP session, Sunshine would not advertise the MED that originated in AS 1000, or the LOCAL_PREF that should only have relevance within AS65533. Because the confederation is seen from the outside as a single AS, however, these values must be consistent throughout the confederation.
Example 3-150 The Routes from AS 1000 Have a MED of 50 and a LOCAL_PREF of 200 at Lakeridge; These Values Were Preserved Across the Confederation EBGP Connection from Sunshine
Lakeridge#show ip bgp
BGP table version is 28, local router ID is 10.34.255.2
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i172.17.0.0 10.33.255.1 50 200 0 (65533) 1000 i
*>i172.18.0.0 10.33.255.1 50 200 0 (65533) 1000 i
*> 192.168.1.0 192.168.255.1 0 0 1500 i
*> 192.168.2.0 192.168.255.1 0 0 1500 i
Lakeridge#
You also can see in Example 3-150 that AS 65533 is included in the AS_PATH of the routes to the networks in AS 1000. The AS_CONFED_SEQUENCE is shown in parentheses for two reasons. First, it is not advertised outside of the confederation, as demonstrated in Example 3-151. Second, it is used only for loop avoidance within the confederation, not for path selection.
Example 3-151 Sugarloaf Sees the Confederation in Figure 3-28 as a Single Autonomous System and Does Not See the Member Autonomous Systems; the AS_CONFED_SEQUENCE, Shown in Parentheses in Example 3-150, Is Replaced with the Confederation ID 1200
Sugarloaf#show ip bgp
BGP table version is 32, local router ID is 192.168.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.17.0.0 10.34.255.2 0 1200 1000 i
*> 172.18.0.0 10.34.255.2 0 1200 1000 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0 0.0.0.0 0 32768 i
Sugarloaf#
In the BGP tables of Whitetooth and Panorama displayed in Example 3-152, you can observe a consequence of the fact that member AS numbers do not influence the path selection process. Both routers have two paths to each of the destinations in AS 1000 and AS1500—one via its IBGP neighbor, and one via its confederation EBGP neighbor. Whitetooth, for instan | 
