Internet Routing Architectures (CISCO):Configuring Basic BGP Functions and Attributes



























Previous
Table of Contents
Next




In the following BGP routing table for RTK, note how the aggregate 192.68.0.0/16 changed to include a SET {2,1} within its path information. This indicates that the aggregate actually summarizes routes that have passed via ASs 1 and 2. The AS-SET information becomes important in avoiding routing loops because it keeps an indication of where the route has been.



RTK#show ip bgp
BGP table version is 12, local router ID is 172.16.220.2
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.16.1.0/24 172.16.220.1 0 0 3 i
*> 172.16.10.0/24 172.16.220.1 20 0 3 i
*> 172.16.65.0/26 172.16.220.1 20 0 3 i
*> 172.16.220.0/24 172.16.220.1 0 0 3 i
*> 192.68.0.0/16 172.16.220.1 0 3 {2,1} i
*> 192.68.10.0 172.16.220.1 0 3 2 i
*> 192.68.11.0 172.16.220.1 0 3 1 i


In case the aggregate reaches AS1 or AS2, BGP's loop detection behavior will note the set information and drop the aggregate.

Given that the aggregate with the AS-SET contains information about each individual route that is summarized, changes in the individual route will cause the aggregate to be updated. In our example, if 192.68.11.0/24 goes down, the path information of the aggregate will change from 3 {2,1} to 3 2, and the aggregate will be updated. If the aggregate summarizes tens and hundreds of routes, the aggregate will be constantly flip-flopping if the routes forming the aggregate have problems.
Changing the Attributes of the Aggregate
In some situations, changing the attributes of the aggregate is required. This example shows one scenario where this could be useful.

As you have seen already, the aggregate can carry information about its individual elements if configured with the AS-SET option. If one or more of the routes forming the AS-SET aggregate are configured with "no-export" community attribute, then the aggregate itself will carry the same attribute. This will prevent the aggregate from being exported. To remedy this situation, the community attribute of the aggregate can be modified by using what Cisco calls an "attribute-map," which is another form of a routemap that applies to aggregates only.
In figure 10-13, RTC has set the community of 192.68.11.0/24 to "no-export." If RTA is aggregating 192.68.11.0/24 into 192.68.0.0/16 using AS-SET, the aggregate itself will also contain the "no-export" community. The following are the configurations of RTC and RTA, which are needed to achieve this behavior:
RTC configuration:


router bgp 1
network 192.68.11.0
neighbor 172.16.20.2 remote-as 3
neighbor 172.16.20.2 send-community
neighbor 172.16.20.2 route-map SETCOMMUNITY out
no auto-summary

access-list 1 permit 192.68.11.0 0.0.0.255

route-map SETCOMMUNITY permit 10
match ip address 1
set community no-export

route-map SETCOMMUNITY permit 20


RTA configuration:



router bgp 3
no synchronization
network 172.16.1.0 mask 255.255.255.0
network 172.16.10.0 mask 255.255.255.0
network 172.16.65.0 mask 255.255.255.192
network 172.16.220.0 mask 255.255.255.0
aggregate-address 192.68.0.0 255.255.0.0 as-set
neighbor 172.16.1.2 remote-as 3
neighbor 172.16.1.2 update-source Loopback0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.220.2 remote-as 5
no auto-summary

ip as-path access-list 10 permit ^$


Because RTA is doing the aggregation using the AS-SET, the aggregate itself will contain all the elements that the individual routes have; in particular, the community "no-export" coming from prefix 192.68.11.0/24 (originated by RTC). Note how the following display indicates that 192.68.0.0/16 is not to be advertised to EBGP peers.



RTA#show ip bgp 192.68.0.0
BGP routing table entry for 192.68.0.0 255.255.0.0, version 22
Paths: (2 available, best #2, not advertised to EBGP peer, advertised
over
IBGP)
Local (aggregated by 3 192.68.5.1)
172.16.1.2 from 172.16.1.2 (192.68.5.1)
Origin IGP, localpref 100, valid, internal, atomic-aggregate
{2,1} (aggregated by 3 172.16.2.254)
0.0.0.0
Origin IGP, localpref 100, weight 32768, valid, aggregated,
local,
best
Community: no-export


By using the "attribute-map," we can manipulate the aggregate attributes. In this example, we can set the community to "none" and allow the aggregate to be advertised to EBGP peers.

RTA configuration:


router bgp 3
no synchronization
network 172.16.1.0 mask 255.255.255.0
network 172.16.10.0 mask 255.255.255.0
network 172.16.65.0 mask 255.255.255.192
aggregate-address 192.68.0.0 255.255.0.0 as-set attribute-map
SET_ATTRIBUTE
neighbor 172.16.1.2 remote-as 3
neighbor 172.16.1.2 update-source Loopback0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.220.2 remote-as 5
no auto-summary

ip as-path access-list 10 permit ^$

route-map SET_ATTRIBUTE permit 10
set community none


The preceding RTA configuration defines an "attribute-map" called SET_ATTRIBUTE that sets the community attribute of the aggregate to none. Note how the following display shows that the aggregate 192.68.0.0/16 is now being advertised to EBGP peers.



RTA#show ip bgp 192.68.0.0
BGP routing table entry for 192.68.0.0 255.255.0.0, version 10
Paths: (2 available, best #2, advertised over IBGP, EBGP)
Local (aggregated by 3 192.68.5.1)
172.16.1.2 from 172.16.1.2 (192.68.5.1)
Origin IGP, localpref 100, valid, internal, atomic-aggregate
{2,1} (aggregated by 3 172.16.2.254)
0.0.0.0
Origin IGP, localpref 100, weight 32768, valid, aggregated,
local,
best






Previous
Table of Contents
Next