CLIFF@UCBCMSA.BITNET (Cliff Frost {415} 642-5360) (07/22/88)
Hi,
I'm looking for help with serial line problems. At this point we don't
know if our problems are with p4200s, Com-4 boards, modems, or serial
lines. If anyone has seen something similar, we'd like to hear about it.
We have about 14 subnets here that are connected back to our main
network via 56 and 64Kb serial lines. These are all p4200 to p4200
connections. We have two p4200s in the main building, each with
2 com-4 boards. Most of the links seem to run with no problems, but
a few of them are exhibiting strange failure modes.
What appears to happen is that the link will go down (in one direction),
the p4200 will detect a Maintenance Failure, and go into Self Test. When
this happens, virtual circuits across the link will die (especially
if the circuit is using KEEPALIVEs, such as rlogin). Sometimes the link
will stay down long enough that routes to that subnet will time out, but
this is unusual.
We're concentrating on one line in particular now. We've swapped all the
equipment at both ends to no avail. We've BERT tested the line, it passed.
We've used a different copper circuit altogether.
Also, we've plugged one of our free com-4 interfaces into a modem in
Local Loopback. In this configuration at 64K, the p4200 indicated 12
Maintenance Failures in the space of a couple of days. At 56K, the p4200
reports 1 Maintenance Failure in the last 15 hours. We've tried two
different modems (General Datacomm) at 64K, and will try a Gandalf at 56
tomorrow.
We're also using a data line monitor to watch the traffic, and so far it
hasn't reported any errors during times when the line bounced.
Again, if this sounds familiar to anyone, please let me know.
Thanks,
Cliff
ps it is happening at 7.4b and 8.0 of the software.swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) (07/22/88)
Cliff, just to clarify: are these strictly-on-campus continuous copper wire private circuits? And what do you use to drive them? Scott
CLIFF@UCBCMSA.BITNET (Cliff Frost {415} 642-5360) (07/22/88)
> Cliff, just to clarify: are these strictly-on-campus continuous copper > wire private circuits? And what do you use to drive them? > Scott All are on-campus, although some go from the main building to the phone co office (across the street from the campus) and back to the 'remote' building. These are driven by General Datacomm modems, and the flakey circuits are less flakey at 56K than at 64K. Other circuits are completely on-campus, driven with DataPath units through our Campus's Nortern Telecom switch. We see the failures (and successes) through both. Cliff
sholom@nynexst.COM (Sholom Fried) (07/23/88)
>What appears to happen is that the link will go down (in one direction), >the p4200 will detect a Maintenance Failure, and go into Self Test. When >this happens, virtual circuits across the link will die (especially >if the circuit is using KEEPALIVEs, such as rlogin). Sometimes the link >will stay down long enough that routes to that subnet will time out, but >this is unusual. Your problem sounds very familiar. We have a testbed of P4200s in our lab here, and we're also involved with NYSERNet, which is currently based on P4200s - and in both cases we've experienced the same thing. Reducing these link failures is very important for NYSERNet, where they may be killing lots of virtual circuits. We haven't completely isolated the causes of these "interface flappings" although we've found some contributing factors. Cables - in the lab we've found that poor cables (not manufactured to V.35 spec - balanced lines not twisted together) can cause interface fluttering particularly if they're long - 20+ feet. Even in shorter cables this frequently contributes to high crc and framing errors. Some people claim that the full set of pins, when not used, add to the problem by adding inductance. You may want to look out for other emi type problems. If you find anything significant let us know! Good luck. Sholom Fried NYNEX S&T 914-287-5159 sholom@nynexst.com