FreeBSD tunnels / performance et'al (gif/tun etc.)
kpielorz at tdx.co.uk
Fri Jan 23 08:42:02 PST 2004
--On 23 January 2004 10:51 -0500 Robert Watson <rwatson at freebsd.org> wrote:
>> I'm just wondering if it was something 'weird' such as the delay over
>> the tunnel being on average 'just the right delay time' to cause
>> problems that you wouldn't get on a LAN or something? :)
> I agree that something sounds weird -- I've had no problem tunneling
> hundreds of megabits using similar hardware to what you're using, and what
> sounds like a similar configuration. So it seems like something is going
> on. Do you have any load information available on the systems -- i.e.,
> interrupt rate as measured by vmstat, cpu usage, etc? Are you using natd
> or other address space translation?
Both systems are dedicated boxes, i.e. they run the tunnel - and nothing
else (no nat, nothing). Load on each was unremarkable, i.e. no excessive
on the hardware that didn't work we were getting about 300 or so interrupts
a second on each network card. After the changes this it rose to about 800
a second per card [as the tunnel performance rose].
We're due to pull the failed machine from the remote end soon - If I get a
chance I'll run it up here - though I don't think it's "flakey
hardware/network card" - as when scp/ftp'ing to that host via either it's
physical address, or tunnel endpoint address we got good performance...
Looking briefly at the tcpdumps - it looks like there were a lot of
duplicated ACK packets being sent from the remote side (which would suggest
they never made it to the other side) - and that would also be a credible
reason for the sessions stalling so badly...
It'd also explain why at the time the 'aggregate' traffic flow on gif0
looked good, but individual machines/IP's were getting really pityful
throughput... I'll see if I can dig out the original tcpdumps [most the
debug stuff usually starts disappearing once the problem is solved,
regardless of how :(]
More information about the freebsd-questions