Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!elbereth.rutgers.edu!madness.rutgers.edu!hobson From: hobson@madness.rutgers.edu (Kevin Hobson) Newsgroups: comp.dcom.sys.cisco Subject: Re: Problems with Novell-routing Keywords: Novell Message-ID: Date: 28 Dec 90 11:17:49 GMT References: <1581@netmbx.UUCP> Distribution: comp Organization: Rutgers Telecommunications Lines: 63 To: macbeth@netmbx.UUCP In article <1581@netmbx.UUCP> macbeth@netmbx.UUCP (Andreas Pahl) writes: > We have a major problem with routing Novell-protocol via X.25: > > Everything seems to be all right, the Novell-servers of each net can be > seen on the other net, login and attach work, BUT: > LARGE FILES CAN'T BE COPIED!!! > When I try to dos-copy a file from one side to the other, the files reaches > the other server, but it's corrupted after about $6000 Bytes. .... So you found out that Novell does not do end-to-end checksumming. Cisco knows about this problem and is working on a solution. We have had the same thing happen to us with DECnet and UDP/IP (NFS checksumming turned off on the SUN or backups not working using rdump under UNIX) over serial lines. Basically, how do you tell the upper-level protocols (above level 2 and level 1) that you had a error at the HDLC level and resend the packet over a serial line before the higher protocol timeout on the packets already sent out by the host? Each protocol deals with this differently. What is each protocol timeout for "corrupted" or lost packets. Most of the above protocols assumes that you are using an ethernet cable for transport since the host machines do not know that there is a slower transport mechanism (two cisco boxes connected by a serial line of speeds anywhere from 9.6K up to T2) in between the LAN (WAN). Host A send out it's ethernet cable assuming ethernet speed to host B who thinks it is talking the ethernet speed transport mechanism. If that serial line is having problems (losing packets or corrupt packets between the two cisco boxes) and it is longer that the protocol timeout for packets to be transported to the end host, what does the upper layers of the protocol do? It is up to the particular protocol and applications. We have seen many protocols break, since we have cisco boxes, just because a serial line (leased circuit), modem, or CSU/DSU was partially or completely broken. Basically, level 5 (session level or session error level) should do an end-to-end checksum. Novell does not have this when using ethernet transport. It assume it is working (or completely not working). Best way to check is bring up IP (encapsulation HDLC) on the serial line and ping both serial interfaces with 1000 packets using the following data patterns: standard [0xABCD], all zeros [0x0000], all ones [0xFFFF] ALL THESE PATTERNS SHOULD WORK ON A WORKING SERIAL LINE AT ANY SPEED. After you have determine that there is a problem, start looping back various devices, one at a time, on both sides of the connection to isolate the particular device (or cable) or leased line using the above test, again. This is how we determine that there was a local cable problem with our X.25 connection to our regional Bell Public Data Network. The DTE loopback (ping test) would work but a remote CSU/DSU loopback (ping test) would not. The regional Bell said everything tested good up to our CSU/DSU when was loopback. Also a great way to find out if the regional Bell installed a "bridged TAP" on T1 leased line. Normal telephone test equipment will say the circuit is good. The cisco will complain, loudly. Good luck. -- Kevin Hobson Internet: hobson@rutgers.edu Rutgers - The State University UUCP: {backbone}!rutgers!hobson P.O. Box 879, CCIS, Hill Center, Busch BITNET: hobson@{cancer,pisces}.BITNET Piscataway, N.J. 08855-0879 PHONE: (908) 932-4780