asp@uunet.UU.NET (Andrew Partan) (12/08/90)
We switched from 8.0(6) to 8.1(14) about 6 months ago and have been
having serial line problems on 1 T1 ever since. This was a T1 that had
been working just fine for over a year prior to this.
We first thought that it was a serial line problem or perhaps bad
boards or bad CSU/DSUs, but we have done the following since:
- reterminate both ends of the T1
- had the local phone company give us a brand new T1
- swapped *every* cable and interface and board on each end
- installed a brand new cisco at each end
- swapped CSU/DSUs (both the same type and to a different
manufacturor)
- upgraded to 8.1(19) or to 8.1(25)
- tried different switch settings on the CSU/DSUs
- basically swapped every piece of hardware or software that we
can find.
All to *no* avail - we are still getting errors - to the tune of 100 -
1000 (nearly) *every* 5 minutes. Most of these error are cisco abort
errors.
The only thing 'special' about this T1 (different from other T1s
attached to the same cisco or elsewhere in our network) is that this T1
is the most used - about 200K almost all of the time.
cisco has been of little or no real help. They keep on saying that it
must be either the T1 or the CSU/DSUs. [The only bug report number
that has ever been given to me by cisco for this problem is 901120235.
I almost never get a number for any of the calls that I make.]
Does anyone have any suggestions? Or have similar problems?
Thanks,
--asp@uunet.uu.net (Andrew Partan)
ASN.1 Object Identifier: "{joint-iso-ccitt mhs(6) group(6) 157}"lanmaint@nssdcb.gsfc.nasa.gov (Dave Yoest) (12/10/90)
In article <30777@boulder.Colorado.EDU>, asp@uunet.UU.NET (Andrew Partan) writes... >We switched from 8.0(6) to 8.1(14) about 6 months ago and have been >having serial line problems on 1 T1 ever since. This was a T1 that had >been working just fine for over a year prior to this. > >We first thought that it was a serial line problem or perhaps bad [Body of message deleted] >All to *no* avail - we are still getting errors - to the tune of 100 - >1000 (nearly) *every* 5 minutes. Most of these error are cisco abort >errors. > >cisco has been of little or no real help. They keep on saying that it >must be either the T1 or the CSU/DSUs. [The only bug report number >that has ever been given to me by cisco for this problem is 901120235. >I almost never get a number for any of the calls that I make.] > >Does anyone have any suggestions? Or have similar problems? > >Thanks, > --asp@uunet.uu.net (Andrew Partan) > ASN.1 Object Identifier: "{joint-iso-ccitt mhs(6) group(6) 157}" I had a somewhat similar problem with my CGS boxes running 8.1 over a T1 microwave circuit using Phoenix 1536 DSU's. When I first attempted to bring this connection up, I had problems somewhat similar to the ones you described. The T1 circuit passed BERT (Firebird 6000) tests with flying colors (no errors in 3 days), and worked fine with a Proteon router, but would not work satisfactorily with the cisco. I spoke with some other people here who use ciscos with Phoenix 1536's and noted that they were using the 1344Kbps clock speed instead of 1536 Kpbs on their DSU's. I tried the 1344Kbps setting and everything worked great! I contacted cisco customer service (cs@cisco.com) with this information and received an immediate response. In summary, cisco uses HDLC over the T1, and at 1536Kbps the cisco does not maintain a minimum 1's density over the T1. By reducing the data rate to 1344 Kbps bit stuffing is performed and everything works fine. Cisco also suggested that I could operate at 1536 if I could invert the data stream, thus maintaing a minimum 1's density. I haven't ever tried the cisco phone support, but I have been exceptionally pleased with the response time and quality of the email support (cs@cisco.com). I have used cisco cs several times in this manner and in all cases I received a response within 2 hours. I wish all the companies I deal with were as good as this..... Dave Yoest LAN Section Supervisor NASA/Goddard Space Flight Center Greenbelt Md. dyoest@zaphod.gsfc.nasa.gov dyoest@128.183.4.5
Maxim_Bohlmann.XSIS-HQ@xerox.com (12/11/90)
The serial problem with the T1 link that you describe sounds exactly like the problem I am having, including all the steps you have taken and cisco's response. Our T1 line stopped working about 6 months ago and went into this abort error mode without us having changed anything. Fortunately, I do have alternate paths to keep us limping along. One possible difference that we may have compared to your situation is heavy XNS traffic in addtion to TCP/IP. Perhaps because of this, I see the problem showing up as a disruption of XNS traffic and not really of TCP/IP traffic. A symptom that may be relevant shows up when a transport connection is first established: the first ten or so packets stream out at breakneck speed and from then on the whole connection stutters and stumbles along. It is almost as if some resource gets used up and the connection then hobbles along, snatching some crumbs of needed capacity now and then. I have been waiting patiently for the new fast switching version of XNS, hoping that something in the XNS code would be tweaked and the problem would disappear. Hearing your tale makes me wonder if the assumption that the problem is XNS related may be wrong and that the problem is wider in scope. I am eagerly awaiting responses that might clear up this mystery. --Max
schoff@psi.com (Martin Lee Schoffstall) (12/11/90)
Are you both using DigitalLink Dl551VX's? While there are other problems, the latest one that has been dug up is an interoperability problem between them and the cisco's. Marty ------------- The serial problem with the T1 link that you describe sounds exactly like the problem I am having, including all the steps you have taken and cisco's respons e. Our T1 line stopped working about 6 months ago and went into this abort err or mode without us having changed anything. Fortunately, I do have alternate p aths to keep us limping along. One possible difference that we may have compared to your situation is heavy X NS traffic in addtion to TCP/IP. Perhaps because of this, I see the problem sh owing up as a disruption of XNS traffic and not really of TCP/IP traffic. A symptom that may be relevant shows up when a transport connection is first e stablished: the first ten or so packets stream out at breakneck speed and from then on the whole connection stutters and stumbles along. It is almost as if some resource gets used up and the connection then hobbles along, snatching som e crumbs of needed capacity now and then. I have been waiting patiently for the new fast switching version of XNS, hopin g that something in the XNS code would be tweaked and the problem would disappe ar. Hearing your tale makes me wonder if the assumption that the problem is XN S related may be wrong and that the problem is wider in scope. I am eagerly awaiting responses that might clear up this mystery. --Max