You want to set up BGP to support two redundant Internet connections.
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 65501 Router1(config-if)#ip address 172.18.5.2 255.255.255.0 Router1(config-if)#exit Router1(config)#router bgp 65501 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)#end Router1#
|
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.
This example shows the configuration for the router at the customer site. The customer network uses ASN 65501, 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 ASes. 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.
The full Internet routing table has well over 100,000 prefixes. 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 ISP 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 in 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 100MB 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.x>show ip route summary Route Source Networks Subnets Overhead Memory (bytes) connected 0 23 56 3680 static 1 4 280 2840 bgp xxx 87075 37990 7003640 20206240 External: 0 Internal: 125065 Local: 0 internal 2078 2452040 Total 89154 38017 7003976 22664800 route-server.x>
As you can see here, this router's routing table consumes most of the over 22MB of system memory. The same device uses roughly 20MB of memory just for its BGP table, as you can see from the following output:
route-server.x>show ip bgp summary
BGP router identifier xxx.xxx.xxx.xxx, local AS number xxx
BGP table version is 205557022, main routing table version 205557022
126231 network entries and 252452 paths using 20827755 bytes of memory
40380 BGP path attribute entries using 2099760 bytes of memory
173 BGP rrinfo entries using 4824 bytes of memory
24797 BGP AS-PATH entries using 606020 bytes of memory
336 BGP community entries using 16266 bytes of memory
Dampening enabled. 0 history paths, 0 dampened paths
BGP activity 2543115/2416883 prefixes, 11282422/11029970 paths
<information deleted for brevity>
route-server.x>
We discuss BGP route servers in more detail in Recipe 9.17.
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 65501 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)#end Router1#
Please refer to Recipe 9.10 for more information on 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 Recipe 9.7, Recipe 9.8, and Recipe 9.17.
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 Recipe 9.13 and Recipe 9.17.
Recipe 9.5; Recipe 9.7; Recipe 9.8; Recipe 9.10; Recipe 9.13; Recipe 9.17
 |
|
|
| Top |