Chapter 10. Configuring Basic BGP Functions and Attributes
This chapter covers the following key topics:
- • Building Peering Sessions
Configuration examples for the first step in the routing task. This section overviews basic syntax used in configuration code.- • Route Filtering and Attribute Manipulation
BGP route maps, filtering based on NLRI, and filtering based on AS_path.- • Peer Groups
Configuration examples of defining and utilizing peer groups.- • Sources of Routing Updates
Dynamic and static configuration for injecting information into BGP.- • Overlapping Protocols (Backdoors)
Configuration examples for changing the distance parameter to favor certain routes over others.- • BGP Attributes
Configuration examples for NEXT_HOP, AS_PATH, local preference, MED, and cummunity attributes.- • BGP4 Aggregation
Configuration examples for various aggregation scenarios. - • Route Filtering and Attribute Manipulation
This is the first of two chapters consisting primarily of configuration examples. Having covered all the important, prerequisite concepts, you can delve into these examples of how to write the code for basic BGP functions and attributes. This chapter focuses on those basics, and the next chapter considers some of the more complex design-oriented configuration problems.
Even if you have been using the references in previous chapters to flip ahead to these configuration examples, you are encouraged to reexamine them now, with the benefit of having read and assimilated all the concept-oriented chapters. In addition to the configuration code itself, be sure to look at the many routing tables that are included; they are intended to solidify your understanding of what results to expect.
Chapters 10 and 11 are not intended to replace Cisco manuals and do not cover every command and scenario. They present configurations for common situations that are encountered in connecting networks to the Internet. Your particular network might require a combination of scenarios—or a different approach—to achieve the most effective policies.
In the following discussions, an AS could play the role of a customer, provider, or both. Do not get confused by having AS numbers and AS roles being switched around, or by IP address numbering not being too realistic. These are just exercises that will help you understand BGP so that you can apply it accordingly in your own environment.
Building Peering Sessions
This example demonstrates the different types of BGP peering sessions you will encounter. Consider figure 10-1. An IBGP peering session is formed within AS3, between the loopback address of RTA and a physical address of RTF. An EBGP session is also formed between AS3 and AS1 by using the two directly connected IP addresses of RTA and RTC. Another EBGP session is formed between RTF in AS3 and RTD in AS2, using IP addresses that are not on the same segment (multihop).
Figure 10-1 Building
peering sessions.
It is important to remember that the BGP peers will never become established unless there is an IGP connectivity between the two peers or the two peers are on the same segment. We will use OSPF as an IGP to establish the required internal connectivity.
RTA's configuration is:
ip subnet-zero
interface Loopback0
ip address 172.16.2.254 255.255.255.255
interface Ethernet1
ip address 172.16.1.1 255.255.255.0
interface Serial0
ip address 172.16.20.2 255.255.255.0
router ospf 10
network 172.16.0.0 0.0.255.255 area 0
router bgp 3
no synchronization
neighbor 172.16.1.2 remote-as 3
neighbor 172.16.1.2 update-source Loopback0
neighbor 172.16.20.1 remote-as 1
no auto-summary
ip classless
RTA's configuration shows some syntax that might be unfamiliar to you. All the syntax is explained here generically, as well as in relation to the particular routing scenario of figure 10-1. In subsequent examples throughout this chapter, however, the router's configuration will be reduced to necessary commands to configure BGP or IGP. Commands that assign IP addresses to interfaces will be omitted in many cases due to space limitations.
- • ip subnet-zero: This global
configuration command is necessary in case you are configuring
interfaces that fall in subnet-zero subnets. With the introduction
of classless routing, using subnet-zero is very common.
- • interface type slot/port: This command configures an interface type and number on the router. Any configuration that appears under the command will be specific to that particular interface. Note that RTA has three interface commands, one for each of its three connections. The loopback interface is a software-only interface that emulates an interface that is always up.
- • ip address ip-address mask [secondary]: This is an interface command that configures an interface with an IP address/mask tuple. RTA's Ethernet IP address, for example, is configured by: ip address 172.16.1.1 255.255.255.0.
- • router process [process-id]: This is a global command that defines a process such as OSPF, RIP, or BGP, and gives the process a process ID. Some processes such as RIP do not require a process ID.
In RTA's configuration, "router ospf 10," for example, indicates an OSPF process with ID 10, whereas "router bgp 3" indicates a BGP process in autonomous system 3.- • network: This command indicates the networks or, in the case of OSPF, the interfaces that will run under a specific router process.
- • inverse mask: In RTA's network command, you will notice a representation of the form 0.0.255.255 or basically a number of 0s followed with a number of 1s. This is an inverse mask with the 0s being an exact match, and the 1s being do-not-care-bits. For example: 172.16.0.0 0.0.255.255 indicates any IP address or network of the form 172.16.X.X. Inverse masks can be applied to access lists as well as the network command.
- • area area-number: This is a representation of an OSPF area with a specified area number.
- • neighbor: This command is used to define the BGP neighbor connection parameters and policies between this router and its peers. In RTA's configuration, "neighbor 172.16.1.2 remote-as 3," for example, is an indication that a BGP peer session is to be established between RTA and peer 172.16.1.2 in autonomous system 3.
- • no synchronization: This command turns the synchronization off between BGP and IGP, as explained in Chapter 5, "Tuning BGP Capabilities."
- • no auto-summary: This command will turn off the BGP automatic summarization at the major net boundary. Without this command, BGP will not send the subnets of a major net that are redistributed into BGP; that is, updates about 172.16.1.0/24, 172.16.2.0/24, and so on will be sent as a single major class B 172.16.0.0/16. Summarization at the major net boundary should be done only if the AS is the owner of the whole major net.
- • ip classless: This command enables the router to forward packets that are destined for unrecognized subnets of directly connected networks. By default, when a router receives packets for a subnet that falls numerically within its subnetwork addressing scheme, if there is no such subnet number in the routing table and there is no network default route, the router discards the packets. When the ip classless command is enabled, however, the router forwards those packets to the best supernet route.
- • update-source interface: This command, when associated with the BGP neighbor statement, specifies the interface to be used as a source IP address of the BGP session with the neighbor. In RTA's configuration, for example, the second neighbor statement indicates that Loopback 0 is to be used as a source IP address.
- • remote-as: This command, when associated with the BGP neighbor statement, specifies the AS number of the remote BGP peer. In RTA's configuration, the first neighbor statement indicates that the internal BGP neighbor 172.16.1.2 belongs to the local AS3. The third neighbor statement indicates that the external BGP peer 172.16.20.1 belongs to AS1.
- • interface type slot/port: This command configures an interface type and number on the router. Any configuration that appears under the command will be specific to that particular interface. Note that RTA has three interface commands, one for each of its three connections. The loopback interface is a software-only interface that emulates an interface that is always up.
We turn now to RTF's configuration.
ip subnet-zero
interface Ethernet1/1
ip address 172.16.1.2 255.255.255.0
interface Serial2/1
ip address 192.68.5.1 255.255.255.0
router ospf 10
network 172.16.0.0 0.0.255.255 area 0
network 192.68.0.0 0.0.255.255 area 0
router bgp 3
no synchronization
neighbor 172.16.2.254 remote-as 3
neighbor 192.68.12.1 remote-as 2
neighbor 192.68.12.1 ebgp-multihop 2
no auto-summary
ip classless
In RTF's configuration, you can see the ebgp-multihop 2 command being used as part of the neighbor configuration. This is an indication that the exterior BGP peer is not directly connected and can be reached at maximum two hops away. Remember that ebgp-multihop is only applicable with EBGP and not IBGP.
RTC configuration:
ip subnet-zero
interface Serial2/1
ip address 172.16.20.1 255.255.255.0
router bgp 1
neighbor 172.16.20.2 remote-as 3
no auto-summary
ip classless
RTD configuration:
ip subnet-zero
interface Serial0/0
ip address 192.68.12.1 255.255.255.0
router ospf 10
network 192.68.0.0 0.0.255.255 area 0
router bgp 2
neighbor 192.68.5.1 remote-as 3
neighbor 192.68.5.1 ebgp-multihop 2
no auto-summary
ip classless
The following is an example of how the peer connection will look after the neighbors are in an established state. From RTF's point of view, neighbor 172.16.2.254 is an internal neighbor that belongs to AS3. The neighbor connection is running BGP version 4 with a table version of 2. The table version changes every time the BGP table gets updated. A table version that increments rapidly is an indication of an unstable BGP neighbor session.
RTF's other neighbor 192.68.12.1 is also in an established state. This is an external neighbor that belongs to AS2. Note that the display indicates that this neighbor is two hops away (as configured in the ebgp-multihop).
RTF#show ip bgp neighbor
BGP neighbor is 172.16.2.254, remote AS 3, internal link
BGP version 4, remote router ID 172.16.2.254
BGP state = Established, table version = 2, up for 22:36:09
Last read 00:00:10, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 5 seconds
Received 1362 messages, 0 notifications, 0 in queue
Sent 1362 messages, 0 notifications, 0 in queue
Connections established 2; dropped 1
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 172.16.1.2, Local port: 11008
Foreign host: 172.16.2.254, Foreign port: 179
BGP neighbor is 192.68.12.1, remote AS 2, external link
BGP version 4, remote router ID 192.68.5.2
BGP state = Established, table version = 2, up for 22:13:01
Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 1336 messages, 0 notifications, 0 in queue
Sent 1336 messages, 0 notifications, 0 in queue
Connections established 1; dropped 0
External BGP neighbor may be up to 2 hops away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 192.68.5.1, Local port: 11016
Foreign host: 192.68.12.1, Foreign port: 179
Route Filtering and Attribute Manipulation
Route filtering and attribute manipulation are the basis of setting BGP policies. This section will describe the following:
- • BGP route maps
- • Identifying and filtering routes based on the NLRI
- • Identifying and filtering routes based on the AS_path
- • Identifying and filtering routes based on the NLRI
For new BGP configuration, such as attribute manipulation or filtering, to take place, you should reset the BGP session by using the following command:
clear ip bgp [* | address | peer-group][soft [in|out]]
Refer to Chapter 11, "Configuring Effective Internet Routing Policies," for more details.
BGP Route Maps
Route maps are used with BGP to control and modify routing information and to define the conditions by which routes are redistributed between routing domains.
The format of a route map is as follows:
route-map map-tag [permit | deny] [sequence-number]
The map tag is a name that identifies the route map, and the sequence number indicates the position that an instance of the route map is to have in relation to other instances of the same route map. (Instances are ordered sequentially.)
You might, for example, use the following commands to define a route map named MYMAP:
route-map MYMAP permit 10
! First set of conditions goes here.
route-map MYMAP permit 20
! Second set of conditions goes here.
When BGP applies MYMAP to routing updates, it applies the lowest instance first (in this case, instance 10). If the first set of conditions is not met, the second instance is applied, and so on, until either a set of conditions has been met, or there are no more sets of conditions to apply.
The condition portion of a route map is set by using the match and set commands. The match command specifies criteria that must be matched, and the set command specifies an action that is to be taken if the routing update meets the conditions defined by the match command.
Following is an example of a simple route map:
route-map MYMAP permit 10
match ip address 1
set metric 5
access-list 1 permit 1.1.1.0 0.0.0.255
The access list is a way to identify routes. There are two types of access lists, standard and extended; the main difference is that a standard access list is applied to the source IP address, whereas an extended access list is applied to source and destination or source and network mask. The following global command defines a standard access list; the extended access list will be covered in this chapter at the point it is used in context.
access-list access-list-number {deny | permit} source [source-wildcard]
A standard access list is used to match on a particular source IP network or host, to permit or deny a specific routing update. The access list number falls between 1 and 99.
In this example, access-list 1 identifies all routes of the form 1.1.1.X (note the inverse mask notation 0.0.0.255). A routing update of the form 1.1.1.X will match the access list and will be propagated (because of the permit keyword) with a metric set to 5. The logic will then break out of the list of route map instances because a match has occurred.
When an update does not meet the criteria of a route map instance, BGP applies the next instance, and so on, until an action is taken, or there are no more routemap instances to apply. If the update does not meet any criteria, the update is not redistributed or controlled.
The route map can be applied on the incoming (in) or the outgoing (out) BGP updates. The following is an example of the route map MYMAP applied on the outgoing updates toward BGP neighbor 172.16.20.2:
router bgp 1
neighbor 172.16.20.2 remote-as 3
neighbor 172.16.20.2 route-map MYMAP out
Identifying and Filtering Routes Based on the NLRI
To restrict the routing information that the router learns or advertises, you can filter based on routing updates to or from a particular neighbor. The filter consists of an access list that is applied to updates to or from a neighbor. In figure 10-2, RTD in AS2 is originating network 192.68.10.0/24 and sending it to RTF. RTF will pass the update to RTA via IBGP, which in turn will propagate it to AS1. By doing so, AS3 could become a transit AS advertising reachability of network 192.68.10.0/24.
Figure 10-2 Identifying
and filtering prefixes.
To prevent this situation from happening, RTA will configure a filter to prevent prefix 192.68.10.0/24 from propagating to AS1. This is demonstrated in the following configuration for RTA:
router bgp 3
no synchronization
neighbor 172.16.1.2 remote-as 3
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 distribute-list 1 out
no auto-summary
access-list 1 deny 192.68.10.0 0.0.0.255
access-list 1 permit 0.0.0.0 255.255.255.255
In the preceding configuration, the combination of the neighbor distribute-list router configuration command and access-list 1 prevents RTA from propagating prefix 192.68.10.0/24 to AS1. The access list portion of the configuration identifies the prefixes, whereas the distribute list portion applies the filtering on the outgoing updates (note the out keyword). Note that access-list 1 ended with a logic that permits all updates (permit 0.0.0.0 255.255.255.255). When using access lists for filtering, if no action is specified at the end of the access list statements, the logic of "deny everything else" applies. This means that anything that did not match any of the access list instances will be denied. This is why it is important to specify the default action; in this example, 192.68.10.0/24 will be denied, and everything else will be allowed.
Notes:
Route maps could have been used to filter updates in the previous example. The distribute list method was chosen to give you different options for doing filtering.
Using access lists to filter supernets or ranges of updates is a bit trickier. Assume, for example, that RTF in figure 10-2 has different subnets of 172.16.X.X, and you want to advertise an aggregate of the form 172.16.0.0/16 only. The following standard access list would not work because it permits more than is desired. The standard access list looks at the source IP address only and cannot check the length of the network mask. The following access list will permit 172.16.0.0/16, 172.16.0.0/17, 172.16.0.0/18, and so on:
access-list 1 permit 172.16.0.0 0.0.255.255
To restrict the update to 172.16.0.0/16 only, you have to use an extended access list of the form:
access-list access-list-number {deny | permit} protocol source
source-wildcard destination destination-wildcard | mask mask-wildcard
This defines an extended access list that matches on a source destination or a source mask tuple, to permit or deny a specific routing update. The access list number falls between 100 and 199. In the case where the protocol is IP and we are checking on a source/mask tuple, this would translate into:
access-list access-list-number permit ip network-number network-do-not-care-bits mask mask-do-not-care-bits
For example:
access-list 101 permit ip 172.16.0.0 0.0.255.255 255.255.0.0 0.0.0.0
(where a "0" is an exact match bit, and a "1" is a do-not-care-bit).
The preceding extended access list indicates that aggregate 172.16.0.0/16 is to be sent only because we have indicated that the mask should match 255.255.0.0 exactly. An update of the form 172.16.0.0/17 will not be allowed.
Identifying and Filtering Routes Based on the AS_Path
Filtering routes based on AS_path information becomes handy when filtering is needed for all routes of the same or multiple ASs. It is an efficient alternative to listing hundreds of routes one-by-one as may be required to filter on a prefix basis.You can specify an access list on both incoming and outgoing updates based on the value of the AS_path attribute.
Referring still to figure 10-2, if AS3 wanted to prevent itself from becoming a transit AS for other ASs, AS3 can configure its border routers RTA and RTF to advertise only local networks. Local networks originated from the AS itself. This can be done with the following RTA configuration; RTF will be configured in the same manner.
RTA configuration:
router bgp 3
no synchronization
neighbor 172.16.1.2 remote-as 3
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 1 out
no auto-summary
ip as-path access-list 1 permit ^$
In the preceding RTA configuration, the as-path access list 1 identifies only updates that originate from AS3. The filter list works in conjunction with the as-path access list to filter the updates. In this example, the filter list is applied on the outgoing updates (note the out keyword). The regular expression ^$ indicates an AS_path that is empty. The "^" symbol indicates the beginning of the AS_path, and the "$" symbol indicates the end of the AS_path. Because all networks originating from AS3 have an empty AS_path list, they will be advertised. All other prefixes will be denied.
If you want to verify that your regular expression works as intended, use the following EXEC command:
show ip bgp regexp regular-expression
The router displays all the paths that match the specified regular expression.
Notes:
Route maps could have been used to filter updates in the previous example. The filter list was chosen to give you a different option for filtering.
Peer Groups
A BGP peer group is a group of BGP neighbors that share the same update policies. Update policies are usually set by route maps, distribution lists, and filter lists. Instead of defining the same policies for each individual neighbor, you define a peer group name and assign policies to the peer group.
The use of BGP peer groups is demonstrated by the network shown in figure10-3. RTC forms similar internal peering sessions with RTD, RTE, and RTH. Instead of formulating and applying similar policies for each neighbor individually, RTC would define a peer group that contains the policies and would apply the peer group to its internal neighbors.
Figure 10-3 BGP peer
groups.
RTC configuration:
router bgp 1
neighbor INTERNALMAP peer-group
neighbor INTERNALMAP remote-as 1
neighbor INTERNALMAP route-map INTERNAL out
neighbor INTERNALMAP filter-list 1 out
neighbor INTERNALMAP filter-list 2 in
neighbor 172.16.11.1 peer-group INTERNALMAP
neighbor 172.16.13.1 peer-group INTERNALMAP
neighbor 172.16.12.1 peer-group INTERNALMAP
neighbor 172.16.12.1 filter-list 3 in
The preceding configuration defines a peer group called INTERNALMAP that contains the following policies:
- • A route map named INTERNAL
- • A filter list for outgoing updates (filter list 1)
- • A filter list for incoming updates (filter list 2)
- • A filter list for outgoing updates (filter list 1)
The configuration applies the peer group to all internal neighbors—RTD, RTE, and RTH.
Members of a peer group inherit all the configuration options of the peer group. Peer group members can also be configured to override configuration options if the options do not affect outgoing updates. That is, peer group members can be configured to override options that affect incoming policies. The configuration of RTC, for example, also defines a filter-list 3 for incoming updates from the neighbor at IP address 172.16.12.1 (RTH). Filter-list 3 will override any incoming policies set by the peer group INTERNALMAP for neighbor RTH.
The following commands configure a BGP peer group named EXTERNALMAP on RTC and apply it to the exterior neighbors in AS3 and AS2:
RTC configuration:
router bgp 1
neighbor EXTERNALMAP peer-group
neighbor EXTERNALMAP route-map SETMED out
neighbor EXTERNALMAP filter-list 1 out
neighbor EXTERNALMAP filter-list 2 in
neighbor 172.16.20.2 remote-as 3
neighbor 172.16.20.2 peer-group EXTERNALMAP
neighbor 172.16.20.3 remote-as 2
neighbor 172.16.20.3 peer-group EXTERNALMAP
neighbor 172.16.20.3 filter-list 3 in
ip as-path access-list 1 permit ^$
In the preceding configuration, the neighbor remote-as router configuration commands are placed outside the neighbor peer-group router configuration commands because different external ASs have to be defined. Also note that this configuration defines filter-list 3, which can be used to override configuration options for incoming updates from the neighbor at IP address 172.16.20.3 (RTF).
Note that the external BGP neighbors RTA and RTF that belong in the same peer group EXTERNALMAP were taken from the same subnet 172.16.20.0. This restriction is needed to prevent loss of information. Placing the external neighbors in different subnets could result in RTC sending updates to its neighbors (RTA and RTF) with a non-connected next hop IP address. These updates would be dropped due to the normal EBGP behavior of ignoring routes with non-connected next hop (remember that ebgp-multihop was implemented to override this behavior).
Another restriction that also applies is that peer groups should not be set on EBGP neighbors if the router is acting as a transit between these neighbors. If the router (RTC) is passing updates from one external neighbor to the other, placing external neighbors in peer groups might result in routes being mistakenly removed. Note that filter-list 1 has been defined to allow AS1's local routes only to be sent to neighbors RTA and RTF. This way RTC will not act as a transit router between RTA and RTF.
As you can see, using peer groups with external BGP peers is no longer intuitive because of limiting restrictions. Using peer groups with EBGP peers should be done with care in order not to cause loss of routes.
Sources of Routing Updates
Routes can be injected dynamically or statically into BGP. The choice of method depends on the number and stability of routes.
Injecting Information Dynamically into BGP
The following example demonstrates how routing information can be injected dynamically into BGP. Consider figure 10-4. Assume that AS3 is getting Internet connectivity from AS1. AS3 is running OSPF as an IGP inside the AS and is running EBGP with AS1.
Figure 10-4 Injecting
routes into BGP.
On the other hand, AS3 has also one customer, C1, with the following criteria:
- • C1 is pointing a default toward AS3.
- • C1 advertises all its routes to AS3 via RIP.
RTF is running two routing processes, the OSPF process and the RIP process. RTF will only listen to RIP on its connection to C1 and will redistribute the RIP updates it gets from C1 into OSPF. On the other hand, RTA will run two routing processes, the OSPF process and the BGP process. RTA will inject all its routes and customer routes dynamically into BGP.
RTF configuration:
interface Ethernet1/0
ip address 172.16.65.1 255.255.255.192
interface Ethernet1/1
ip address 172.16.1.2 255.255.255.0
interface Serial2/1
ip address 192.68.5.1 255.255.255.0
router ospf 10
redistribute rip subnets
network 172.16.0.0 0.0.255.255 area 0
router rip
passive-interface Serial2/1
network 192.68.5.0
interface Ethernet1/1
ip address 192.68.10.1 255.255.255.0
interface Serial0/0
ip address 192.68.5.2 255.255.255.0
router rip
redistribute static
network 192.68.5.0
network 192.68.10.0
default-metric 1
ip route 0.0.0.0 0.0.0.0 192.68.5.1
Note that RTD has configured a static route pointing a 0/0 default toward RTF. For all destinations that are outside C1, RTD will direct the traffic to RTF. RTD will also redistribute the static default route into the internal RIP domain so that all other routers can follow a default toward AS3. The default-metric router command assigns a metric to the routes redistributed into a particular protocol. In this case, the default-metric assigns a hop count of 1 to the 0/0 route injected into RIP.
RTA configuration:
interface Ethernet0
ip address 172.16.220.1 255.255.255.0
interface Ethernet1
ip address 172.16.1.1 255.255.255.0
interface Serial0
ip address 172.16.20.2 255.255.255.0
router ospf 10
passive-interface Serial 0
network 172.16.0.0 0.0.255.255 area 0
router bgp 3
redistribute ospf 10 match external 1 external 2
neighbor 172.16.20.1 remote-as 1
no auto-summary
RTA has a combination of OSPF routes that belong to AS3 and other external routes that came in from the RIP domain C1. Using the redistribute router command, RTA will dynamically inject all these routes into its BGP process. Note that RTA is using the keywords "match external 1 external 2" in conjunction with the redistribute router command. This is because OSPF does not inject external OSPF routes into BGP unless it is specifically instructed to do so. This measure was put in for loop avoidance in case the external OSPF information came from BGP.
The following is a snapshot of what the IP routing table of RTA looks like:
RTA#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is not set
O E2 192.68.5.0/24 [110/20] via 172.16.1.2, 2d13h, Ethernet1
O E2 192.68.10.0/24 [110/20] via 172.16.1.2, 2d13h, Ethernet1
B 192.68.11.0/24 [20/0] via 172.16.20.1, 2d13h
172.16.0.0/16 is variably subnetted, 5 subnets, 3 masks
C 172.16.2.254/32 is directly connected, Loopback0
C 172.16.220.0/24 is directly connected, Ethernet0
C 172.16.20.0/24 is directly connected, Serial0
C 172.16.1.0/24 is directly connected, Ethernet1
O 172.16.65.0/26 [110/20] via 172.16.1.2, 2d13h, Ethernet1
Note in RTA's IP table how networks 192.68.10.0/24 and 192.68.5.0/24 are listed as external OSPF routes (O E2). Dynamic redistribution will cause all these networks to be sent into BGP. The following is how the BGP table of RTC would look:
RTC#sh ip bgp
BGP table version is 20, 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
*> 172.16.1.0/24 172.16.20.2 0 0 3 ?
*> 172.16.2.254/32 172.16.20.2 0 0 3 ?
*> 172.16.20.0/24 172.16.20.2 0 0 3 ?
*> 172.16.65.0/26 172.16.20.2 20 0 3 ?
*> 172.16.220.0/24 172.16.20.2 0 0 3 ?
*> 192.68.5.0 172.16.20.2 20 0 3 ?
*> 192.68.10.0 172.16.20.2 20 0 3 ?
*> 192.68.11.0 0.0.0.0 0 32768 i
Note how all networks running OSPF in AS3 have become BGP routes in AS1. Usually, not every network that belongs to your AS needs to be sent via BGP. You might be running private or illegal network numbers inside the AS that need not be advertised. Note how the loopback address 172.16.2.254/32 was also injected into BGP. No provider will enable you to advertise such prefixes and will instruct you to filter them, or the provider might filter them on its end. This restriction is put in place to make sure that customers are aggregating their routes as much as possible to prevent the explosion of the global IP routing tables. Also, the DMZ network 172.16.20.0/24 has been injected into BGP, which is not necessary. This is why redistribution should be accompanied by filtering to specify the exact routes that need to be advertised.
The following configuration of RTA gives an example of how filtering could be applied.
Notes:
From now on, due to space limitations, configuration examples will focus on commands that are directly relevant to the discussion at hand. Do not be alarmed if you notice commands that are missing, such as interface commands.
router ospf 10
passive-interface Serial0
network 172.16.0.0 0.0.255.255 area 0
router bgp 3
redistribute ospf 10 match external 1 external 2
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 route-map BLOCKROUTES out
no auto-summary
access-list 1 permit 172.16.2.254 0.0.0.0
access-list 1 permit 172.16.20.0 0.0.0.255
route-map BLOCKROUTES deny 10
match ip address 1
route-map BLOCKROUTES permit 20
Filtering in the preceding example was performed with a route map, which is an indication of a set of actions to be taken in case certain criteria are found. Our criteria here are to find a match on the host route 172.16.2.254/32 and the network 172.16.20.0/24 and to prevent them from being sent via BGP. The access-list 1 will enable us to find a match on these routes, and the route map BLOCKROUTES specifies that they are to be denied. The second instance of the route map (20) permits all other routes to be injected into BGP. (Refer to the discussion of filtering in Chapter 5 for more details.)
This is how the BGP table of RTC would look after filtering has been applied. The host route 172.16.2.254/32 and the network 172.16.20.0/24 do not show anymore.
RTC#sh ip bgp
BGP table version is 34, 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
*> 172.16.1.0/24 172.16.20.2 0 0 3 ?
*> 172.16.65.0/26 172.16.20.2 20 0 3 ?
*> 172.16.220.0/24 172.16.20.2 0 0 3 ?
*> 192.68.5.0 172.16.20.2 20 0 3 ?
*> 192.68.10.0 172.16.20.2 20 0 3 ?
*> 192.68.11.0 0.0.0.0 0 32768 i
To have better control over what is being redistributed from the IGP into BGP, the network command can be used. The network command is a way to individually listing the prefixes that need to be sent via BGP. The network command has a limit of 200. If more than 200 networks need to be listed, dynamic redistribution is a must. The network command specifies the prefix to be sent out (network and mask). The statement "network 172.16.1.0 mask 255.255.255.0," for example, is an indication for prefix 172.16.1.0/24 to be sent. Networks that fall on a major net boundary (255.0.0.0, 255.255.0.0, or 255.255.255.0) do not need to have the mask included; for example, the statement "network 172.16.0.0" is sufficient to send the prefix 172.16.0.0/16. Such networks are also listed in the BGP routing table without the /x notation. For example, the class C network 192.68.11.0 is equivalent to 192.68.11.0/24.
Considering figure 10-4, the following configuration of RTA will specify the networks that will be injected into BGP.
RTA configuration:
router ospf 10
passive-interface Serial0
network 172.16.0.0 0.0.255.255 area 0
router bgp 3
network 172.16.1.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
network 192.68.5.0
network 192.68.10.0
neighbor 172.16.20.1 remote-as 1
no auto-summary
The following is what the BGP table of RTC would look like. All routes have been injected into BGP except for 172.16.2.254/32 and 172.16.20.0/24. Note that the table looks similar to the one produced when redistributing the OSPF routes into BGP and applying filters. The only noticeable difference is with the origin code, which is indicated by the "i" at the end of the path information. The "i" origin code indicates that the source of these networks is internal (IGP) to the originating AS. If you look at the previous snapshot of RTC's BGP table, the origin code was "?", meaning incomplete, which is an indication that the origin of these networks is learned by some other means. Anytime routes are injected into BGP via redistribution, the origin code would be incomplete.
RTC#sh ip bgp
BGP table version is 34, 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, i - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 172.16.20.2 0 0 3 i
*> 172.16.65.0/26 172.16.20.2 20 0 3 i
*> 172.16.220.0/24 172.16.20.2 0 0 3 i
*> 192.68.5.0 172.16.20.2 20 0 3 i
*> 192.68.10.0 172.16.20.2 20 0 3 i
*> 192.68.11.0 0.0.0.0 0 32768 i
The network command only takes effect if the prefixes listed are known to the router—that is, BGP will not go blindly advertising prefixes just because they were listed. The router will check for the availability of an exact match of the prefix in the IP routing table before the network is advertised. In the preceding example, if we list "network 172.16.192.0 mask 255.255.255.0," that network will not be originated because it is unknown by the router.
Injecting Information Statically into BGP
Listing prefixes with the network command has the same drawbacks as dynamic redistribution. If a route that is listed with the network command goes down, BGP will send an update; if the route comes back, BGP will send another update. If this behavior continues, the IGP instability will translate into BGP instabilities. The only way around this is to use a combination of statically defined prefixes in conjuction with the network command. This will make sure that the prefixes will always remain in the IP routing tables and will always be advertised.
In the previous example, if you wanted to make sure that the fluctuations of route 192.68.10.0/24 do not translate into fluctuations in the BGP, you would include in RTA a static route of the form:
ip route 192.68.10.0 255.255.255.0 Ethernet1
By using the static approach, the prefix entry will always be present in the IP routing table and will always be advertised. The drawback of this approach is that even when a route is down, it will still be advertised by BGP. Considering the gain in network stability compared to the damage an ill-behaved route or multiple ill-behaved routes can cause, administrators may find this approach very efficient.
RTA configuration:
router bgp 3
network 172.16.1.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
network 192.68.5.0
network 192.68.10.0
neighbor 172.16.20.1 remote-as 1
no auto-summary
ip route 192.68.10.0 mask 255.255.255.0 Ethernet1
Overlapping Protocols: (Backdoors)
This example shows how the backdoor command can be used to change the EBGP distance to have IGP routes favored over EBGP routes for specific network numbers.
In Figure 10-5, AS2 is running an IGP (OSPF) on the private link between it and AS1, and is running EBGP with AS3. RTC, in AS1, will receive advertisements about 192.68.10.0/24 from AS3 via EBGP with a distance of 20 and from AS2 via OSPF with a distance of 110. Because the lower distance is preferred, RTC will use the BGP link to AS3 to reach 192.68.10.0/24.
Figure 10-5 BGP backdoor
routes.
Looking at RTC's IP routing table, you see the following:
RTC#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
* - candidate default U - per-user static route
Gateway of last resort is not set
C 192.68.6.0/24 is directly connected, Ethernet0/1
B 192.68.10.0/24 [20/0] via 172.16.20.2, 00:21:36
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.20.0/24 is directly connected, Serial2/1
B 172.16.1.0/24 [20/0] via 172.16.20.2, 00:21:37
B 172.16.65.0/26 [20/20] via 172.16.20.2, 00:21:37
Prefix 192.68.10.0/24 is indeed learned via BGP. RTC will take the longer path via AS3 (next hop 172.16.0.2) to reach 192.68.10.0/24. Note the distance of [20] that the EBGP route has. If you wanted to have RTC prefer the OSPF entry, you would configure RTC in the following way:
RTC configuration:
router bgp 1
neighbor 172.16.20.2 remote-as 3
network 192.68.10.0 backdoor
no auto-summary
The preceding configuration, "network 192.68.10.0 backdoor," changes the distance of the BGP route 192.68.10.0/24 from 20 to 200, which makes the OSPF route with a distance of 110 more preferred. Note that "network 192.68.10.0 backdoor" entry will not cause BGP to generate an advertisement for that network.
Following is the new routing table of RTC. Note that the 192.68.10.0/24 entry is now learned via OSPF with distance [110], and the private link between AS1 and AS2 will be used.
RTC#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
* - candidate default U - per-user static route
Gateway of last resort is not set
C 192.68.6.0/24 is directly connected, Ethernet0/1
O IA 192.68.10.0/24 [110/20] via 192.68.6.1, 00:00:21, Ethernet0/1
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.20.0/24 is directly connected, Serial2/1
B 172.16.1.0/24 [20/0] via 172.16.20.2, 00:29:07
B 172.16.65.0/26 [20/20] via 172.16.20.2, 00:29:07
BGP Attributes
In this section, we will work with the network topology illustrated in figure 10-6 to demonstrate how the different BGP attributes are used.
Figure 10-6 Applying BGP
attributes.
Following is a first run of basic configuration for routers RTA, RTF, RTC, and RTD, illustrated in figure 10-6. Additional configuration will be added according to the topic under discussion.
RTA configuration:
ip subnet-zero
interface Loopback0
ip address 172.16.2.254 255.255.255.255
interface Ethernet0
ip address 172.16.220.1 255.255.255.0
interface Ethernet1
ip address 172.16.1.1 255.255.255.0
interface Serial0
ip address 172.16.20.2 255.255.255.0
router ospf 10
passive-interface Serial0
network 172.16.0.0 0.0.255.255 area 0
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 filter-list 10 out
no auto-summary
ip classless
ip as-path access-list 10 permit ^$
RTF configuration:
ip subnet-zero
interface Ethernet0/0
ip address 172.16.10.1 255.255.255.0
interface Ethernet 1/0
ip address 172.16.65.1 255.255.255.192
interface Ethernet1/1
ip address 172.16.1.2 255.255.255.0
interface Serial2/1
ip address 192.68.5.1 255.255.255.0
router ospf 10
network 172.16.0.0 0.0.255.255 area 0
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.2.254 remote-as 3
neighbor 172.16.2.254 next-hop-self
neighbor 192.68.5.2 remote-as 2
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip classless
ip as-path access-list 10 permit ^$
RTC configuration:
ip subnet-zero
interface Ethernet0/0
ip address 192.68.11.1 255.255.255.0
interface Ethernet0/1
ip address 192.68.6.2 255.255.255.0
interface Serial2/1
ip address 172.16.20.1 255.255.255.0
router bgp 1
network 192.68.11.0
neighbor 172.16.20.2 remote-as 3
neighbor 192.68.6.1 remote-as 2
no auto-summary
ip classless
RTD configuration:
ip subnet-zero
interface Ethernet1/0
ip address 192.68.10.1 255.255.255.0
interface Ethernet1/1
ip address 192.68.6.1 255.255.255.0
interface Serial0/0
ip address 192.68.5.2 255.255.255.0
router bgp 2
network 192.68.10.0
neighbor 192.68.5.1 remote-as 3
neighbor 192.68.6.2 remote-as 1
no auto-summary
ip classless
The Next_Hop Attribute
Consider the BGP table of RTF:
RTF#sh ip bgp
BGP table version is 8, local router ID is 192.68.5.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.1.0/24 172.16.2.254 0 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.10.0/24 172.16.2.254 20 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.65.0/26 172.16.2.254 20 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.220.0/24 172.16.2.254 0 100 0 i
*> 172.16.1.1 20 32768 i
*> 192.68.10.0 192.68.5.2 0 0 2 i
* 192.68.11.0 192.68.5.2 0 2 1 i
*>i 172.16.20.1 0 100 0 1 i
Network 192.68.11.0/24 is learned via IBGP (note the "i" at the far left) with next hop 172.16.20.1, which is the IP address of the external neighbor of RTA. The EBGP next hop IP address is always carried inside the IBGP, which is why it is very important to have an internal route to the next hop. Otherwise, the BGP route would be unreachable. There are a couple of ways to make sure that you do not have problems reaching the EBGP next hop. The first way is to include the network that the next hop belongs to in the IGP. This is illustrated on RTA by including interface serial 0 in the OSPF; this way, RTF would know about 172.16.20.1. Note that even though OSPF is running on RTA serial 0, it need not exchange any OSPF "Hello" packets on serial 0, hence the passive-interface router command.
The second method is to use the next-hop-self (see RTF) neighbor command to force the router to advertise itself, rather than the external peer, as the next hop. On RTF, note how the next-hop-self is added at the end of the neighbor statement toward RTA. This way, when RTF advertises external networks such as 192.68.10.0/24 toward RTA, it will use itself as the next hop. Looking at RTA's BGP table that follows, prefix 192.68.10.0/24 is learned via next hop 172.16.1.2, which is its internal peer with RTF. Because 172.16.1.2 is part of the OSPF already, we have no problem reaching it.
RTA#sh ip bgp
BGP table version is 20, 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
* i172.16.1.0/24 172.16.1.2 0 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.10.0/24 172.16.1.2 0 100 0 i
*> 172.16.1.2 20 32768 i
* i172.16.65.0/26 172.16.1.2 0 100 0 i
*> 172.16.1.2 20 32768 i
* i172.16.220.0/24 172.16.1.2 20 100 0 i
*> 0.0.0.0 0 32768 i
*>i192.68.10.0 172.16.1.2 0 100 0 2 i
* 172.16.20.1 0 1 2 i
*> 192.68.11.0 172.16.20.1 0 0 1 i
Note in the preceding table that 192.68.10.0/24 is actually learned via two different paths, whereas 192.68.11.0/24 is learned via a single path. This might seem misleading, but actually routing is doing the right thing. In this situation, RTF has decided that the best path to reach 192.68.11.0/24 is via RTA (check RTF's BGP table) ; this is why RTF will not advertise network 192.68.11.0/24 back to RTA, and RTA will have a single entry for 192.68.11.0/24.
The AS_Path Attribute
Looking at RTF's BGP table that follows, you can see the AS_path information at the end of each line. Network 192.68.11.0/24 is learned via IBGP with AS_path 1 and via EBGP with AS_path 2 1. This means that if RTF wanted to reach 192.68.11.0/24 via IBGP, it can go to AS1, and if RTF wanted to reach 192.68.11.0/24 via EBGP, it has to go via AS2 then AS1. BGP always prefers the shortest path, which is why the path via IBGP with AS_path 1 is preferred. The ">" sign at the left is an indication that out of the two available paths that BGP has for 192.68.11.0/24, BGP has preferred the second one as being the "best" path.
RTF#sh ip bgp
BGP table version is 8, local router ID is 192.68.5.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.1.0/24 172.16.2.254 0 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.10.0/24 172.16.2.254 20 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.65.0/26 172.16.2.254 20 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.220.0/24 172.16.2.254 0 100 0 i
*> 172.16.1.1 20 32768 i
*> 192.68.10.0 192.68.5.2 0 0 2 i
* 192.68.11.0 192.68.5.2 0 2 1 i
*>i 172.16.20.1 0 100 0 1 i
AS_Path Manipulation
Considering RTF's BGP table, RTF has picked the direct path via AS1 to reach 192.68.11.0/24 because it is shorter. The following configuration shows how the AS_path information can be manipulated to make the AS_path longer by prepending AS path numbers. Considering figure 10-6, we will prepend two extra AS path numbers to the AS_path information sent from RTC to RTA to change RTF's decision about reaching 192.68.11.0/24.
RTC configuration:
router bgp 1
network 192.68.11.0
neighbor 172.16.20.2 remote-as 3
neighbor 172.16.20.2 route-map AddASnumbers out
neighbor 192.68.6.1 remote-as 2
no auto-summary
route-map AddASnumbers permit 10
set as-path prepend 1 1
The preceding configuration prepends two additional AS_path numbers 1 and 1 to the AS_path information sent from RTC to RTA. If you look at RTF's BGP table, you will see that RTF can now reach 192.68.11.0/24 via next hop 192.68.5.2—that is, via path 2 1. RTF will prefer this path because it is shorter than the direct path via AS1, which has a path information of 1 1 1.
RTF#sh ip bgp
BGP table version is 18, local router ID is 192.68.5.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.1.0/24 172.16.2.254 0 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.10.0/24 172.16.2.254 20 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.65.0/26 172.16.2.254 20 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.220.0/24 172.16.2.254 0 100 0 i
*> 172.16.1.1 20 32768 i
*> 192.68.10.0 192.68.5.2 0 0 2 i
*> 192.68.11.0 192.68.5.2 0 2 1 i
* i 172.16.20.1 0 100 0 1 1 1 i
Using Private ASs
This example demonstrates how BGP can be configured to prevent the leakage of private AS numbers into the Internet. Consider figure 10-7; AS1 will prevent private AS number 65001 from being leaked to the Internet when BGP routes are propagated.
Figure 10-7 Stripping
private AS numbers.
RTA configuration:
router bgp 65001
network 172.16.220.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
no auto-summary
RTC configuration:
router bgp 1
network 192.68.11.0 mask 255.255.255.0
neighbor 172.16.20.2 remote-as 65001
neighbor 192.68.6.3 remote-as 7
neighbor 192.68.6.3 remove-private-AS
no auto-summary
Note how RTC is using the remove-private-AS keyword in its neighbor connection to AS7. The following output shows the BGP tables of RTC and RTE.
RTC#show ip bgp
BGP table version is 72, 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
*> 172.16.220.0/24 172.16.20.2 0 0 65001 i
*> 192.68.11.0 0.0.0.0 0 32768 i
RTE#sh ip bgp
BGP table version is 245, local router ID is 192.68.30.1
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.16.220.0/24 192.68.6.2 0 1 i
*> 192.68.11.0 192.68.6.2 0 0 1 i
The Local Preference Attribute
Setting the local preference also affects the BGP decision process. If multiple paths for the same prefix are available, the path with the larger local preference is preferred. Local preference is at the highest level of the BGP decision process (comes after the Cisco proprietary weight parameter); it is considered before the path length. A longer path with a higher local preference is preferred over a shorter path with a lower local preference. In the following example, still referring to figure 10-6, we will configure RTF to have a higher local preference for all BGP updates coming from RTD.
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
neighbor 172.16.2.254 remote-as 3
neighbor 172.16.2.254 next-hop-self
neighbor 192.68.5.2 remote-as 2
neighbor 192.68.5.2 filter-list 10 out
neighbor 192.68.5.2 route-map SETLOCAL in
no auto-summary
ip as-path access-list 10 permit ^$
route-map SETLOCAL permit 10
set local-preference 300
The route-map SETLOCAL will assign a local preference of 300 for all routes coming from RTD (note the keyword in). Note how BGP has decided that prefixes 192.68.10.0/24 and 192.68.11.0/24 are now reachable via next hop 192.68.5.2 having a local preference of 300.
RTF#sh ip bgp
BGP table version is 20, local router ID is 192.68.5.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 0.0.0.0 0 32768 i
* i 172.16.2.254 0 100 0 i
*> 172.16.10.0/24 0.0.0.0 0 32768 i
* i 172.16.2.254 20 100 0 i
*> 172.16.65.0/26 0.0.0.0 0 32768 i
* i 172.16.2.254 20 100 0 i
*> 172.16.220.0/24 172.16.1.1 20 32768 i
* i 172.16.2.254 0 100 0 i
*> 192.68.10.0 192.68.5.2 0 300 0 2 i
*> 192.68.11.0 192.68.5.2 300 0 2 1 i
Because the local preference attribute is carried inside the AS, RTF will pass the local preference value to RTA. This is illustrated in RTA's BGP table. Note how prefix 192.68.11.0/24 is preferred via IBGP with a local preference of 300, even though the AS_path via EBGP is shorter. Other prefixes learned via IBGP such as 172.16.10.0/24 have a default local preference of 100.
RTA#sh ip bgp
BGP table version is 43, 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
* i172.16.1.0/24 172.16.1.2 0 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.10.0/24 172.16.1.2 0 100 0 i
*> 172.16.1.2 20 32768 i
* i172.16.65.0/26 172.16.1.2 0 100 0 i
*> 172.16.1.2 20 32768 i
* i172.16.220.0/24 172.16.1.2 20 100 0 i
*> 0.0.0.0 0 32768 i
*>i192.68.10.0 172.16.1.2 0 300 0 2 i
* 172.16.20.1 0 1 2 i
*>i192.68.11.0 172.16.1.2 300 0 2 1 i
* 172.16.20.1 0 0 1 i
The MULTI_EXIT_DISC (MED) Attribute
This example shows how metrics can be used by one AS to influence routing decisions of another AS. In figure 10-8, AS3 is the customer of provider AS1. AS3 wants to generate metrics toward AS1 to influence inbound traffic. In case all BGP attributes are the same, BGP will prefer routes with a lower metric over routes with a higher metric.
Figure 10-8 Setting the
MED attribute.
RTA and RTF are running IBGP internally and EBGP with the provider AS1. RTG is an internal non-BGP router, running OSPF only. Assume that RTA and RTF want to send MEDs toward AS1 to achieve the following:
- 1. Incoming traffic toward network
172.16.1.0/24 takes the SF link.
- 2. Incoming traffic toward all other networks should come in by using the border router that can reach these networks with a smaller internal metric. Incoming traffic toward network 172.16.112.0/24, for example, should come in on the SF link if RTA can reach this network with a smaller internal metric than RTF.
The following is the required configuration:
RTA configuration:
router ospf 10
passive-interface Serial0
network 172.16.0.0 0.0.255.255 area 0
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
network 172.16.112.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 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
RTF configuration:
router ospf 10
network 172.16.0.0 0.0.255.255 area 0
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
network 172.16.112.0 mask 255.255.255.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 route-map SETMETRIC out
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
access-list 1 permit 172.16.1.0 0.0.0.255
route-map SETMETRIC permit 10
match ip address 1
set metric 50
route-map SETMETRIC permit 20
The preceding configuration will make RTF generate prefix 172.16.1.0/24 with a MED of 50. When AS1 gets the prefix, AS1 will compare a metric of 50 coming from RTF versus a metric of 0 coming from RTA and will prefer the SF link. All other networks will be advertised with their internal metrics carried into BGP, and AS1 will choose the entrance with a smaller metric to the destination.
RTD#sh ip bgp
BGP table version is 17, 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.5.1 50 0 3 i
*>i 192.68.6.2 0 100 0 3 i
*> 172.16.10.0/24 192.68.5.1 0 0 3 i
*> 172.16.65.0/26 192.68.5.1 0 0 3 i
* 172.16.112.0/24 192.68.5.1 84 0 3 i
*>i 192.68.6.2 74 100 0 3 i
* 172.16.220.0/24 192.68.5.1 20 0 3 i
*>i 192.68.6.2 0 100 0 3 i
*> 192.68.10.0 0.0.0.0 0 32768 i
*>i192.68.11.0 192.68.6.2 0 100 0 i
Note how RTD has preferred network 172.16.1.0/24 via next hop 192.68.6.2, which is RTC (RTC is using next-hop-self). This is because of the lower metric ( 0 <50). For all other networks, RTD is preferring routes with the smaller metrics. Note that 172.16.112.0/24 is learned via metric 74 from RTA and metric 84 from RTF. RTD will prefer the SF link to reach 172.16.112.0/24.
For BGP learned routes, an AS can also advertise these routes to another AS with the internal IGP metric carried into BGP. This is achieved by using the following command as part of a route map towards a neighbor: set metric-type internal. This would cause BGP routes to carry the internal IGP metric as MED.
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
The output of RTC's BGP table shows that the only prefix that was learned from RTA is the aggregate 172.16.0.0/16. Because RTF is also performing the same aggregation, RTC will also learn an aggregate that is originated from RTF (next hop RTD via AS2).
RTC#sh ip bgp
BGP table version is 22, 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
*> 172.16.0.0 172.16.20.2 0 3 i
* 192.68.6.1 0 2 3 i
*> 192.68.10.0 192.68.6.1 0 0 2 i
*> 192.68.11.0 0.0.0.0 0 32768 i
Looking at the specific 172.16.0.0/16 aggregate entry, the following display provides more information about the aggregate itself. Note the presence of the "atomic-aggregate" attribute, which indicates that the prefix 172.16.0.0/16 is an aggregate. Also note the presence of the "aggregated by 3 192.68.5.1" and "aggregated by 3 172.16.2.254" statements, which represent the "aggregator" attribute. The "aggregator" attribute (Chapter 5) indicates the AS number and Router ID of the router who originated the aggregate; in this case, AS3 and the Router IDs of RTA and RTF.
RTC#sh ip bgp 172.16.0.0
BGP routing table entry for 172.16.0.0/16, version 22
Paths: (2 available, best #1, advertised over EBGP)
3, (aggregated by 3 172.16.2.254)
172.16.20.2 from 172.16.20.2 (172.16.2.254)
Origin IGP, valid, external, atomic-aggregate, best
23, (aggregated by 3 192.68.5.1)
192.68.6.1 from 192.68.6.1 (192.68.10.1)
Origin IGP, valid, external, atomic-aggregate
Aggregates can also be generated by using static routes. This is illustrated in the following RTA and RTF configuration.
RTA configuration:
router bgp 3
no synchronization
network 172.16.0.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 filter-list 10 out
no auto-summary
ip route 172.16.0.0 255.255.0.0 null0
ip as-path access-list 10 permit ^$
RTF configuration:
router bgp 3
no synchronization
network 172.16.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 2
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip route 172.16.0.0 255.255.0.0 null0
ip as-path access-list 10 permit ^$
The preceding configuration places a static instance of 172.16.0.0/16 in the routing table. Note that the static entry is pointing to null0 (pit bucket). If RTA or RTF have no knowledge of the more specific routes of 172.16.0.0, then traffic will be dropped. This is to prevent loops in case RTA or RTF are themselves following defaults to their providers (see "Aggregation and Loops," in Chapter 3, "Handling IP Address Depletion").
Aggregate Plus More Specific Routes
In some cases, more specific routes, in addition to the aggregate, need to be passed (leaked) to a neighboring AS. This is usually done in ASs multihomed to a single provider. An AS (the provider) that gets the more specific routes would be able to make a better decision about which way to take to reach the route. (You have already seen how an AS receiving different metrics can direct the traffic accordingly.)
In figure 10-11, AS3 is multihomed to a single provider AS1. RTA and RTF in AS3 can send the aggregate 172.16.0.0/16 and the more specific routes toward AS1. The following configuration of RTA and RTF will do so:
Figure 10-11 More BGP
aggregation scenarios.
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
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 ^$
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 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
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
Aggregate with a Subset of the More Specific Routes
In figure 10-12, we will show how AS3 can utilize a combination of aggregation and more specific routes to influence what link AS1 uses to reach AS3's networks. RTA will send over its direct link to AS1 the aggregate 172.16.0.0/16 plus the more specific routes 172.16.1.0/24, 172.16.10.0/24, and 172.16.65.0/26. RTF will send over its direct link to AS3, the aggregate 172.16.0.0/16, plus the more specific route 172.16.220.0/24 only. As a result, AS1 is forced to reach 172.16.220.0/24 via RTF and all the other routes in AS3 via RTA.
Figure 10-12 BGP
aggregates with subset of 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 suppress-map SUPPRESS
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 ^$
access-list 1 permit 172.16.220.0 0.0.0.255
access-list 1 deny any
route-map SUPPRESS permit 10
match ip address 1
The suppress-map is another form of route-map that can be used to indicate the more specific routes to be suppressed or the more specific routes to be allowed. When a route is permitted through the suppress map, the route is suppressed. If the route is not permitted (denied), the route is not suppressed—that is, allowed. Note that the deny logic here does not prevent the route from being advertised; rather, it prevents it from being suppressed.
In RTA's configuration, we have used a suppress map called SUPPRESS that will prevent 172.16.220.0/24 from being advertised and enable all other routes. As a result, RTA will announce the aggregate 172.16.0.0/16, plus the more specific routes 172.16.1.0/24, 172.16.10.0/24, and 172.16.65.0/26. The following is RTA's BGP table; note how the suppressed entries have the "s" at the far left.
RTA#sh ip bgp
BGP table version is 17, 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
* i172.16.0.0 172.16.1.2 100 0 i
*> 0.0.0.0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.10.0/24 172.16.1.2 20 32768 i
*> 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
* i192.68.10.0 172.16.1.2 0 100 0 1 i
*> 172.16.20.1 0 1 i
* i192.68.11.0 172.16.1.2 0 100 0 1 i
*> 172.16.20.1 0 0 1 i
On the other hand, RTF will use a similar logic to advertise the aggregate, plus the more specific route 172.16.220.0/24. RTF's configuration will include a suppress map called ALLOW that allows the prefix 172.16.220.0/24 and suppresses everything else. As a result, AS1 will be forced to use RTF to reach 172.16.220.0/24. The naming of the suppress maps SUPPRESS and ALLOW reflects the main function of the route map. In RTA's configuration, it made more sense to suppress a specific entry and allow the rest because the number of routes to be allowed is large. In RTF's configuration, it made sense to allow a specific entry and suppress the rest because the number of routes to be suppressed is large.
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 suppress-map ALLOW
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 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
access-list 1 deny 172.16.220.0 0.0.0.255
access-list 1 permit any
route-map ALLOW permit 10
match ip address 1
The preceding configuration of RTF will allow the aggregate 172.16.0.0/16 and the more specific route 172.16.220.0/24 to be advertised; all other more specific routes will be suppressed. The following is RTF's BGP table:
RTF#sh ip bgp
BGP table version is 17, local router ID is 192.68.5.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.0.0 0.0.0.0 32768 i
* i 172.16.2.254 100 0 i
s> 172.16.1.0/24 0.0.0.0 0 32768 i
s i 172.16.2.254 0 100 0 i
s> 172.16.10.0/24 0.0.0.0 0 32768 i
s i 172.16.2.254 20 100 0 i
s> 172.16.65.0/26 0.0.0.0 0 32768 i
s i 172.16.2.254 20 100 0 i
*> 172.16.220.0/24 172.16.1.1 20 32768 i
*> 192.68.10.0 192.68.5.2 0 0 1 i
* i 172.16.20.1 100 0 1 i
*> 192.68.11.0 192.68.5.2 0 1 i
* i 172.16.20.1 100 0 1 i
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
Forming the Aggregate Based on a Subset of Specific Routes
Having control over which individual prefixes form the aggregate is very useful in deciding which attributes the aggregate is going to carry. In the previous example, if we could exclude prefix 192.68.11.0/24 from being part of the prefixes that form the aggregate, the aggregate would not inherit the "no-export" community attribute.
The advertise map is yet another form of a route map that enables you to form the aggregated route based on a limited selection of the more specific routes.
In figure 10-14, RTA and RTF are getting routes 192.68.11.0/24 and 192.68.10.0/24 from ASs 1 and 2, respectively. If RTA and RTF are to aggregate these routes into 192.68.0.0/16 using the "as-set" option, the aggregate cannot be sent back to either AS1 or AS2 because it contains {1 2} in the AS_path information. This is due to the normal BGP behavior in detecting loops.
Figure 10-14 Aggregation
with advertise-map.
Assume that the required behavior is to have the aggregate 192.68.0.0/16 be sent back to AS1 and not to AS2. The solution is to have AS1 not be part of the AS_path of the aggregate; then, AS1 will not drop the aggregate. This could be achieved by having RTA and RTF form the aggregate based on the 192.68.10.0/24 prefix only, using the advertise-map option.
RTA's configuration would be set as in the following example. RTF would have the same relative configuration.
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 advertise-map
SELECT_MORE_SPECIF_ROUTES
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 ^$
access-list 1 permit 192.68.10.0 0.0.0.255
route-map SELECT_MORE_SPECIF_ROUTES permit 10
match ip address 1
By permitting prefix 192.68.10.0/24, the above advertise map causes RTA to base its aggregate calculation on 192.68.10.0/24 only. Thus, 192.68.11.0/24 is not included in the formation of the aggregate.
The following show ip bgp command output illustrates that the path information of the aggregate is now 2 and not {1 2}. This means that the aggregate can now be advertised to AS1 because the AS_path does not include AS1. AS2 will not be able to receive the aggregate.
RTA#show ip bgp 192.68.0.0
BGP routing table entry for 192.68.0.0 255.255.0.0, version 31
Paths: (2 available, best #2, advertised over IBGP)
2 (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 (aggregated by 3 172.16.2.254)
0.0.0.0
Origin IGP, localpref 100, weight 32768, valid, aggregated,
local,
atomic-aggregate, best
Looking Ahead
The BGP attributes are the basic elements in interdomain network design. Combining and manipulating different attributes will result in a unique routing policy for your autonomous system. The next chapter takes what you have learned so far and goes further in showing implementations for major design problems facing every network. The chapter also shows examples of controlling Internet stabilty by using route dampening.