Load-Balancing 9.9

Load-Balancing

Problem

You want to load-balance traffic over two or more links, between two eBGP or iBGP neighbors.

Solution

Although BGP goes to great lengths to ensure that there is only one path for each route by default, Cisco routers also allow you to configure load-balancing for equal cost paths:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#router bgp 65500
Router1(config-router)#maximum-paths 4
Router1(config-router)#exit
Router1(config)#end
Router1#

Discussion

This option is useful when there are multiple paths to a particular adjacent AS. As you can see from the following BGP route table, there are three different options for these routes:

Router1#show ip bgp
BGP table version is 12, local router ID is 172.18.5.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* 10.0.0.0 192.168.1.5 0 65510 65520 i
*> 192.168.2.5 0 0 65520 i
* 192.168.3.5 0 65520 i
* 172.25.0.0 192.168.1.5 0 65510 65520 i
*> 192.168.2.5 0 0 65520 i
* 192.168.3.5 0 65520 i
Router1#

But without the maximum-paths command enabled, there is only one route for each of these destinations in the IP routing table:

Router1#show ip route bgp
172.25.0.0/16 is variably subnetted, 2 subnets, 2 masks
B 172.25.0.0/16 [20/0] via 192.168.2.5, 00:06:58
B 10.0.0.0/8 [20/0] via 192.168.2.5, 00:06:58

We then increase the maximum path value to 4 from the default of 1:

Router1(config)#router bgp 65500
Router1(config-router)#maximum-paths 4

The router now installs two routes in the IP routing table for each prefix:

Router1#show ip route bgp
172.25.0.0/16 is variably subnetted, 2 subnets, 2 masks
B 172.25.0.0/16 [20/0] via 192.168.2.5, 00:00:02
[20/0] via 192.168.3.5, 00:00:02
B 10.0.0.0/8 [20/0] via 192.168.2.5, 00:00:02
[20/0] via 192.168.3.5, 00:00:02

Note the router did not install all three of the available BGP routes. This is because the other routes, the ones that use 192.168.1.5 for the next-hop router, both have a longer AS Path. Similarly, if one of these routes had a smaller Local Preference value, it also would not be used. As we mentioned when discussing the BGP route selection rules in the introduction to this chapter, the router uses BGP Multipath feature only for routes that are equivalent after all tests up to and including the MED test.

This feature only works for routes that leave the AS. If you have multiple paths to a remote AS, but they depart through different routers, then they will not load balance.

Also note that for eBGP connections, this only balances the outbound traffic load. Incoming packets are subject to whatever routing policies your neighboring AS uses.

Adjusting Local Preference Values

Adjusting Local Preference Values

Problem

You want to change the Local Preference values to control which routes you use.

Solution

There are two ways to adjust Local Preference values on a router. The first method changes the Local Preference values for every route distributed into iBGP from this router:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#router bgp 65500
Router1(config-router)#bgp default local-preference 200
Router1(config-router)#exit
Router1(config)#end
Router1#

The second method uses route maps to give finer granularity control over which routes get what Local Preference values:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip prefix-list LOW_LP_PREFIXES seq 10 permit 172.22.0.0/16
Router1(config)#route-map LOCALPREF permit 10
Router1(config-route-map)#match ip address prefix-list LOW_LP_PREFIXES
Router1(config-route-map)#set local-preference 50
Router1(config-route-map)#exit
Router1(config)#route-map LOCALPREF permit 20
Router1(config-route-map)#exit
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 route-map LOCALPREF in
Router1(config-router)#exit
Router1(config)#end
Router1#

Discussion

When BGP routers within an AS exchange information about a particular route using iBGP, they include the Local Preference value. All of the routers in the AS are then able to use this value to decide how to weight this route versus other BGP routes to the same destination. BGP consults the Local Preference value early in the route selection process, before even the AS Path attribute. So this provides an extremely useful and flexible way of forcing particular routes to use particular paths. Routers do not include Local Preference information when exchanging routes through eBGP connections.

A common example would be if you had two connections to an external network and you wanted to ensure that one was the primary path and the other was a backup. Suppose further that one of the routers in the AS handles the primary path and a second router handles the secondary path. The first example shows how to globally increase the Local Preference values of all routes received by one of these routers:

Router1(config)#router bgp 65500
Router1(config-router)#bgp default local-preference 200

Now all of the external routes that this router handles will have a Local Preference value of 200. If you can reach a particular prefix through more than one path, the other routers in this AS will prefer to use the one with the highest Local Preference value. The default Local Preference is 100.

To see how this works in practice, we will once again use the network shown in Figure 9-2. The following output shows two paths to the network 10.0.0.0/8. This router learned the first route through iBGP from another router. You can see from the LocPrf column that this route has the default Local Preference value of 100:

Router2#show ip bgp
BGP table version is 4, local router ID is 172.18.5.3
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
* i10.0.0.0 172.18.5.2 100 0 65510 65531 i
*> 192.168.2.5 0 65520 65531 i
Router2#

This router learned the second route through eBGP, so it doesn't have a Local Preference value. The router treats any missing Local Preference values as if they had the default value of 100. Note that although BGP has a route selection rule that prefers eBGP routes to iBGP routes, this rule is consulted after the Local Preference is, but for now the Local Preference values are equal. So, all other things being equal, this router prefers to use the more direct route that it learned itself, which is indicated by the ">" character at the beginning of the line.

Now we will change the default Local Preference value on the other router to 200, using the bgp default local-preference command as shown above:

Router2#show ip bgp
BGP table version is 4, local router ID is 172.18.5.3
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
*>i10.0.0.0 172.18.5.2 200 0 65510 65531 i
* 192.168.2.5 0 65520 65531 i
Router2#

As you can see, the Local Preference value has changed to 200 for the iBGP route. So this router now prefers the iBGP route. You can see more detail by specifying the prefix with this command:

Router2#show ip bgp 10.0.0.0/8
BGP routing table entry for 10.0.0.0/8, version 4
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.2.5
65510 65531
172.18.5.2 from 172.18.5.2 (172.18.5.2)
Origin IGP, localpref 200, valid, internal, best
65520 65531
192.168.2.5 from 192.168.2.5 (172.21.1.1)
Origin IGP, localpref 100, valid, external
Router2#

This clearly shows that the router interprets the missing Local Preference value as 100 on this router. If we now change the default value on this router to 75, you can see that it will use this new value instead when the value is missing:

Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#router bgp 65500
Router2(config-router)#bgp default local-preference 75
Router2(config-router)#end
Router2#clear ip bgp *

Router2#show ip bgp 10.0.0.0/8
BGP routing table entry for 10.0.0.0/8, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.2.5
65520 65531
192.168.2.5 from 192.168.2.5 (172.21.1.1)
Origin IGP, localpref 75, valid, external
65510 65531
172.18.5.2 from 172.18.5.2 (172.18.5.2)
Origin IGP, localpref 200, valid, internal, best
Router2#

Notice that we had to clear the BGP peers and wait until they reconnected for this change to take effect. Also notice that, by chance, the router displays the routes in the opposite order. There is no particular significance to this ordering. The route that entered the AS via eBGP on this router (Router2) now has a Local Preference value of 75, while the route that entered via Router1 has a Local Preference of 200, which we configured earlier in this recipe.

You can also use route maps to define different Local Preference values for different individual routes. This gives you a finer granularity, even allowing you to manually balance the load between these links by forcing some routes through one path and the rest through the other path.

The second example shows how to use a route map to adjust Local Preference values:

Router1(config)#ip prefix-list LOW_LP_PREFIXES seq 10 permit 172.22.0.0/16
Router1(config)#route-map LOCALPREF permit 10
Router1(config-route-map)#match ip address prefix-list LOW_LP_PREFIXES
Router1(config-route-map)#set local-preference 50
Router1(config-route-map)#exit
Router1(config)#route-map LOCALPREF permit 20
Router1(config-route-map)#exit

Here we have defined a prefix list that just matches the prefix 172.22.0.0/16. Whenever the route map sees a route that matches this prefix list, it sets the Local Preference value for this route to 50.

We have included an empty clause at the end of the route map, which simply passes all other routes unchanged. Every route map ends with an implicit deny all. So if we didn't include this, the router would simply drop any prefixes that didn't match the first clause.

Then we invoke this rule by using the standard route-map option to the neighbor command:

Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 route-map LOCALPREF in

Notice that we are applying this route map to all incoming routes received from this specific eBGP peer. Now you can see that this particular route has a local preference value of 50:

Router1#show ip bgp 172.22.0.0/16
BGP routing table entry for 172.22.0.0/16, version 5
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x208
Advertised to non peer-group peers:
192.168.1.5
65510 65531
192.168.1.5 from 192.168.1.5 (172.25.26.55)
Origin IGP, localpref 50, valid, external
65520 65531
172.18.5.3 from 172.18.5.3 (172.18.5.3)
Origin IGP, localpref 75, valid, internal, best
Router1#

Note also that the other iBGP router is still using the Local Preference value of 75 that we configured a moment ago.

Because this method used a route map, you can easily construct rules that would change the Local Preference values based on a large variety of different parameters. For example, you could match based on the AS Path, which is a technique that we will discuss in more detail in Recipe 9.10. You could do this to give a higher or lower Local Preference value, based on whether or not the route passes through a particular remote AS:

Router1(config)#ip as-path access-list 17 permit _65531_
Router1(config)#route-map LOCALPREF permit 25
Router1(config-route-map)#match as-path 17
Router1(config-route-map)#set local-preference 75
Router1(config-route-map)#exit

See Also

Restricting Networks Advertised to a BGP Peer

Restricting Networks Advertised to a BGP Peer

Problem

You want to restrict which routes your router advertises to another AS.

Solution

There are three ways to filter routes in BGP. The first one uses extended access lists and route maps, as follows:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 105 deny ip host 172.25.0.0 host 255.255.0.0
Router1(config)#access-list 105 permit ip any any
Router1(config)#route-map ACL-RT-FILTER permit 10
Router1(config-route-map)#match ip address 105
Router1(config-route-map)#exit
Router1(config)#route-map ACL-RT-FILTER deny 20
Router1(config-route-map)#exit
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 route-map ACL-RT-FILTER in
Router1(config-router)#exit
Router1(config)#end
Router1#

The second method uses a distribute-list:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 106 deny ip host 172.25.0.0 host 255.255.0.0
Router1(config)#access-list 106 permit ip any any
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 distribute-list 106 in
Router1(config-router)#exit
Router1(config)#end
Router1#

But the most common way to filter routes in BGP is to use prefix lists. The following example has a similar effect the preceding ones:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip prefix-list PREFIX-FILTER seq 10 deny 172.25.0.0/16
Router1(config)#ip prefix-list PREFIX-FILTER seq 20 permit 0.0.0.0/0 le 32
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 prefix-list PREFIX-FILTER in
Router1(config-router)#exit
Router1(config)#end
Router1#

Discussion

In all of these examples, the router will suppress the route 172.25.0.0/16 from its BGP route table if it is received from the eBGP peer, 192.168.1.5. The first example uses route maps, the second one uses a distribute list, and the third uses prefix lists. Examples of route maps and access lists appear throughout this book, so they should already be somewhat familiar to the reader. You can use them for a variety of different applications, such as adjusting route tags, Local Preference, and BGP Weight values. Here we just use the route map to look at the incoming routes from a peer device and reject certain routes.

The access list in the first example uses a "deny" clause to suppress the unwanted route, and ends with a "permit" command to allow all other routes to pass normally:

Router1(config)#access-list 105 deny ip host 172.25.0.0 host 255.255.0.0
Router1(config)#access-list 105 permit ip any any

Then the route map uses this access list to define which routes are permitted to pass:

Router1(config)#route-map ACL-RT-FILTER permit 10
Router1(config-route-map)#match ip address 105

Then we have added an explicit deny all clause to the route map that simply rejects anything that the first clause hasn't matched:

Router1(config-route-map)#route-map ACL-RT-FILTER deny 20
Router1(config-route-map)#exit

Note that every route map ends with an implicit deny all clause, so this was not strictly necessary. But it does make our intentions more clear to the next person who reads this router configuration.

For the distribute list example, we have created a normal access list that specifies the routes that are to be either included or excluded from the distribution. This is almost identical to the route map technique that we discussed for RIP and EIGRP in Chapters 6 and 7, respectively.

Note also the rather odd construction of the extended access lists in both the route map and the distribute list examples. As we discuss in Chapter 19, the first address and wildcard pair usually refers to the source, and the second set refers to the destination. But in this case, we are actually trying to match specific route prefixes, and not source and destination addresses, so the meanings are somewhat different. When filtering routes with extended ACLs, the first address defines the prefix, while the second part of the ACL defines the length of the prefix. This particular ACL matches the prefix 172.25.0.0/16:

Router1(config)#access-list 105 permit ip host 172.25.0.0 host 255.255.0.0

If we had wanted to match the prefix 172.25.0.0/24 instead, we could have used an ACL that looks like this:

Router1(config)#access-list 105 permit ip host 172.25.0.0 host 255.255.255.0

Note that you can also use standard ACLs for route filtering, but the results can be a little strange. Suppose we had used this ACL instead of the one we discussed above:

Router1(config)#access-list 5 permit 172.25.0.0

This will match 172.25.0.0/16. But it doesn't specify the length of the prefix. So it will also match, for example, 172.25.0.0/24, if it exists. But it doesn't include any of the other subnets of 172.25.0.0/16, such as 172.25.1.0/24. We don't recommend using standard ACLs for route filtering because of this strange behavior.

Because it is so easy to get confused when using ACLs for matching prefixes, most people now prefer to use prefix lists instead.

Prefix lists provide another way of doing the same kind of filtering. But it is often considerably easier to create useful filters with prefix lists because they were designed specifically for this purpose. Look at the prefix list in the example:

Router1(config)#ip prefix-list PREFIX-FILTER seq 10 deny 172.25.0.0/16
Router1(config)#ip prefix-list PREFIX-FILTER seq 20 permit 0.0.0.0/0 le 32

The first line of this list rejects the prefix 172.25.0.0/16. The second line explicitly allows all other prefixes. Notice that there is a sequence number in each line, specified by the argument of the seq keyword. This provides a convenient way of either inserting or removing new lines in the middle of a prefix list, as well as at the beginning or the end.

We suggest that you space these numbers in steps of 10, as we have done here, so that you can easily add lines. If you use a smaller step size between sequence numbers, you might find that there isn't enough room to add new rules. When this happens, you will have to delete the entire set of rules and re-enter the commands with new sequence numbers.

Prefix lists show their real power when you want to deal with subnets. For example, suppose what you actually wanted to do was reject all of the subnets of 172.25.0.0/16, while allowing a single summary route for the entire network. You could do this with the following prefix list:

Router1(config)#ip prefix-list PRE-RTFILTER seq 10 deny 172.25.0.0/16 ge 17
Router1(config)#ip prefix-list PRE-RTFILTER seq 20 permit 0.0.0.0/0 le 32

The first line rejects any subnets of 172.25.0.0/16 that have a prefix length of 17 bits or longer. So this would include, for example, 172.25.15.8/30, 172.25.100.0/24, and 172.25.252.0/22. But this rule does not suppress the summary route, 172.25.0.0/16, itself because it has a prefix length of only 16 bits. The rule only rejects prefixes that are 17 or more bits long.

This also helps to clarify the meaning of the second line of the prefix list. This line looks at any subnets of 0.0.0.0/0, which is the entire IPv4 address range, and matches anything with a prefix length of 32 bits or less, which is everything.

You can also combine the ge and le keywords to create useful lists. For a slightly artificial example, if you wanted to permit all routes with prefixes of 8 to 16 bits, but nothing longer and nothing shorter, you could use the following single line prefix list:

Router1(config)#ip prefix-list CLASS-A-B permit 0.0.0.0/0 ge 8 le 16

This also shows that you can match on prefix length independently of the actual network number. Notice also that we have omitted the sequence number in this example. By default, the router will rewrite this command and store it with a default sequence number of 5 as follows:

ip prefix-list CLASS-A-B seq 5 permit 0.0.0.0/0 ge 8 le 16

If we were to then add another line to this list, the router would automatically give it sequence number 10, always incrementing in steps of 5. But we recommend using explicit sequence numbers to ensure that things are in the order you expect.

Here is a similar example that selects only the subnets of 172.25.0.0/16 that are between 19 and 24 bits long:

Router1(config)#ip prefix-list BIG-SUBNETS permit 172.25.0.0/16 ge 19 le 24

Once you have created a prefix list, you need to apply it to a neighbor statement by using the prefix-list keyword as follows:

Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 prefix-list PREFIX-FILTER in

You have to define the peer with a neighbor remote-as command before you can apply any special options like prefix lists to it. Otherwise, the router will simply reject the command.

Notice the keyword in at the end of the neighbor command. As with route maps, you can assign a prefix list either inbound or outbound by using the keywords in or out, respectively, at the end of the line.

See Also

Connecting to Two ISPs with Redundant Routers

Connecting to Two ISPs with Redundant Routers

Problem

You want to connect your network to two different ISPs using two routers to eliminate any single points of failure.

Solution

In this example, we have two routers in our AS, which has ASN 65500. The first router has a link to the first ISP, whose ASN is 65510:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface Serial0
Router1(config-if)#description connection to ISP #1, ASN 65510
Router1(config-if)#ip address 192.168.1.6 255.255.255.252
Router1(config-if)#exit
Router1(config)#interface Ethernet0
Router1(config-if)#description connection to internal network, ASN 65500
Router1(config-if)#ip address 172.18.5.2 255.255.255.0
Router1(config-if)#exit
Router1(config)#ip as-path access-list 15 permit ^$
Router1(config)#router bgp 65500
Router1(config-router)#network 172.18.5.0 mask 255.255.255.0
Router1(config-router)#neighbor 172.18.5.3 remote-as 65500
Router1(config-router)#neighbor 172.18.5.3 next-hop-self
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 filter-list 15 out
Router1(config-router)#no synchronization
Router1(config-router)#exit
Router1(config)#end
Router1#

Then the second router connects to the second ISP, which uses ASN 65520. And because these two routers are both members of the same AS, they also must have an iBGP connection:

Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#interface Serial1
Router2(config-if)#description connection to ISP #2, ASN 65520
Router2(config-if)#ip address 192.168.2.6 255.255.255.252
Router2(config-if)#exit
Router2(config)#interface Ethernet0
Router2(config-if)#description connection to internal network, ASN 65500
Router2(config-if)#ip address 172.18.5.3 255.255.255.0
Router2(config-if)#exit
Router2(config)#ip as-path access-list 15 permit ^$
Router2(config)#router bgp 65500
Router2(config-router)#network 172.18.5.0 mask 255.255.255.0
Router2(config-router)#neighbor 192.168.2.5 remote-as 65520
Router2(config-router)#neighbor 192.168.2.5 filter-list 15 out
Router2(config-router)#neighbor 172.18.5.2 remote-as 65500
Router2(config-router)#neighbor 172.18.5.2 next-hop-self
Router2(config-router)#no synchronization
Router2(config-router)#exit
Router2(config)#end
Router2#

Discussion

This recipe is similar to Recipe 9.4, but here we have split the functions across two routers to ensure that you can sustain a link failure or a router failure without losing your Internet connection. Figure 9-2 shows the new network topology.

Figure 9-2. Using two ISPs

The main difference is that we have had to configure an eBGP link from each router to its ISP, as well as an iBGP link between the two routers. Note that we have included the same AS Path filter on both routers to ensure that our network doesn't allow transit routing from one ISP to the other.

However, just as in the single router example, you have to decide how you want to deal with the problem of the excessive number of routes that you will receive from both of these ISPs.

Notice we have included the next-hop-self option for the iBGP peers on both routers:

Router1(config)#router bgp 65500
Router1(config-router)#neighbor 172.18.5.3 remote-as 65500
Router1(config-router)#neighbor 172.18.5.3 next-hop-self

Without this option, the next hop IP address for prefixes learned through Router1 will be the ISP connected to Router1. But even in this simple network, Router2 will not have a route to this next hop address. We could also get around this problem by including static routes on both routers. We discuss the next-hop-self option in more detail in Recipe 9.3.

In this example, we only have two routers inside our AS. You could add more, using exactly the same configuration commands that we used here. However, you need to remember to create a full mesh of iBGP peer relationships between all of these routers. Every BGP router must have a neighbor statement connecting to every other BGP router in the same AS.

See Also

Connecting to Two ISPs

Connecting to Two ISPs

Problem

You want to set up BGP to support two redundant Internet connections.

Solution

The following configuration shows how to make the basic BGP connections, but it has serious problems that we will show how to fix in other recipes in this chapter:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface Serial0
Router1(config-if)#description connection to ISP #1, ASN 65510
Router1(config-if)#ip address 192.168.1.6 255.255.255.252
Router1(config-if)#exit
Router1(config)#interface Serial1
Router1(config-if)#description connection to ISP #2, ASN 65520
Router1(config-if)#ip address 192.168.2.6 255.255.255.252
Router1(config-if)#exit
Router1(config)#interface Ethernet0
Router1(config-if)#description connection to internal network, ASN 65500
Router1(config-if)#ip address 172.18.5.2 255.255.255.0
Router1(config-if)#exit
Router1(config)#router bgp 65500
Router1(config-router)#network 172.18.5.0 mask 255.255.255.0
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.2.5 remote-as 65520
Router1(config-router)#no synchronization
Router1(config-router)#exit
Router1(config)#end
Router1#

We do not recommend using this configuration as printed for a real Internet connection because it leaves out several key components. A more complete example is shown in Recipe 9.19.


Discussion

Perhaps the most common BGP application involves connecting a single router to two different ISPs to share information about a single /24 IP address range. A setup like this is the simplest way of building a redundant Internet connection. You can improve this redundancy by using two routers, one for each ISP connection, as shown in Recipe 9.5. Figure 9-1 shows the connections used in this recipe.

Figure 9-1. Using two ISPs

This example shows the configuration for the router at the customer site. The customer network uses ASN 65500, while the two ISPs use 65510 and 65520, respectively. Both of these connections are made through serial connections.

This configuration is a simple extension of the one shown in Recipe 9.1. The main difference is that we have set up two different peers, both in different ASs. This router is configured to distribute routing information for its 172.18.5.0/24 segment with both ISPs, and to receive their routing tables.

There are two critical problems with this simple configuration. First, the full Internet routing table is extremely large and consumes a vast amount of memory, so we will probably want to do some filtering. The second problem is that this configuration allows your network to act as a transit path between the two ISPs, which you probably don't want in practice.

The full Internet routing table has roughly 187,000 prefixes, a number that grows over time. Each BGP route entry consumes somewhere between 100 and 200 bytes of memory on the router, and you wouldn't use BGP unless there were at least two ISPs, each of which will likely supply a similar sized routing table, doubling the memory requirement. Then, if the router puts all of these prefixes into its main routing table, as well as the CEF table, you can wind up consuming as much as 1KB of router memory per route prefix. So we don't recommend using a router with less than 100 MB of memory when connecting to the Internet without significant filtering. In fact, Internet backbone routers frequently have hundreds of megabytes of memory.

Here is a typical routing summary taken from a BGP route server:

route-server>show ip route summary
IP routing table name is Default-IP-Routing-Table(0)
Route Source Networks Subnets Overhead Memory (bytes)
connected 0 3 272 480
static 2 9 704 1760
ospf 2 0 2 128 320
Intra-area: 2 Inter-area: 0 External-1: 0 External-2: 0
NSSA External-1: 0 NSSA External-2: 0
bgp 65000 115207 70435 11881088 29713940
External: 185642 Internal: 0 Local: 0
internal 1808 2133440
Total 117017 70449 11882192 31849940
route-server>

As you can see here, this router's routing table consumes most of the over 31 MB of system memory. The same device uses roughly 29 MB of memory just for its BGP table, as you can see from the following output:

route-server>show ip bgp summary
BGP router identifier 10.1.2.5, local AS number 65000
BGP table version is 283729, main routing table version 283729
185761 network entries using 18761861 bytes of memory
3529036 path entries using 169393728 bytes of memory
44183 BGP path attribute entries using 2474248 bytes of memory
40017 BGP AS-PATH entries using 1041908 bytes of memory
4 BGP community entries using 96 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 191671841 total bytes of memory
Dampening enabled. 1637 history paths, 559 dampened paths
185644 received paths for inbound soft reconfiguration
BGP activity 186953/1192 prefixes, 3559638/30597 paths, scan interval 60 secs



route-server>

This represents a 45 percent increase in memory requirements since we wrote the first edition of this book, just a few years ago!

We will discuss BGP route servers in more detail in Recipe 9.19.

Fixing the transit problem is somewhat easier than the route filtering that is necessary to reduce the size of the Internet route tables. To prevent the external networks from using your network for transit, you simply have to ensure that you never pass BGP routing information that you learn from one ISP over to the other ISP. This way neither ISP will know that it can reach the other through your network, so they won't send their traffic this way.

The easiest way to accomplish this is to put a filter on the AS Path. In the following example, we will apply the same filter to both BGP peers. This filter will force our router to advertise only local routes. Any route that already has an entry in its AS Path must have come from somewhere else, so we prevent the router from forwarding these routes. The router will add its own ASN to the AS Path only after doing this filter processing, so the local routes will still be sent out:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip as-path access-list 15 permit ^$
Router1(config)#router bgp 65500
Router1(config-router)#network 172.18.5.0 mask 255.255.255.0
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 filter-list 15 out
Router1(config-router)#neighbor 192.168.2.5 remote-as 65520
Router1(config-router)#neighbor 192.168.2.5 filter-list 15 out
Router1(config-router)#exit
Router1(config)#end
Router1#

Please refer to Recipe 9.10 for more information about how to use AS filters.

Before you can solve the problem of the large size of the Internet routing tables, you have to make some decisions about how you want your Internet connections to work. Specifically, you might want one of these ISPs to be the primary and the other the backup for all traffic. Alternatively, you might want to just use the first ISP to handle traffic for its directly connected customers, while the second ISP handles everything else. Or you could opt to have load sharing between the two ISPs. These options are discussed in Recipes 9.7, 9.8, and 9.19.

You should also think about whether you want to control which path inbound traffic uses to reach you. If one of your ISP links has a large usage charge, you might prefer to force all of the inbound traffic through the other link. This can be slightly tricky because you don't directly control the ISP routers. But you can control how your routing information looks to the ISP. Techniques for doing this are discussed in Recipes 9.13 and 9.19.

See Also