Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dss
From: dss@unix.cis.pitt.edu (Don Salvin)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Bug in cisco bridging?
Message-ID: <30651@unix.cis.pitt.edu>
Date: 22 Aug 90 15:23:18 GMT
References: <24936@boulder.Colorado.EDU>
Reply-To: dss@unix.cis.pitt.edu (Don Salvin)
Organization: Univ. of Pittsburgh, Comp & Info Services
Lines: 60

Newsgroups: comp.dcom.sys.cisco
Subject: Re: Bug in cisco bridging?
Summary: 
References: <24936@boulder.Colorado.EDU>
Sender: 
Reply-To: dss@unix.cis.pitt.edu (Don Salvin)
Followup-To: 
Distribution: 
Organization: Univ. of Pittsburgh, Comp & Info Services
Keywords: 

In article <24936@boulder.Colorado.EDU> SHERWOOD@AC.DAL.CA (John Sherwood) writes:
>Hank:
> 
>>I have defined two ciscos (8.1(14)) each with bridging between the

           [stuff deleted...]

>>dies between the Decserver and the Vaxstation.
> 
>LAT is a very time-sensitive protocol. I would not be surprised to find
>it will not work on a single 19.2k link. I am surprised that you can get it
>to work at all even with 2 links sharing the load. Even minor delays
>in packet delivery can give LAT heartburn.

It is true that the DEFAULT timers provided with the DECserver 200's
make them quite sensitive to "minor" delays in the network. However,
they are parameters in the server that are settable. At our site we run
MANy servers, some of them running over slow, crowded links, and have no
problems. This is admittedly a pain to administer in a large network,
but we have written tools to make it easier for us. The timers you want
to set are RETRANSMIT LIMIT and KEEPALIVE TIMER. We use RETRANSMIT
LIMIT=60 and KEEPALIVE TIMER=180 .

>>  This does not happen
>>when I do a connect from one Vax station to another (using routing rather
>>than bridging) and removing one of the cables (physically).> 
>I am guessing that you are using DECnet CTERM rather than LAT. CTERM
>(ie. $SET HOST xxxx) should work with no problems over slow links; we run
>it at 4800 regularly.
> 
>I would try switching to CTERM as the terminal protocol and see if your
>problems go away.

I would try fixing the timers first, as LAT is more efficient in its use
of network bandwidth, something I would be concerned about, especially
over slow links. It also provides better functionality as a terminal
protocol than CTERM.

>Cheers
> 
>John Sherwood
>Dalhousie University
>Halifax, Nova Scotia
> 
>sherwood@ac.dal.ca.

Don Salvin
Data Comm Manager, University of Pittsburgh
dss@pitt.edu