Redundant Small Site Multi-Homing

[LEFT][CODE]http://www.nil.com/ipcorner/RedundantMultiHoming/[/CODE]
The IP Corner article [URL="http://www.nil.com/ipcorner/SmallSiteMultiHoming/"][I]Small Site Multi[/I][I]homing[/I][/URL]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).
[B]Redundant Design[/B]

The basic design of a redundant multi-homed small site is very similar to the one described in IP Corner article [URL="http://www.nil.com/ipcorner/SmallSiteMultiHoming/"][I]Small Site Multihoming[/I][/URL] (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.


Figure 1
IP addressing in small multi-homed site
[IMG]http://www.nil.com/ipcorner/RedundantMultiHoming/$FILE/RedundantMultihoming_1.jpg[/IMG]
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 [I]Not-so-Very-Static-Routes[/I] in the [URL="http://www.nil.com/ipcorner/SmallSiteMultiHoming/"]Small Site Multihoming[/URL] 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).


[B]Note[/B]
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.


Figure 2
Static default routing
[IMG]http://www.nil.com/ipcorner/RedundantMultiHoming/$FILE/RedundantMultihoming_2.jpg[/IMG]
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).


Figure 3
Symmetrical routing with NAT
[IMG]http://www.nil.com/ipcorner/RedundantMultiHoming/$FILE/RedundantMultihoming_3.jpg[/IMG]
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.

[B]Configuring Internet Routing[/B]

The configuration of the gateway routers follow the principles explained in the [URL="http://www.nil.com/ipcorner/SmallSiteMultiHoming/"]Small Site Multihoming[/URL] 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).


[B]Listing 1 [COLOR=Red]IP addressing, DHCP and NAT configuration[/COLOR][/B]


[CODE]

hostname GW-A
!
ip cef
!
ip dhcp pool LAN
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
!
ip dhcp excluded-addresses 192.168.0.1 192.168.0.10
ip dhcp excluded-addresses 192.168.0.128 192.168.0.255
!
interface FastEthernet0/0
description *** Inside LAN interface ***
ip address 192.168.0.1 255.255.255.0
ip nat inside
!
interface Serial0/0/0
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
[/CODE][B]Note[/B]
To increase the overall reliability, the DHCP server is running on both gateway routers. Use the [B]ip dhcp excluded-addresses [/B]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 [B]track[/B] 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 [B]track [/B]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 [URL="http://www.nil.com/ipcorner/SmallSiteMultiHoming/"]Small Site Multihoming[/URL] 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.


[B]Listing 2 [COLOR=Red]Basic multi-homed default routing setup[/COLOR][/B]



[CODE]
hostname GW-A
!
ip sla 15
icmp-echo 172.29.0.1 source-interface Serial0/0/0
timeout 200
frequency 10
!
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
[/CODE]

[B]Configuring Intra-Site Routing[/B]

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.

[B]Listing 3 [COLOR=Red]Redistributing the static default route[/COLOR][/B]


[CODE]router ospf 1
redistribute static metric 10
default-information originate
!
interface FastEthernet0/0
ip ospf 1 area 0
[/CODE][B]Note[/B]
OSPF will not announce the redistributed default route until you configure [B]default-information originate[/B] 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).


Figure 4
Intra-site routing in a large site
[IMG]http://www.nil.com/ipcorner/RedundantMultiHoming/$FILE/RedundantMultihoming_4.jpg[/IMG]
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 [B]track [/B]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).


[B]Note[/B]
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.

[B]Listing 4 [COLOR=Red]HSRP configuration on GW A[/COLOR][/B]


[CODE]interface FastEthernet0/0
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
[/CODE][B]Listing 5 [COLOR=Red]HSRP configuration on GW B[/COLOR][/B]
[B][COLOR=Red]
[/COLOR][/B]
[CODE]interface FastEthernet0/0
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

[/CODE][B]Summary[/B]
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
[/LEFT]