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 s oft 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.

Figure 3-15. AS 30 Is Multihomed to Different Transit Autonomous Systems

graphics/03fig15.gif

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
Metacharacter What It Matches
. 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.

Figure 3-16. AS 125 Provides an Alternate Path to AS 50

graphics/03fig16.gif

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.

Figure 3-17. Zermatt and Moritz Are Multihomed for Redundancy

graphics/03fig17.gif

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.

Figure 3-18. AS 75 Has Been Connected to the NAP

graphics/03fig18.gif

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 neighbor filter-list weight have their weights set by the neighbor weight command.

You also can manipulate the weight with the neighbor route-map command. Example 3-96 shows the configuration for Moritz using route maps to achieve the same results as the configuration in Example 3-94.

Example 3-96 Configuring Moritz to Prefer Cervinia as the Next-Hop Router to AS 75 via Route Maps
  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 in   neighbor 10.100.83.1 filter-list 1 out   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 in   neighbor 10.200.60.1 filter-list 1 out   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$   !   route-map Innsbruck permit 10   match as-path 2   set weight 40000   !   route-map Innsbruck permit 20   match as-path 3   set weight 60000   !   route-map Cervinia permit 10   match as-path 2   set weight 60000   !   route-map Cervinia permit 20   match as-path 3   set weight 40000  

When route maps are used to set weights, only the AS_PATH can be matched; individual IP addresses cannot be matched with the match ip address command. You also can use weight-setting route maps in the same neighbor configuration as neighbor filter-list weight and neighbor weight commands. Weight-setting route maps take precedence over either of the other two commands.

Case Study: Administrative Distances and Backdoor Routes

The other Cisco-specific tool for manipulating preferences on a single router is administrative distance. Whereas administrative weight influences preference among multiple routes to the same destination that have been learned from different BGP peers, administrative distance influences preference among multiple routes to the same destination that have been learned from different routing protocols. This means that whereas the effects of administrative weights are seen in the BGP table, the effects of administrative distances are seen in the IP routing table.

Normally, an administrative distance is assigned to a route according to the protocol or source from which the route is learned. The lower the distance, the more preferable the route. Table 3-2 shows the default administrative distances for the various protocols. You can see that within an AS, if a router learns routes to the same destination from RIP and OSPF, the OSPF route is preferred because its distance (110) is lower than that of the RIP route (120).

EBGP has a default distance of 20, lower than any of the IGPs. At first, this might seem like a problem in internetworks such as the one in Figure 3-18. When Zermatt advertises one of the AS 30 internal addresses to Innsbruck, the address is passed to Cervinia, which can pass it back to Moritz. Moritz, hearing the route via EBGP, prefers it over the IS-IS route to the same destination, because the IS-IS route has a distance of 115. In fact, this doesn't happen, because of the basic BGP loop- avoidance mechanism. Moritz observes the 30 in the AS_PATH of the route from Cervinia and drops the route.

Table 3-2. Cisco Default Administrative Distances [1]
Route Source Administrative Distance
Connected interface
Static route 1
EIGRP summary route 5
External BGP 20
EIGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EGP 140
External EIGRP 170
Internal BGP 200
Local BGP 200
Unknown 255

[1] When a static route refers to an interface rather than a next-hop address, the destination is considered to be a directly connected network.

On the other hand, IBGP does not add an AS number to the AS_PATH. So a route learned from an IGP and then passed to an IBGP peer within a single AS could cause routing loops or black holes. For this reason, the distance of IBGP routes is 200, higher than that of any IGP. An IGP-learned route is always preferred over an IBGP route to the same destination.

Local BGP routes are those originated on the local router as the result of using the BGP network command. Like IBGP routes, they have a default administrative distance of 200 so that they are not preferred over IGP routes.

Chapter 13, "Route Filtering," of Volume I includes a case study demonstrating how to manipulate the default distances of IGP routes. To change the default distances of BGP, you use the distance bgp command. This command sets the distances for EBGP, IBGP, and local BGP routes, respectively. The configuration in Example 3-97 changes the IBGP administrative distance to 95, making the IBGP routes preferred over all IGP routes to the same destination, except EIGRP routes.

Example 3-97 Changing the IBGP Administrative Distance to 95 to Make IBGP Routes Preferred Over All IGP Routes Except EIGRP
  router bgp 30   neighbor 10.200.60.1 remote-as 200   neighbor 10.200.60.1 ebgp-multihop 2   neighbor 10.200.60.1 update-source Loopback0    distance bgp 20 95 200   

Unlike IGPs, there is seldom a good reason for changing the default BGP distances for all routes. However, there is a situation is which the distances of some BGP routes should be changed. In Figure 3-19, a private link is added between routers Meribel and Lillehammer, and the routers speak RIP across the link. This link is used as a back door. That is, some traffic between AS 50 and AS 75 should be sent over the private backdoor route rather than across the public NAP. Perhaps AS 50 and AS 75 have a business partnership, and they want some of their communications to pass over their private link rather than the public Internet.

Figure 3-19. A Private Backdoor Link Has Been Added Between AS 50 and AS 75, Allowing the IGP Processes of Those Autonomous Systems to Communicate Directly Rather Than Through the EBGP Sessions

graphics/03fig19.gif

In this example, traffic between 172.17.0.0 in AS 50 and 172.18.0.0 in AS75 should travel across the backdoor link and use the NAP route only if the backdoor route fails. The problem is the administrative distance. Lillehammer, for instance, learns the route to 172.17.0.0 from Meribel via both RIP across the backdoor link and EBGP across the NAP link. EBGP has a distance of 20 and RIP has a distance of 120, so the EBGP route is preferred, as indicated in the output in Example 3-98.

Example 3-98 Lillehammer Learns the Route to 172.17.0.0 via Both RIP and EBGP; the EBGP Route, with an Administrative Distance of 20, Is Preferred
 Lillehammer#  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        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        T - traffic engineered route Gateway of last resort is not set C    192.168.75.0/24 is directly connected, Ethernet2  B    172.17.0.0/16 [20/1] via 10.50.250.1, 00:01:24  B    172.16.0.0/16 [20/0] via 10.100.83.1, 00:01:22 C    172.18.0.0/16 is directly connected, Ethernet1      172.29.0.0/16 is variably subnetted, 2 subnets, 2 masks B       172.29.1.0/24 [20/0] via 10.100.83.1, 00:01:22 B       172.29.0.0/16 [20/1] via 10.50.250.1, 00:01:24 B    172.31.0.0/16 [20/0] via 10.100.83.1, 00:01:22      192.168.4.0/29 is subnetted, 1 subnets C       192.168.4.0 is directly connected, Ethernet0      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks B       10.30.0.0/16 [20/0] via 10.100.83.1, 00:01:22 B       10.20.0.0/16 [20/0] via 10.50.250.1, 00:01:24 C       10.21.0.0/16 is directly connected, Serial1.507 C       10.75.100.1/32 is directly connected, Loopback0 S       10.100.83.1/32 is directly connected, Ethernet0 S       10.50.250.1/32 is directly connected, Ethernet0 S       10.200.60.1/32 is directly connected, Ethernet0 B    192.168.50.0/24 [20/1] via 10.50.250.1, 00:01:27 B    192.168.100.0/24 [20/0] via 10.100.83.1, 00:01:25 Lillehammer# 

One solution is to use the BGP network command, as demonstrated in Example 3-99.

Example 3-99 Using the network Command to Cause the EBGP- Discovered Routes to Be Treated as Local BGP Routes
  Lillehammer   router rip   redistribute bgp 75   network 10.0.0.0   network 172.18.0.0   network 192.168.75.0   !   router bgp 75    network 172.17.0.0    network 172.18.0.0   network 192.168.75.0   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 10.200.60.1 remote-as 200   neighbor 10.200.60.1 ebgp-multihop 2   neighbor 10.200.60.1 update-source Loopback0  ___________________________________________________________________________________________________________  Meribel   router rip   redistribute bgp 50 metric 1   network 10.0.0.0   !   router bgp 50    network 172.18.0.0    redistribute rip   neighbor 10.75.100.1 remote-as 75   neighbor 10.75.100.1 ebgp-multihop 2   neighbor 10.75.100.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 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  

In the configurations in Example 3-99, the network commands cause the EBGP-discovered routes to be treated as local BGP routes. Network 172.17.0.0 is advertised to Lillehammer via EBGP, for instance, and is entered into the routing table. The command network 172.17.0.0 is added to Lillehammer's BGP configuration, even though 172.17.0.0 is not really a local route. Because the address is in the routing table, the network command matches it and makes it a local route.

The logic sounds quite strange , but it works. By first being an EBGP route, 172.17.0.0 is changed into a local BGP route with the network command. Because 172.17.0.0 is now considered a local route at Lillehammer, it is assigned an administrative distance of 200. The RIP route to 172.17.0.0 now has a lower distance and becomes the preferred route, as indicated in the output in Example 3-100.

Example 3-100 By Causing Lillehammer to Treat the EBGP Route to 172.17.0.0 as a Local BGP Route with an Administrative Distance of 200, the RIP Route to That Network Becomes the Preferred Route
 Lillehammer#  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        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        T - traffic engineered route Gateway of last resort is not set C    192.168.75.0/24 is directly connected, Ethernet2  R    172.17.0.0/16 [120/2] via 10.21.1.1, 00:00:06, Serial1.507  B    172.16.0.0/16 [20/0] via 10.200.60.1, 00:00:36 C    172.18.0.0/16 is directly connected, Ethernet1      172.29.0.0/16 is variably subnetted, 2 subnets, 2 masks B       172.29.1.0/24 [20/0] via 10.200.60.1, 00:00:36 B       172.29.0.0/16 [20/1] via 10.50.250.1, 00:00:24 B    172.31.0.0/16 [20/0] via 10.200.60.1, 00:00:36      192.168.4.0/29 is subnetted, 1 subnets C       192.168.4.0 is directly connected, Ethernet0      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks B       10.30.0.0/16 [20/0] via 10.200.60.1, 00:00:36 B       10.20.0.0/16 [20/0] via 10.50.250.1, 00:00:24 C       10.21.0.0/16 is directly connected, Serial1.507 C       10.75.100.1/32 is directly connected, Loopback0 S       10.100.83.1/32 is directly connected, Ethernet0 S       10.50.250.1/32 is directly connected, Ethernet0 S       10.200.60.1/32 is directly connected, Ethernet0 B    192.168.50.0/24 [20/1] via 10.50.250.1, 00:00:25 B    192.168.100.0/24 [20/0] via 10.200.60.1, 00:00:37 Lillehammer# 

Although the administrative distances have been manipulated correctly, this configuration has a problem. By using the network command to convert an EBGP route into a local route, the local BGP router now advertises the route in its own EBGP updates. Lillehammer, for example, now advertises 172.17.0.0 in its EBGP updates to its peers across the NAP. Because Meribel's BGP process learns the route to 172.17.0.0 from redistribution, it advertises the route with an ORIGIN of Incomplete. But Lillehammer, because of the network statement, advertises the route with an ORIGIN of IGP. As a result, Cervinia and Innsbruck choose Lillehammer as the best next hop to 172.17.0.0, as demonstrated in the output in Example 3-101. External traffic to 172.17.0.0 is forwarded to Lillehammer, which forwards the traffic across the backdoor link. Only traffic between 172.17.0.0 and 172.18.0.0 is supposed to use the backdoor link; all other traffic should use the NAP.

Example 3-101 Cervinia Shows Lillehammer (10.75.100.1) as the Best Next Hop to Network 172.17.0.0, Causing the Backdoor Link Between Lillehammer and Meribel to Become a Transit Network for All External Traffic to 172.17.0.0
 Cervinia#  show ip bgp 172.17.0.0  BGP routing table entry for 172.17.0.0/16, version 474 Paths: (3 available, best #2, advertised over EBGP)   100 75     10.100.83.1 from 10.100.83.1       Origin IGP, localpref 100, valid, external   75     10.75.100.1 from 10.75.100.1 (192.168.75.1)       Origin IGP, metric 2, localpref 100, valid, external, best   50     10.50.250.1 from 10.50.250.1       Origin incomplete, metric 1, localpref 100, valid, external Cervinia# 

Example 3-102 shows the solution to this problem via the network backdoor command, another Cisco-specific tool.

Example 3-102 Restricting External Traffic from the Backdoor Link Between Lillehammer and Meribel
  Lillehammer   router rip   redistribute bgp 75   network 10.0.0.0   network 172.18.0.0   network 192.168.75.0   !   router bgp 75    network 172.17.0.0 backdoor    network 172.18.0.0   network 192.168.75.0   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 10.200.60.1 remote-as 200   neighbor 10.200.60.1 ebgp-multihop 2   neighbor 10.200.60.1 update-source Loopback0  ___________________________________________________________________________________________________________  Meribel   router rip   redistribute bgp 50 metric 1   network 10.0.0.0   !   router bgp 50    network 172.18.0.0 backdoor    redistribute rip   neighbor 10.75.100.1 remote-as 75   neighbor 10.75.100.1 ebgp-multihop 2   neighbor 10.75.100.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 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  

The network backdoor command has the same effect as the network command: The EBGP route is treated as a local BGP route, and the administrative distance is changed to 200. The difference is that the address specified by the network backdoor command is not advertised to EBGP peers. In the case of network 172.17.0.0, the new configurations result in the same routing table at Lillehammer shown in Example 3-100. But Cervinia's BGP table no longer contains a route to that network from Lillehammer.

Case Study: Using the LOCAL_PREF Attribute

The LOCAL_PREF attribute is used to set preferences among multiple routes to the same destination. Unlike administrative weight, the LOCAL_PREF is not limited to a single router. Rather, it is communicated to IBGP peers. The attribute is not communicated to EBGP peers ”hence the name local preference.

A route's LOCAL_PREF attribute can be any number between 0 and 4,294,967,295; the higher the number, the more preferable the route. By default, all routes advertised to IBGP peers have a LOCAL_PREF of 100. This default value can be changed with the ip default local-preference command. You can change the LOCAL_PREF attribute of individual routes by using a route map and the command set local-preference.

In Figure 3-20, AS 30 is multihomed to a single AS. For redundancy, links are added between Zermatt and Moritz and between Innsbruck and Saalbach; IBGP is run on each of these links.

Figure 3-20. AS 30 Is Multihomed to a Single Autonomous System

graphics/03fig20.gif

Routing policy in AS 30 requires that all outgoing traffic to AS 75 must use the Moritz-Saalbach link, and all outgoing traffic to AS 50 must use the Zermatt-Innsbruck link. In each case, the other link should be used only if the preferred link is unavailable. Example 3-103 shows the configurations of Zermatt and Moritz.

Example 3-103 Influencing Route Preferences with the LOCAL_PREF Attribute
  Zermatt   router isis   net 30.5678.1234.defa.00   default-information originate   !   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 PREF in   neighbor 10.100.83.1 filter-list 1 out   neighbor 172.30.255.150 remote-as 30   neighbor 172.30.255.150 ebgp-multihop 2   neighbor 172.30.255.150 update-source Loopback0   neighbor 172.30.255.150 next-hop-self   no auto-summary   !   ip route 10.100.83.1 255.255.255.255 Serial1.906   ip route 172.30.255.150 255.255.255.255 Serial1.908   !   ip as-path access-list 1 permit ^$   ip as-path access-list 2 permit _50$   !   route-map PREF permit 10   match as-path 2   set local-preference 200   !   route-map PREF permit 20  ___________________________________________________________________________________________________________  Moritz   router isis   net 30.1234.5678.abcd.00   default-information originate   !   router bgp 30   redistribute isis level-2   neighbor 10.100.65.1 remote-as 100   neighbor 10.100.65.1 ebgp-multihop 2   neighbor 10.100.65.1 update-source Loopback0   neighbor 10.100.65.1 route-map PREF in   neighbor 10.100.65.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   neighbor 172.30.255.254 next-hop-self   no auto-summary   !   ip route 10.100.65.1 255.255.255.255 Serial1.803   ip route 172.30.255.254 255.255.255.255 Serial1.809   !   ip as-path access-list 1 permit ^$   ip as-path access-list 2 permit _75$   !   route-map PREF permit 10   match as-path 2   set local-preference 300   !   route-map PREF permit 20  

Each router links the incoming routes from its EBGP peer to a route map named PREF. Sequence 10 of this route map identifies the AS_PATH of the incoming routes. Incoming routes at Zermatt whose AS_PATH ends in a 50 are assigned a LOCAL_PREF of 200. Incoming routes at Moritz whose AS_PATH ends in a 75 are assigned a LOCAL_PREF of 300. Any routes that are not matched at sequence 10 are permitted by sequence 20 and get the default value of 100.

NOTE

In practice, the two routers would probably assign the same LOCAL_PREF values. The values differ in this example only so that the influence of each route map is more easily observed .


Example 3-104 shows the results in the BGP tables of the two routers.

Example 3-104 Zermatt Sets a LOCAL_PREF of 200 for Routes to Destinations Within AS 50, and Moritz Sets a LOCAL_PREF of 300 for Routes to Destinations Within AS 75
 Zermatt#  show ip bgp  BGP table version is 20, 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                 200      0 100 50 ? *> 10.30.0.0/16     192.168.2.1           20         32768 ? * i                 172.30.255.150        20    100      0 ? *> 10.50.250.1/32   10.100.83.1                 200      0 100 50 ? *> 10.75.100.1/32   10.100.83.1                 100      0 100 75 ? *> 10.100.65.1/32   10.100.83.1                 200      0 100 50 ? *>i10.100.83.1/32   172.30.255.150              100      0 100 50 ? *> 172.16.0.0/16    192.168.2.1           20         32768 ? * i                 172.30.255.150        20    100      0 ? *> 172.17.0.0       10.100.83.1                 200      0 100 50 ? *  172.18.0.0       10.100.83.1                          0 100 75 i *>i                 172.30.255.150              300      0 100 75 i *> 172.29.0.0       10.100.83.1                 200      0 100 50 ? *> 172.29.1.0/24    192.168.2.1           20         32768 ? * i                 172.30.255.150        20    100      0 ? *> 172.31.0.0       192.168.2.1           20         32768 ? * i                 172.30.255.150        20    100      0 ? *>i192.168.2.0/30   172.30.255.150        20    100      0 ? *> 192.168.2.4/30   192.168.2.1           20         32768 ? *> 192.168.50.0     10.100.83.1                 200      0 100 50 ? *  192.168.75.0     10.100.83.1                          0 100 75 i *>i                 172.30.255.150              300      0 100 75 i *> 192.168.100.0    192.168.2.1           20         32768 ? * i                 172.30.255.150        20    100      0 ? Zermatt# ___________________________________________________________________________________________________________ Moritz#  show ip bgp  BGP table version is 25, 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.65.1                          0 100 50 ? *>i                 172.30.255.254              200      0 100 50 ? *> 10.30.0.0/16     192.168.2.5           20         32768 ? * i                 172.30.255.254        20    100      0 ? *  10.50.250.1/32   10.100.65.1                          0 100 50 ? *>i                 172.30.255.254              200      0 100 50 ? *  10.75.100.1/32   10.100.65.1                          0 100 75 ? *>i                 172.30.255.254              100      0 100 75 ? *>i10.100.65.1/32   172.30.255.254              200      0 100 50 ? *> 10.100.83.1/32   10.100.65.1                          0 100 50 ? *> 172.16.0.0/16    192.168.2.5           20         32768 ? * i                 172.30.255.254        20    100      0 ? *  172.17.0.0       10.100.65.1                          0 100 50 ? *>i                 172.30.255.254              200      0 100 50 ? *> 172.18.0.0       10.100.65.1                 300      0 100 75 i *  172.29.0.0       10.100.65.1                          0 100 50 ? *>i                 172.30.255.254              200      0 100 50 ? *> 172.29.1.0/24    192.168.2.5           20         32768 ? * i                 172.30.255.254        20    100      0 ? *> 172.31.0.0       192.168.2.5           20         32768 ? * i                 172.30.255.254        20    100      0 ? *> 192.168.2.0/30   192.168.2.5           20         32768 ? *>i192.168.2.4/30   172.30.255.254        20    100      0 ? *  192.168.50.0     10.100.65.1                          0 100 50 ? *>i                 172.30.255.254              200      0 100 50 ? *> 192.168.75.0     10.100.65.1                 300      0 100 75 i *> 192.168.100.0    192.168.2.5           20         32768 ? * i                 172.30.255.254        20    100      0 ? Moritz# 

Notice the fundamental difference between the configurations in Example 3-103 and the IS\_IS configurations from several of the earlier examples. Here, BGP routes are not distributed into the IS-IS domain. Instead, each router advertises a default address. When sending traffic to an external destination, the interior routers forward packets to the nearest default address ”either Zermatt or Innsbruck. Those routers then forward the packets to either their respective EBGP peer or to the IBGP peer across the redundant link, depending on the LOCAL_PREF attribute of the external route.

Eliminating the redistribution of BGP into IS-IS is not done on a whim; it is required for this topology and this routing policy. If Moritz redistributes the EBGP route to 172.18.0.0 into IS-IS, for example, the route is advertised across the IS-IS domain to Zermatt. Zermatt accepts the route and redistributes it back into BGP, entering it into its own BGP table. Because Zermatt enters the route into its BGP table, the route is considered locally originated and is given a weight of 32768. Administrative weight overrules LOCAL_PREF, and Zermatt sees the best route to 172.17.0.0 as through the IS-IS domain rather than across the direct link to Moritz.

Case Study: Using the MULTI_EXIT_DISC Attribute

The MULTI_EXIT_DISC attribute, or MED, is used to influence the routing decisions in neighboring autonomous systems. The MED is also known as the external metric, and in fact is labeled as "metric" in the BGP table. Like LOCAL_PREF, the MED is a 4-octet number and therefore can be any number from 0 to 4294967295.

When a BGP speaker learns a route from a peer, it can pass the route's MED to any IBGP peers, but not to EBGP peers. As a result, the MED has relevance only between neighboring autonomous systems. If router Zermatt in Figure 3-20 advertises 172.16.0.0 with a certain MED to Innsbruck, Innsbruck can advertise the MED to Saalbach. When Innsbruck and Saalbach advertise the route to their EBGP peers in AS 50 and AS 75, however, they cannot include the MED in the route.

The MED is a relatively weak attribute. In the BGP decision process, the weights, LOCAL_PREFs, AS_PATH lengths, and ORIGINs of multiple routes to the same destination are all considered before MED. If all of those variables are equal, however, the route with the lowest MED is chosen .

TIP

It can be a bit confusing to remember that the highest LOCAL_PREF is preferred, but the lowest MED is preferred. Another term for MED is metric, and another term for metric is distance. So remember "highest preference, shortest distance."


You can manipulate the MED with the set metric command under a route map. In Figure 3-20, AS 30 wants AS 100 to send incoming traffic to network 172.16.0.0 via the Saalbach-Moritz link. Traffic to network 172.31.0.0 should be sent across the Innsbruck-Zermatt link. AS 100 is free to send other traffic across either link. Example 3-105 shows the configurations of Zermatt and Moritz.

Example 3-105 Configuring Zermatt and Moritz to Manipulate the MED Attribute
  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 route-map PREF in   neighbor 10.100.83.1 route-map MED out   neighbor 10.100.83.1 filter-list 1 out   neighbor 172.30.255.150 remote-as 30   neighbor 172.30.255.150 ebgp-multihop 2   neighbor 172.30.255.150 update-source Loopback0   neighbor 172.30.255.150 next-hop-self   !   access-list 1 permit 172.31.0.0   access-list 2 permit any   !   route-map MED permit 10   match ip address 1   set metric 100   !   route-map MED permit   match ip address 2   set metric 200  ___________________________________________________________________________________________________________  Moritz   router bgp 30   redistribute isis level-2   neighbor 10.100.65.1 remote-as 100   neighbor 10.100.65.1 ebgp-multihop 2   neighbor 10.100.65.1 update-source Loopback0   neighbor 10.100.65.1 route-map PREF in   neighbor 10.100.65.1 route-map MED out   neighbor 10.100.65.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   neighbor 172.30.255.254 next-hop-self   no auto-summary   !   access-list 1 permit 172.16.0.0   access-list 2 permit any   !   route-map MED permit 10   match ip address 1   set metric 100   !   route-map MED permit 20   match ip address 2   set metric 200  

Each router links the outgoing routes to its EBGP peer to a route map named MED. Sequence 10 of this route map references access list 1 and assigns a MED to matching routes. Zermatt gives the route to 172.31.0.0 a MED of 100, and Moritz gives the route to 172.16.0.0 a MED of 100. Any routes that do not match the access list in sequence 10 are permitted in sequence 20 and are assigned a MED of 200. Example 3-106 shows the results in Innsbruck's BGP table.

Example 3-106 Innsbruck Forwards Packets Destined for 172.16.0.0 to Saalbach (10.100.65.1) and Packets Destined for 172.31.0.0 to Zermatt (172.30.255.254) Based on the Lower Metrics of These Paths
 Innsbruck#  show ip bgp 172.16.0.0  BGP routing table entry for 172.16.0.0/16, version 10  Paths: (2 available, best #2)  Advertised to non peer-group peers:     10.50.250.1 10.75.100.1   30     172.30.255.254 from 172.30.255.254 (172.30.255.254)  Origin incomplete, metric 200, localpref 100, valid, external, ref 2  30     10.100.65.1 from 10.100.65.1 (10.100.65.1)  Origin incomplete, metric 100, localpref 100, valid, internal, best, ref 2  Innsbruck#  show ip bgp 172.31.0.0  BGP routing table entry for 172.31.0.0/16, version 26  Paths: (2 available, best #1)  Advertised to non peer-group peers:     10.50.250.1 10.75.100.1   30     172.30.255.254 from 172.30.255.254 (172.30.255.254)  Origin incomplete, metric 100, localpref 100, valid, external, best, ref 2  30     10.100.65.1 from 10.100.65.1 (10.100.65.1)  Origin incomplete, metric 200, localpref 100, valid, internal, ref 2  Innsbruck# 

Normally, the MEDs of multiple routes to the same destination are compared only when the routes originate from the same AS. After all, the purpose of the MED is to allow an AS to communicate its preferences for incoming traffic when multiple links exist to a neighboring AS. Comparing the preferences of two different autonomous systems usually makes no sense. On occasion, however, exceptions apply.

Figure 3-21 again shows a backdoor link between AS 50 and AS 75. As in the case study "Administrative Distances and Backdoor Routes," the networks 172.17.0.0 and 172.18.0.0 are advertised via RIP over the backdoor link and are used for private communication between the two autonomous systems.

Figure 3-21. The Backdoor Route Between AS 50 and AS 75 Should Also Be Used as a Backup Route

graphics/03fig21.gif

The network backdoor command was used so that AS 75 would not advertise 172.17.0.0 and AS 50 would not advertise 172.18.0.0. But in this example, AS 50 and AS 75 want the routers in AS 100 to use the backdoor link as a secondary route. If Meribel's interface to the NAP fails, for example, Innsbruck and Saalbach should send packets destined for 172.17.0.0 to Lillehammer, to be forwarded across the backdoor to AS 50. This requires Meribel and Lillehammer to advertise networks that do not exist in their own AS and to clearly identify the routes as backup routes. In this situation, because routes to the same destination are being originated by routers in different autonomous systems, comparing MEDs from different autonomous systems can make sense.

Two commands are relevant to the circumstances of Figure 3-21. The first is set metric-type internal. This command, used as part of a route map, sets the MED of a BGP route to the same metric as the IGP route to the same destination. For instance, Meribel's RIP route to 172.17.0.0 is one hop. Lillehammer's RIP route to the same destination, learned across the backdoor link, is two hops. The set metric-type internal command causes those routers' BGP routes advertising the network to inherit those metrics. As a result, the routers in AS 100 prefer Meribel's route, with a MED of 1, over Lillehammer's route to the same destination, with a MED of 2.

The second relevant command is used on the receiving side ”in Figure 3-21, on the routers in AS 100. The command bgp always-compare-med tells a router to compare the MED of multiple routes to the same destination, even if the routes originate in different autonomous systems. Using these two commands, Example 3-107 presents the configurations of Meribel, Lillehammer, and Saalbach.

Example 3-107 The Configurations of Meribel, Lillehammer, and Saalbach in Figure 3-21, Allowing Saalbach to Compare MED Values from Different Autonomous Systems
  Meribel   router bgp 50   network 172.17.0.0   network 172.18.0.0   redistribute rip   neighbor 10.75.100.1 remote-as 75   neighbor 10.75.100.1 ebgp-multihop 2   neighbor 10.75.100.1 update-source Loopback0   neighbor 10.75.100.1 distribute-list 2 in   neighbor 10.100.65.1 remote-as 100   neighbor 10.100.65.1 ebgp-multihop 2   neighbor 10.100.65.1 update-source Loopback0   neighbor 10.100.65.1 route-map MED out   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 MED out   no auto-summary   !   ip as-path access-list 1 permit ^$   !   access-list 2 permit 192.168.75.0   access-list 2 permit 172.18.0.0   !   route-map MED permit 10   match as-path 1    set metric-type internal   ___________________________________________________________________________________________________________  Lillehammer   router bgp 75   network 172.17.0.0   network 172.18.0.0   network 192.168.75.0   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.100.65.1 remote-as 100   neighbor 10.100.65.1 ebgp-multihop 2   neighbor 10.100.65.1 update-source Loopback0   neighbor 10.100.65.1 route-map MED out   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 MED out   !   ip as-path access-list 1 permit ^$   !   access-list 2 permit 10.20.0.0   access-list 2 permit 172.17.0.0   access-list 2 permit 172.29.0.0   access-list 2 permit 192.168.50.0   !   route-map MED permit 10   match as-path 1    set metric-type internal   ________________________________________________________________  Saalbach   router bgp 100   no synchronization    bgp always-compare-med    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.75.100.1 remote-as 75   neighbor 10.75.100.1 ebgp-multihop 2   neighbor 10.75.100.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 10.100.83.1 next-hop-self   neighbor 10.100.83.1 filter-list 1 in   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  

Notice that in Meribel's configuration a network statement is used for 172.17.0.0, even though the network is being redistributed into BGP. This statement is necessary to fix the ORIGIN of the route to IGP, because a network statement is used for the route at Lillehammer. Without it, the ORIGIN of the route from Meribel would be Incomplete. ORIGIN has a higher priority than MED in the BGP decision process, meaning that the Lillehammer route would be preferred at AS 100, even with its higher MED.

Another important detail in Meribel's configuration is the distribute list filtering incoming NLRI from Lillehammer. This filter permits the route to 192.168.75.0 and 172.18.0.0 and denies all other routes. Of particular importance is the fact that the route to 172.17.0.0 advertised by Lillehammer is denied by this filter. Otherwise, the EBGP route, with an administrative distance of 20, would take precedence over Meribel's RIP route, causing a routing loop.

Example 3-108 shows the resulting BGP table at Saalbach. Meribel's route to 172.17.0.0, with a MED of 1, is preferred over Lillehammer's route, with a MED of 2. 172.18.0.0 is directly attached to Lillehammer, so the local metric and the resulting MED from that router are 0. After being advertised via RIP to Meribel, the local metric at that router is 1, which is also reflected in that MED of Meribel's route. If either of the preferred routes fails, the alternate route is chosen, and traffic to that destination uses the backdoor link.

Example 3-108 The MEDs for the Routes to 172.17.0.0 and 172.18.0.0 Match the Internal RIP Metrics of AS 50 and AS 75
 Saalbach#  show ip bgp  BGP table version is 54, local router ID is 10.100.65.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.21.0.0/16     10.50.250.1            0             0 50 ? * i10.30.0.0/16     10.100.83.1          200    100      0 30 ? *>                  172.30.255.150       200             0 30 ? *> 10.50.250.1/32   10.50.250.1            0             0 50 ? *> 10.75.100.1/32   10.50.250.1            0             0 50 ? *> 10.100.83.1/32   10.50.250.1            0             0 50 ? *> 172.16.0.0       172.30.255.150       100             0 30 ?  *> 172.17.0.0       10.50.250.1            1             0 50 i   *                   10.75.100.1            2             0 75 i   *  172.18.0.0       10.50.250.1            1             0 50 i   *>                  10.75.100.1            0             0 75 i  *> 172.29.0.0       10.50.250.1            1             0 50 ? * i172.29.1.0/24    10.100.83.1          200    100      0 30 ? *>                  172.30.255.150       200             0 30 ? *>i172.31.0.0       10.100.83.1          100    100      0 30 ? *                   172.30.255.150       200             0 30 ? *> 192.168.50.0     10.50.250.1            1             0 50 ? *> 192.168.75.0     10.75.100.1            0             0 75 i * i192.168.100.0    10.100.83.1          200    100      0 30 ? *>                  172.30.255.150       200             0 30 ? Saalbach# 

Innsbruck's configuration and BGP table are not shown in this example, but they are similar.

Case Study: Prepending the AS_PATH

The MULTI_EXIT_DISC attribute can influence the incoming traffic from neighboring autonomous systems, but it cannot influence the routing decisions of more-remote autonomous systems.

Figure 3-22 repeats a topology encountered in an earlier case study. Looking at the BGP table of Meribel in Example 3-109, you can see that the router has duplicate, equal-cost paths to the destinations within AS 30. Because all other values are equal, Meribel's BGP decision process has chosen Innsbruck as the next-hop router for all traffic to AS 30 based on Innsbruck's lower router ID. As a result, the Cervinia-Moritz link does not get used at all for traffic from AS 50 to AS 30; available bandwidth is poorly utilized.

Figure 3-22. Dual, Equal-Cost Paths Exist Between AS 50 and AS 30

graphics/03fig22.gif

Example 3-109 Meribel's BGP Table Shows the Dual Paths to the Destinations Within AS 30; Innsbruck Is Chosen as the Best Path for All the Destinations Because Its Router ID (10.100.83.1) Is Lower Than Cervinia's (10.200.60.1)
 Meribel#  show ip bgp  BGP table version is 18, local router ID is 10.50.250.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     0.0.0.0                  0         32768 ? *  10.30.0.0/16     10.200.60.1                            0 200 30 ? *>                  10.100.83.1                            0 100 30 ? *> 10.50.250.1/32   0.0.0.0                  0         32768 ? *> 10.100.65.1/32   0.0.0.0                  0         32768 ? *> 10.100.83.1/32   0.0.0.0                  0         32768 ? *> 10.200.60.1/32   0.0.0.0                  0         32768 ? *  172.16.0.0       10.200.60.1                            0 200 30 ? *>                  10.100.83.1                            0 100 30 ? *> 172.17.0.0       10.20.1.1                1         32768 i *> 172.29.0.0       10.20.1.1                1         32768 ? *  172.29.1.0/24    10.200.60.1                            0 200 30 ? *>                  10.100.83.1                            0 100 30 ? *> 172.30.255.150/32 10.100.83.1                            0 100 30 ? *> 172.30.255.254/32 10.200.60.1                            0 200 30 ? *  172.31.0.0       10.200.60.1                            0 200 30 ? *>                  10.100.83.1                            0 100 30 ? *> 192.168.2.0/30   10.200.60.1                            0 200 30 ? *> 192.168.2.4/30   10.100.83.1                            0 100 30 ? *> 192.168.50.0     10.20.1.1                1         32768 ? *  192.168.100.0    10.200.60.1                            0 200 30 ? *>                  10.100.83.1                            0 100 30 ? Meribel# 

AS 30 cannot influence the routing decisions of AS 50 with MEDs, because the two autonomous systems are not directly connected neighbors. But AS 30 can influence the routing decisions of AS 50 by modifying the AS_PATH of the routes it advertises by using the set as-path prepend command. Suppose AS 30 wants AS 50 to forward all traffic destined for 172.16.0.0 and 172.31.0.0 to Cervinia and wants traffic to 10.30.0.0, 172.29.1.0/24, and 192.168.100.0 forwarded to Innsbruck. Example 3-110 shows the configuration for Zermatt and Moritz.

Example 3-110 Configuring Zermatt and Moritz for AS Path Prepending
  Zermatt   router bgp 30   no synchronization   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 PATH out   neighbor 10.100.83.1 filter-list 1 out   no auto-summary   !   ip as-path access-list 1 permit ^$   !   access-list 3 permit 172.31.0.0   access-list 3 permit 172.16.0.0   !   route-map PATH permit 10   match ip address 3   set as-path prepend 30   !   route-map PATH permit 20  ___________________________________________________________________________________________________________  Moritz   router bgp 30   no synchronization   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   neighbor 10.200.60.1 route-map PATH out   neighbor 10.200.60.1 filter-list 1 out   no auto-summary   !   ip as-path access-list 1 permit ^$   !   access-list 3 permit 192.168.100.0   access-list 3 permit 10.30.0.0   access-list 3 permit 172.29.1.0   !   route-map PATH permit 10   match ip address 3   set as-path prepend 30   !   route-map PATH permit 20  

Each router filters outgoing packets through a route map named PATH. Statement 10 of the route map uses access list 3 to identify certain roues by their NLRI; matching routes have an AS number of 30 added to their AS_PATH. Note that this number is in addition to the AS number 30 normally added to the AS_PATH. Routes that are not matched by access list 3 are permitted by statement 20 of the route map.

Example 3-111 shows the resulting BGP table at Meribel. The prepended routes are now longer than the routes from the preferred path, and the router chooses the routes with the shorter AS_PATHs.

Example 3-111 Meribel's BGP Table Shows the Prepended AS_PATHs from Zermatt and Moritz; the Router Chooses the Paths with the Shorter AS_PATH
 Meribel#  show ip bgp  BGP table version is 70, local router ID is 10.50.250.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     0.0.0.0                  0         32768 ? *  10.30.0.0/16     10.200.60.1                            0 200 30 30 ? *>                  10.100.83.1                            0 100 30 ? *> 10.50.250.1/32   0.0.0.0                  0         32768 ? *> 10.100.65.1/32   0.0.0.0                  0         32768 ? *> 10.100.83.1/32   0.0.0.0                  0         32768 ? *> 10.200.60.1/32   0.0.0.0                  0         32768 ? *> 172.16.0.0       10.200.60.1                            0 200 30 ? *                   10.100.83.1                            0 100 30 30 ? *> 172.17.0.0       10.20.1.1                1         32768 i *> 172.29.0.0       10.20.1.1                1         32768 ? *  172.29.1.0/24    10.200.60.1                            0 200 30 30 ? *>                  10.100.83.1                            0 100 30 ? *> 172.30.255.150/32 10.100.83.1                            0 100 30 ? *> 172.30.255.254/32 10.200.60.1                            0 200 30 ? *> 172.31.0.0       10.200.60.1                            0 200 30 ? *                   10.100.83.1                            0 100 30 30 ? *> 192.168.2.0/30   10.200.60.1                            0 200 30 ? *> 192.168.2.4/30   10.100.83.1                            0 100 30 ? *> 192.168.50.0     10.20.1.1                1         32768 ? *  192.168.100.0    10.200.60.1                            0 200 30 30 ? *>                  10.100.83.1                            0 100 30 ? Meribel# 

You should use AS_PATH prepending with great caution. If you do not fully understand the effects your configuration will have, unexpected or broken routing can result. Suppose, for example, the command set as-path prepend 30 30 is used in Moritz's configuration. This command adds two instances of the AS number 30 to the AS_PATH rather than one. Examining the effects on the route to 10.30.0.0, Cervinia in Figure 3-22 receives the route from Moritz with an AS_PATH of (30,30,30) and a route from Meribel to the same destination with an AS_PATH of (50,100,30). Because the routes have the same AS_PATH length, Cervinia chooses the route with the lowest next-hop address: Meribel's. The original intention was to affect the routing at AS 50 only, but this configuration also has caused AS 200 to choose a longer path to the destination.

It is also important when prepending to always use the AS number of the prepending router's AS. If another AS number is used, and an AS using that number is encountered by the advertised route, that AS will not accept the route.

Case Study: Route Tagging

A route tag field can be thought of as a sort of "pocket" in a routing update for transporting information across a routing domain. The information represented by the tag has no relevance to the routing protocol itself, and the routing protocol does not act on the tag in any way. Tags are useful when a route is redistributed from protocol A into protocol B and then redistributed back into protocol A at some other point. The tag field within the transit routing protocol's updates allows protocol A to send information to its peers on the other side of the transit domain. Usually, this information is inconsistent or meaningless to the transit routing protocol.

RIP-2, EIGRP, Integrated IS-IS, OSPF, and BGP support route tags. RIP-1 and IGRP do not. Chapter 14 of Volume I introduces route tagging and presents examples of its use. This case study obviously concentrates on the use of tags in a BGP environment.

Figure 3-23 depicts an environment in which route tags are useful. AS 1300 provides transit for the inter-AS traffic of several autonomous systems. Each route of the three outlying autonomous systems is advertised via EBGP to one of the three border routers in AS 1300. The route is redistributed into OSPF, redistributed back into BGP at the other two border routers, and then advertised to their EBGP peers.

Figure 3-23. AS 1300 Is a Transit AS for the Other Three Autonomous Systems

graphics/03fig23.gif

NOTE

A configuration such as the one depicted here, with BGP redistributed into an IGP, can find applications in some large enterprise networks. As stated several times throughout this chapter, however, you should never redistribute BGP routes into an IGP in a service provider AS or in an AS in which large numbers of BGP prefixes are being received.


The problem with the topology in Figure 3-23 is that the BGP processes of the three outlying autonomous systems must share their routing information through OSPF, which has no understanding of BGP path attributes. As a result, path information is lost. Example 3-112 shows the BGP table at router Turoa. You can see that all routes appear to be originated by AS 1300. If AS 1400 has an alternate path to AS 1100 or AS 1200, it cannot make an accurate routing decision because of this information loss.

Example 3-112 The AS_PATH Information of the Routes from AS 1100 and AS 1200 Has Not Been Preserved Across the OSPF Domain in AS 1300; as a Result, All Routes Learned from AS 1300 Appear to Have Been Originated by That AS
 Turoa#  show ip bgp  BGP table version is 44, local router ID is 192.168.8.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 *> 192.168.1.0      192.168.10.22            1             0 1300 ? *> 192.168.2.0      192.168.10.22            1             0 1300 ? *> 192.168.3.0      192.168.10.22            1             0 1300 ? *> 192.168.4.0      192.168.10.22            1             0 1300 ? *> 192.168.5.0      192.168.10.22           20             0 1300 ? *> 192.168.6.0      192.168.10.22           20             0 1300 ? *> 192.168.7.0      0.0.0.0                  0         32768 i *> 192.168.8.0      0.0.0.0                  0         32768 i *> 192.168.10.0     192.168.10.22          192             0 1300 ? Turoa# 

BGP can use the route tag field in the OSPF packets to convey AS_PATH information across the OSPF domain. In fact, Cisco's BGP implementation does this automatically. Example 3-113 shows the details of Zao's route to 192.168.1.0 in AS 1200, across the OSPF domain. Notice the tag field, which is marked with a 1200.

Example 3-113 When Router Naeba Redistributed Its EBGP Route to 192.168.1.0 into OSPF, It Wrote the AS_PATH of the Route into the External Route Tag Field of the OSPF AS-External LSA; You Can See the Tag in the Route Entry at Zao, on the Other Side of the OSPF Domain
 Zao#  show ip route 192.168.1.0  Routing entry for 192.168.1.0/24   Known via "ospf 1300", distance 110, metric 1  Tag 1200, type extern 2, forward metric 128  Redistributing via ospf 1300, bgp 1300   Advertised by bgp 1300 match internal external 2   Last update from 192.168.10.18 on Serial1.503, 00:13:33 ago   Routing Descriptor Blocks:   * 192.168.10.18, from 192.168.10.13, 00:13:33 ago, via Serial1.503       Route metric is 1, traffic share count is 1 Zao# 

See Chapter 9, "Open Shortest Path First," of Volume I for more details on the format and use of the OSPF AS-External LSA.

When IGP routes are redistributed into BGP, however, the BGP process does not automatically assume that the IGP's tag field contains AS_PATH information. You must configure the process to recover the AS_PATH information. One way to recover the AS_PATH information from the tags of redistributed routes is with the set as-path tag command. Example 3-114 shows the configuration for Zao using the set as-path tag command.

Example 3-114 Configuring Zao to Recover AS_PATH Information from the Tags of Redistributed Routes
  router ospf 1300   redistribute bgp 1300   network 192.168.10.0 0.0.0.255 area 0   !   router bgp 1300   redistribute ospf 1300 match internal external 2 route-map GET_TAG   neighbor 192.168.10.21 remote-as 1400   !   route-map GET_TAG permit 10   set as-path tag  

The redistribute ospf statement under the BGP configuration references a route map named GET_TAG, which sets the AS_PATH attribute of the redistributed routes to the value in the OSPF tag field. Example 3-115 shows that as a result, Turoa's BGP table now contains accurate AS_PATH information to the routes in AS 1100 and AS 1200.

Example 3-115 Turoa's BGP Table Now Contains Accurate AS_PATH Information
 Turoa#  show ip bgp  BGP table version is 148, local router ID is 192.168.8.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 *> 192.168.1.0      192.168.10.22            1             0 1300 1200 ? *> 192.168.2.0      192.168.10.22            1             0 1300 1200 ? *> 192.168.3.0      192.168.10.22            1             0 1300 1100 ? *> 192.168.4.0      192.168.10.22            1             0 1300 1100 ? *> 192.168.5.0      192.168.10.22           20             0 1300 ? *> 192.168.6.0      192.168.10.22           20             0 1300 ? *> 192.168.7.0      0.0.0.0                  0         32768 i *> 192.168.8.0      0.0.0.0                  0         32768 i *> 192.168.10.0     192.168.10.22          192             0 1300 ? Turoa# 

No configuration is required at Happo or Naeba for Zao to pick up AS_PATH information from the OSPF tag field with the set as-path tag command. However, the only information that is entered into the tag field automatically is the AS_PATH. Notice in Example 3-115 that the routes from AS 1100 and AS 1200 are marked with an ORIGIN of Incomplete. Routers Thredbo and Yangii use the BGP network command to advertise their interior routes with an ORIGIN of IGP, but Happo and Naeba do not enter that information into the OSPF tag. The ORIGIN code that Turoa sees is Incomplete as a result of the route's being redistributed from OSPF into BGP at Zao.

This might or might not be a problem, depending on whether Turoa has alternative routes to AS 1100 and AS 1200, and whether the ORIGIN of the routes might influence the BGP decision process. Cisco offers an alternative configuration, called an automatic tag, which enters not only the AS_PATH information but also the ORIGIN code. The automatic tag is set with the set automatic-tag command, and the route map containing the command is called from the BGP process with the table-map command. Unlike the set as-path tag command, which is configured on routers redistributing routes from an IGP into BGP, the set automatic-tag command is configured on the routers redistributing routes from BGP into an IGP.

All three AS 1300 routers in Figure 3-23 will be configured the same for setting automatic tags. Example 3-116 shows the configuration for Naeba.

Example 3-116 Configuring Naeba to Enter AS_PATH Information and ORIGIN Code
  router ospf 1300   redistribute bgp 1300   network 192.168.0.0 0.0.255.255 area 0   !   router bgp 1300   table-map SET_TAG   redistribute ospf 1300 match internal external 2   neighbor 192.168.10.5 remote-as 1200   !   ip as-path access-list 1 permit .*   !   route-map SET_TAG permit 10   match as-path 1   set automatic-tag  

Example 3-117 shows the resulting BGP table at Turoa. You can see that it looks almost identical to the table in Example 3-115, but the routes from AS 1100 and AS 1200 now correctly reflect an ORIGIN attribute of IGP.

Another use for route tags is to identify certain groups of routes, perhaps for filtering. In Figure 3-23, routers Naeba and Happo might be configured to tag some subset of their EBGP routes before redistributing them into OSPF. Zao, retrieving the routes from the OSPF domain, could then identify the routes by their common tag instead of having to filter by NLRI. Recall from Chapter 2 that the BGP COMMUNITY attribute also is designed to identify routes in a common group. In the topology of Figure 3-23, however, the COMMUNITY attribute cannot be communicated across the OSPF domain. For an example of using tags for this purpose, see "Case Study: Route Tagging," in Chapter 14 of Volume I.

Finally, you can use tagging only when an IGP is redistributed into BGP. When the network command is used, the BGP route is considered locally originated and therefore does not inherit any of the attributes, including tags, of the IGP route.

Example 3-117 Turoa's BGP Table Now Contains Not Only the Correct AS_PATH Information, But Also the Correct ORIGIN
 Turoa#  show ip bgp  BGP table version is 228, local router ID is 192.168.8.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 *> 192.168.1.0      192.168.10.22            1             0 1300 1200 i *> 192.168.2.0      192.168.10.22            1             0 1300 1200 i *> 192.168.3.0      192.168.10.22            1             0 1300 1100 i *> 192.168.4.0      192.168.10.22            1             0 1300 1100 i *> 192.168.5.0      192.168.10.22           20             0 1300 ? *> 192.168.6.0      192.168.10.22           20             0 1300 ? *> 192.168.7.0      0.0.0.0                  0         32768 i *> 192.168.8.0      0.0.0.0                  0         32768 i *> 192.168.10.0     192.168.10.22          192             0 1300 ? Turoa# 

Case Study: Route Dampening

Route dampening, as discussed in Chapter 2, is a process that can assign a penalty to a flapping route. If the route accumulates enough penalties, the route is suppressed ”that is, it is not advertised ”for a certain period of time. By default, a route is assigned a penalty value of 1000 for each flap. If the value of the route's accumulated penalties exceeds 2000, the route is suppressed until the penalty value drops below 750. These upper and lower thresholds are the suppress limit and the reuse limit. The accumulated penalty is reduced every 5 seconds, at a rate such that the penalty is reduced by half every 15 minutes. You can see that this rate, known as the half-life, is exponential. If the penalty is 3000, it is reduced by 1500 over 15 minutes; if the penalty is 300, it is reduced by 150 over 15 minutes. There is also a maximum time the route can be suppressed, known as the maximum suppress limit. By default, this limit is four times the half-life, or 60 minutes.

Route dampening is enabled under the BGP process configuration with the command bgp dampening. If you want to change the default values, the syntax is bgp dampening half-life reuse suppress max-suppress.

Figure 3-24 shows a topology in which one router, Colorado, is homed to five other autonomous systems. If the routes advertised by any of the remote autonomous systems flaps, Colorado must advertise the change to all other EBGP peers. Although this may not be much of a burden on the sample topology, imagine the effects if Colorado has 150 EBGP peers rather than the five shown. A regularly flapping route could cause a heavy processing burden on that hub router.

Figure 3-24. If a Route in Any of the "Spoke" Autonomous Systems Flaps, the "Hub" Router, Colorado, Must Send an Update to All of Its EBGP Peers Advertising the Change

graphics/03fig24.gif

Example 3-118 provides the BGP configuration for Colorado.

Example 3-118 Configuring Colorado to Send Updates to EBGP Peers to Advertise Changes When a Route Flaps
  router bgp 100    bgp dampening    network 10.1.11.0 mask 255.255.255.0   network 10.1.12.0 mask 255.255.255.0   neighbor 10.1.255.2 remote-as 200   neighbor 10.1.255.2 ebgp-multihop 2   neighbor 10.1.255.2 update-source Loopback2   neighbor 10.1.255.3 remote-as 300   neighbor 10.1.255.3 ebgp-multihop 2   neighbor 10.1.255.3 update-source Loopback2   neighbor 10.1.255.4 remote-as 400   neighbor 10.1.255.4 ebgp-multihop 2   neighbor 10.1.255.4 update-source Loopback2   neighbor 10.1.255.5 remote-as 500   neighbor 10.1.255.5 ebgp-multihop 2   neighbor 10.1.255.5 update-source Loopback2   neighbor 10.1.255.6 remote-as 600   neighbor 10.1.255.6 ebgp-multihop 2   neighbor 10.1.255.6 update-source Loopback2   no auto-summary  

Example 3-119 shows Colorado's BGP table. Notice that 10.1.4.0/24 is marked with a d, indicating that it has been dampened, or suppressed. 10.1.7.0/24 has been marked with an h. This means that there is a history of flapping; that is, although the route has not accumulated a large-enough penalty to be suppressed, it does have a penalty.

Example 3-119 Two Routes, 10.1.4.0/24 and 10.1.7.0/24, Have Accumulated Penalties; the First Has Accumulated More than 2000 and Has Been Dampened
 Colorado#  show ip bg  p BGP table version is 756, local router ID is 10.1.255.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.1.1.0/24      10.1.255.2             0             0 200 i *> 10.1.2.0/24      10.1.255.2             0             0 200 i *> 10.1.3.0/24      10.1.255.3             0             0 300 i  *d 10.1.4.0/24      10.1.255.3             0             0 300 i  *> 10.1.5.0/24      10.1.255.4             0             0 400 i *> 10.1.6.0/24      10.1.255.4             0             0 400 i  h 10.1.7.0/24      10.1.255.5             0             0 500 i  *> 10.1.8.0/24      10.1.255.5             0             0 500 i *> 10.1.9.0/24      10.1.255.6             0             0 600 i *> 10.1.10.0/24     10.1.255.6             0             0 600 i *> 10.1.11.0/24     0.0.0.0                0         32768 i *> 10.1.12.0/24     0.0.0.0                0         32768 i 

The unstable routes are readily apparent in the BGP table of Example 3-119 because there are not very many entries. What about a table with thousands of BGP entries, however? Finding unstable routes by looking for a d or h could be impractical. Two commands make finding these routes easier: show ip bgp flap-statistics and show ip bgp dampened-paths . As the names imply, the first command shows all routes that have flapped and how many times a route has flapped. The second command shows only those routes that have been suppressed. Example 3-120 shows these commands used at Colorado; notice that for suppressed routes, both outputs indicate when the route is expected to be advertised again. This time is contingent on the route's not being assigned further penalties. Note that flap statistics are recorded only if BGP dampening is configured. You cannot use the command show ip bgp flap-statistics to check for unstable routes on a router that is not running the dampening process.

Example 3-120 You Can Display Only Those Routes in the BGP Table That Have Flapped, or Only Those Routes That Have Been Suppressed
  Colorado    #show ip bgp flap-statistics   BGP table version is 756, local router ID is 10.1.255.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          From            Flaps Duration Reuse    Path *d 10.1.4.0/24      10.1.255.3      3     00:15:52 00:19:40 300  h 10.1.7.0/24      10.1.255.5      2     00:20:49          500  Colorado#    show ip bgp dampened-paths   BGP table version is 757, local router ID is 10.1.255.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          From             Reuse   Path *d 10.1.4.0/24      10.1.255.3       00:19:2 300 i 

Looking at the details of a route shows you not only the statistics displayed in Example 3-120, but also the accumulated penalties. In Example 3-121, you can see that the route to 10.1.4.0/24 has a penalty of 1815; the half-life decay process has reduced the penalty below the suppress threshold of 2000, but not yet to the reuse threshold of 750. That second threshold is expected to be reached in 19 minutes and 10 seconds.

Example 3-121 If an Unstable Route Is Specified with the show ip bgp Command, the Route's Penalty Value Displays
 Colorado#  show ip bgp 10.1.4.0  BGP routing table entry for 10.1.4.0/24, version 755 Paths: (1 available, no best path, advertised over EBGP)  300, (suppressed due to dampening)  10.1.255.3 from 10.1.255.3       Origin IGP, metric 0, localpref 100, valid, external  Dampinfo: penalty 1815, flapped 3 times in 00:16:28, reuse in 00:19:10  Colorado# 

In some cases, you might want to put a suppressed route back into service before the reuse limit is reached. The administrator in AS 300 might have assured you that the cause of the flaps of subnet 10.1.4.0/24 has been identified and eliminated, for instance, and now he wants traffic to resume. Two commands are available: clear ip bgp flap-statistics and clear ip bgp dampening. These two commands have the same effect of clearing all penalties for a route or for all routes (depending on whether a route is specified with the command), but the second command clears only those routes that have been suppressed. The clear ip bgp flap-statistics also enables you to identify a group of routes by their AS path, either by specifying a filter list or by using a regular expression. For example, the command clear ip bgp flap-statistics regexp _30_ clears the flap statistics for all routes that have the AS number 30 in their AS_PATH attribute. This command proves useful if AS 30 is a transit AS, and a bad link has caused all destinations reachable through that AS to accumulate penalties.



Routing TCP[s]IP (Vol. 22001)
Routing TCP[s]IP (Vol. 22001)
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 182

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net