Redundant links problem

[dhegler]

Here is my situation:

(1) - We have two offices, let's say Office A and Office B. They are connected via a bonded dual T1 dedicated connection.

(2) - Each office has its own internet T1 connection.

(3) - We have 'newer' Cisco routers connecting the offices together

(4) - We have Watchguard Fiebox units as a Router/Proxy/Firewall in each office which are each connected to their respective ISPs.

(5) - I have static routing enabled (not RIP, IGRP, etc) where the default route is set to each office's internet connection and the opposite office's network is explicitly routed through our dedicated connection between the offices.

You can think of the routing this way in each office:

Example for Office A:

0.0.0.0/0 <ip address of our internet connection (Firebox)>

172.16.0.0/22 <ip address of our 'intranet' connection (Cisco)> (1022 internal addresses)

I have yet to find a way to edit the routing tables so if our internet (Firebox) connection goes down, it will automatically route through the 'intranet' (Cisco) routers out of the other office.

I can make the switch manually, which is not a problem, but I would rather find a more passive way to fix the problem of one office not being able to access the internet when one of our our Fireboxes (inevitably) fails us.

Sorry for the long post - maybe someone out there has an idea for me...

Thanks!

[Harold Ritter]

Without knowing what the firebox does and doesn't support, you should run a dynamic routing protocol on the firebox and inject the default gateway from there. If the firebox goes down on one side the default route would converge to the remote office.

[dhegler]

So, you are saying that this is not possible if you are hindered by only being able to run static routes?

At quick glance, it looks like the Firebox can only run static routing, but I am looking into it a bit more.

Thank you!

[dhegler]

Watchguard apparently does not include support for dynamic routing protocols on our model (maybe all of them).

My idea was to set up RIP between the Cisco routers that connect the offices and assign a very high administrative cost to the link. This way, I assume it will propagate a second default route to the other router with an incredibly high cost. However, I read that if you explicitly assign two default routes with the 0.0.0.0/0 convention, it will load-balance. But what about my idea - will the routers propagate their default routes correctly? And, if they do, will it allow for a "failover" or will it still load-balance although the routes were not explicitly assigned?

[jamey]

The issue with what you are talking about is you are advertising the default route from the "internal" router. You would still have to define the default route on the "internal" router. The internal router would still need a default route defined (a static route pointing to the firewall). This static route will always override RIP routes. So I don't think what you are talking about would work.

Another idea:

I assume you have your hosts default gateway as the "internal router"-the router with the T1s connecting the sites.

On that internal router, I assume you have a default route 0.0.0.0/0 pointing to the Watchguard at the local office. If you have two ethernet interfaces on the internal router, connect one directly to the Watchguard and the other to your LAN.

Add a floating static route that points to the router at the other office on the internal router with a high Admin Distance:

ip route 0.0.0.0 0.0.0.0 x.x.x.x 240

where x.x.x.x is the serial IP of the far end "internal router"

If the Watchguard goes down, the ethernet interface on the router connecting to it will go up/down and the "normal" default route that pointed to the Watchguard will be flushed from the routing table on the local internal router and the floating static route one will kick in.

You could also add two default floating static routes with the same Admin Distance so if the link to the Watchguard goes down, both floating static routes will kick in that point to the other side.

-HTH