(usr-tc) Which code to run
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) signal@shreve.net 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 "majordomo@xmission.com" 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.
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 ljc1@cornell.edu 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: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
On Thu, 13 Jul 2000 mmm3@cornell.edu wrote:
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 ljc1@cornell.edu 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
********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu **********************************************
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Why do suggest the MTU value 576? I beleive the default 1514. Why the change?
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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Quoting Terry Kennedy <terry@olypen.com>:
Why do suggest the MTU value 576? I beleive the default 1514. Why the change?
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
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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Is there any support for Linux on an Edgeserver? - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Also sprach ved@iyka.com
Quoting Terry Kennedy <terry@olypen.com>:
Why do suggest the MTU value 576? I beleive the default 1514. Why the change?
Windows operating system has issues with higher MTU values, they do not 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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
*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 sagonzal@sky.net.co Senior Network Operations Engineer - SkyNet de Colombia. +57 (1) 6422020 +57 (3) 2277871 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]En nombre de Sergio Gonzalez Enviado el: Jueves, 13 de Julio de 2000 06:20 a.m. Para: usr-tc@lists.xmission.com Asunto: (usr-tc) Quad Modem Add Cost Feature. *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 sagonzal@sky.net.co Senior Network Operations Engineer - SkyNet de Colombia. +57 (1) 6422020 +57 (3) 2277871 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Also sprach Ved
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
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
participants (9)
-
Aaron Nabil -
Brian -
Jeff Mcadams -
Jorge Lozano -
mmm3＠cornell.edu -
Sergio Gonzalez -
Terry Kennedy -
Ved -
ved＠iyka.com