Re: [Shorewall-users] default route(r,s}

On Sun, 2008-03-23 at 05:36 +, 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 i

Re: [Shorewall-users] default route(r,s}

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

Re: [Shorewall-users] default route(r,s}

Brian J. Murrell wrote: On Sun, 2008-03-23 at 05:36 +, 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

Re: [Shorewall-users] default route(r,s}

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

[Shorewall-users] remember "large" connections?

I want to let connections start out unrestricted, but then demote any that become very large to a low priority traffic shaping class. Demoting all "large" transfers seems much simpler than trying to identify every single kind of P2P, video, audio, etc. How can I do this? If I can't do it through S

Re: [Shorewall-users] remember "large" connections?

Chuck Kollars wrote: I want to let connections start out unrestricted, but then demote any that become very large to a low priority traffic shaping class. Demoting all "large" transfers seems much simpler than trying to identify every single kind of P2P, video, audio, etc. How can I do this? Wa

[Shorewall-users] HA routing monitor

I know that Tom has expressed before his reluctance for Shorewall to get deeper into the routing management game, but the reality is that complex routing (i.e. shaping, etc.) and firewalling go hand-in-hand, hence the routing control that is already in Shorewall. I wonder how well the possibility

Re: [Shorewall-users] HA routing monitor

Brian J. Murrell wrote: It's not a terribly difficult thing to do, an a small script can do it, indeed, but it would just be so much nicer to have such a thing packaged as a part of a project rather than having everyone cobble up their own, and Shorewall already has the MultiISP (i.e. providers

Re: [Shorewall-users] HA routing monitor

On Sun, Mar 23, 2008 at 06:09:58PM -0400, Brian J. Murrell wrote: > I wonder how well the possibility of Shorewall supplying a HA routing > monitor would be received. I don't know of any other packages out there > supplying such a thing and it's almost too small a task to support a > whole project

[Shorewall-users] Shorewall and xen

This is not my first setup of Shorewall, but first involving XEN Trying to implement FW at routed Dom0. I did not find similar problem in the FAQ or mailing list, but if somebody knows similar thread let me know. My setup is following ISP--non routed--(eth0)x.x.x.173 FW--LAN(eth1)10.10.0.2 ---

Re: [Shorewall-users] Shorewall and xen

Hristo Benev wrote: This is not my first setup of Shorewall, but first involving XEN Trying to implement FW at routed Dom0. I did not find similar problem in the FAQ or mailing list, but if somebody knows similar thread let me know. My setup is following ISP--non routed--(eth0)x.x.x.173 FW--