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
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
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
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
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
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
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
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
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
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
---
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--
11 matches
Mail list logo