On Sat, Mar 22, 2008 at 02:42:32PM -0400, Brian J. Murrell wrote:
> default
> nexthop via 67.193.44.1 dev eth0.1 weight 1
> nexthop via 192.168.200.1 dev ppp0 weight 1
>
> However, if I go pull the phone plug on the PPPoE interface the result
> is that I have no default route at all. I suspected that somewhere some
> script was doing a "route delete default ..." because of the PPPoE
> interface down event but I've been through the whole process of scripts
> that get called on this event and there is no such event.
The kernel deletes routes that have become invalid because the
interface has gone away, and ppp interfaces disappear when the link is
lost. As a rule, if it wouldn't let you add the route at this point,
it won't let you keep it either - I haven't checked that this still
applies to nexthop routes, but I expect it does. Since default/nexthop
rules are just one rule, and this one references the now-deceased
ppp0, it should get removed.
> Two (well, only one really workable) solutions come to mind. The first
> is only a solution if the default gateway has been set up already once,
> before the main table is copied to the providers tables. If this is
> true, then the provider table can be consulted for the default route.
> Even with no (weighted or otherwise) default routes in my main table, my
> provider table still shows:
>
> default via 67.193.44.1 dev eth0.1
>
> This seems to me like it will not always work -- i.e. if the provider
> table is not set up yet, etc.
A variation on this theme would eliminate the failure when one
interface goes away. If the last three entries in the routing table
are these:
default
nexthop via 67.193.44.1 dev eth0.1 weight 1
nexthop via 192.168.200.1 dev ppp0 weight 1
default via 67.193.44.1 dev eth0.1
default via 192.168.200.1 dev ppp0
Then normally the kernel will always hit the first one and stop, but
after two of them have been deleted by a vanished ppp0 interface then
you'll be left with just:
default via 67.193.44.1 dev eth0.1
You still need to add them all back when the interface returns, so the
problem you describe still exists.
> The second solution seems to be to allow a specification other than
> "detect" for the gateway that somehow still results in shorewall[-lite]
> figuring it out. Perhaps a (i.e. shell) code fragment can be used
> instead of "detect" that results in the gateway's IP address.
>
> On OpenWRT (Kamikaze) for example I can do:
>
> # uci get "/var/state/network.wan0.gateway"
> 67.193.44.1
>
> To get the gateway's address.
You can do that with the params file or with a SHELL directive.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
