Balancing Between Two Routers Sharing Multiple Paths

This example shows how load balancing can be achieved between two routers sharing multiple paths without having routing updates being duplicated over the two paths.

For the scenario in figure 11-6, we will configure loopback interfaces on RTA and RTC and run a single peering session between the two routers. Using static routes, we can point to the loopback interfaces via both of the physical interfaces. This way, the IP routing table will have two paths to reach the next hop and will load balance.

Figure 11-6  Balancing between two routes sharing multiple paths.

RTA configuration:

    interface Loopback0
    ip address 172.16.2.254 255.255.255.255

    router bgp 3
    no synchronization
    neighbor 172.16.1.2 remote-as 3
    neighbor 172.16.1.2 update-source Loopback0
    neighbor 172.16.90.1 ebgp-multihop 2
    neighbor 172.16.90.1 update-source Loopback0
    no auto-summary

    ip route 172.16.90.1 255.255.255.255 172.16.20.1
    ip route 172.16.90.1 255.255.255.255 172.16.60.1

RTC configuration:

    interface Loopback0
    ip address 172.16.90.1 255.255.255.255

    router bgp 1
    network 192.68.11.0
    neighbor 172.16.2.254 remote-as 3
    neighbor 172.16.2.254 ebgp-multihop 2
    neighbor 172.16.2.254 update-source Loopback0
    no auto-summary

    ip route 172.16.2.254 255.255.255.255 172.16.20.2
    ip route 172.16.2.254 255.255.255.255 172.16.60.2

The following output shows how RTA is now learning BGP updates from RTC via next hop 172.16.90.1, the loopback address.

    RTA#show ip bgp
    BGP table version is 4, local router ID is 172.16.2.254
    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
    *>i172.16.10.0/24 172.16.1.2     0   100      0 i
    *> 192.68.11.0    172.16.90.1   0             0 1 i

The two static routes in RTA's routing table will provide multiple paths to reach the next hop 172.16.90.1, and hence the router will load balance between the two paths.

    RTA#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

    Gateway of last resort is not set

    B  192.68.11.0/24 [20/0] via 172.16.90.1, 00:00:41
     172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
    C  172.16.2.254/32 is directly connected, Loopback0
    C  172.16.60.0/24 is directly connected, Ethernet0
    C  172.16.20.0/24 is directly connected, Serial0
    O  172.16.10.0/24 [110/20] via 172.16.1.2, 02:17:34, Ethernet1
    C  172.16.1.0/24 is directly connected, Ethernet1
    S  172.16.90.1/32 [1/0] via 172.16.20.1
                     [1/0] via 172.16.60.1

Multihoming to Different Providers

For the case of one customer multihomed to multiple providers, we will discuss a scenario where updates are following a combination of defaults, partial, and full routing.

In figure 11-7, AS3 is multihomed to two different ASs, AS1 and AS2, which in turn exchange routing information and traffic with AS6 and each other via a network access point. AS6, AS2, and AS1 all peer with RTE, which is acting as a route server that has the function of only passing routing updates between all three ASs.

Figure 11-7  Multiple providers (default, primary and backup, full/partial).

1.  AS3 will be accepting AS1's local and customer routes only via the SF link. All other Internet routes will be accepted via the NY link (primary).

2.  AS3 will accept a default route from AS1 just in case there is a failure in the NY link.

3.  AS3 prefers that the SF network 172.16.220.0/24 be reachable by the outside world via the SF link, and the NY networks 172.16.10.0/24 and 172.16.65.0/26 be reachable via the NY link.

4.  AS3 cannot be a transit network for AS1 and AS2, which means that under no circumstances will AS1 use AS3 to reach AS2.

The following configurations illustrate how to implement this routing arrangement.

RTA configuration:

    router bgp 3
    no synchronization
    network 172.16.1.0 mask 255.255.255.0
    network 172.16.10.0 mask 255.255.255.0
    network 172.16.65.0 mask 255.255.255.192
    network 172.16.220.0 mask 255.255.255.0
    neighbor 172.16.1.2 remote-as 3
    neighbor 172.16.1.2 update-source Loopback0
    neighbor 172.16.1.2 next-hop-self
    neighbor 172.16.20.1 remote-as 1
    neighbor 172.16.20.1 route-map ACCEPT_LOCAL in
    neighbor 172.16.20.1 route-map PREPEND_PATH out
    no auto-summary

    ip as-path access-list 1 permit ^1 ?[0-9]*$
    ip as-path access-list 2 permit ^$

    access-list 1 permit 172.16.65.0 0.0.0.63
    access-list 1 permit 172.16.10.0 0.0.0.255
    route-map PREPEND_PATH permit 10
    match ip address 1
    set as-path prepend 3

    route-map PREPEND_PATH permit 20
    match as-path 2

    route-map ACCEPT_LOCAL permit 10
    match as-path 1

RTA uses a route map called ACCEPT_LOCAL that accepts partial routes from AS1. The route map will try to match on any path of the form ^1 ?[0-9]*$, which, as already explained, enables AS1's local and customer routes.

RTA uses toward RTC a route map called PREPEND_PATH that will prepend an additional AS number to all NY prefixes such as 172.16.10.0/24 and 172.16.65.0/26. This will make the AS_path length of these prefixes shorter via the NY link. Doing the AS_path prepend should always be coordinated with the provider. Your provider might have policies that conflict with your path information. AS1, for example, might have a policy that advertises AS3 to the NAP, for example, using the form ^3$, which means an AS_path that starts with 3 and ends with 3. If AS3 starts sending AS_path information of the form 3 3 3 3, the provider will drop the routes because the AS_path will not match its policy.

Note that instance 20 of the route-map PREPEND_PATH enables AS3's local routes to be advertised only. This is done by matching on the local prefixes with empty AS_path information represented by the ^$ regular expression.