How to provide failover for space-diversity T1

Question

I have inherited a small, insular, dedicated network which is essentially trouble-free, so naturally I want to improve it :-) I lowered my network knowledge and savvy to somewhere around a 2 to 3 on a scale of 1-10 after reading networking posts here. I have only included the pertinent routers in my diagram for clarity.

Currently there's a mix of roughly 6-8 Cisco 2800 and 2900 at each campus with voice cards for a dedicated homegrown application, using static routes to get packets between the 2 campuses. They are running c2801-spservicesk9-mz.124-3g on R1 and R2, and c2800nm-adventerprisek9-mz.124-15.t3 on R3 and R4.

This is a fixed, unchanging network that serves only this dedicated application. No desktops nor laptops coming and going, just the Cisco routers connected via third party fiber muxes in a ring topology on each campus with a couple server machines connected (part of the "other nodes").

Sometime along the way the customer decided it would be a great idea to install a second T1 between R2 and R3 for redundancy. Based on my tests the static routing has no way of employing that second T1. Even with AD/metric on a secondary route to the new T1 only the router whose T1 has failed knows this, but the other routers on that campus do not.

I was considering using ip tracking objects after reading such solutions here to keep things simple and minimize upset to the network. Then I read where EIGRP is the preferred way to handle this.

But if dynamic routing is the way to go it must be implemented in a way that does not disrupt service. This is all remote to me and would require me to arrange a local technician to be standing by in case I lose connectivity during reconfiguration. Hopefully with such a small, unchanging network this disruption could be minimized.

So should I be researching how to employ ip tracking objects or EIGRP to accomplish this T1 failover routing?

EDIT: Here are the currently configured routes for R4. I'm pretty confident that there is some cruft here, but I tried exactly one time to simplify it and backed off when I made one tiny mistake and lost connectivity to Campus B. Outages are a big no-no. I decided to leave well enough alone until I devised a better approach.

ip route 10.0.0.0 255.0.0.0 10.1.1.8
ip route 10.1.1.8 255.255.255.252 Serial0/3/0
ip route 192.168.30.0 255.255.255.0 Serial0/3/0
ip route 192.168.6.0 255.255.255.0 Serial0/3/0
ip route 192.168.8.0 255.255.255.0 FastEthernet0/0
ip route 10.0.2.128 255.255.255.192 192.168.31.2
ip route 10.2.160.0 255.255.255.0 192.168.31.2
ip route 192.168.254.0 255.255.255.0 192.168.31.2
ip route 192.168.6.0 255.255.255.0 192.168.8.11 110 name fallback
ip route 0.0.0.0 0.0.0.0 10.1.1.9
ip route 0.0.0.0 0.0.0.0 192.168.8.11 110 name fallback

The route configuration for R3 is simple:

ip route 0.0.0.0 0.0.0.0 192.168.8.15
ip route 0.0.0.0 0.0.0.0 10.1.1.5 110

Thanks.

Answer 1

This is a fixed, unchanging network that serves only this dedicated application.

I think you’re finding that this is rarely the norm with networking, even with unchanging networks; hence, why you’re here asking how to automate this. Eventually, another link comes online that requires you to reengineer all of your previous efforts. This is, by definition, what the purpose of a routing protocol is. It’s to make sure you don’t have to use static routes everywhere!

Based on my tests the static routing has no way of employing that second T1.

You can setup a sort of IP SLA that can keep your system running how it is while still allowing for failover in case your Old T1 goes down.

An example of this type of configuration for R4 would be something like this.

R4(config)# ip sla 1
R4(config)# icmp-echo 10.1.1.9 source-interface Serial0/3/0
R4(config)# timeout 1000
R4(config)# threshold 2
R4(config)# frequency 3
R4(config)# ip sla schedule 1 life forever start-time now
R4(config)# track 1 ip sla 1 reachability
R4(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.9 track 1
R4(config)# ip route 0.0.0.0 0.0.0.0 192.168.8.11 100

_{modified version of firewall.cx sample configuration.}

But, as you’re quickly finding out, is the less than ideal way of doing this. Automating this with EIGRP is probably your best bet since you have all Cisco hardware.

But if dynamic routing is the way to go it must be implemented in a way that does not disrupt service.

If you setup EIGRP in conjunction with your static routes. EIGRP neighbor relationships will be built and your routing tables will be populated with routes to the different locations. No outage should really occur, because your routers will have a fully populated routing table with knowledge of how to get to the other subnets.

Just remember, once everything is setup and running smoothly with both EIGRP and static routing, your still going to use your static routes until you remove them. Done properly, you shouldn’t even notice a blip in traffic flow.

Compare your previous configurations with an example EIGRP configuration for R4.

R4(config)#router eigrp 1
R4(config-router)#no auto-summary
R4(config-router)#network 10.1.1.8
R4(config-router)#network 192.168.8.0

It’s usually that simple for such a small network.