|
Question : Static Route for "preferred gateway" with failover to "default gateway" for ONE subnet ONLY
|
|
I am having trouble working through this situation. I have four branches connected via full mesh WAN links. ONE of the four branchs is a 56k connection, while the other three are all High Speed connections. We have set up a secondary high speed WAN link (using a wireless connection) to the slow linked branch that will ONLY provide access between the Head Office and the "slow" branch office. For this slow branch, the Primary Gateway will still remain the slow link for remote workstations accessing everything except Win2k Server Access (ie..Internet still goes out over slow link). I want the workstations to fail over to the slow speed link for Win2k Server access if the high speed link goes down (fails to respond to PING) because there IS a route to head office through the slow link (and vice versa for Head Office to Slow Office).
Branch Office Subnet: 192.168.2.0
Default Gateway (slow full mesh): 192.168.2.254
Second Gateway (fast main office link only): 192.168.2.1
Head Office Subnet: 192.168.1.0
Default Gateway (fast full mesh): 192.168.1.254
Second Gateway (single branch direct link only): 192.168.1.1
In the Main Office, I want the servers to communicate to the Branch Office via the fast link, BUT if the fast link goes down I want the servers to auto-switch to the slow link. I also want the workstations in the Branch office to do the same thing.
What I know:
I did my testing from a workstation in HEAD Office. The metric on the default gateway is set to 2.
I have added a static route to the 192.168.2.x network with this command
route add 192.168.2.0 mask 255.255.255.0 192.168.1.1 metric 1 -p
Therefore, the head office workstation would communicate to slow branch on metric 1 static route, but on Failure it should have tried the Default Gateway.
PROBLEM:
When I ping a workstation at the remote branch, it goes through the static route that I have set up to the Fast Gateway. To test the "failover" I shut down the power to the fast gateway device. I expected the pings to time out for a short period of time and then the workstation would start using the Default Gateway at metric 2. This never happened, and I do not know why.
To test further, I added a second static route with a metric 2 pointing to the default gateway. When I did a ROUTE PRINT, the following lines appeared as I expected they would at the bottom of the output:
Default Gateway: 192.168.1.254
============================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
192.168.2.0 255.255.255.0 192.168.1.1 1
192.168.2.0 255.255.255.0 192.168.1.254 2
I cannot set two DEFAULT gateways in Network Properties because the 2nd gateway is ONLY valid to reach the slow remote branch (vice-versa for the remote branch access to Head Office). The Primary Link gateways need to stay valid at all times.
QUESTION:
Does anyone have any ideas why my workstation is not automatically using the 2nd gateway when it fails to get through the "dead" gateway?
All Hail The Ascii Map
Remote Branch...................Remote Branch
...............|.........\.........................../
...............|..........\......................../
...............|.........56k...............FAST
...............|..............\................./
...............|...............\======/
.............FAST...........|.............|
...............|...........Private Network
...............|...............|.............|
...............|...............|======|
...............|............../...............\
...............|............./..................\
...............|........FAST...............FAST
...............|........../.......................\
........Head Office................Remote Branch
|
Answer : Static Route for "preferred gateway" with failover to "default gateway" for ONE subnet ONLY
|
|
Every host that speaks TCP/IP has a routing table; under Windows, you can display it by typing "route print" at a command prompt. You'll see that from the address and subnet masks configured on interfaces, it has inferred routes to local subnets, and from the default gateway setting, it has inferred a route to "everything else". You can add additional routes for special destinations.
"Routing protocols" (stupid term, since they don't "route", but too late to fix it now) like RIP are *normally* used by routers ("gateways") to share information about remote destination networks. The device listening to RIP learns about routes other machines have, and adds them to its local routing table.
I've heard a few people suggest that "speaks/understands a routing protocol" is a good definition of a router. I disagree; what makes a box a router is that it forwards, using its own routing table, packets on behalf of other machines. On NT, this behaviour was enabled by a checkbox; I think on 2K and above you probably have to install RRAS first to have that capability available. I AM *NOT* SUGGESTING THAT YOU ENABLE THIS CAPABILITY.
You're correct to be concerned about traffic volumes -- RIP is very chatty, with each participating device broadcasting its routing table every 30 seconds. That's one of the reasons that other choices exist, although most aren't available on Windows client boxes. (Luckily, the routing tables in this scenario will be quite small.)
For the solution I had in mind, the hosts only need to *listen* to the RIP broadcasts from the gateway, they never actually need to send their own. I'm not sure whether the Microsoft RIP config offers that option -- if it does, you definitely want to use it since the hosts are not offering to route traffic. (Microsoft might, just possibly, have been smart enough that their RIP implementation does listen-only unless packet forwarding is enabled....)
The basic idea I had in mind was that while the normal gateway is up, clients will keep seeing its RIP broadcasts and learning that they should use it. When it goes away, those broadcasts stop, and as the clients stop inserting the route(s) learned from RIP into their routing tables, they fall back on their higher-metric static route to the backup gateway.
|
|
|
|
|
