[vortex] Problems with Redhat 7.1 and 3c095c

[Bill MacAllister]

--On Monday, October 15, 2001 11:29 AM -0400 Donald Becker <becker@scyld.com> 
wrote:

> On Sun, 14 Oct 2001 ruben@nutz.nl wrote:
>> On Sun, Oct 14, 2001 at 02:21:07AM -0700, Bill MacAllister wrote:
>> > In some notes that I read about setting up ADSL a problem with mentioned
>> > with an MTU setting of 1500 and passing packets over PPP.  Basically, all
>> > packets were getting fragmented into a big and small packet.  The solution
>> > was to drop the MTU.  I tried it and that has fixed the problem that I was
>> > seeing.  So, in the end it was the network.
>>
>> Which is why I kept insisting on knowing details about your ipchains/tables
>> config. If you block ICMP_FRAG_NEEDED-packets you'll effectively disable the
>> mechanism IP uses to find the lowest MTU on a link, the MTU-path-discovery.

Well, if you asked me about ipchains/tables it never got to you.  Indeed, on 
this system I have them turned off.

> Yes, that's very likely what was happening.
>
>> will run into problems. 'Normal' ethernet MTU is 1500 bytes, but after
>> encapsulating in PPPoE you have only 1454 bytes left.
>
> Note: PPPoE only takes about 8 bytes, not 46.  So a static mtu=1492 will
> usually avoid the problem.

It really is a bit messier than this.  I actually tried 1492 and it didn't 
work.   I then got drastic and dropped it to 512 and I ended up with steady 
transfer rates of large files.  I bumped it back up to 1000 and it still seems 
to be holding out okay.

The culprit are the ISDN boxes in the network path.  It is an Ascend Pipe50 at 
my end and a Ascend Max1800 at the far end.  They talk a protocol called MPP to 
each other and will initiate a second call when traffic warrants it.  I suspect 
that it is the second call that is causing the problem because transfers would 
start fine and then bog down.  Of course, it could be the Max1800 at the far 
end that is responsible for the whole mess.  It is so under powered that if you 
plug in half the number of BRI's that the spec's say it supports it is really 
difficult to get it to boot at all.

Thanks for you ear,

Bill


+------------------------------------------------------------
| Bill MacAllister
| 14219 Auburn Road
| Grass Valley, CA  95949
| +1 530.272.8555

>
> Donald Becker				becker@scyld.com
> Scyld Computing Corporation		http://www.scyld.com
> 410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
> Annapolis MD 21403			410-990-9993
>
>
> _______________________________________________
> vortex mailing list
> vortex@scyld.com
> http://www.scyld.com/mailman/listinfo/vortex