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 the next listing:
router ospf 1
redistribute static metric 10
default-information originate
!
interface Ethernet0/1
ip ospf 1 area 0
If no workstations are 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 a dynamic switchover of the default gateway with a first-hop redundancy protocol (FHRP), for example, Virtual Router Redundancy Protocol (VRRP) or Hot Standby Router Protocol (HSRP). The configuration is straightforward since the track object that you can use to adjust the router’s HRSP priority based on the state of the upstream link has already been configured (see the following two listings; the only difference is the default HSRP priority, which is higher on GW A).
interface Ethernet0/1
ip address 192.168.0.3 255.255.255.0
standby 1 priority 100
standby 1 ip 192.168.0.1
standby 1 preempt
standby 1 track 17 decrement 20
interface Ethernet0/1
ip address 192.168.0.4 255.255.255.0
standby 1 priority 90
standby 1 ip 192.168.0.1
standby 1 preempt
Configuring Internet Routing
The gateway routers’ configuration follows the principles explained in the Small Site Multihoming article. IP addressing and NAT are configured on both gateway routers, as shown in the following listing (only the GW-A configuration is included in most examples; the complete router configurations are on GitHub).
ip dhcp pool LAN
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
exit
!
ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp excluded-address 192.168.0.128 192.168.0.255
!
interface Ethernet0/1
description gw_a -> [h1,h2,gw_b]
ip address 192.168.0.1 255.255.255.0
ip nat enable
!
interface Ethernet0/2
description gw_a -> pe_a
ip address 172.16.1.1 255.255.255.252
ip nat enable
!
ip access-list standard Site
10 permit 192.168.0.0 0.0.0.255
!
route-map Internet_Exit permit 10
match ip address Site
!
ip nat inside source route-map Internet_Exit interface Ethernet0/2 overload
Notes:
- The DHCP server runs on both gateway routers to increase the overall reliability. Use the ip dhcp excluded-addresses configuration commands to ensure the routers allocate addresses from non-overlapping pools.
- The NAT configuration is using the NAT Virtual Interface
- The NAT translation must use a route map to match the outgoing interface. Otherwise, GW-A would translate the host-originated packets routed to GW-B.
- The gateway router configuration was recreated on a netlab topology using IOS-on-Linux (IOL) as the gateway router and a pair of FRRouting nodes acting as PE-routers.
- All nodes in netlab-powered labs use the first LAN interface as a management interface, which is why the first data plane (inside) interface is Ethernet0/1.
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 ISP network’s core; tracking an upstream ISP server is even better).
- A track object that monitors the state of the IP SLA object.
- A local routing policy ensuring the IP SLA measurements always use the Internet interface (otherwise, a gateway router with a failed upstream link might use the default path the other gateway router provided for its SLA measurements).
- A static default route based on the state of the track object.
The relevant parts of GW-A configuration are included in the following listing (the detailed description of the configuration and monitoring commands related to reliable static routing is available in the Small Site Multihoming article).
ip access-list extended Ping_probe
10 permit icmp host 172.16.1.1 host 172.29.0.1
!
route-map LocalPolicy permit 10
match ip address Ping_probe
set ip next-hop 172.16.1.2
set interface Ethernet0/2
!
ip local policy route-map LocalPolicy
!
ip sla 15
icmp-echo 172.29.0.1 source-interface Ethernet0/2
threshold 100
timeout 200
frequency 1
ip sla schedule 15 life forever start-time now
!
track 17 ip sla 15 state
delay down 5 up 20
!
ip route 0.0.0.0 0.0.0.0 172.16.1.2 name ISP_A track 17
The setup on GW-B is much more straightforward, as we’re using it just as a backup router. It has a floating static default route; if Internet connectivity on GW-A is operational, the default route received through the routing protocol should override the static default route.
ip route 0.0.0.0 0.0.0.0 172.17.3.2 name ISP_B 250
Basic Small Site Multi-Homing
Connecting a small site to multiple service providers can be extremely easy – you get two upstream links and two provider-assigned (PA) IPv4 addresses (static or dynamically assigned). Since each ISP will give you only a single IPv4 address, you have to use private IPv4 addresses on the LAN side of the router (Figure 1).

IP addressing in small multi-homed site
Most ISPs are unwilling to run a dynamic routing protocol with small sites, so you must configure static default routing on your router. Since you would almost always prefer one provider over the other, you would create a primary and a backup default route.

Static default routing
The router on the remote site would also have to perform two independent NAT translations, one for packets sent to ISP A (where local addresses get translated to the IP address assigned by ISP A) and another for packets sent to ISP B (Figure 3).

NAT translation in small multi-homed site
One of the significant issues in multi-homed site design is the proper handling of the return traffic. It’s not uncommon to experience performance problems if the outbound and return traffic flow over different links (also known as asymmetrical routing), while IP multicast and stateful packet inspection (part of the Cisco IOS firewall feature set) almost always break under these conditions. Fortunately, asymmetrical routing is never a problem in a dual NAT design (see the above diagram), as the source address of the outbound packet indicates the link that has been used to send it:

Symmetrical routing with dual NAT