<< | Thread Index | >> ]    [ << | Date Index | >> ]

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-reply-to: <3AA2FCA9.2050903@yahoo.com>

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: is a local LAN (optional).

        # is a LAN on the other side of CIPE

        # is the ipaddr of CIPE
        # is the ptpaddr of CIPE

        # PPP IP is dynamic, but guaranteed not on
        #       and not on subnet

        # Use policy routing to isolate the local traffic
        ip rule pref 100 to 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 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 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

(or, if you prefer ipchains)

        ip route replace default via table main

When you don't have connectivity via CIPE, you bring up PPP and do the

        ip route replace default via (PPP peer here) table main


        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=

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 netmask

while on the other peer:

        ciped -o ... ptpaddr=

Then you can test the CIPE link with:


This of course only works if there is no route for through

>Any way to make this work?  Are there better and/or workable alternatives?

Attachment: pgp00000.pgp
Description: "PGP signature"

<< | Thread Index | >> ]    [ << | Date Index | >> ]