routing decisions.

[jurgen]

Hi. I want to have an (automatic) fail-over route from my
network A which uses a hardware VPN tunnel to connect to
network B. The fail-over route would utilize an ISDN
dialup router.

The ISDN router has RIPv2 but the 3com internet firewall
(which builds up the VPN tunnel) does not seem to use any
type of routing protocol. Using rip listener is therefore
useless.

The solution would be to set the default route on the
workstations to the W2k servers and let the servers make
the routing decisions. I thought the solution was to make
the following static routes on the W2k servers:
Route add "remote network" mask 255.255.255.0 "local vpn-
tunnel router" metric 5 /p
Route add "remote network" mask 255.255.255.0 "local isdn
fail-over router" metric 10 /p

Sure enough the ping works as long as the vpn-tunnel is
operational but fails when the tunnel is down never trying
the fail-over route. Someone suggested the solution would
be to install RRAS, is that really necessary for W2k to
make such a simple routing decision? If so I'd appreciate
it to have some pointers for using RRAS to solve this
problem.

Thanks.

 

[Herb Martin]

Hi. I want to have an (automatic) fail-over route from my

network A which uses a hardware VPN tunnel to connect to
network B. The fail-over route would utilize an ISDN
dialup router.

Ok, you do this with the METRIC on the route -- set the main
route to a lower metric.

The ISDN router has RIPv2 but the 3com internet firewall
(which builds up the VPN tunnel) does not seem to use any
type of routing protocol. Using rip listener is therefore
useless.

What routing role does the 3Com play? If it doesn't have any
routing settings but IS A router then it is using just static routes
based on the default gateway setting.

You have to 1) find a common route "point" where you CAN
make the distinction and 2) the first pathway has to FAIL cleanly.

When the ISDN (or whatever) is down, then that connection AND
device has to fail (or you must turn it off) so that the "router" will
know the pathway is gone.

Problem is when a break happens OUTSIDE your control; your
internal/configurable equipment will send to the next hop, until it
reaches that break -- and now it is to late to take the "other route."

Analogy: The Interstate is blocked, but the "on ramp" is working;
traffic gets own and just joins the traffic jam.

Were the on-ramp blocked too, there would be plenty of other
pathways for the traffic.

 

[jurgen]

Ok, you do this with the METRIC on the route -- set the
main route to a lower metric.

This is how I expected it to work. However when testing
this by turning off the main router (3com/vpn), all ping
packets on the w2k server were lost while the second
route was up and in the routing table on the w2k servers
in both networks (with a higher metric value). To make
sure I wasn't overlooking anything I deleted the lowest
metric route in the routing table on both sides and the
ping worked fine.

What routing role does the 3Com play? If it doesn't

have any routing settings but IS A router then it is
using just static routes based on the default gateway
setting.

The 3com is the firewall which has a VPN option, btw both
networks use the same hardware. And yes, this piece of
hardware only seems to expect a static route to it. No
way of telling the VPN tunnel is up from the network
other than that traffic gets through or not.

You have to 1) find a common route "point" where you

CAN make the distinction and 2) the first pathway has to
FAIL cleanly.

The W2k servers on both networks are the common
route "point", unfortunately it does not seem to be able
to tell that the lowest metric route has become non
existent (by turning the routing device off). Is just
adding a second route with a higher metric not sufficient
for w2k server?

Problem is when a break happens OUTSIDE your control;

your internal/configurable equipment will send to the
next hop, until it reaches that break -- and now it is to
late to take the "other route."

I'm pretty sure the traffic will not get to the next hop
if the VPN-tunnel collapses, the VPN-tunnel only
collapses if the Internet link goes down. If the Internet
link is down the firewall losses it's very short DHCP-
client lease (5 minutes) from the ISP... the firewall's
local IP address would thereby stop working too. So
within 5 minutes the W2k server should not be able not
send any traffic to it.

I'll retry the route settings with the different metric
settings on an other machine, see what happens

 

[Herb Martin]

You have to 1) find a common route "point" where you

CAN make the distinction and 2) the first pathway has to
FAIL cleanly.

The W2k servers on both networks are the common
route "point", unfortunately it does not seem to be able
to tell that the lowest metric route has become non
existent (by turning the routing device off). Is just
adding a second route with a higher metric not sufficient
for w2k server?

I had this problem also -- the cable company router would work
when the cable network had failed so of course my route to the
cable network still "looked good" and we would not fail over to the
DSL network.

Metrics won't help you for this -- except to pick the best FIRST
try (e.g., most reliable).

You could try writing a procedure that pings the upstream routers
periodically and then re-configures the routes if one fails/other works.

I also used a static route to send the obvious "roadrunner" traffic to
the cable and the obvious SWBell traffic through the DSL.