No problem. BGP will allow us to set up weighting on one of the routes so that we can prefer a route from one of the customer's routers, but will revert to the less preferred route if the primary site goes off-line for any reason. To explain how it's done, we'll use this example network:
R1 and R2 are my routers. R3 and R4 are the customer's routers, with R3 being the primary location, and R4 being the secondary site. R5 is $Random_Internet_Host.
We'll start by configuring the IP addresses on each of the routers.
R1:
R1#sho ip int brie
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.0.1 YES manual up up
FastEthernet1/0 172.16.3.1 YES manual up up
FastEthernet2/0 100.64.17.1 YES manual up up
FastEthernet3/0 unassigned YES unset administratively down down
Loopback0 10.254.254.1 YES manual up up
R1#
R2:
R2#sho ip int brie
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.0.2 YES manual up up
FastEthernet1/0 172.16.4.1 YES manual up up
FastEthernet2/0 unassigned YES unset administratively down down
FastEthernet3/0 unassigned YES unset administratively down down
Loopback0 10.254.254.2 YES manual up up
R2#
R3:
R3#sho ip int brie
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.1.1 YES manual up up
FastEthernet1/0 172.16.3.2 YES manual up up
FastEthernet2/0 unassigned YES unset administratively down down
FastEthernet3/0 unassigned YES unset administratively down down
Loopback0 10.10.10.3 YES manual up up
R3#
R4:
R4#sho ip int brie
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.1.1 YES manual up up
FastEthernet1/0 172.16.4.2 YES manual up up
FastEthernet2/0 unassigned YES unset administratively down down
FastEthernet3/0 unassigned YES unset administratively down down
Loopback0 10.10.10.4 YES manual up up
R4#
We'll skip R5's IP configuration, since it doesn't really matter for this lab -- any subnet(s) that isn't being used elsewhere is fine on R5.
Next, we'll start with an ordinary BGP configuration on each of the routers:
R1:
router bgp 42
no synchronization
bgp router-id 10.254.254.1
bgp log-neighbor-changes
network 10.0.0.0 mask 255.255.255.0
network 172.16.3.0 mask 255.255.255.252
network 100.64.17.0 mask 255.255.255.0
neighbor 10.0.0.2 remote-as 42
neighbor 172.16.3.2 remote-as 2358
neighbor 100.64.17.5 remote-as 2112
no auto-summary
!
R2:
router bgp 42
no synchronization
bgp router-id 10.254.254.2
bgp log-neighbor-changes
network 10.0.0.0 mask 255.255.255.0
network 172.16.4.0 mask 255.255.255.252
neighbor 10.0.0.1 remote-as 42
neighbor 172.16.4.2 remote-as 2358
no auto-summary
!
R3:
router bgp 2358
no synchronization
bgp router-id 10.10.10.3
bgp log-neighbor-changes
network 10.10.10.3 mask 255.255.255.255
network 172.16.3.0 mask 255.255.255.252
network 192.168.1.0
neighbor 172.16.3.1 remote-as 42
no auto-summary
!
R4:
router bgp 2358
no synchronization
bgp router-id 10.10.10.4
bgp log-neighbor-changes
network 10.10.10.4 mask 255.255.255.255
network 172.16.4.0 mask 255.255.255.252
network 192.168.1.0
neighbor 172.16.4.1 remote-as 42
no auto-summary
!
Again, we'll skip R5, as nothing special is going on there. It's just a straight peering configuration with R1.
Give the routers time to establish BGP adjacencies and to discover all of the routes on this network, then on R1 and R2, run the "show ip route" command:
R1#sho ip route
<...snip...>
169.254.0.0/24 is subnetted, 1 subnets
B 169.254.1.0 [20/0] via 100.64.17.5, 01:59:05
172.16.0.0/30 is subnetted, 2 subnets
B 172.16.4.0 [200/0] via 10.0.0.2, 00:37:33
C 172.16.3.0 is directly connected, FastEthernet1/0
8.0.0.0/32 is subnetted, 1 subnets
B 8.8.8.8 [20/0] via 100.64.17.5, 01:59:05
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.254.254.2/32 [200/0] via 10.0.0.2, 00:37:33
B 10.10.10.3/32 [20/0] via 172.16.3.2, 00:37:25
C 10.0.0.0/24 is directly connected, FastEthernet0/0
C 10.254.254.1/32 is directly connected, Loopback0
B 10.10.10.4/32 [200/0] via 172.16.4.2, 00:37:14
12.0.0.0/16 is subnetted, 1 subnets
B 12.12.0.0 [20/0] via 100.64.17.5, 01:59:06
C 100.64.17.0/24 is directly connected, FastEthernet2/0
B 192.168.1.0/24 [20/0] via 172.16.3.2, 00:37:25
R1#
R2#sho ip route
<...snip...>
169.254.0.0/24 is subnetted, 1 subnets
B 169.254.1.0 [200/0] via 100.64.17.5, 00:37:13
172.16.0.0/30 is subnetted, 2 subnets
C 172.16.4.0 is directly connected, FastEthernet1/0
B 172.16.3.0 [200/0] via 10.0.0.1, 00:38:13
8.0.0.0/32 is subnetted, 1 subnets
B 8.8.8.8 [200/0] via 100.64.17.5, 00:37:13
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.254.254.2/32 is directly connected, Loopback0
B 10.10.10.3/32 [200/0] via 172.16.3.2, 00:38:01
C 10.0.0.0/24 is directly connected, FastEthernet0/0
B 10.10.10.4/32 [20/0] via 172.16.4.2, 00:37:59
12.0.0.0/16 is subnetted, 1 subnets
B 12.12.0.0 [200/0] via 100.64.17.5, 00:37:14
B 100.64.17.0/24 [200/0] via 10.0.0.1, 00:38:14
B 192.168.1.0/24 [20/0] via 172.16.4.2, 00:37:59
R2#
If you'll notice, R1 has discovered the route to 192.168.1.0/24 via 172.16.3.2 (R3), but R2 has discovered the route to 192.168.1.0/24 via 172.16.4.2 (R4). This is not what we want. We want all traffic routed to R3 until and unless R3 goes off-line; right now, traffic will be routed to either R3 OR R4 based upon whether it passes through R1 or R2. To fix this, we'll create an access list to match the 192.168.1.0/24 subnet, then apply it to a route map, and finally, apply the route map to the BGP configuration on R2:
R2(config)#access-list 5 permit 192.168.1.0 0.0.0.255
R2(config)#route-map LPREF permit 10
R2(config-route-map)#match ip address 5
R2(config-route-map)#set weight 100
R2(config-route-map)#route-map LPREF permit 20
R2(config-route-map)#exit
R2(config)#router bgp 42
R2(config-router)#neighbor 10.0.0.1 route-map LPREF in
R2(config-router)#
At this point, if you run the "sho ip route" command again, you'll notice that nothing has changed. Clear the BGP session with R1 to apply the change to your BGP configuration:
R2#clear ip bgp 42
R2#
02:43:14: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Down User reset
R2#
02:43:19: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up
R2#sho ip route | inc 192.168.1.
B 192.168.1.0/24 [200/0] via 172.16.3.2, 00:00:12
R2#
BGP uses hop count to determine the preferred path when it has multiple routes to a subnet. Since there is one hop to 192.168.1.0/24 via 172.16.4.2, and two hops to 192.168.1.0/24 via 172.16.3.2 (from R2's perspective), R2 will route to R4 by default. What we've done is adjust the weighting for routes from R1 matching "192.168.1.xxx" to 100, so that R2 will prefer the route through R1 and R3 over the route from R4:
R2#sho ip bgp
<...snip...>
Network Next Hop Metric LocPrf Weight Path
<...snip...>
*>i192.168.1.0 172.16.3.2 0 100 100 2358 i
* 172.16.4.2 0 0 2358 i
<...snip...>
R2#
If you shut fa-1/0 on R3, then wait about four minutes, you'll see both R1 and R2 change their route to 192.168.1.0/24 to traverse R4 rather than R3. This is kind of a long time for an outage, but that delay can be tuned by adjusting the BGP timers. However, adjusting the timers too aggressively can lead to other problems. That means that a proper discussion on tuning BGP timers is probably beyond the scope of this lesson, so I'll save that for another day.
