Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cisco: NAS

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

 

 

Cisco nas RSS feed   Index | Next | Previous | View Threaded


robconklin at win

Feb 18, 2009, 5:58 PM

Post #1 of 2 (2321 views)
Permalink
Let my b-channels go! (CISCO 5300/5400 modem banks).

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


Aaron at cisco

Feb 18, 2009, 7:02 PM

Post #2 of 2 (2187 views)
Permalink
Re: Let my b-channels go! (CISCO 5300/5400 modem banks). [In reply to]

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
> https://puck.nether.net/mailman/listinfo/cisco-nas

Cisco nas RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.