[cisco-nas] Let my b-channels go! (CISCO 5300/5400 modem banks).

[Aaron Leonard]

Rob,

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.

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.

(See
http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094cac.shtml
for more on the topic.)

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
http://www.cisco.com/en/US/docs/ios/12_2/dial/command/reference/drflcmo.html#wp1081087
.)

Hth,

Aaron

------------------------------------------------------------------------


Rob Conklin wrote:
> My question concerns tuning IOS to modify the threshold(s) for putting
> b-channels out-of-service.
>
> My company is using (our own, in-house) software based media gateway
> controller to control
> CISCO 5300/5400 modem banks.
>
> We've used this system for operations for about a year now with good
> results, but
> have lately found a problem in a deployment for several CISCO 5300s
> that are being pushed
> very hard, reaching almost full capacity with and approaching all busy
> time-slots/b-channels.
>
> On this system, at 2 am, we are noting that the CISCO 5300 is putting
> quite a few b-channels
> out of service.  This corresponds to modem maintenance period set by
> IOS configuration we use
> (not sure this has anything to do with b-channels..., but only config
> item that corresponds to
> the seemingly important point in time discussed below, 2 am):
>
> modem recovery maintenance window 120
> modem recovery maintenance time 2:00
> modem recovery maintenance stop-time 5:00
> modem recovery threshold 100
>
> The exact process of how and when these state changes take place is
> hard to describe (and
> hard to understand!), but we are waking up to find 4, 5, 6 or more
> b-channels out-of-service most
> days now, (oddly, almost always on the same t1, but different T1s and
> different b-channels).
>
> In logs see that these state changes take place as soon as 2 am or
> follow some
> time within the next hours.  If we reset the T1s, (shut/no shut or
> reboot), any time in the
> early morning hours (after 6 am say), there are no out-of-service
> b-channels until 2 am again.
>
> Interpretation of this (the appearance of out-of-service b-channels,
> no matter the details),
> might be that with the very high call rates we are seeing a large
> increase in the number of
> interactions, with a proportional increase in errors or problems.  The
> CISCO analysis for
> putting channels out-of-service may be fixed, or tuned to a lower
> level of activity.
>
> I've tried to find information about how to adjust IOS (from the
> command line interface) that would increase thresholds to the point
> where these oos
> retirements were not so common, but have not come across anything 
> useful.  Does anyone
> reading this by chance have a tip on that?
>
> TIA for any suggestions!
> -- 
> Rob Conklin 
> AMSS NOC 
> (502) 407-0033
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> cisco-nas mailing list
> cisco-nas at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-nas/attachments/20090218/9f327d1f/attachment.html>