Brian J. Murrell wrote: > I'm using shorewall[-lite] 4.0.5 on an OpenWRT Kamikaze(ish) platform. > As you all probably already know, I have multiple ISP uplinks. One is > DHCP based and the other PPP[oE] based. I also use track and balance on > both interfaces and do some tc based routing. > > I'm finding an interesting phenomena with this set up. If the PPPoE > connection ever drops, my weighted default route(s) go away. To > illustrate, before a PPP line drop I have: > > default > nexthop via 67.193.44.1 dev eth0.1 weight 1 > nexthop via 192.168.200.1 dev ppp0 weight 1 > > Which is about right for a track and balanced MultiISP Shorewall > configuration. > > 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. Additionally, > OpenWRT has a config switch one can use to prevent default route > updating and I have that selected and for good measure I added > "nodefaultroute" to the /etc/ppp/options file. > > Most of the above is really an aside to a real problem and could > probably be worked around by simply executing > an /etc/init.d/shorewall-lite restart on an interface down event. > Except... and here is the real bug... > In /etc/ppp/ip-down(.local) you could source the other provider's routing table, replace the default gateway in the main table with such info, adjust routing rules if required and flush the routing tables.
> Now that the (weighted) default route(s) entry is gone, shorewall-lite > can't figure out how to restore them (when the providers table specifies > "detect" for GATEWAY) because it (apparently) consults the routing table > to find the default route for DHCP (or more accurately, broadcast > network) interfaces. > No, it's looking for preexisting gateways in the main table which were removed with the network scripting. > 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. > > 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. > > Thots? > So, can't you use that in params? Third option, fix the network scripts. Jerry ------------------------------------------------------------------------- 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 Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
