<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rob,<br>
<br>
I'd recommend that you turn off the modem recovery stuff. This was
needed back in the bad old days of MICA "dsp death" and "hex flu" and
suchlike, where the modem DSPs and control processors would sometimes
go out to lunch and need to get reset. So we implemented this recovery
stuff to busy out modem modules so that we could get all the users off
a bad module so that we could gracefully reset it.<br>
<br>
But if you're running any MICA code from the last 6 [?] years or so -
certainly since 2.9.4.0 or above - these problems are virtually never
seen, so the recovery logic is not needed.<br>
<br>
(See
<a class="moz-txt-link-freetext" href="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094cac.shtml">http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094cac.shtml</a>
for more on the topic.)<br>
<br>
Now, there is (/was) an independent command called "modem
busyout-threshold" which would proactively busy out DS0s so that there
would never be more free DS0s than free modems. This was done for the
case where the NAS is part of a hunt group, so that the circuit network
would know not to offer a call to a NAS that couldn't answer it.
Sounds like you might have that configured? (Seems that this command
also goes by the name "ds0 busyout-threshold" - see
<a class="moz-txt-link-freetext" href="http://www.cisco.com/en/US/docs/ios/12_2/dial/command/reference/drflcmo.html#wp1081087">http://www.cisco.com/en/US/docs/ios/12_2/dial/command/reference/drflcmo.html#wp1081087</a>
.)<br>
<br>
Hth,<br>
<br>
Aaron<br>
<br>
<hr size="2" width="100%"><br>
<br>
Rob Conklin wrote:
<blockquote cite="mid:499CBCB8.4030506@win.net" type="cite">
<meta http-equiv="content-type" content="text/html; ">
<font face="Courier New, Courier, monospace">My question concerns
tuning IOS to modify the threshold(s) for putting b-channels
out-of-service.<br>
<br>
My company is using (our own, in-house) software based media gateway
controller to control <br>
CISCO 5300/5400 modem banks. <br>
<br>
We've used this system for operations for about a year now with good
results, but <br>
have lately found a problem in a deployment for several CISCO 5300s
that are being pushed <br>
very hard, reaching almost full capacity with and approaching all busy
time-slots/b-channels.<br>
<br>
On this system, at 2 am, we are noting that the CISCO 5300 is putting
quite a few b-channels <br>
out of service. This corresponds to modem maintenance period set by
IOS configuration we use<br>
(not sure this has anything to do with b-channels..., but only config
item that corresponds to <br>
the seemingly important point in time discussed below, 2 am):<br>
<br>
modem recovery maintenance window 120<br>
modem recovery maintenance time 2:00<br>
modem recovery maintenance stop-time 5:00<br>
modem recovery threshold 100<br>
<br>
The exact process of how and when these state changes take place is
hard to describe (and <br>
hard to understand!), but we are waking up to find 4, 5, 6 or more
b-channels out-of-service most<br>
days now, (oddly, almost always on the same t1, but different T1s and
different b-channels).<br>
<br>
In logs see that these state changes take place as soon as 2 am or
follow some <br>
time within the next hours. If we reset the T1s, (shut/no shut or
reboot), any time in the <br>
early morning hours (after 6 am say), there are no out-of-service
b-channels until 2 am again.<br>
<br>
Interpretation of this (the appearance of out-of-service b-channels, no
matter the details),<br>
might be that with the very high call rates we are seeing a large
increase in the number of <br>
interactions, with a proportional increase in errors or problems. The
CISCO analysis for <br>
putting channels out-of-service may be fixed, or tuned to a lower level
of activity.<br>
<br>
I've tried to find information about how to adjust IOS (from the <br>
command line interface) that would increase thresholds to the point
where these oos <br>
retirements were not so common, but have not come across anything
useful. Does anyone <br>
reading this by chance have a tip on that?<br>
<br>
TIA for any suggestions!</font><br>
<pre class="moz-signature" cols="72">--
Rob Conklin
AMSS NOC
(502) 407-0033
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
cisco-nas mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-nas@puck.nether.net">cisco-nas@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-nas">https://puck.nether.net/mailman/listinfo/cisco-nas</a></pre>
</blockquote>
</body>
</html>