Routing Policies
Webster's Dictionary defines a policy as "a high-level overall plan embracing the general goals and acceptable procedures." A routing policy is a plan that defines how routes are accepted on a router and how routes are advertised. The goal that the policy embraces is the correct forwarding or suppressing of IP packets. Acceptable procedures means that the routing policy is implemented with the least-negative impact possible on the CPU and memory resources of the router, the bandwidth resources of the connected links, and the policies of neighboring routers.
NOTE
The term routing policies used in this section and throughout this chapter should not be confused with the Cisco feature known as Policy Routes. These special versions of static routes, implemented with the command ip policy route-map, are discussed in Routing TCP/IP, Volume I, Chapter 14, "Route Maps."
Routing policies are always important, but especially so in a BGP environment. By its very nature, BGP interconnects autonomous systems, and neighboring autonomous systems probably are not under your administrative control. You must plan BGP routing policies very carefully. You must fully understand which packets should be forwarded to which neighbors, which packets should be accepted from those neighbors, and under what circumstances those packets are forwarded and received. When a complete routing plan is developed, you are ready to design the configuration that enables the policy. This stage requires that you completely understand the BGP configuration options available to you. A lab can prove very useful at this stage, to test the design and verify your assumptions before the design is implemented on a production network. Only after a configuration has been completely designed, understood, and validated should you implement it.
A mistake at any one of these steps can have serious consequences in your internetwork and can result in unhappy users, unhappy customers, unhappy service providers, and unhappy managers. Because of the potential for disruption of traffic across significant portions of the Internet, many service providers discontinue BGP peering with customers who frequently misconfigure their policies. The economic impact of being denied BGP peering—particularly if the customer is itself a service provider—can be severe. No other IP routing protocol offers policy features as powerful as those of BGP, and no other protocol carries as great a potential for getting you into trouble as does BGP.
This section demonstrates the available options for configuring routing policies under BGP. You already have been exposed to some of the most fundamental tools for configuring routing policy. If you read Volume I and have read all of this volume up to this point, you know how to configure any of the IP routing protocols to advertise selected routes and how to redistribute routes from one protocol to another. You also know how to use route filters and route maps and how to manipulate the administrative distances and metrics of the various IP routing protocols. You understand the hazards of having more than one path into and out of an area, a routing domain, or an AS, and you know some strategies for avoiding those hazards. In this chapter, you have encountered several brief examples of some BGP-specific tools, such as manipulating the ORIGIN and COMMUNITY attributes and filtering NLRI from a single neighbor.
Finally, you understand that outbound route advertisements affect incoming traffic and that inbound route advertisements affect outgoing traffic. When designing a routing policy, it is vitally important that you consider the advertised routes and received routes separately and design both an inbound and an outbound routing policy.
Resetting BGP Connections
When a BGP speaker's configuration is changed, it is often necessary to reset the connections to the affected neighbors for the change to take effect. The Cisco IOS Software Command Summary lists the following circumstances under which you must reset a BGP connection:
Additions or changes to BGP-related access lists Changes to BGP-related weights Changes to BGP-related distribution lists Changes in the BGP-related timer's specifications Changes to the BGP administrative distance Changes to BGP-related route maps
All the items on this list affect a route's BGP routing policy in some way, and this is a hint about why resets are required. If you are changing routing policy, you do not want the policies to take effect "on the fly." Rather, you want to fully configure the new policy and only then implement the policy. Allowing each statement of a routing policy to take effect as you enter it can cause routing loops, black holes, security breaches, or other equally nasty results.
You can reset connections with the command clear ip bgp, issued from IOS Exec mode. You can apply the reset to a specific neighbor, a peer group, or to all the router's neighbors. To reset a connection to a specific neighbor, the neighbor's IP address is specified. To reset a connection to neighbor 192.168.1.253, for example, the command is clear ip bgp 192.168.1.253. To reset a connection to all members of a peer group named subscribers, the command is clear ip bgp subscribers. And to reset all of a router's BGP connections, the command is clear ip bgp *.
You should clear only the connections that are actually affected by the changes you make. When a connection is reset, a Cease notification message is sent to the neighbor, the BGP session is closed, the TCP session is closed, and all caches are invalidated. A new BGP session is then begun. While this process takes place, service is disrupted to and from the connection. Resetting all connections when only one or two are affected by the new configuration can have serious consequences in a production environment.
Cisco provides an alternative to a full reset, called soft reconfiguration. Rather than completely tearing down and reestablishing a TCP and BGP connection, soft reconfiguration merely triggers updates to cause new routing policies to take effect. A soft reset can be triggered for outbound only, inbound only, or both. Outbound soft reconfiguration is used when the policies affecting outbound traffic are changed. Inbound soft reconfiguration is used when the policies affecting inbound traffic are changed. Like a "hard" reset, you can specify a single neighbor, a peer group, or all BGP connections.
Suppose, for example, that you change the policy on a BGP router that affects the outbound traffic to neighbor 192.168.1.253. To trigger updates to that neighbor under the new policy, the command is clear ip bgp 192.168.1.253 soft out.
Inbound soft reconfiguration is used when you change the policies concerning inbound traffic. Beginning with Cisco IOS Software Release 12.1, dynamic soft reconfiguration is supported for inbound routes. Prior to that version, however, you must first add a neighbor soft-reconfiguration inbound statement to the BGP configuration before inbound soft reconfiguration can be used. The command clear ip bgp soft in is then used for every neighbor that sends traffic affected by the new inbound policies. Suppose you change the inbound routing policies on router Stowe in Figure 3-14, and the policies affect traffic received from neighbor 192.168.1.253. Example 3-77 shows what Stowe's BGP configuration will look like.
Example 3-77 Configuring a Neighbor for Soft Inbound Reconfiguration
router bgp 100
redistribute eigrp 100
neighbor 192.168.1.253 remote-as 200
neighbor 192.168.1.253 soft-reconfiguration inbound
When the neighbor soft-reconfiguration inbound statement is added, the router begins storing updates from the specified neighbor. These updates are unmodified by any existing inbound policies so that the router can correctly apply the new policies when soft reconfiguration is triggered. After the new inbound policies are configured for Stowe in the example shown, the command clear ip bgp 192.168.1.253 soft in is entered from Exec mode. The router then uses the stored, unmodified updates to implement the new inbound policies.
Soft reconfiguration also can be triggered for both inbound and outbound policies at the same time. For instance, the command clear ip bgp 192.168.1.253 soft, with no in or out keyword, sends updates to neighbor 192.168.1.253 and also applies inbound policies to the stored updates from that neighbor.
The obvious drawback to using inbound soft reconfiguration is that memory is required to store the updates. If the neighbor is advertising a large number of routes, or if updates from many neighbors are being stored, the impact on the local router's memory can be significant. You can avoid this load on memory. When inbound BGP routing policies are changed on a router, its neighbors can send an outbound soft reconfiguration. The local router, receiving the updates from its neighbors, then applies the new inbound policies. You should use inbound soft reconfiguration only if you cannot send, or arrange to have sent, an outbound soft reconfiguration from the affected neighbors. You might find inbound soft reconfiguration necessary if the policy change affects the traffic from many neighbors, and if you must apply the policy change to all neighbors simultaneously. In either case, you must carefully weigh the impact on local memory.
Case Study: Filtering Routes by NLRI
Route filters are at the heart of almost any routing policy. After all, if you have an inbound and an outbound routing policy, what you are most likely defining is which routes a router accepts and which routes a router advertises.
The first and simplest of the route filters available to BGP are defined by the distribute-list command. This route filter is defined for each neighbor or peer group and points to an access list that defines the prefixes, or NLRI, on which the filter will act.
The internetwork in Figure 3-15 is used for this and the following two case studies.
The IGP of AS 50 is RIP, and the IGP of AS 30 is Integrated IS-IS. AS 100 and AS 200 are transit autonomous systems. Example 3-78 shows the preliminary configurations of the five routers in Figure 3-15.
Example 3-78 Filtering Routes by NLRI: Initial Router Configurations
Zermatt
interface Loopback0
ip address 172.30.255.254 255.255.255.255
ip router isis
!
router isis
net 30.5678.1234.defa.00
redistribute bgp 30 metric 0 metric-type internal level-2
!
router bgp 30
redistribute isis level-2
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
no auto-summary
!
ip classless
ip route 10.100.83.1 255.255.255.255 Serial1.906
_______________________________________________________________________
Moritz
interface Loopback0
ip address 172.30.255.150 255.255.255.255
ip router isis
!
router isis
net 30.1234.5678.abcd.00
redistribute bgp 30 metric 0 metric-type internal level-2
!
router bgp 30
redistribute isis level-2
neighbor 10.200.60.1 remote-as 200
neighbor 10.200.60.1 ebgp-multihop 2
neighbor 10.200.60.1 update-source Loopback0
no auto-summary
!
ip route 10.200.60.1 255.255.255.255 Serial1.803
_______________________________________________________________________
Innsbruck
interface Loopback0
ip address 10.100.83.1 255.255.255.255
!
router bgp 100
neighbor 10.50.250.1 remote-as 50
neighbor 10.50.250.1 ebgp-multihop 2
neighbor 10.50.250.1 update-source Loopback0
neighbor 10.200.60.1 remote-as 200
neighbor 10.200.60.1 ebgp-multihop 2
neighbor 10.200.60.1 update-source Loopback0
neighbor 172.30.255.254 remote-as 30
neighbor 172.30.255.254 ebgp-multihop 2
neighbor 172.30.255.254 update-source Loopback0
no auto-summary
!
ip classless
ip route 10.50.250.1 255.255.255.255 Ethernet0
ip route 10.200.60.1 255.255.255.255 Ethernet0
ip route 172.30.255.254 255.255.255.255 Serial1.609
Cervinia
interface Loopback0
ip address 10.200.60.1 255.255.255.255
!
router bgp 200
neighbor 10.50.250.1 remote-as 50
neighbor 10.50.250.1 ebgp-multihop 2
neighbor 10.50.250.1 update-source Loopback0
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
neighbor 172.30.255.150 remote-as 30
neighbor 172.30.255.150 ebgp-multihop 2
neighbor 172.30.255.150 update-source Loopback0
no auto-summary
!
ip classless
ip route 10.50.250.1 255.255.255.255 Ethernet0/0
ip route 10.100.83.1 255.255.255.255 192.168.4.2
ip route 172.30.255.150 255.255.255.255 Serial0/1.308
_______________________________________________________________________
Meribel
interface Loopback0
ip address 10.50.250.1 255.255.255.255
!
router rip
redistribute bgp 50 metric 1
network 10.0.0.0
!
router bgp 50
redistribute rip
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
neighbor 10.200.60.1 remote-as 200
neighbor 10.200.60.1 ebgp-multihop 2
neighbor 10.200.60.1 update-source Loopback0
no auto-summary
!
ip classless
ip route 10.100.83.1 255.255.255.255 Ethernet0
ip route 10.200.60.1 255.255.255.255 Ethernet0
Notice that Figure 3-15 shows no IP addresses for any of the data links. All the BGP sessions are configured between router IDs, defined by the loopback interfaces of the routers, so the data link addresses are irrelevant to this example. Also important in these configurations are the static routes, which tell the routers how to find their neighbors' router IDs. Without the static routes, the BGP sessions cannot be established.
CAUTION
This case study and some of the following case studies use mutual redistribution between the IGP and BGP to easily demonstrate the application of routing policy. Once again, keep in mind that in practice, mutual distribution is usually a bad idea. And more importantly, if many prefixes are involved, redistribution from BGP to any IGP is always a bad idea.
AS 30 in Figure 3-15 is multihomed for redundancy but should not be a transit AS. That is, no traffic passing between AS 100 and AS 200 should cross AS 30. Innsbruck's BGP table in Example 3-79 shows that as the configurations stand, this policy is not in effect. One of the next-hop routers that Innsbruck shows for the destinations within AS 50 is Zermatt (172.30.255.254). The reason for this is that Meribel advertises those addresses to both Cervinia and Innsbruck. Cervinia advertises the addresses to Moritz, which redistributes the addresses into IS-IS. Zermatt then learns the addresses from its IS-IS neighbor within AS 30, redistributes them into BGP, and advertises them to Innsbruck.
Example 3-79 Innsbruck Shows Zermatt as a Feasible Next Hop to the Destinations Within AS 50
Innsbruck#show ip bgp
BGP table version is 21, local router ID is 10.100.83.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 10.20.0.0/16 172.30.255.254 20 0 30 ?
* 10.200.60.1 0 200 50 ?
*> 10.50.250.1 0 0 50 ?
* 10.30.0.0/16 10.50.250.1 0 50 200 30 ?
*> 172.30.255.254 20 0 30 ?
* 10.200.60.1 0 200 30 ?
* 10.50.250.1/32 172.30.255.254 20 0 30 ?
* 10.200.60.1 0 200 50 ?
*> 10.50.250.1 0 0 50 ?
*> 10.200.60.1/32 10.50.250.1 0 0 50 ?
* 172.16.0.0 10.50.250.1 0 50 200 30 ?
*> 172.30.255.254 20 0 30 ?
* 10.200.60.1 0 200 30 ?
* 172.17.0.0 172.30.255.254 20 0 30 ?
* 10.200.60.1 0 200 50 ?
*> 10.50.250.1 1 0 50 ?
* 172.29.0.0 172.30.255.254 20 0 30 ?
* 10.200.60.1 0 200 50 ?
*> 10.50.250.1 1 0 50 ?
* 172.29.1.0/24 10.50.250.1 0 50 200 30 ?
*> 172.30.255.254 20 0 30 ?
* 10.200.60.1 0 200 30 ?
*> 172.30.255.150/32 172.30.255.254 30 0 30 ?
* 172.30.255.254/32 10.50.250.1 0 50 200 30 ?
*> 10.200.60.1 0 200 30 ?
* 172.31.0.0 10.50.250.1 0 50 200 30 ?
*> 172.30.255.254 20 0 30 ?
* 10.200.60.1 0 200 30 ?
* 192.168.2.0/30 10.50.250.1 0 50 200 30 ?
*> 10.200.60.1 0 200 30 ?
*> 192.168.2.4/30 172.30.255.254 20 0 30 ?
* 192.168.50.0 172.30.255.254 20 0 30 ?
* 10.200.60.1 0 200 50 ?
*> 10.50.250.1 1 0 50 ?
* 192.168.100.0 10.50.250.1 0 50 200 30 ?
*> 172.30.255.254 20 0 30 ?
* 10.200.60.1 0 200 30 ?
Innsbruck#
If Innsbruck loses its connection to the NAP, it will forward packets destined for AS 50 to Zermatt, making AS 30 a transit AS. To prevent this, an outbound policy is implemented at both Zermatt and Moritz, allowing only addresses interior to AS 30 to be advertised. Example 3-80 shows the BGP configuration for Zermatt.
Example 3-80 Implementing an Outbound Policy at Zermatt to Allow Only Addresses Interior to AS 30 to Be Advertised
router bgp 30
redistribute isis level-2
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
neighbor 10.100.83.1 distribute-list 1 out
no auto-summary
!
access-list 1 permit 192.168.100.0
access-list 1 permit 10.30.0.0
access-list 1 permit 192.168.2.0
access-list 1 permit 172.29.1.0
access-list 1 permit 172.31.0.0
access-list 1 permit 172.16.0.0
Only the parts of Zermatt's configuration relevant to the example are shown.
Moritz's distribute-list configuration is identical, except for the neighbor reference. At both routers, access list 1 allows all the interior routes and denies all other routes.
Another problem shown in Example 3-79 is that Innsbruck lists not only Meribel (10.50.250.1) as a next hop for the destinations within AS 50, but also Cervinia (10.200.60.1). The same double entry exists in the BGP table of Cervinia, which shows both Meribel and Innsbruck as next-hop routers for the AS 50 addresses. The problem is caused by the fact that Innsbruck and Cervinia are peered not only with Meribel, but also with each other.
This problem does not cause any sort of routing dysfunction—if Meribel withdraws a route, the withdrawal is advertised between Cervinia and Innsbruck also. The problem is more a matter of aesthetics and clarity. An invalid route should not exist in the BGP table.
To correct the problem, Example 3-81 provides the BGP configuration for Innsbruck.
Example 3-81 Eliminating Redundant Next-Hop Routers in Innsbruck's BGP Configuration
router bgp 100
neighbor 10.50.250.1 remote-as 50
neighbor 10.50.250.1 ebgp-multihop 2
neighbor 10.50.250.1 update-source Loopback0
neighbor 10.200.60.1 remote-as 200
neighbor 10.200.60.1 ebgp-multihop 2
neighbor 10.200.60.1 update-source Loopback0
neighbor 10.200.60.1 distribute-list 1 out
neighbor 172.30.255.254 remote-as 30
neighbor 172.30.255.254 ebgp-multihop 2
neighbor 172.30.255.254 update-source Loopback0
no auto-summary
!
access-list 1 deny 10.20.0.0
access-list 1 deny 192.168.50.0
access-list 1 deny 172.29.0.0
access-list 1 deny 172.17.0.0
access-list 1 permit any
Cervinia has an identical route filter configured for Innsbruck. The filter blocks the advertisement of the AS 50 addresses on the BGP connection between Innsbruck and Cervinia. A point of interest in this configuration is the third line of the access list. Figure 3-15 indicates that subnet 172.29.2.0/24 resides in AS 50, but the access list filters for the network 172.29.0.0. This is because RIP, a classful protocol, does not redistribute the subnet to BGP at Meribel. Rather, it summarizes to the major network address. Subnet 172.29.1.0/24 resides in AS 30; IS-IS is classless and therefore redistributes the subnet into BGP at Zermatt and Moritz. Innsbruck's access list has no effect on this subnet advertisement, because the third line must have an exact match to the major network address.
Finally, Example 3-79 shows that some of the AS 30 addresses, such as 192.168.100.0, are being advertised to Innsbruck from Meribel. This problem is similar to the preceding one—Cervinia advertises the routes to Meribel, which then advertises them to Innsbruck. Example 3-82 shows the configuration for Innsbruck to block all incoming routes from Meribel except the ones that are interior to AS 50.
Example 3-82 Configuring Innsbruck to Block Incoming Routes from Mirabel Except Those Interior to AS 50
router bgp 100
neighbor 10.50.250.1 remote-as 50
neighbor 10.50.250.1 ebgp-multihop 2
neighbor 10.50.250.1 update-source Loopback0
neighbor 10.50.250.1 distribute-list 2 in
neighbor 10.200.60.1 remote-as 200
neighbor 10.200.60.1 ebgp-multihop 2
neighbor 10.200.60.1 update-source Loopback0
neighbor 10.200.60.1 distribute-list 1 out
neighbor 172.30.255.254 remote-as 30
neighbor 172.30.255.254 ebgp-multihop 2
neighbor 172.30.255.254 update-source Loopback0
no auto-summary
!
access-list 1 deny 10.20.0.0
access-list 1 deny 192.168.50.0
access-list 1 deny 172.29.0.0
access-list 1 deny 172.17.0.0
access-list 1 permit any
access-list 2 permit 10.20.0.0
access-list 2 permit 192.168.50.0
access-list 2 permit 172.29.0.0
access-list 2 permit 172.17.0.0
Example 3-83 shows the resulting BGP table at Innsbruck. Comparing it to the table in Example 3-79, you can readily see that the table is much smaller and that it now makes much more sense.
Example 3-83 Innsbruck's BGP Table After the Route Filters Have Been Added
Innsbruck#show ip bgp
BGP table version is 12, local router ID is 10.100.83.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.20.0.0/16 10.50.250.1 0 0 50 ?
* 10.30.0.0/16 10.200.60.1 0 200 30 ?
*> 172.30.255.254 20 0 30 ?
*> 10.50.250.1/32 10.50.250.1 0 0 50 ?
* 172.16.0.0 10.200.60.1 0 200 30 ?
*> 172.30.255.254 20 0 30 ?
*> 172.17.0.0 10.50.250.1 1 0 50 ?
*> 172.29.0.0 10.50.250.1 1 0 50 ?
* 172.29.1.0/24 10.200.60.1 0 200 30 ?
*> 172.30.255.254 20 0 30 ?
* 172.31.0.0 10.200.60.1 0 200 30 ?
*> 172.30.255.254 20 0 30 ?
*> 192.168.2.0/30 10.200.60.1 0 200 30 ?
*> 192.168.50.0 10.50.250.1 1 0 50 ?
* 192.168.100.0 10.200.60.1 0 200 30 ?
*> 172.30.255.254 20 0 30 ?
Innsbruck#
Case Study: Filtering Routes by AS_PATH
In the face of a large number of advertised addresses, filtering by NLRI can quickly become unwieldy or completely impractical. Only a few addresses are being advertised in Figure 3-15, yet the access lists shown in the previous section are already somewhat lengthy.
A common factor in the examples in the preceding section is that in each case, the access lists are used to identify all the addresses within a single AS. In such situations, it is easier to filter on the AS number instead of enumerating each interior address in an access list. The ip as-path access-list command defines a variant of an access list that identifies AS numbers. Just as an access list identifying NLRI is called by the neighbor distribute-list command, the AS_PATH access list is called by the neighbor filter-list command.
The AS_PATH access list uses a powerful text-parsing tool known as regular expressions, or regex for short. Regular expressions are commonly used in such programming languages as Perl, Expect, awk, and Tcl, in search engines, and in UNIX utilities such as egrep. Regular expressions use a string of characters, all of which are either metacharacters or literals, to find matches in text. In the case of AS_PATH access lists, they are used to find matches in the AS_PATH attributes of BGP updates.
Literals are regular characters that describe what to match. Metacharacters describe how the match is made. For example, the regex ^[4-7] matches any string of text that begins with a number between 4 and 7. In this expression, 4 and 7 are the literals. The metacharacters in the expression are ^, [], and -. The caret indicates the beginning of a line: "The string begins with the following." The brackets indicate a group of characters known as a character class: "Anything within the brackets." The hyphen indicates a range: "Anything in the sequence from the first literal to the last literal." Table 3-1 summarizes the most common metacharacters, and Appendix B, "A Regular-Expression Tutorial," contains a short tutorial on the use of regular expressions. If you are not experienced with regular expressions, read Appendix B before continuing with this section.
Other metacharacters, and some of the metacharacters shown in the table, match more than what is indicated. For the sake of simplicity, only the metacharacters and the matches relevant to AS_PATH access lists are listed.
Table 3-1. Regular-Expression Metacharacters Relevant to AS_PATH Access Lists|
| .
| Any single character, including white space.
| | []
| Any character listed between the brackets.
| | [^]
| Any character except those listed between the brackets. (The caret is placed before the sequence of literals.)
| | -
| (Hyphen.) Any character in the range between the two literals separated by the hyphen.
| | ?
| Zero or one instance of the character or pattern.
| | *
| Zero or more instances of the character or pattern.
| | +
| One or more instances of the character or pattern.
| | ^
| Start of a line.
| | $
| End of a line.
| | |
| Either of the literals separated by the metacharacter.
| | _
| (Underscore.) A comma, the beginning of the line, the end of the line, or a space.
|
In the preceding section, the routers Zermatt and Moritz were configured to advertise only routes to addresses interior to AS 30. All other routes were filtered, to prevent AS 100 or AS 200 from attempting to use AS 30 as a transit AS. To implement the filter, all the AS 30 addresses were individually listed in an access list. Example 3-84 shows the configuration for Zermatt using an AS_PATH access list to achieve the same results as in the preceding case study.
Example 3-84 Configuring Zermatt to Advertise Only Routes to Addresses Interior to AS 30 Using an AS_PATH Access List
router bgp 30
redistribute isis level-2
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
neighbor 10.100.83.1 filter-list 1 out
no auto-summary
!
ip as-path access-list 1 permit ^$
Moritz's configuration has an identical AS_PATH access list. The regular expression here uses two metacharacters—the first matches the beginning of a line, and the second matches the end of a line. No literals are included. The regex matches AS_PATHs that include no AS numbers. The only routes in Zermatt's BGP table in Example 3-85 that have empty AS_PATHs are to the destinations interior to AS 30. They match the AS_PATH list statement and are permitted. Like other access lists, the AS_PATH list has an implicit "deny any" at the end; all the other routes in Example 3-85 match this implicit deny and are not advertised.
Example 3-85 The Only Empty AS_PATHs in Zermatt's BGP Table Are Those of Routes to Addresses Within AS 30
Zermatt#show ip bgp
BGP table version is 109, local router ID is 172.30.255.254
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.20.0.0/16 10.100.83.1 0 100 50 ?
*> 10.30.0.0/16 192.168.2.1 20 32768 ?
*> 10.50.250.1/32 10.100.83.1 0 100 50 ?
*> 172.16.0.0 192.168.2.1 20 32768 ?
*> 172.17.0.0 10.100.83.1 0 100 50 ?
*> 172.29.0.0 10.100.83.1 0 100 50 ?
*> 172.29.1.0/24 192.168.2.1 20 32768 ?
*> 172.30.255.150/32 192.168.2.1 30 32768 ?
*> 172.31.0.0 192.168.2.1 20 32768 ?
*> 192.168.2.4/30 192.168.2.1 20 32768 ?
*> 192.168.50.0 10.100.83.1 0 100 50 ?
*> 192.168.100.0 192.168.2.1 20 32768 ?
Zermatt#
Also in the preceding case study, routers Innsbruck and Cervinia were configured to accept routes from Meribel only if the advertised addresses are interior to AS 50. Additionally, these two routers should not advertise to each other routes learned from Meribel. Example 3-86 shows Innsbruck's configuration using AS_PATH access lists to accomplish the same goals.
Example 3-86 Configuring Innsbruck Using AS_PATH Access Lists to Accept Routes from Meribel if They Are Interior to AS 50
router bgp 100
neighbor 10.50.250.1 remote-as 50
neighbor 10.50.250.1 ebgp-multihop 2
neighbor 10.50.250.1 update-source Loopback0
neighbor 10.50.250.1 filter-list 2 in
neighbor 10.200.60.1 remote-as 200
neighbor 10.200.60.1 ebgp-multihop 2
neighbor 10.200.60.1 update-source Loopback0
neighbor 10.200.60.1 filter-list 1 out
neighbor 172.30.255.254 remote-as 30
neighbor 172.30.255.254 ebgp-multihop 2
neighbor 172.30.255.254 update-source Loopback0
no auto-summary
!
ip as-path access-list 1 deny _50_
ip as-path access-list 1 permit .*
ip as-path access-list 2 permit ^50$
List 1 is applied to outgoing updates to Cervinia. The first statement of this list denies any update that includes the AS number 50 anywhere in its AS_PATH. The metacharacters before and after the 50 ensure that this number alone is matched. If the metacharacters were left out, the statement would match not only 50, but also such numbers as 500, 5000, 350, and so on. The regex of the second statement says, "Match any character, and match zero or more occurrences of that character." In other words, match anything. This is the AS_PATH access list version of a "permit any." The result of these two lines is that Innsbruck does not advertise to Cervinia any routes learned from Meribel but advertises all other routes to Cervinia.
List 2 is applied to incoming updates from Meribel. The regex of the one line reads, "Match the beginning of the line, followed by 50, followed by the end of the line." In other words, match AS_PATHs that include the AS number 50 and nothing else. Those routes are permitted. Any routes that Meribel advertises that it learned from another AS will have more than the number 50 in the AS_PATH. These routes are denied by the implicit "deny" at the end of the list.
For the topology in Figure 3-15, Cervinia's AS_PATH access lists are identical to those shown for Innsbruck. In Figure 3-16, however, the topology has been modified. Here, AS 125 is added and serves as a transit between AS 200 and AS 50. If Meribel loses its link to the NAP, traffic into and out of AS 50 should traverse AS 125 and AS 200. With the AS_PATH access lists shown in the preceding example, list 1 denies any routes whose AS_PATH includes the AS number 50. This includes routes to AS 50 learned from router Oberstdorf, which have an AS_PATH of (125,50). As a result, Innsbruck cannot learn these routes from Cervinia and take advantage of the alternate route into AS 50.
To remedy the situation, Example 3-87 shows the configuration for Cervinia.
Example 3-87 Configuring Cervinia to Accommodate AS 125 as a Transit AS to AS 50
router bgp 200
neighbor 10.50.250.1 remote-as 50
neighbor 10.50.250.1 ebgp-multihop 2
neighbor 10.50.250.1 update-source Loopback0
neighbor 10.50.250.1 filter-list 2 in
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
neighbor 10.100.83.1 filter-list 1 out
neighbor 10.125.25.1 remote-as 125
neighbor 10.125.25.1 ebgp-multihop 2
neighbor 10.125.25.1 update-source Loopback0
neighbor 172.30.255.150 remote-as 30
neighbor 172.30.255.150 ebgp-multihop 2
neighbor 172.30.255.150 update-source Loopback0
no auto-summary
!
ip as-path access-list 1 deny ^50$
ip as-path access-list 1 permit .*
ip as-path access-list 2 permit ^50$
In Example 3-87, the first statement of list 1 denies AS_PATHs that contain only the AS number 50, not all AS_PATHs that contain 50, as in the preceding example. Routes that Cervinia learns directly from Meribel are denied, whereas routes to AS 50 learned from Oberstdorf are permitted.
Case Study: Filtering with Route Maps
You also can implement route filters with route maps. The route map can use either access lists, to filter by NLRI, or AS_PATH access lists, to filter by the AS_PATH attribute.
Example 3-88 shows a possible configuration for Zermatt in Figure 3-15.
Example 3-88 Configuring Zermatt to Filter Routes with a Route Map
router bgp 30
redistribute isis level-2
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
neighbor 10.100.83.1 route-map Innsbruck out
no auto-summary
!
access-list 1 permit 192.168.100.0
access-list 1 permit 10.30.0.0
access-list 1 permit 192.168.2.0
access-list 1 permit 172.29.1.0
access-list 1 permit 172.31.0.0
access-list 1 permit 172.16.0.0
!
route-map Innsbruck permit 10
match ip address 1
Access list 1 is the same list that is used in the case study "Filtering Routes by NLRI," in which the access list is called by the neighbor distribute-list command. In this case, the neighbor route-map command refers outgoing routes to a route map named Innsbruck, which in turn uses the match ip address command to call the access list. The route map permits any routes permitted by the access list and denies the rest.
A route map also can call an AS_PATH access list, as demonstrated in the configuration for Zermatt in Example 3-89.
The configuration for Zermatt in Example 3-89 is the same as in Example 3-88, except the match as-path command is used rather than the match ip address command. The AS_PATH access list is the same one as is used in the case study "Filtering Routes by AS_PATH." Routes with an empty AS_PATH attribute—routes originating in AS 30—are permitted, and all other routes are denied.
Example 3-89 Configuring Zermatt with a Route Map to Call an AS_PATH Access List
router bgp 30
redistribute isis level-2
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
neighbor 10.100.83.1 route-map Innsbruck out
no auto-summary
!
ip as-path access-list 1 permit ^$
!
route-map Innsbruck permit 10
match as-path 1
Route maps can filter incoming as well as outgoing BGP updates. In the preceding case study, router Innsbruck filters incoming routes from Meribel and accepts only those routes that have an AS_PATH attribute of 50, with no other numbers in the list. The router also filters outgoing routes to Cervinia and allows only those routes that do not have AS 30 in their AS_PATH. Using route maps for the same purpose, Example 3-90 shows the configuration for Innsbruck.
Example 3-90 Configuring Innsbruck to Filter Routes with a Route Map
router bgp 100
neighbor 10.50.250.1 remote-as 50
neighbor 10.50.250.1 ebgp-multihop 2
neighbor 10.50.250.1 update-source Loopback0
neighbor 10.50.250.1 route-map Meribel in
neighbor 10.200.60.1 remote-as 200
neighbor 10.200.60.1 ebgp-multihop 2
neighbor 10.200.60.1 update-source Loopback0
neighbor 10.200.60.1 route-map Cervinia-to-Meribel out
neighbor 172.30.255.254 remote-as 30
neighbor 172.30.255.254 ebgp-multihop 2
neighbor 172.30.255.254 update-source Loopback0
no auto-summary
!
ip as-path access-list 1 deny _50_
ip as-path access-list 1 permit .*
ip as-path access-list 2 permit ^50$
!
route-map Meribel permit 10
match as-path 2
!
route-map Cervinia-to-Meribel permit 10
match as-path 1
Using route maps rather than distribute lists or filter lists can prove useful when you must configure many route filters on a single router. Because route maps use names rather than numbers, an intuitive name can make such a configuration a little easier to decipher. In Example 3-88 and Example 3-89, naming the route map Innsbruck very clearly identifies what neighbor the route map concerns. In Example 3-90, the names identify paths through neighbors.
The major reason for using route maps, however, is their power not only to identify particular routes with match statements, but also to change their attributes with set statements. The next five case studies demonstrate the use of route maps to implement more-complex routing policies. Respectively, the five case studies demonstrate methods for influencing route preferences:
Within a single router (multiple BGP routes to the same destination) Within a single router (multiple routes to the same destination from different routing protocols) Within the local autonomous system Within neighboring autonomous systems Within autonomous systems beyond the neighboring autonomous systems
Case Study: Administrative Weights
Frequently, a BGP router is presented with multiple routes to the same destination. Although BGP has default methods for choosing among these routes, you might need to override these defaults on occasion to implement a routing policy. Although the RFCs do not provide for methods to influence route preferences within a single router, Cisco's IOS Software does.
The first of these Cisco-specific tools is administrative weight. Each route is assigned a weight, which is a number between 0 and 65,535. Given multiple routes to the same destination, the router prefers the route with the highest weight. By default, BGP routes originated by the router are given a weight of 32,768, and routes learned from neighbors are given a weight of 0.
Given multiple routes to the same destination, administrative weight overrides all other factors in the BGP decision process. But administrative weight is also local to the router. That is, it is not advertised to any neighboring BGP speakers. Therefore, the assigned weight of a route on one router does not have any bearing on the preference of the route in other routers.
In Figure 3-17, the connectivity of AS 30 has been improved. Zermatt and Moritz are each multihomed to AS 100 and AS 200 for added redundancy. Each router receives routes to the addresses in AS 50 from Innsbruck and from Cervinia. Recall from the discussion of the BGP decision process in Chapter 2 that when selecting a preferred route from multiple same-destination routes, if all other attributes are equal, BGP selects the route from the neighbor with the lowest router ID. This means that both Zermatt and Moritz in Figure 3-17 will use Innsbruck to reach the destinations in AS 50, because its router ID is lower than Cervinia, as demonstrated by the output in Example 3-91. Zermatt and Moritz show that the destinations within AS 50 are reachable via either Innsbruck (10.100.83.1) or Cervinia (10.200.60.1). Both routers have marked the routes from Innsbruck as the best routes, because Innsbruck's router ID is lower.
Example 3-91 BGP Tables of Zermatt and Moritz in Figure 3-17
Zermatt# show ip bgp
BGP table version is 34, local router ID is 172.30.255.254
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 10.20.0.0/16 10.200.60.1 0 200 50 ?
*> 10.100.83.1 0 100 50 ?
*> 10.30.0.0/16 192.168.2.1 20 32768 ?
* 10.50.250.1/32 10.200.60.1 0 200 50 ?
*> 10.100.83.1 0 100 50 ?
*> 10.100.83.1/32 10.200.60.1 0 200 50 ?
*> 10.200.60.1/32 10.100.83.1 0 100 50 ?
*> 172.16.0.0 192.168.2.1 20 32768 ?
* 172.17.0.0 10.200.60.1 0 200 50 ?
*> 10.100.83.1 0 100 50 ?
* 172.29.0.0 10.200.60.1 0 200 50 ?
*> 10.100.83.1 0 100 50 ?
*> 172.29.1.0/24 192.168.2.1 20 32768 ?
*> 172.30.255.150/32 192.168.2.1 30 32768 ?
*> 172.31.0.0 192.168.2.1 20 32768 ?
*> 192.168.2.4/30 192.168.2.1 20 32768 ?
* 192.168.50.0 10.200.60.1 0 200 50 ?
*> 10.100.83.1 0 100 50 ?
*> 192.168.100.0 192.168.2.1 20 32768 ?
Zermatt#
_______________________________________________________________________
Moritz#show ip bgp
BGP table version is 33, local router ID is 172.30.255.150
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.20.0.0/16 10.100.83.1 0 100 50 ?
* 10.200.60.1 0 200 50 ?
*> 10.30.0.0/16 192.168.2.5 20 32768 ?
*> 10.50.250.1/32 10.100.83.1 0 100 50 ?
* 10.200.60.1 0 200 50 ?
*> 10.100.83.1/32 10.200.60.1 0 200 50 ?
*> 10.200.60.1/32 10.100.83.1 0 100 50 ?
*> 172.16.0.0 192.168.2.5 20 32768 ?
*> 172.17.0.0 10.100.83.1 0 100 50 ?
* 10.200.60.1 0 200 50 ?
*> 172.29.0.0 10.100.83.1 0 100 50 ?
* 10.200.60.1 0 200 50 ?
*> 172.29.1.0/24 192.168.2.5 20 32768 ?
*> 172.30.255.254/32 192.168.2.5 30 32768 ?
*> 172.31.0.0 192.168.2.5 20 32768 ?
*> 192.168.2.0/30 192.168.2.5 20 32768 ?
*> 192.168.50.0 10.100.83.1 0 100 50 ?
* 10.200.60.1 0 200 50 ?
Network Next Hop Metric LocPrf Weight Path
*> 192.168.100.0 192.168.2.5 20 32768 ?
Moritz#
To spread out the traffic load more evenly, Zermatt should use the link to Innsbruck to reach AS 50, and only use the link to Cervinia as a backup. Moritz should use the link to Cervinia, and only use Innsbruck as a backup. Both routers implement this policy by manipulating the weights of the routes, as demonstrated in Example 3-92.
Example 3-92 Configuring Zermatt and Moritz to Follow Route Policies by Manipulating Route Weights
Zermatt
router bgp 30
redistribute isis level-2
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
neighbor 10.100.83.1 filter-list 1 out
neighbor 10.100.83.1 weight 50000
neighbor 10.200.60.1 remote-as 200
neighbor 10.200.60.1 ebgp-multihop 2
neighbor 10.200.60.1 update-source Loopback0
neighbor 10.200.60.1 filter-list 1 out
neighbor 10.200.60.1 weight 20000
no auto-summary
___________________________________________________________________________________________________________
Moritz
router bgp 30
redistribute isis level-2
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
neighbor 10.100.83.1 filter-list 1 out
neighbor 10.100.83.1 weight 20000
neighbor 10.200.60.1 remote-as 200
neighbor 10.200.60.1 ebgp-multihop 2
neighbor 10.200.60.1 update-source Loopback0
neighbor 10.200.60.1 filter-list 1 out
neighbor 10.200.60.1 weight 50000
no auto-summary
The configurations in Example 3-92 use the neighbor weight command to assign weights to routes according to which neighbor advertises the routes. Zermatt assigns a weight of 50000 to routes learned from Innsbruck (10.100.83.1) and a weight of 20000 to routes learned from Cervinia (10.200.60.1). Moritz does just the opposite. As a result, the two routers prefer the routes with the higher weight, and will use the alternative paths only if the preferred route becomes invalid, as demonstrated by the output in Example 3-93.
Example 3-93 Zermatt and Moritz Designate the Routes with the Highest Weight as "Best"; the Locally Originated Routes Continue to Have a Default Weight of 32768
Zermatt#show ip bgp
BGP table version is 104, local router ID is 172.30.255.254
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.20.0.0/16 10.100.83.1 50000 100 50 ?
* 10.200.60.1 20000 200 50 ?
*> 10.30.0.0/16 192.168.2.1 20 32768 ?
*> 10.50.250.1/32 10.100.83.1 50000 100 50 ?
* 10.200.60.1 20000 200 50 ?
*> 10.100.83.1/32 10.200.60.1 20000 200 50 ?
*> 10.200.60.1/32 10.100.83.1 50000 100 50 ?
*> 172.16.0.0 192.168.2.1 20 32768 ?
*> 172.17.0.0 10.100.83.1 50000 100 50 ?
* 10.200.60.1 20000 200 50 ?
*> 172.29.0.0 10.100.83.1 50000 100 50 ?
* 10.200.60.1 20000 200 50 ?
*> 172.29.1.0/24 192.168.2.1 20 32768 ?
*> 172.30.255.150/32 192.168.2.1 30 32768 ?
*> 172.31.0.0 192.168.2.1 20 32768 ?
*> 192.168.2.4/30 192.168.2.1 20 32768 ?
*> 192.168.50.0 10.100.83.1 50000 100 50 ?
* 10.200.60.1 20000 200 50 ?
*> 192.168.100.0 192.168.2.1 20 32768 ?
Zermatt#
___________________________________________________________________________________________________________
Moritz#show ip bgp
BGP table version is 20, local router ID is 172.30.255.150
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 10.20.0.0/16 10.100.83.1 20000 100 50 ?
*> 10.200.60.1 50000 200 50 ?
*> 10.30.0.0/16 192.168.2.5 20 32768 ?
* 10.50.250.1/32 10.100.83.1 20000 100 50 ?
*> 10.200.60.1 50000 200 50 ?
*> 10.100.83.1/32 10.200.60.1 50000 200 50 ?
*> 10.200.60.1/32 10.100.83.1 20000 100 50 ?
*> 172.16.0.0 192.168.2.5 20 32768 ?
* 172.17.0.0 10.100.83.1 20000 100 50 ?
*> 10.200.60.1 50000 200 50 ?
* 172.29.0.0 10.100.83.1 20000 100 50 ?
*> 10.200.60.1 50000 200 50 ?
*> 172.29.1.0/24 192.168.2.5 20 32768 ?
*> 172.30.255.254/32 192.168.2.5 30 32768 ?
*> 172.31.0.0 192.168.2.5 20 32768 ?
*> 192.168.2.0/30 192.168.2.5 20 32768 ?
* 192.168.50.0 10.100.83.1 20000 100 50 ?
*> 10.200.60.1 50000 200 50 ?
*> 192.168.100.0 192.168.2.5 20 32768 ?
Moritz#
The neighbor weight command is useful if the weights for all routes learned from a particular neighbor are to be the same. Sometimes, however, different weights must be assigned to routes from the same neighbor. One way to implement a policy requiring this is with the neighbor filter-list weight command. Like the neighbor filter-list command used for route filtering, this command references an AS_PATH access list to identify routes according to the details of their AS_PATH attribute. However, although a particular neighbor can have at most one neighbor filter-list in and one neighbor filter-list out command, multiple instances of the neighbor filter-list weight command might be assigned to a single neighbor. You can configure the neighbor filter-list and the neighbor filter-list weight command for the same neighbor; although the commands look very similar, their purposes and effects differ significantly.
Figure 3-18 depicts the same topology as in Figure 3-17, but another AS has been connected to the NAP. Both Innsbruck and Cervinia advertise the routes from AS 50 and AS 75 to both Zermatt and Moritz. A new routing policy is established, requiring Moritz to use Cervinia to reach the destinations within AS 75 and Innsbruck to reach the destinations within AS 50.
Example 3-94 shows the configuration for Moritz using the neighbor filter-list weight command.
Example 3-94 Configuring Moritz to Prefer Cervinia as the Next-Hop Router to AS 75 via the neighbor filter-list weight Command
router bgp 30
redistribute isis level-2
neighbor 10.100.83.1 remote-as 100
neighbor 10.100.83.1 ebgp-multihop 2
neighbor 10.100.83.1 update-source Loopback0
neighbor 10.100.83.1 filter-list 1 out
neighbor 10.100.83.1 filter-list 2 weight 40000
neighbor 10.100.83.1 filter-list 3 weight 60000
neighbor 10.200.60.1 remote-as 200
neighbor 10.200.60.1 ebgp-multihop 2
neighbor 10.200.60.1 update-source Loopback0
neighbor 10.200.60.1 filter-list 1 out
neighbor 10.200.60.1 filter-list 2 weight 60000
neighbor 10.200.60.1 filter-list 3 weight 40000
no auto-summary
!
ip as-path access-list 1 permit ^$
ip as-path access-list 2 permit _75$
ip as-path access-list 3 permit _50$
The regular expression _75$ in list 2 identifies AS_PATHs that end in 75 and will match the paths (100,75) and (200,75). Similarly, list 3 matches paths that end in 50. Under the neighbor configuration for Innsbruck (10.100.83.1), routes to AS 75 are given a weight of 40000, and routes to AS 50 are given a weight of 60000. Under the neighbor configuration for Cervinia (10.200.60.1), the opposite is true. Routes to AS 75 are given a weight of 60000, and routes to AS 50 are given a weight of 40000. Example 3-95 shows the resulting BGP table at Moritz.
Example 3-95 Cervinia Is the Preferred Next-Hop Router to Reach AS 75, and Innsbruck Is the Preferred Next-Hop Router to Reach AS 50
Moritz#show ip bgp
BGP table version is 19, local router ID is 172.30.255.150
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.20.0.0/16 10.100.83.1 60000 100 50 ?
* 10.200.60.1 40000 200 50 ?
*> 10.30.0.0/16 192.168.2.5 20 32768 ?
*> 10.50.250.1/32 10.100.83.1 60000 100 50 ?
* 10.200.60.1 40000 200 50 ?
*> 10.100.83.1/32 10.200.60.1 40000 200 50 ?
*> 10.200.60.1/32 10.100.83.1 60000 100 50 ?
*> 172.16.0.0 192.168.2.5 20 32768 ?
*> 172.17.0.0 10.100.83.1 60000 100 50 ?
* 10.200.60.1 40000 200 50 ?
* 172.18.0.0 10.100.83.1 40000 100 75 i
*> 10.200.60.1 60000 200 75 i
*> 172.29.0.0 10.100.83.1 60000 100 50 ?
* 10.200.60.1 40000 200 50 ?
*> 172.29.1.0/24 192.168.2.5 20 32768 ?
*> 172.30.255.254/32 192.168.2.5 30 32768 ?
*> 172.31.0.0 192.168.2.5 20 32768 ?
*> 192.168.2.0/30 192.168.2.5 20 32768 ?
*> 192.168.50.0 10.100.83.1 60000 100 50 ?
* 10.200.60.1 40000 200 50 ?
* 192.168.75.0 10.100.83.1 40000 100 75 i
*> 10.200.60.1 60000 200 75 i
*> 192.168.100.0 192.168.2.5 20 32768 ?
Moritz#
If you use both the neighbor weight command and the neighbor filter-list weight command under the same neighbor configuration, the neighbor filter-list weight command takes precedence. Any routes from the peer whose weights are not set by | 
