Summary

Using the design described in this article, you can 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.

read more add comment

Not-so-Very-Static Routes

Numerous network devices can combine static routes with Bidirectional Forwarding Detection (BFD) and remove them from the routing table if the BFD session with the next-hop router fails. Unfortunately, that works only if the upstream network supports BFD on its customer-facing interfaces1; we need a more generic solution that does not rely on the functionality of the upstream router2.

Cisco IOS includes Enhanced Object Tracking functionality, which, together with Reliable Static Routing Using Object Tracking, solves the “Is the next hop reachable?” problem without relying on the adjacent router’s cooperation.

read more add comment

Monitoring Reliable Static Routing

Reliable static routes silently appear or disappear from the IP routing table based on the state of the attached track object; the only way to monitor their state is to use the show ip route track-table command.

Show tracked routes
GW#show ip route track-table
 ip route 0.0.0.0 0.0.0.0 Serial0/0/0 10 name ISP_A track 100 state is [down]

However, state tracking generates logging messages, and you can use the debug track command to get even more details.

read more add comment

End-to-End Connectivity Test

After you’ve successfully implemented the tracking of the primary next-hop router’s availability, you might be tempted to improve the solution to track end-to-end connectivity through ISP A and switch to the backup ISP whenever your central site is not reachable through the primary ISP. In theory, the required configuration change should be minimal – you only have to change the destination IP address in the IP SLA definition:

Pinging a remote host
hostname GW
!
ip sla 100
 icmp-echo 172.18.0.6 source-interface GigabitEthernet0/2
 threshold 500
 timeout 1000
 frequency 3
ip sla schedule 100 life forever start-time now

Unfortunately, there’s a serious problem with this setup when the path between GW and PE_A fails in a way that is not detected by the GW router (for example, there’s a problem in an intermediate layer-2 switch):

read more add comment

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:

Redistributing the static default route
router ospf 1
 redistribute static metric 10
 default-information originate
!
interface Ethernet0/1
 ip ospf 1 area 0
OSPF will not announce the redistributed default route until you configure default-information originate within the OSPF process.

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).

read more add comment

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 addressing, DHCP and NAT configuration on GW-A
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:

read more add comment

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

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.

read more add comment
Sidebar