On Fri, 31 Jan 2003 10:23:37 -0800 (PST), Bill Moran wrote:
> [could you wrap lines around 72 chars or so, please]
Sorry about that.
> >>>After connecting via VPN I can get decent throughput from the MPD
> host but
> >> > very poor speed from anything past it.
> >>What do you mean by this? We use MPD off and on, and (honestly) it
is just slow.
> > From other posts I knew MPD would be slow but what concerns me is
that it is how much slower it is beyond the mpd host itself, see test
> I'm not sure I understand your test results.
> Are you saying
> PPTP client <--> MPD machine <---> "other host"
> If so, is "other host" on the Internet, or on your
> local network?
Other host is on the local network behind the MPD box and transfers
files at a slower rate over the PPtP connection than a transfer from the
MPD box. I also have the 'other host' aliased to a public IP address so
thats how I got the baseline from it.
> We've seen that trying to route through the MPD
> machine to the internet is terribly slow, but
> haven't noticed any problems with routing to the
> local network.
> Did you check the box on the MS side to say
> "use gateway on remote network"?
> >>>A separte public IP is redirected to a 4.7 RELEASE box on the
> >>>Client(s) tested with have been Windows 2000 SP2 and SP3 from 2
> different ADSL Lines.
> >>>client-----220.127.116.11 MPD/NATD 172.16.105.80------172.16.105.66 /
> 18.104.22.168 Redirected from 22.214.171.124
> >>>Tests using Penguinet SCP and a 1.9 MB ZIP file.
> >>>Baseline Download the file from the public IP's
> >>>126.96.36.199 -> client 180 kBs
> >>>188.8.131.52 -> client 180 kBs
> >>>Now test via the PPtP.
172.16.105.80 aka. 184.108.40.206 -> client 84 kBs ****
172.16.105.66 aka. 220.127.116.11 -> client 35 kBs **** These are the results
that don't make sense.
> I see now.
> We haven't tested this extensively. We've only seen it when routing
> into the VPN, just to
> go back out on the Internet (which seemed a silly thing to do).
NO I'm not trying to go back out onto the Internet but could if you
wanted to make sure your remote workers were safe behind your firewall -
but thats a policy/procedure discussion and not for this one :)
> > Actually I used SCP on the second test so as not to skew things, in
> normal operations we won't
> > be. My concern is test to 172.16.105.66. What
> > would make it perform worse than to 172.16.105.80 ? In my mind they
> should be same, like the public IP tests.
> Apparently, something in MPD isn't working as efficiently as it should.
> > It also shows Transmit Errors=0 Receive Errors=xx <- increments at a
> slow rate when connected.
> Ok, now this is something. We need to find out the nature of the
errors and fix it.
> I'm very interested in getting this working better for the same reason
> that you are. I'm going to set up a test network here and see what I
> can figure out. I'll keep in touch with you on my findings if you
agree to do the same.
Certainly, I wonder if Archie Cobbs is out there today :)
Here's a recap,
File downloads to the remote client are much slower from a box(es) on
the same network as the MPD server/Gateway than from the MPD server
MPD server is also running Natd and IPFW in OPEN mode for this testing.
Have adjusted the MTU down to as low as 1350 with no difference in
performance. ng0 does display an MTU of 1350 when the tunnel is up.
Have tried with compression on/off - no change.
On the W2K Network status I see a steady increase on 'Receive Errors'
when the PPtP is up. Transmit errors=0
Could it be something to do with NATd ? Since I'm already behind on this
by 4 days I think I'll do up a test network without NAT and see.
If someone can read a tcpdump I can do one of those too. Let me know
from which box and what options.
Get your FREE personalized e-mail at http://www.canada.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message