<!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">
Hi Tassos,<br>
<br>
<blockquote cite="mid4476BDD7.5030800@forthnet.gr" type="cite">
<blockquote type="cite">Modem recovery can automatically busy out
modems, if it should see excessive failures on certain modems and
decide that it wants to "recover" the module.
<br>
<br>
</blockquote>
<br>
I have neven seen on 12.2(15)T16 busied out calls (we're talking about
20 routers with this IOS), although i get messages like:
<br>
<br>
May 25 04:00:00: %MODEM-1-MODEMOK: Modem (2/96) Running old firmware
<br>
May 25 04:38:00: %MICA-5-MODEM_RECOVERY: Modem (2/96) is being
recovered by asap-redownload
<br>
May 25 04:38:06: %MODEM-5-DL_START: Modem (2/96) started firmware
download
<br>
May 25 04:38:19: %MODEM-5-DL_GOOD: Modem (2/96) completed firmware
download:
<br>
<br>
On the other hand, in 12.3.18 (only one router and in the same hunt
group with the other 20), i never got such messages, but i had quite a
lot of busied out calls.
<br>
</blockquote>
<br>
Doesn't the modem log show <b>anything</b> when the busied counter
increments for a modem?<br>
<br>
<blockquote cite="mid4476BDD7.5030800@forthnet.gr" type="cite">
<blockquote type="cite">There are probably some other reasons why the
router will decide automatically to busy out modems, ... oh, I just
though of one, that little featurette where where we proactively busy
out modems to signal to the switch that the trunks are busy to force
the switch to hunt to a different router.
<br>
<br>
</blockquote>
<br>
Can you explain it a little bit more?
<br>
Why do you proactively busy out the modems in this case (signal to the
switch), when the isdn channels are the ones that should be busied out?
<br>
</blockquote>
<br>
Um, you're right, it was my foggy memory that was faulty.<br>
<br>
<blockquote cite="mid4476BDD7.5030800@forthnet.gr" type="cite">
<blockquote type="cite">Maybe if you look at the modem logs, they'll
provide some explanation, unless they have rolled over past the busyout
event.
<br>
<br>
</blockquote>
<br>
I just reloaded the box :( and loaded 12.3.19....i'm waiting for busied
out calls to appear again.
<br>
Then i'll try to grab the modem logs.
<br>
<br>
--
<br>
Tassos
<br>
</blockquote>
<br>
OK.<br>
<br>
I do have one concern that I should raise here, about using current
12.3 mainline code on MICA platforms - (such as the 5300, or the
3600/3700 with NM-DM modems) - see below. I think if I were running
such a platform, I would be tempted to run latest 12.3(6) throttle
(12.3(6f)) rather than a subsequent 12.3M release.<br>
<br>
Regards,<br>
<br>
Aaron<br>
<br>
---<br>
<br>
CSCei63851<br>
mica modems randomly marked as bad in any version afer 12.3(6)<br>
Release-note: Modified 050919<br>
<br>
Click to see the enclosure with line wrapping enabled<br>
<br>
<br>
In 3640 and 5300 platform running any version after 12.3(6), mica
modems may randomly<br>
marked as BAD<br>
<br>
The symptoms observed only in situations where call success rate(CSR)
is very<br>
low and there are good amount of calls failing continously in modem to
modem<br>
trainup<br>
<br>
Modem log of modem in bad state, showed that IOS put modem out of
service<br>
because modem failed to go onhook/offhook<br>
<br>
Workaround<br>
-Use 12.3(6)d or any version before it<br>
<br>
-Manually download the modem portware to spe that has bad modem using<br>
"firmware location.." command in spe mode<br>
<br>
-Reboot the router <br>
<br>
-Make sure many calls are not failing in trainup that is CSR is good<br>
<br>
---<br>
<br>
This is marked Unreproducible, although it probably should be reopened,
as this problem is seen on 5300s and 36/3700s on all 12.3 mainline
after the 12.3(6) throttle.<br>
<br>
<hr size="2" width="100%"><br>
<blockquote cite="mid4476BDD7.5030800@forthnet.gr" type="cite"><br>
<blockquote type="cite">Aaron
<br>
<br>
------------------------------------------------------------------------
<br>
<br>
<br>
<blockquote type="cite">Router1 is AS5300 with 12.3(18.8) - 2.9.5.0
<br>
<br>
router1>sh mode sum
<br>
Avg Hold Incoming calls Outgoing calls Busied Failed
No Succ
<br>
Time Succ Fail Avail Succ Fail Avail Out Dial
Ans Pct.
<br>
00:32:21 65667 4330 91 0 0 0 54 0
0 94%
<br>
<br>
Router2 is AS5300 with 12.2(15)T16 - 2.9.5.0
<br>
<br>
router2>sh modem sum
<br>
Avg Hold Incoming calls Outgoing calls Busied Failed
No Succ
<br>
Time Succ Fail Avail Succ Fail Avail Out Dial
Ans Pct.
<br>
00:31:52 435989 25314 76 0 0 0 0 0
4 95%
<br>
<br>
<br>
Router1 is the only AS5300 running 12.3(18.8) and is the only one
showing busied out calls during the last 2 months. Previously, when it
was running 12.2(15)T16 too, no busied calls were there for over a
year.
<br>
<br>
So, is there a known bug with "busied out" calls in 12.3.18 IOS? I
couldn't find anything in bugtool.
<br>
<br>
<br>
-- <br>
Tassos
<br>
_______________________________________________
<br>
cisco-nas mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:cisco-nas@puck.nether.net">cisco-nas@puck.nether.net</a>
<br>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-nas">https://puck.nether.net/mailman/listinfo/cisco-nas</a>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>