Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!snorkelwacker!mintaka!spdcc!dyer
From: dyer@spdcc.COM (Steve Dyer)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: help needed debugging DDS 56kb prob
Message-ID: <3970@ursa-major.SPDCC.COM>
Date: 10 Sep 90 06:54:33 GMT
References: <25924@boulder.Colorado.EDU>
Reply-To: dyer@ursa-major.spdcc.COM (Steve Dyer)
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 24

In article <25924@boulder.Colorado.EDU> pte900@jatz.aarnet.edu.au (Peter Elford) writes:
>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,

I wasn't suggesting that it adjusted the actual bandwidth.  I was
hypothesizing that the "informational parameter" might have been used
for HDLC timers and that a severe mismatch might cause the line to go
down or behave erratically.  I've since been told by folks at Cisco
that the bandwidth parameter is only used within IGRP for routing
information.

In any event, the "fix" appears to have been a coincidence.  Having moved the
equipment to its permanent resting place, the carrier transitions and
interface resets (after a stable, peaceful weekend) have returned with a
vengeance, even with the parameter set to 56kb.  I think I'm in the
nether world of flaky cables/modems, and will pursue it on that level.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu