|Subject:||Re: Failover from VPN|
|From:||errzyy3i,AT,umail,DOT,furryterror,DOT,org (Zygo Blaxell)|
|Date:||Wed, 7 Mar 2001 00:27:24 +0100|
In article <3AA2FCA9.2050903,AT,yahoo,DOT,com>, R. Steve McKown <rsmckown,AT,yahoo,DOT,com> wrote: >I'm looking to provide a way to backup a failed CIPE link using dialup >PPP (or more generally any other network link). My thoughts on an >initial solution has limitations I'm not sure are workable with CIPE. >Would anyone be willing to comment on how to make this solution work, or >propose an alternative? I do this using policy routing. See the 'iproute' package for details. The basic setup is to have three routing tables: the normal one, one for traffic coming from your CIPE link's virtual address, and one for local LAN traffic. Something like this: # Setup: 10.0.0.0/8 is a local LAN (optional). # 126.96.36.199/24 is a LAN on the other side of CIPE # 188.8.131.52 is the ipaddr of CIPE # 184.108.40.206 is the ptpaddr of CIPE # PPP IP is dynamic, but guaranteed not on 220.127.116.11/24 # and not on subnet 10.0.0.0/8 # Use policy routing to isolate the local traffic ip rule pref 100 to 10.0.0.0/8 lookup main # If the packet is definitely FROM the CIPE interface IP, # then send it via lookup table 10 (see below). ip rule pref 200 from 18.104.22.168 lookup 10 # All the other routes are normal routes which can be # created using the normal 'route' command. # The aforementioned special route for CIPE: ip route add 22.214.171.124/24 dev cipcb0 table 10 # Always put this command at the end for changes to take effect ip route flush cache Note that in this setup, the PPP link must _not_ have the same IP addresses as the CIPE link. Actually, if anything, both ends of the PPP link should have the respective addresses of the Internet-connected interfaces of the two peer hosts. In other words, you always route through the CIPE link, preferably without having to change either peer address, but you use PPP to act as a backup for whatever you're currently using as a carrier network for CIPE. To control the routes, you adjust the default route through the main routing table. When you have connectivity via CIPE, you do route del default route add default gw 126.96.36.199 (or, if you prefer ipchains) ip route replace default via 188.8.131.52 table main When you don't have connectivity via CIPE, you bring up PPP and do the opposite: ip route replace default via (PPP peer here) table main or route del default pppd defaultroute call foo... To test network connectivity through CIPE, you use the 'source address' or 'interface address' ping option to force the outgoing packet to be sent via CIPE without regard to the default route of the main routing table. >Where I get hung up is starting the tunnel. The routes appear to get >created as soon as the CIPE device is initialized and before any traffic >passes through it. The failover solution really needs to have CIPE >bring up the routes through the tunnel _after_ it has verified traffic >can pass through the tunnel. That way, packets are routed toward the >CIPE device only when there is someplace for them to go -- otherwise >they take the backup path. This is most obvious when the link is >failing, most likely due to a network link problem. One wants CIPE to >continue to periodically attempt to initialize the tunnel, but not >override the working backup route(s) until the tunnel has been shown to >successfully pass traffic. Another idea which might help you is to consider that the CIPE ptpaddr can be any IP address, not necessarily the primary IP address of the peer. You could say: ciped -o ... ptpaddr=184.108.40.206 then use another script to explicitly adjust the route to the real CIPE ptp address after verifying the integrity of the CIPE connection. ---- A variation on this would be to use the ip-up script to _remove_ the route to the CIPE peer when the tunnel comes up. You can always add it again later after verifying that it works. ---- Another variation on this would be to configure the CIPE peer to have an extra IP address which is reachable only via CIPE. So on one peer: ifconfig dummy0 220.127.116.11 netmask 255.255.255.255 while on the other peer: ciped -o ... ptpaddr=18.104.22.168 Then you can test the CIPE link with: ping 22.214.171.124 This of course only works if there is no route for 126.96.36.199 through PPP... >Any way to make this work? Are there better and/or workable alternatives?
Description: "PGP signature"