Hi,
I have a low cost 128kbps and a high cost 512 kbps link to internet.
Is it possible to do a spillover routing so that the high cost link
is used only when the low cost link is, say, used more than 80%.
I have seen this work in Sonicwall, from it's Manual:
Spillover-Based -- when selected,
From: FUJITA Kazutoshi [EMAIL PROTECTED]
Subject: re(4) can't receive some multicast ?
Date: Fri, 06 Apr 2007 20:01:05 +0900 (JST)
I have ASUS P5B, running FreeBSD 6.2-STABLE.
It has on-board re(4) as follows,
It seems re0 can't receive IPv6 RA message.
But in promisc mode(running tcpdump on
Hi,
There is now a patch here:
http://people.freebsd.org/~gnn/fast_ipv6.20070406.diff
which follows the current state of my radical_ipsec p4 branch.
The patch removes Kame derived IPsec from the tree, and adds v6
support to FAST_IPSEC. The IPSEC kernel option is removed, but the
FAST_IPSEC
[EMAIL PROTECTED] wrote:
The patch removes Kame derived IPsec from the tree, and adds v6
support to FAST_IPSEC. The IPSEC kernel option is removed, but the
FAST_IPSEC option remains. This is a test patch and has a known
problem with routing packets through a node. Nodes can operate in a
host
On Thu, 5 Apr 2007, Jack Vogel wrote:
Our test group uses a script that does 100 iterations of
a module load, then bring up all interfaces, and then
unload driver.
Depending on the system in anything from just a few
iterations to 20 or more, the system will panic.
Just a me too here. :p
I am very close to merging support for RFC 3678 to -CURRENT. I will
make a patch available before I commit.
The only userland consumer in the tree which is likely to be affected by
the removal of ip_multicast_if() from the kernel is routed, which I will
update to use the new
On Fri, Apr 06, 2007 at 04:49:01PM +0200, Ivan Voras wrote:
[EMAIL PROTECTED] wrote:
The patch removes Kame derived IPsec from the tree, and adds v6
support to FAST_IPSEC. The IPSEC kernel option is removed, but the
FAST_IPSEC option remains. This is a test patch and has a known
problem
I'm all for this in principle. I believe that the case for FAST_IPSEC
over KAME IPSEC is fairly clear for those of us who have read the USENIX
paper. Qualitatively speaking I can say FAST_IPSEC has been more
pleasant to work with when introducing the TCP-MD5 support.
I will try to look at the
