Redundant Small Site Multi-homing
The IP Corner article Small Site Multihoming has generated lots of responses, most of them being questions about redundant implementation of the same principles. In this article, we’ll thus extend the small site multi-homing design with a set of redundant routers. The final design will still retain the administrative simplicity of the original solution – with no need to own public IP address space, autonomous system number or to run Border Gateway Protocol (BGP).
The basic design of a redundant multi-homed small site is very similar to the one described in IP Corner article Small Site Multihoming (I would strongly suggest you read that article before this one). The public IP addresses used by the site are still within the address space of the two service providers (Figure 1), and the private IP addresses are used within the site. Each gateway router performs independent Network Address Translation (NAT) from the private IP addresses to the public IP address pool (or a single IP address) assigned by the ISP.
IP addressing in small multi-homed site
Static default routes are configured on both gateway routers. The availability of these routes depends on tracked objects configured on each router (see the section Not-so-Very-Static-Routes in the Small Site Multihoming article). The static default routes are redistributed into a dynamic routing protocol to ensure that both gateway routers (as well as any other additional router within the site) have the same view of the Internet connectivity (Figure 2).
In the primary/backup scenario, the backup static default route configured on the gateway routers is a floating static route to ensure the backup path will not be used as long as the primary path is available.
Static default routing
Due to NAT being performed by the gateway routers, the return traffic is always handled properly regardless of the path the outgoing packet is taking. For example, if the outgoing packet is forwarded by GW B, the NAT performed by the gateway router would replace the source IP address with the IP address assigned by ISP B; the return packet would thus automatically take the path through ISP B (Figure 3).
Symmetrical routing with NAT
Although NAT solves the return path problem, the solution is not perfect. For example, if the traffic is flowing over the backup link and the primary link is reestablished, all the traffic will be shifted to the primary link (regardless of the TCP session status), resulting in a different public source IP address, and the workstations will lose all TCP sessions established at the switchover moment.
Configuring Internet Routing
The configuration of the gateway routers follow the principles explained in the Small Site Multihoming article. IP addressing and NAT is configured on both gateway routers, as shown in Listing 1 (only GW-A configuration is included in most examples).
IP addressing, DHCP and NAT configuration
ip dhcp pool LAN
network 192.168.0.0 255.255.255.0
ip dhcp excluded-addresses 192.168.0.1 192.168.0.10
ip dhcp excluded-addresses 192.168.0.128 192.168.0.255
description *** Inside LAN interface ***
ip address 192.168.0.1 255.255.255.0
ip nat inside
description *** Link to ISP A ***
ip address 172.16.1.1 255.255.255.252
ip nat outside
ip nat inside source route-map ISP_A interface Serial0/0/0 overload
route-map ISP_A permit 10
match interface Serial0/0/0
To increase the overall reliability, the DHCP server is running on both gateway routers. Use the ip dhcp excluded-addresses configuration commands to ensure the routers always allocate addresses from non-overlapping pools.
To implement reliable static routes on both gateway routers, you have to configure:
An IP SLA object to track end-to-end connectivity to an IP address that is “far enough” (at least within the core of the ISP network, tracking a server of an upstream ISP is even better).
A track object that monitors the state of the IP SLA object.
A default route that is inserted in the IP routing table based on the state of the track object.
Local policy routing to ensure that the IP SLA measurements always use the Internet interface (otherwise a gateway router with failed upstream link might use the default path provided by the other gateway router for its SLA measurements).
The relevant parts of GW-A configuration are included in Listing 2 (and the detailed description of the configuration and monitoring commands related to reliable static routing is available in the Small Site Multihoming article). The only major difference between GW-A and GW-B is the default route configuration, where you would use a high administrative on the backup router (GW-B in our example) to make the default route floating; if Internet connectivity on GW-A is operational, the default route received through the routing protocol should override the static default route.
Basic multi-homed default routing setup
ip sla 15
icmp-echo 172.29.0.1 source-interface Serial0/0/0
ip sla schedule 15 life forever start-time now
track 17 rtr 15 reachability
delay down 10 up 20
ip local policy route-map LocalPolicy
ip access-list extended PingISP_A
permit icmp host 172.16.1.1 host 172.29.0.1
route-map LocalPolicy permit 10
match ip address PingISP_A
set interface Serial0/0/0
ip route 0.0.0.0 0.0.0.0 Serial0/0/0 10 name ISP_A track 17
Configuring Intra-Site Routing
The static default route configured on GW-A and GW-B has to be propagated between them to ensure that both routers have the same view of the Internet connectivity. The easiest way to implement this requirement is to redistribute the static default route into a dynamic routing protocol configured between the two routers, as shown in Listing 3.
Redistributing the static default route
router ospf 1
redistribute static metric 10
ip ospf 1 area 0
OSPF will not announce the redistributed default route until you configure default-information originate within the OSPF process.
If there are no workstations attached to the LAN between GW-A and GW-B, we’re finished; all routers attached to that LAN will get the default route pointing to the currently-active gateway router through a dynamic routing protocol (Figure 4).
Intra-site routing in a large site
Intra-site routing with workstations attached to the same LAN as GW-A and GW-B is a bit more complex. You can usually configure only a single default gateway on the workstations, so you have to provide dynamic switchover of the default gateway with Hot Standby Router Protocol (HSRP) or an equivalent (for example, Gateway Load Balancing Protocol; GLBP, or Virtual Router Redundancy Protocol; VRRP). The configuration is very simple, since the track objects that you can use to adjust the router’s HRSP priority based on the state of the upstream link have already been configured (see Listing 4 and Listing 5; the only difference is the default HSRP priority, which is higher on GW A).
HSRP and VRRP address only the needs of primary/backup router scenarios, whereas GLBP supports outbound load balancing. As our design does not address load balancing toward the Internet, HSRP nicely fits the requirements.
HSRP configuration on GW A
ip address 10.0.0.5 255.255.255.0
standby 1 priority 95
standby 1 ip 10.0.0.1
standby 1 preempt
standby 1 track 17 decrement 20
HSRP configuration on GW B
ip address 10.0.0.6 255.255.255.0
standby 1 ip 10.0.0.1
standby 1 priority 90
standby 1 preempt
standby 1 track 17 decrement 20
The design described in this article gives you the ability to implement fully redundant Internet connectivity without having an allocated public IP address space or autonomous system number. Even better, it’s completely static on the Internet side, thus alleviating the need to configure BGP on the gateway routers. However, the simplicity of the design brings a few drawbacks as well; you should use this design only in a stable environment where the switchover from primary to backup ISP is unlikely (but you still need the secondary connection to ensure reliability), as every switchover will cause all established TCP sessions to be terminated.
The article focused solely on the primary/backup scenario. It’s possible to extend it to support rudimentary load sharing, but you have to be careful to make certain that all the IP packets between a pair of inside/outside hosts will always flow across the same gateway router (otherwise the NAT configured on the gateway router will destroy the TCP session). Similarly, it’s possible (although not trivial) to implement publicly accessible inside servers; this topic will be covered in a later IP Corner article.