| Previous | Table of Contents | Next |
Note that the aggregate-address command in both the RTA and RTF configurations does not include the summary-only parameter, so both the aggregate and specific routes will be advertised. The following output of RTC's BGP table shows that RTC has learned the aggregate 172.16.0.0/16 in addition to the more specific routes. RTD will also receive the same information.
RTC#sh ip bgp
BGP table version is 28, local router ID is 192.68.11.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
* i172.16.0.0 192.68.6.1 100 0 3 i
*> 172.16.20.2 0 3 i
* i172.16.1.0/24 192.68.6.1 0 100 0 3 i
*> 172.16.20.2 0 0 3 i
* i172.16.10.0/24 192.68.6.1 0 100 0 3 i
*> 172.16.20.2 20 0 3 i
* i172.16.65.0/26 192.68.6.1 0 100 0 3 i
*> 172.16.20.2 20 0 3 i
* i172.16.220.0/24 192.68.6.1 20 100 0 3 i
*> 172.16.20.2 0 0 3 i
*>i192.68.10.0 192.68.6.1 0 100 0 i
*> 192.68.11.0 0.0.0.0 0 32768 i
Using the community "no-export" attribute, RTA and RTF can instruct RTC and RTD not to export the more specific routes and to only send the aggregate 172.16.0.0/16 toward AS4. This is very useful in controlling routing table expansion, assuming that AS4 can get by using the aggregate route only. The following is the needed configuration on RTF; RTA will have the same relative configuration.
RTF 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
neighbor 172.16.2.254 remote-as 3
neighbor 172.16.2.254 next-hop-self
neighbor 192.68.5.2 remote-as 1
neighbor 192.68.5.2 send-community
neighbor 192.68.5.2 route-map SETCOMMUNITY out
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
access-list 101 permit ip 172.16.0.0 0.0.255.255 host 255.255.0.0
route-map SETCOMMUNITY permit 10
match ip address 101
route-map SETCOMMUNITY permit 20
set community no-export
In the preceding configuration, RTF will use multiple instances of a route map SETCOMMUNITY to assign the more specific routes 172.16.1.0/24, 172.16.220.0/24, 172.16.10.0/24, and 172.16.65.0/26 with community "no-export," which instructs RTD not to send these routes to exterior ASs such as AS4. On the other hand, the aggregate itself, 172.16.0.0/16, is passed as is without any community and will be sent to AS4.
Instance 10 of the route map uses an extended access-list 101, which matches on the aggregate 172.16.0.0/16 only. Note how the host 255.255.0.0 part of the access list makes sure that no other entry that starts with 172.16 matches by specifiying the mask to be exactly 255.255.0.0 and nothing else. Instance 10 does not set any community values; hence, the aggregate will be passed as is.
Instance 20 will make sure that all the more specific routes will have a community "no-export."
The following are the required RTC and RTD configurations:
RTC configuration:
router bgp 1
no synchronization
network 192.68.11.0
neighbor 172.16.20.2 remote-as 3
neighbor 192.68.6.1 remote-as 1
neighbor 192.68.6.1 next-hop-self
neighbor 192.68.6.1 send-community
no auto-summary
RTD configuration:
router bgp 1
no synchronization
network 192.68.10.0
neighbor 192.68.5.1 remote-as 3
neighbor 192.68.6.2 remote-as 1
neighbor 192.68.6.2 next-hop-self
neighbor 192.68.10.2 remote-as 4
no auto-summary
Note the send-community neighbor parameter in RTC's configuration. Because RTA is also performing the same aggregation, RTD will receive the specific routes from its IBGP session with RTC. If RTC does not propagate the "no-export" community to RTD, RTD will advertise the specific routes to external peers.
The following are selected entries in RTD's BGP table. The first entry indicates that prefix 172.16.220.0/24 is not advertised to EBGP peer. This is because RTA and RTF have set this prefix (and all other specific routes) with community no-export. The second entry indicates that the aggregate itself has been originated by RTA and RTF as is. The aggregate will be passed on to AS4.
RTD#sh ip bgp 172.16.220.0
BGP routing table entry for 172.16.220.0/24, version 5
Paths: (2 available, best #2, not advertised to EBGP peer)
3
192.68.5.1 from 192.68.5.1
Origin IGP, metric 20, valid, external
Community: no-export
3
192.68.6.2 from 192.68.6.2 (192.68.11.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: no-export
RTD#sh ip bgp 172.16.0.0
BGP routing table entry for 172.16.0.0/16, version 8
Paths: (2 available, best #1, advertised over IBGP, EBGP)
3, (aggregated by 3 192.68.5.1)
192.68.5.1 from 192.68.5.1
Origin IGP, valid, external, atomic-aggregate, best
3, (aggregated by 3 172.16.2.254)
192.68.6.2 from 192.68.6.2 (192.68.11.1)
Origin IGP, localpref 100, valid, internal, atomic-aggregate
Looking at the BGP table of RTG, you will note that only the aggregate 172.16.0.0/16 has been propagated from AS3 to AS4. All the more specific routes do not show up.
RTG#sh ip bgp
BGP table version is 14, local router ID is 192.68.10.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.0.0 192.68.10.1 0 1 3 i
*> 192.68.10.0 192.68.10.1 0 0 1 i
*> 192.68.11.0 192.68.10.1 0 1 i
| Previous | Table of Contents | Next |