| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq15237 | Title: | GM hangs while applying show crypto gdoi command |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
GM2 hangs after applying the command "show crypto gdoi | inc (POLICY|spi|remaining)"
Conditions:
This is seen in IPv6 IPSec scenarios.
Workaround:
Unknown
Further Problem Description:
|
|
Last Modified: | 10-OCT-2015 |
|
Known Affected Releases: | 15.5(0.10)T, 15.5(0.11)T |
|
Known Fixed Releases: * | 15.0(2)EA, 15.0(2)EB, 15.0(2)EC, 15.0(2)ED, 15.0(2)EH, 15.0(2)EJ, 15.0(2)EJ1, 15.0(2)EK, 15.0(2)EK1, 15.0(2)EX |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc11293 | Title: | Signature did not verify when attempting to upgrade IOS |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: * | Symptom:
Signature did not verify when attempting to upgrade IOS.
Conditions:
ROMMON: 15.0(1r)M13
IOS: c3900-universalk9-mz.SPA.152-1.T3.bin
When attempting to upgrade to the aforementioned IOS using ROMMON 15.0(1r)M13,
the error "Signature did not verify" is seen upon booting the IOS.
Workaround:
If ROMMON 15.0(1r)M6 or 15.0(1r)M16 is used the problem is not seen. The
problem is also not seen
under IOS 152-3.T1.
|
|
Last Modified: | 15-OCT-2015 |
|
Known Affected Releases: | 15.2(1)T3 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv34342 | Title: | SVIs stay up after shutdown ISR - SM-ES interconnect |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When shutdown interconnect interface between router and SM-ES module, related SVIs don't bring down but stay up.
Conditions:
Shutting down the router side interconnect interface, let's say Gi1/1 after doing either of followings;
1)
hw-module sm oir-stop
and then without removing the module,
hw-module sm oir-start
2) reload after entering SM console.
Workaround:
None but reloading the router.
Or explicitly shutting down the SVIs
Further Problem Description:
|
|
Last Modified: | 22-OCT-2015 |
|
Known Affected Releases: | 15.2(4)M6 |
|
Known Fixed Releases: * | 15.6(0.25)T, 15.6(1.1)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut66144 | Title: | VXML GW fails to handoff call to VXML Application on second VRU leg |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Call comes in to VXML GW and the TCL script for bootstrap comes up but VXML does not.
HTTP Get is never sent to CVP Server so then CVP Server times out and disconnects the call as never got any HTTP get from GW.
15.3.3.M5
Conditions:
High volume on the GW.
Workaround:
no workaround.
Further Problem Description:
GW is showing this.
9931429: Mar 26 14:22:21.839: //873876//MSM :/ms_handle_stream_timer: >>ms_start_play()
9931430: Mar 26 14:22:21.839: //873876//MSM :/ms_start_play: 1w4d, Tstart(ply: num 22 max 196 StDly 10)
Message should be.
ms_start_play: 1w4d mgdTstop(ply)
|
|
Last Modified: | 13-OCT-2015 |
|
Known Affected Releases: | 15.3(0.1) |
|
Known Fixed Releases: * | 15.3(3)M5.2, 15.3(3)M6, 15.3(3)S5.12, 15.3(3)S6, 15.4(3)M3.1, 15.4(3)M4, 15.4(3)S3.3, 15.5(2)S0.9, 15.5(2)S1, 15.5(2)SN |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus30128 | Title: | RRI dynamic L2L after client change ip address Ipsec rekey lost routes |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Dynamic L2L IPsec VPN , client used PPPOE to connect to internet.
When the client PPPOE disconnect and got the new ip address .
In the hub when the old address SPI lifetime reached and delete it will delete the RRI route.
When the new SPI lifetime reached , IPsec rekey the RRI route be added and then very quickly be delete.
Conditions:
The issue is happened when remote router change the ip address , but in the hub still have the old SPI information.
Workaround:
Manually add an static route for the RRI entry.
Further Problem Description:
|
|
Last Modified: | 13-OCT-2015 |
|
Known Affected Releases: | 15.2(4)M6.1 |
|
Known Fixed Releases: * | 15.2(4.0)ST, 15.2(4.0.21)E, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(1)IE101.170, 15.3(3)M5.2, 15.3(3)M6, 15.3(3)S5.16, 15.3(3)S6, 15.4(3)M3.2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw29082 | Title: | VXML GW : Record element not recording more than 15min |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Call Recording feature in the VXML Gateways through the VXML browser is failing to create and transfer the wav file via POST message to the VXML Server for recordings larger than 10mins. Any other short recording with less than 10mins of audio is sent to the VXML Server just fine.
Conditions:
Contact Center deployments with Call Recording enabled.
Voice Store and Forward Recording feature store in DRAM as define in the VXML Application Document and transfer via HTTP
Workaround:
None
Further Problem Description:
Audio recordings with less than 10mins worth of audio are transfer accordingly to the VXML Server.
|
|
Last Modified: | 22-OCT-2015 |
|
Known Affected Releases: | 15.4(3)M |
|
Known Fixed Releases: * | 15.6(0.26)T, 15.6(1.9)S |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum18790 | Title: | Ds3(SMX-T3/E3) link flaps when CPU goes High.(intermittent issue) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
A SM-X-1T3/E3 may periodically change state(s) between up/down for no apparent reason. The flapping is intermittent but at times can be continuous.
1. DS3 link associated with SM-X card flaps when CPU goes high.
2. It is an intermittent problem, Issue observed around 3 times in last couple of days.
Conditions:
This issue only occurs on the SM-X1-T3/E3 module.
Workaround:
Manually shutting down then bringing up the interface will resolve the flapping temporarily. At times, a full reboot may be needed.
Further Problem Description:
|
|
Last Modified: | 23-OCT-2015 |
|
Known Affected Releases: | 15.2(22.22), 15.2(4)M4.5, 15.3(3)M2.7 |
|
Known Fixed Releases: | 15.2(4)M6.3, 15.2(4)M7, 15.3(3)M3.2, 15.3(3)M4, 15.4(1)T1.3, 15.4(1)T2, 15.4(2.6)T, 15.4(3.6)PIB25 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun41068 | Title: | VWIC3 faces one-way audio with few Service Providers(VWIC2 works fine) |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
VWIC3 faces no-audio(no ringback) on Outbound calls. Inbound calls work fine.
VWIC2 works absolutely fine. This happens with only few Service Provider(like Alcatel).
Conditions:
This happens with only few Service Providers(like Alcatel 1642). With VWIC2 works all fine. In the RIN you see audio but you do not get SIN/SOUT in PCM or get muted audio in SIN/SOUT if you get it.
Applies to all IOS
Applies to ISRG2(3945 platform specifically checked)
Not a HW issue as applies to all 3945 having VWIC3 going to the provider.
Only Outbound calls face the issue. Inbound calls work fine.
Workaround:
Replace the VWIC3 with VWIC2.
Further Problem Description:
Troubleshooting Performed
In the PCM captures we observed that for the failure there is proper RIN but no SIN/SOUT.
Different IOS has been tried like c3900-universalk9-mz .SPA.153-3.M1.bin and c3900-universalk9-mz .SPA.151-4.M7.bin and all result in the same.
Configurations has been verified again and again and all routing has been ensured to be symmetric with proper Proxy-Arp setting etc.
Packet capture with old and latest IOS is same there is no Sin from Telco to the Gateway.
++ Collected debugs and show command and observed Outbound call connects fine.
AMPMLBR08L02# sh voice call status
CallID CID ccVdb Port Slot/DSP:Ch Called # Codec MLPP Dial-peers
0x33 11F7 0x1A33CA44 0/1/0:15.31 0/1:1 * g711ulaw 0/0
++ With show output we see the packet increasing but it looks like comfort noise as there is no Sin. Noise=-84
11F7 : 52 11750480ms.1 (*02:34:54.031 UTC Sat Nov 30 2013) +0 pid:0 Originate connecting
dur 00:00:22 tx:1068/170880 rx:1066/170560 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 10.32.20.13:20704 SRTP: off rtt:0ms pl:17560/0ms lost:0/0/0 delay:55/55/65ms g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
11F7 : 51 11750480ms.2 (*02:34:54.031 UTC Sat Nov 30 2013) +0 pid:0 Originate active
dur 00:00:22 tx:1066/179088 rx:1106/176960 dscp:0 media:0 audio tos:0x0 video tos:0x0
Tele 0/1/0:15 (51) [0/1/0.31] tx:22120/22120/0ms g711ulaw noise:-84 acom:51 i/0:-79/-50 dBm
+++++++++++++++++++++
++ In same call the Tx/Rx packet count increased.
11F7 : 52 11750480ms.1 (*02:34:54.031 UTC Sat Nov 30 2013) +0 pid:0 Originate connecting
dur 00:01:50 tx:5194/831040 rx:5195/831200 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 10.32.20.13:20704 SRTP: off rtt:0ms pl:100250/0ms lost:0/0/0 delay:55/55/65ms g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
11F7 : 51 11750480ms.2 (*02:34:54.031 UTC Sat Nov 30 2013) +0 pid:0 Originate active
dur 00:01:51 tx:5195/872760 rx:5586/893760 dscp:0 media:0 audio tos:0x0 video tos:0x0
Tele 0/1/0:15 (51) [0/1/0.31] tx:101110/101110/0ms g711ulaw noise:-84 acom:51 i/0:-79/-70 dBm
++ In PCM capture there is NO Sin but just Rin.
++ Tested with IOS 15.2(4)M4 and 15.3(3)M1 and same behaviour where DSP is the default version of the IOS.
|
|
Last Modified: | 24-OCT-2015 |
|
Known Affected Releases: | 15.2(4)M4.3 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx25738 | Title: | processes memory increase about 10% from 15.2(2)T to 15.2(2.10)T |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The Used processes memory after router bootup increases above 10% from 15.2(2)T to 15.2(2.10)T.
Conditions:
The problem is seen on both c3945 and c3945e.
Workaround:
There is no known workaround.
|
|
Last Modified: | 04-OCT-2015 |
|
Known Affected Releases: | 15.2(2.10)T |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)E, 15.2(1)E1, 15.2(1)E2, 15.2(1)E3, 15.2(1)EX0.147, 15.2(1)EY, 15.2(1)IC273.5, 15.2(1.1)EY, 15.2(1.1)PSR |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto43532 | Title: | CUCME not sending RTCP sender report |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
CUCME is not sending RTCP sender report
Conditions:
For SIP calls to/from AT&T network
Workaround:
none
|
|
Last Modified: | 26-OCT-2015 |
|
Known Affected Releases: | 15.1(3)T |
|
Known Fixed Releases: | |
|
|
| |
:
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论