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



























Previous
Table of Contents
Next




The Community Attribute
This example shows how the community attribute can be used to dynamically influence the routing decisions of another AS. With the network illustrated in figure 10-9, the following configuration example shows how AS3 can advertise route 172.16.65.0/26 to AS1 and dynamically instruct AS1 not to advertise this route externally. AS3 will assign route 172.16.65.0/26 the community attribute "no-export" when advertising it to AS1.


Figure 10-9  Setting the community attribute.

Notes:  The send-community option in the neighbor router subcommand is used to cause the assigned community to be sent out.

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
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 send-community
neighbor 172.16.20.1 route-map SETCOMMUNITY out
no auto-summary

access-list 1 permit 172.16.65.0 0.0.0.63

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

route-map SETCOMMUNITY permit 20


The preceding RTA configuration shows that RTA has defined a route map SETCOMMUNITY toward neighbor 172.16.20.1 (RTC). Instance 10 of the the route map will match on prefix 172.16.65.0/26 and will set its community attribute to no-export. The send-community keyword assigned to the neighbor session is required to enable the community attribute to be sent to the specified neighbor. Instance 20 of the route map will enable all other networks to be passed with no change.
RTC's BGP entry for 172.16.65.0/26 will show the following:


RTC#sh ip bgp 172.16.65.0 255.255.255.192
BGP routing table entry for 172.16.65.0/26, version 3
Paths: (1 available, best #1, not advertised to EBGP peer)
3
172.16.20.2 from 172.16.20.2 (172.16.2.254)
Origin IGP, metric 20, valid, external, best
Community: no-export


Note how the entry has been assigned the community no-export and instructions that it is not to be advertised to EBGP peers. RTC will not propagate this entry to its external peer RTD. Note that in the following RTD BGP table, RTD did not receive an update about 172.16.65.0/26.



RTD#sh ip bgp
BGP table version is 22, local router ID is 192.68.10.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.16.1.0/24 192.68.6.2 0 1 3 i
*> 172.16.10.0/24 192.68.6.2 0 1 3 i
*> 172.16.220.0/24 192.68.6.2 0 1 3 i
*> 192.68.10.0 0.0.0.0 0 32768 i
*> 192.68.11.0 192.68.6.2 0 0 1 i


BGP4 Aggregation
The following examples demonstrate different methods of aggregation that are seen on the Internet. The way aggregates are formed and advertised and whether they carry with them more specific routes will influence traffic patterns and sizes of BGP routing tables. Remember that aggregation applies to routes that exist in the BGP routing table. An aggregate can be sent if at least one more specific route of that aggregate exists in the BGP table.

Aggregate Only, Suppressing the More Specific
This example shows how an aggregate can be generated without propagating any of the more specific routes that fall under the aggregate. In the network illustrated in figure 10-10, RTA is sending prefixes 172.16.220.0/24, 172.16.1.0/24, 172.16.10.0/24, and 172.16.65.0/26 toward RTC. The following configuration shows how RTA can aggregate all these routes into a single prefix 172.16.0.0/16 and send it to RTC. This of course assumes that AS3 is the sole owner of the class B 172.16.0.0/16. RTF is also doing the same aggregation on its end with a configuration similar to RTA.


Figure 10-10  BGP aggregation (suppressing the specific routes).
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 172.16.0.0 255.255.0.0 summary-only
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
no auto-summary

ip as-path access-list 10 permit ^$


RTA's configuration uses the aggregate-address command to aggregate all the more specific routes of 172.16.0.0/16 into a single address. RTA's BGP table (illustrated in the show command output that follows) indicates that a new aggregate 172.16.0.0/16 has been originated by this router (next hop is 0.0.0.0), whereas all the more specific prefixes have been suppressed (note the "s" at the far left). In this case, the same result could have been achieved by using auto-summary.



RTA#sh ip bgp
BGP table version is 14, local router ID is 172.16.2.254
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.0.0 0.0.0.0 32768 i
* i 172.16.1.2 100 0 i
s> 172.16.1.0/24 0.0.0.0 0 32768 i
s> 172.16.10.0/24 172.16.1.2 20 32768 i
s> 172.16.65.0/26 172.16.1.2 20 32768 i
s> 172.16.220.0/24 0.0.0.0 0 32768 i
* 192.68.10.0 172.16.20.1 0 1 2 i
*>i 172.16.1.2 0 100 0 2 i
*> 192.68.11.0 172.16.20.1 0 0 1 i






Previous
Table of Contents
Next