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
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