Subject: (usr-tc) Which code to run

From: Brian <[email-masked]>
Date: Wed, 12 Jul 2000 17:15:48 +0000

Nello all!

It has been a while since I have participated on this list, I have been
very busy, hopefully I will be more active once again.  I have a few
questions.  Right now, and for the longest time, we are running:

ARC: 4.1.22
HDM: 2.0.51

What seems to be the general concensus on what the latest very stable code
is to run?  We aren't using OSPF yet (becuase it was never stable enough
in past releases), but would be very interested in doing so, if we could
at leat gain that.  Also would be interested in gaining more compatibility
with modems if the dsp code is indeed better code.

Brian

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: [email-masked]
Date: Thu, 13 Jul 2000 18:43:41 +0000

This is one for the books, definitely.

Here's the setup:

Total control chassis
Card			Firmware	Hardware
One dual PRI card	3.1.5		4.0.0
12 digiquad modem cards	6.1.6		2.0.0
2 DSP cards		2.0.51		0.52.0
1 ARC			4.1.59		19.0.0
1 HiPerNMC		6.2.17		2.0
2 PSUs

We are having trouble downloading one particular file through this 
chassis and ONLY this chassis. I have checked and re-checked the 
settings and the ONLY thing different on this chassis is a 15-minute 
session limit and the Carrier Loss Detect Delay is set to 2 seconds. 
The file will consistently download to 69 or 72%, then the connection 
to the server dies; however, the modem connection remains viable. I 
am absolutely stumped. I've doubled the MTU size and swapped the ARC 
so far. Any clues? If you reply off-list, please cc [email-masked] 
as I will be on vacation and checking email sporadically.

*********************************************************
Michelle M. Mogil
Network and Computing Systems
735 Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8521
email: [email-masked]
**********************************************

-

---

From: Ved <[email-masked]>
Date: Thu, 13 Jul 2000 19:40:07 +0000

> as I will be on vacation and checking email sporadically.

Are you having this problem appear both on the quad and the HiPerDSP?
Increasing the MTU size is not a good thing.  I would suggest that you set
the MTU on the HiPer arc to 576 and do not change anything on the client
side.  This should fix the issue.  Also if this problem is only on the
Quad or the DSP alone then check your PPP settings on the ARC - you want
to see if PPP on the modem is enabled or disabled.  Disable the PPP on the
modem and try your download again with mtu set to 576.

-V

-

---

From: Terry Kennedy <[email-masked]>
Date: Thu, 13 Jul 2000 23:26:16 +0000

Why do suggest the MTU value 576? I beleive the default 1514. Why the
change?

-

---

From: Sergio Gonzalez <[email-masked]>
Date: Thu, 13 Jul 2000 23:26:27 +0000

*This message was transferred with a trial version of CommuniGate(tm) Pro*
Hi there, I got a little question. How do I enable the V.90 Add cost
feature in Analog/digital Quad Modem card that are managed by a
Netserver 16?

Thanks a lot in advance.

/Sergio
-- 
Sergio Gonzalez
Calle 100 #8A-55 Torre C oficina 711 
[email-masked]
Senior Network Operations Engineer - SkyNet de Colombia.
+57 (1) 6422020
+57 (3) 2277871

-

---

From: Jorge Lozano <[email-masked]>
Date: Fri, 14 Jul 2000 00:07:21 +0000

Sergio,
in order to enable the V.90 feature take a look in the followong page:

http://totalservice.usr.com/56k/totalcontrol.html

Regards,

Jorge Lozano

-----Mensaje original-----
De: [email-masked]
[mailto:[email-masked]]En nombre de Sergio Gonzalez
Enviado el: Jueves, 13 de Julio de 2000 06:20 a.m.
Para: [email-masked]
Asunto: (usr-tc) Quad Modem Add Cost Feature.

Thanks a lot in advance.

/Sergio

-

-

---

From: [email-masked]
Date: Fri, 14 Jul 2000 01:23:45 +0000

> Why do suggest the MTU value 576? I beleive the default 1514. Why the
Windows operating system has issues with higher MTU values, they do not 
negotiate MTU properlly.  Win 2000 does have a fix for this.  For most 
applications it does not matter.  Where it matters is how the packet when sent 
from the server to the host changes or how its fragmented.  By setting a lower 
MTU, you are forcing the sending end to fragment the packet.  

-V

-

---

From: Aaron Nabil <[email-masked]>
Date: Sat, 15 Jul 2000 08:36:28 +0000

Is there any support for Linux on an Edgeserver?

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sat, 15 Jul 2000 15:43:42 +0000

Also sprach Ved
>the MTU on the HiPer arc to 576 

You probably really *don't* want to do this.  With Path MTU Discovery
being as flaky as it is on today's Internet, dropping the MTU in the
middle or the end of an end to end Internet path is not a Good Thing.

What you probably want to do is set the MRU setting on the Arc to
576...but since I don't know if there's any mechanism to actually do
that (I don't see a Framed-MRU value in RADIUS, and if you're getting
authentication through PAP or CHAP, that would be too late anyway), you
may just have to diddle with the registry on the windows machines to
drop it down...not fun, I know.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sat, 15 Jul 2000 15:47:08 +0000

Also sprach [email-masked]
 
>negotiate MTU properlly.  

OK...let's clarify here...'cause I'm not sure.

Does windows have problem with *sending* or *receiving* large packets
(or both?)

The reason that I ask is that you seem to be using "MTU" for both
sending and receiving packets.  Keep in mind that "MTU" means "Maximum
Transmission Unit", meaning that its the largest size packet that the
host will *send*...it has nothing to do with how large of a packet that
the host is willing and able to receive.  You could easily have a host
with an MTU of 276 that is still willing and able to receive packets of
size 1500.

>By setting a lower MTU, you are forcing the sending end to fragment the
>packet.  

Yeah, and with PMTUD being a crap-shoot at best on the Internet, forcing
the sending end to fragment the packet is a crap-shoot at best.

What if the sending server is behind a LocalDirector or some other load
balancing device...all of a sudden, PMTUD doesn't work and you're client
on that connection can't transfer any data from that site.  So sorry.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-