🚀 go-pugleaf

In article <3961@ursa-major.SPDCC.COM>, dyer@spdcc.COM (Steve Dyer) writes:
|> In article <3951@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
|> >[problems of hundreds of carrier transitions and serial line resets]
|> 
|> The problem has disappeared, and the superficial solution was simple
|> (if that was in fact the source of the problem.)  I'd specified the
|> high-speed serial interface on my CGS/2 even though I was planning to
|> run at 56kb so that I could upgrade simply to fractional T1 speeds if my
|> downstream link ever upgraded also.  During the initial configuration
|> of the serial interface, we neglected to specify the line bandwidth as 56kb
|> (since that was what had been assumed for other CGS/2 models, and was
|> the default for the Cisco on the other end of the DDS line.  Apparently
|> though, the default for the high-speed serial interface is T1 rate.
|> Once I reset this to 56kb, things settled down within minutes, and
|> I've had only a few carrier transitions and no interface resets since.
|> 
|> I suppose that the "bandwidth" field is used for the initial values
|> of the HDLC timers, and having such a mismatch between the two sides
|> (not to mention the actual bandwidth) could cause problems, no? 

I understood that the bandwidth sub-command "sets an informational parameter
only; you cannot adjust the actual bandwidth of an interface with this command"
(Gateway Server Manual p. 4-22). If this is not the case, then I would like
to know about it, because on some of our 48K DDS services we see similar
very high transition and reset counts,

Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator,	 			phone: +61 6 249 3542
Australian Academic Research Network,		fax: +61 6 247 3425
c/o, Computer Services Centre,			post: PO Box 4
Australian National University			      Canberra 2601
Canberra, AUSTRALIA