I'm trying to run an IPsec tunnel between a Linux router and a FreeBSD
router, but the FreeBSD router isn't passing any of the IPv6 traffic
(IPv4 works perfectly). I have the following in /etc/ipsec.conf:
spdadd 10.1.0.0/2110.2.2.0/24 any -P out ipsec
esp/tunnel/192.0.2.1-192.0.2.2/r
On Tue, 12 Feb 2013, John Nielsen wrote:
On Feb 9, 2013, at 5:02 PM, Ronald F. Guilmette wrote:
P.S. While I appreciate all the friendly advice people here have given
me, i.e. to go with a card based around some non-Realtek chip, I have to
say that up until now I have always and consistantly
Since it deserved recognition, here's the bit from if_rl.c that John is
referring to:
* The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
* probably the worst PCI ethernet controller ever made, with the possible
* exception of the FEAST chip made by SMC. The 8139 supports bus
On Feb 9, 2013, at 5:02 PM, Ronald F. Guilmette wrote:
> P.S. While I appreciate all the friendly advice people here have given
> me, i.e. to go with a card based around some non-Realtek chip, I have to
> say that up until now I have always and consistantly had -zero- problems
> with the many ot
Hello list,
on a FreeBSD 8.3-RELEASE-p3, I have come across a problem with lacp
protocol on a lagg interface. I have aggregated two interfaces with the
same speed but slightly different type of media (namely 10Gbase-SR and
10Gbase-LR). There is a Cisco switch on the other side.
LACP won't work as
On Feb 12, 2013, at 11:06 AM, Ivan Voras wrote:
> On 12/02/2013 18:57, Ivan Voras wrote:
>> On 12/02/2013 18:52, Freddie Cash wrote:
>>> Any reason you can't just use lagg(4) in one of the non-LACP modes? That's
>>> bascially designed to do exactly what you want.
>>
>> No particular reason, I'
On 12/02/2013 19:10, Eggert, Lars wrote:
> Hi,
>
> On Feb 12, 2013, at 9:50, Ivan Voras wrote:
>>> You can make this work with ipfw rules (and I guess also setfib, although I
>>> have not tried that.)
>>
>> The concept of FIBs looks clean and applicable but setfib works on newly
>> started proce
Hi,
On Feb 12, 2013, at 9:50, Ivan Voras wrote:
>> You can make this work with ipfw rules (and I guess also setfib, although I
>> have not tried that.)
>
> The concept of FIBs looks clean and applicable but setfib works on newly
> started process, and I would need to do something like apply it
On Feb 12, 2013, at 7:06 PM, Ivan Voras wrote:
> On 12/02/2013 18:57, Ivan Voras wrote:
>> On 12/02/2013 18:52, Freddie Cash wrote:
>>> Any reason you can't just use lagg(4) in one of the non-LACP modes? That's
>>> bascially designed to do exactly what you want.
>>
>> No particular reason, I'm
On 12/02/2013 18:57, Ivan Voras wrote:
> On 12/02/2013 18:52, Freddie Cash wrote:
>> Any reason you can't just use lagg(4) in one of the non-LACP modes? That's
>> bascially designed to do exactly what you want.
>
> No particular reason, I'm just not familiar enough with it. Will e.g.
> the "loadb
On 12/02/2013 18:52, Freddie Cash wrote:
> Any reason you can't just use lagg(4) in one of the non-LACP modes? That's
> bascially designed to do exactly what you want.
No particular reason, I'm just not familiar enough with it. Will e.g.
the "loadbalance" mode "just work" ? Should I expect any pr
Any reason you can't just use lagg(4) in one of the non-LACP modes? That's
bascially designed to do exactly what you want.
On Tue, Feb 12, 2013 at 9:50 AM, Ivan Voras wrote:
> On 12/02/2013 18:38, Eggert, Lars wrote:
>
> > This sounds like your default route is going via igb2.
>
> Yes, it is.
On 12/02/2013 18:38, Eggert, Lars wrote:
> This sounds like your default route is going via igb2.
Yes, it is.
> You can make this work with ipfw rules (and I guess also setfib, although I
> have not tried that.)
The concept of FIBs looks clean and applicable but setfib works on newly
started p
Hi,
On Feb 12, 2013, at 9:32, Ivan Voras wrote:
> I have a machine with two interfaces, igb2 and igb3 on the same subnet
> but with different IP addresses, e.g. igb2 has 192.168.1.221, igb3 has
> 192.168.1.222. Firstly, is there anything which would preclude this from
> working? As I see it, thes
Hello,
I have a machine with two interfaces, igb2 and igb3 on the same subnet
but with different IP addresses, e.g. igb2 has 192.168.1.221, igb3 has
192.168.1.222. Firstly, is there anything which would preclude this from
working? As I see it, these are two different MAC addresses and to the
outsi
Hello,
I'm trying to add NAT-traversal support on FreeBSD to the portable
version of OpenBSD's IKEv2 daemon, openiked. See http://openiked.org/
for more. My NAT-T branch is called "natt" and lives here:
http://github.com/mchackorg/openiked/
It seems to work, but only one way. The receiving node d
On 11.02.2013 19:56, Adrian Chadd wrote:
On 11 February 2013 03:18, Andre Oppermann wrote:
In general Google does provide quite a bit of data with their experiments
showing that it isn't harmful and that it helps the case.
Smaller RTO (1s) has become a RFC so there was very broad consensus in
On 12.02.2013 11:55, Andrey Zonov wrote:
On 2/11/13 3:18 PM, Andre Oppermann wrote:
Smaller RTO (1s) has become a RFC so there was very broad consensus in
TCPM that is a good thing. We don't have it yet because we were not fully
compliant in one case (loss of first segment). I've fixed that a
The following reply was made to PR kern/173475; it has been noted by GNATS.
From: Ralf Wenk
To: Emanuel Haupt
Cc: bug-follo...@freebsd.org
Subject: Re: kern/173475: [tun] tun(4) stays opened by PID after process is
terminated
Date: Tue, 12 Feb 2013 12:27:12 +0100
> Could you please try the f
On 2/11/13 3:18 PM, Andre Oppermann wrote:
>
> Smaller RTO (1s) has become a RFC so there was very broad consensus in
> TCPM that is a good thing. We don't have it yet because we were not fully
> compliant in one case (loss of first segment). I've fixed that a while
> back and will bring 1s RTO
20 matches
Mail list logo
