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...
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.
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?
b.
-------------------------------------------------------------------------
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/
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/
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/
On Sat, 2008-03-22 at 19:31 +0000, Andrew Suffield wrote:> > 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.Yeah, I had wondered if this is what was going on.> 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 ppp0Ahhh. Very interesting solution. I wonder what says Tom about implementing this one.> You still need to add them all back when the interface returns, so the > problem you describe still exists.Right, but a "shorewall restart" (or restore probably) will do that. I''m OK with having to do a rest{art|ore} on interface up/down events. It''s that currently even that does not work when the ppp0 interface goes down that is my current [b]itch.> You can do that with the params file or with a SHELL directive.Ahh. IIUC, the params file is configured and it''s contents evaluated on the shorewall ("proper" as opposed to the -lite) node, yes? The reality is that I don''t really need to figure out the value of the gateway on the compile node. Deferring it''s evaluation to the execution of "firewall" script on the -lite node at policy installation time is sufficient (and preferred). Can I do that with params? When/where is params evaluated in a -lite context? How does this SHELL directive work in a -lite context? The only information I could find about it is in http://www.shorewall.net/News.htm and the referenced URL in there (http://www.shorewall.net/configuration_file_basics.html#Embedded) doesn''t seem to point to anything about embedding shell (or perl) in config files. On a more generic level, I wonder if this situation is worth flagging to an unsuspecting user. That is, if: * using multiple providers and * one of the providers is a broadcast based network and * the gateway for that provider is configured "detect" and * (probably some other conditions I''m just not thinking of) Warn the user that if any of the providers "goes AWOL", they will lose default routing through the firewall machine. Perhaps even error out. I personally consider this condition a configuration error. Without a default route, my shorewall box is completely unusable. b. ------------------------------------------------------------------------- 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/
On Sat, 2008-03-22 at 14:25 -0500, Jerry Vonau wrote:>See Andrew''s reply on this issue for context on answers below...> 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.I think it''s too late by this time. The interface is gone and the kernel has deleted the routes already.> No, it''s looking for preexisting gateways in the main table which were > removed with the network scripting.I don''t think so. As I said in my original post, I have traced and tracked through the networking scripts and the delete is not being done in userspace by any of them. I believe Andrew''s explanation that the kernel is removing the (multi-hop) default route is spot-on.> So, can''t you use that in params?I''m just experimenting with that, but my experiments are showing that the params file and any variable substitutions into config files (such as "providers") is evaluated at rule (i.e. the "firewall" script) compilation time on the main node. That means the firewall script has the "current" (as of rule compilation time) value hardcoded into it and if the gateway changes after the "firewall" script is generated and copied to the shorewall-lite machine, any future attempt to rest{art,ore} will not work. The value needs to be evaluated/calculated at every policy installation time (i.e. on the -lite machine when a rest{ore,art} is executed).> Third option, fix the network scripts.As per above, it''s not the network scripts that''s causing this problem. b. ------------------------------------------------------------------------- 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/
Brian J. Murrell wrote:> On Sat, 2008-03-22 at 14:25 -0500, Jerry Vonau wrote: >> > > See Andrew''s reply on this issue for context on answers below... > >> 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. > > I think it''s too late by this time. The interface is gone and the > kernel has deleted the routes already. >No it''s not, as per your observations with the providers tables, the remaining (not dead) provider''s table has a usable gateway.>> No, it''s looking for preexisting gateways in the main table which were >> removed with the network scripting. > > I don''t think so. As I said in my original post, I have traced and > tracked through the networking scripts and the delete is not being done > in userspace by any of them. I believe Andrew''s explanation that the > kernel is removing the (multi-hop) default route is spot-on. >Doing an "ip addr flush dev DEV" leaves the multi-hop default gateway, if that interface has one and tags the gateway as dead. Same for /sbin/ifdown DEV. This is with network cards and not pppd, might be pppd''s code that is causing your headaches. I''ll dig around and see what I can find for pppd... 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/
On Sat, Mar 22, 2008 at 04:22:40PM -0500, Jerry Vonau wrote:> >> No, it''s looking for preexisting gateways in the main table which were > >> removed with the network scripting. > > > > I don''t think so. As I said in my original post, I have traced and > > tracked through the networking scripts and the delete is not being done > > in userspace by any of them. I believe Andrew''s explanation that the > > kernel is removing the (multi-hop) default route is spot-on. > > > Doing an "ip addr flush dev DEV" leaves the multi-hop default gateway, > if that interface has one and tags the gateway as dead. Same for > /sbin/ifdown DEV. This is with network cards and not pppd, might be > pppd''s code that is causing your headaches. I''ll dig around and see > what I can find for pppd...Wrong behaviour. You''re looking at removal of the *address*. The special thing about ppp connections is that the entire ppp0 interface goes away. Try rmmodding the driver for your network card driver and see what happens. The routing table can accept a default route with an incorrect address, but it can''t accept a route to a device that doesn''t exist any more, since that would be a dangling pointer. ------------------------------------------------------------------------- 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/
Andrew Suffield wrote:> On Sat, Mar 22, 2008 at 04:22:40PM -0500, Jerry Vonau wrote: >>>> No, it''s looking for preexisting gateways in the main table which were >>>> removed with the network scripting. >>> I don''t think so. As I said in my original post, I have traced and >>> tracked through the networking scripts and the delete is not being done >>> in userspace by any of them. I believe Andrew''s explanation that the >>> kernel is removing the (multi-hop) default route is spot-on. >>> >> Doing an "ip addr flush dev DEV" leaves the multi-hop default gateway, >> if that interface has one and tags the gateway as dead. Same for >> /sbin/ifdown DEV. This is with network cards and not pppd, might be >> pppd''s code that is causing your headaches. I''ll dig around and see >> what I can find for pppd... > > Wrong behaviour. You''re looking at removal of the *address*. The > special thing about ppp connections is that the entire ppp0 interface > goes away. > > Try rmmodding the driver for your network card driver and see what > happens. The routing table can accept a default route with an > incorrect address, but it can''t accept a route to a device that > doesn''t exist any more, since that would be a dangling pointer.Thanks, I see what you mean.... So then I guess the only workaround is to use ppp''s ip-down to replace the missing gateway. 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/
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 >> default via 67.193.44.1 dev eth0.1 >> default via 192.168.200.1 dev ppp0 > > Ahhh. Very interesting solution. I wonder what says Tom about > implementing this one.Most systems won''t allow two default routes with the same metric. Ubuntu systems create the default route at metric 100. So Shorewall doesn''t replace it -- the Shorewall added default route is simply added in front of it. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
On Sat, Mar 22, 2008 at 04:00:40PM -0700, Tom Eastep wrote:> 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 >>> default via 67.193.44.1 dev eth0.1 default via 192.168.200.1 dev ppp0 >> >> Ahhh. Very interesting solution. I wonder what says Tom about >> implementing this one. > > Most systems won''t allow two default routes with the same metric.Right, sorry, you need to stuff metrics in those rules as well. The basic principle works, the syntax might need tweaking. (Although it would be better fixed by teaching the kernel how to degrade nexthop routes rather than delete them outright)> Ubuntu systems create the default route at metric 100. So Shorewall > doesn''t replace it -- the Shorewall added default route is simply added > in front of it.Which raises the question of why that isn''t working here. ------------------------------------------------------------------------- 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/
Andrew Suffield wrote:> > Which raises the question of why that isn''t working here.Can''t imagine -- works here. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
On Sat, 2008-03-22 at 16:00 -0700, Tom Eastep wrote:> > Most systems won''t allow two default routes with the same metric.So for only two providers, this could work. Two standard default routes at meterics 100 and (say) 101 and then the nexthop routing before that. When the ppp0 interface goes down the nexthop routing goes away and so does one of the default routes leaving you with one. Doesn''t work for >2 providers though. And it really seems to me that having shorewall replumb the routing with the missing interface is more like the right thing to do. And! That does work. I have a small very hackish hack here that proves to work very well: --- /usr/share/shorewall-perl/Shorewall/Providers.pm.dist 2008-03-22 15:01:20.000000000 -0400 +++ /usr/share/shorewall-perl/Shorewall/Providers.pm 2008-03-22 15:17:30.000000000 -0400 @@ -197,9 +197,14 @@ fatal_error ''A non-empty COPY column requires that a routing table be specified in the DUPLICATE column'' if $copy ne ''-''; } - if ( $gateway eq ''detect'' ) { + if ( $gateway eq ''detect'' || $gateway =~ /^\$\(.+\)/ ) { my $variable = get_interface_address $interface; - emit ( "gateway=\$(detect_gateway $interface)\n", + my $gw_detect = "detect_gateway $interface"; + if ( $gateway =~ /^\$\((.+)\)/ ) { + $gw_detect = $1; + $gw_detect =~ s/_/ /g; + } + emit ( "gateway=\$($gw_detect)\n", ''if [ -n "$gateway" ]; then'', " run_ip route replace $variable dev $interface table $number", " run_ip route add default via \$gateway dev $interface table $number", and providers configuration of: CGCO 1 64 main eth0.1 $(uci_get_/var/state/network.wan0.gateway) track,balance,optional br-lan,tun0 IGS 2 128 main ppp0 detect track,balance,optional br-lan,tun0 The "s/_/ /g" ugliness has to do with what''s allowed and what''s not in a configuration file. Indeed, I could replace the $(uci ...) shenanigans with a params variable, but as I''ve mentioned before, it appears that params are evaluated at compile time and not policy rest{art,ore} time so the ability to shorewall-lite rest{art,ore} will actually fail if the gateway of the interface changes after the firewall script is compiled. So, now that I think about it, this usability issue has morphed from that of the default gateways getting lost when an interface goes down (because that is solvable but for ...) into one of not being able to define parameters that are evaluated at policy installation time. There seems to be some indication that the "init" script is a kind of params that is run exclusively on the shorewall-lite system but having looked at the firewall script and how the whole gateway detection and addition code works, I cannot see how setting a variable in the init file is going to propagate into that code in the firewall script on the -lite machine. Am I wrong? b. ------------------------------------------------------------------------- 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/
On Sat, Mar 22, 2008 at 11:25:23PM -0400, Brian J. Murrell wrote:> On Sat, 2008-03-22 at 16:00 -0700, Tom Eastep wrote: > > > > Most systems won''t allow two default routes with the same metric. > > So for only two providers, this could work. Two standard default routes > at meterics 100 and (say) 101 and then the nexthop routing before that. > When the ppp0 interface goes down the nexthop routing goes away and so > does one of the default routes leaving you with one. > > Doesn''t work for >2 providers though.It does, but there''s a factorial explosion in the number of rules required (you stack up a 3-way route first, then three 2-way routes, etcetera). The right solution is to teach the kernel to trim down nexthop rules when it loses interfaces, rather than deleting them outright. As usual, the right solution is a pain to implement. ------------------------------------------------------------------------- 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/
On Sun, 2008-03-23 at 05:36 +0000, Andrew Suffield wrote:> > It does, but there''s a factorial explosion in the number of rules > required (you stack up a 3-way route first, then three 2-way routes, > etcetera). The right solution is to teach the kernel to trim down > nexthop rules when it loses interfaces, rather than deleting them > outright. As usual, the right solution is a pain to implement.It''s not even that. As has been observed, you cannot have multiple default routes at the same cost, so once the nexthop routing goes away you effectively have only one default route, whichever one was installed with the lowest cost. b. ------------------------------------------------------------------------- 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/
Brian J. Murrell wrote:> > So, now that I think about it, this usability issue has morphed from > that of the default gateways getting lost when an interface goes down > (because that is solvable but for ...) into one of not being able to > define parameters that are evaluated at policy installation time.> A capability for ''run-time variables'' is something that I''ve thought about but haven''t gotten around to implementing yet.> > There seems to be some indication that the "init" script is a kind of > params that is run exclusively on the shorewall-lite system but having > looked at the firewall script and how the whole gateway detection and > addition code works, I cannot see how setting a variable in the init > file is going to propagate into that code in the firewall script on the > -lite machine. Am I wrong?No. In 4.1.7, you will be able to set a variable <interface>_GATEWAY in your init script where <interface> is the interface name in upper case and with those characters not allowed in shell variable names replaced by "_". So, for example, the gateway variable for eth0.1 is ETH0_1_GATEWAY. If that variable is non-empty then the generated default-route logic will use its contents -- otherwise, an attempt will be made to detect the gateway using the contents of the main routing table as is done today. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
Brian J. Murrell wrote:> On Sun, 2008-03-23 at 05:36 +0000, Andrew Suffield wrote: >> It does, but there''s a factorial explosion in the number of rules >> required (you stack up a 3-way route first, then three 2-way routes, >> etcetera). The right solution is to teach the kernel to trim down >> nexthop rules when it loses interfaces, rather than deleting them >> outright. As usual, the right solution is a pain to implement. > > It''s not even that. As has been observed, you cannot have multiple > default routes at the same cost, so once the nexthop routing goes away > you effectively have only one default route, whichever one was installed > with the lowest cost.For single line-failure tolerance, only N+1 routes are needed; the N-way, followed by N (N-1)-ways. After a single-line failure, there will only be one route remaining; the one that omitted the failed line. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
Tom Eastep wrote:> > For single line-failure tolerance, only N+1 routes are needed; the > N-way, followed by N (N-1)-ways. After a single-line failure, there will > only be one route remaining; the one that omitted the failed line. >But I would rather see this fixed correctly rather than hacking around it in Shorewall. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/