| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv37210 | Title: | SM-X-1T3/E3 show controller serial x/y crashes 3900e |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
Issuing show controller Serial command of the Serial
interface created by SM-X-1T3/E3 card causes router to crash.
Conditions:
Issue is seen only on 3900e router platform with SM-X-1T3/E3
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 05-DEC-2015 |
|
Known Affected Releases: | 15.6(0.6)T |
|
Known Fixed Releases: * | 15.3(3)M6.2, 15.4(3)M3.2, 15.4(3)M4, 15.5(3)M0.2, 15.5(3)M1, 15.6(0.8)T, 15.6(1.9)T0.1 |
|
|
| |
| |
|
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: | 05-DEC-2015 |
|
Known Affected Releases: | 15.2(4)M6 |
|
Known Fixed Releases: * | 15.6(0.25)T, 15.6(1.1)T, 15.6(1.9)T0.1 |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCtj79476 | Title: | Traffic loss seen after few hrs of operation on hwic-4esw |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic loss and VLAN related errors seen when the traffic is
sent for a prolonged duration on an HWIC.
Conditions:
The symptom is observed when traffic is sent for a prolonged
duration (>12hrs) on an HWIC.
esw_mrvl_vlan_port_remove : Unable to find entry for VLAN(50) dbnum(3)
esw_mrvl_vlan_port_remove : Unable to find entry for VLAN(52) dbnum(4)
The following devices are affected.
HWIC-4ESW
HWIC-4ESW-POE
HWIC-D-9ESW
HWIC-D-9ESW-POE
Workaround:
Delete the vlan and create it back, will not work on vlan1 as we cannot delete vlan 1 from database.
Further information:
If you upgrade, please also make sure that you avoid the following similar bug :
CSCtx72953 Traffic loss on hwic-4ESW due to loss of vlan
Further Problem Description:
|
|
Last Modified: | 10-DEC-2015 |
|
Known Affected Releases: | 12.4(15)T7, 12.4(24)T2, 15.0(1)M3.12, 15.0(1.1) |
|
Known Fixed Releases: | 12.4(24)T8, 15.0(1)M7.20, 15.1(4)M2.9, 15.1(4)M3, 15.1(4)XB7, 15.2(2.10)T, 15.2(2.14)PI19, 15.2(2.9.5)PIH18, 15.2(3.30)PIP |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux37497 | Title: | Malloc Issues with chunk manager perf_mon_async_cft_create_fo() |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
MALLOCFAIL and CHUNKEXPANDFAIL syslogs seen:
*Dec 1 19:01:52.764: %SYS-2-MALLOCFAIL: Memory allocation of 32768 bytes failed from 0x11B769, alignment 0
Pool: Processor Free: 597780 Cause: Memory fragmentation
Alternate Pool: None Free: 0 Cause: No Alternate pool
-Process= "Chunk Manager", ipl= 6, pid= 1
-Traceback= 1E7E64Az 115116z 110ACEz 10D56Ez 11B769z 1076CDz 107593z
*Dec 1 19:01:54.704: %DUAL-6-NBRINFO: EIGRP-IPv4 400: Neighbor 10.103.5.1 (GigabitEthernet0/2.99) is blocked: not on common subnet (10.103.8.1/24)
*Dec 1 19:01:54.724: %SYS-2-CHUNKEXPANDFAIL: Could not expand chunk pool for PM CLS HIER. No memory available -Process= "Chunk Manager", ipl= 6, pid= 1
-Traceback= 1E7E64Az 107650z
*Dec 1 19:02:08.492: %DUAL-6-NBRINFO: EIGRP-IPv4 400: Neighbor 10.103.5.1 (GigabitEthernet0/2.99) is blocked: not on common subnet (10.103.8.1/24)
*Dec 1 19:02:18.836: %SYS-2-CHUNKEXPANDFAIL: Could not expand chunk pool for PM CLS HIER. No memory available -Process= "Chunk Manager", ipl= 6, pid= 1
-Traceback= 1E7E64Az 107650z
Conditions:
PFRv3 is configured and traffic of EMIX pattern is run for long duration with very high CPU of 75%.
Workaround:
None
Further Problem Description:
None
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 15.5(3)S |
|
Known Fixed Releases: * | 15.6(1.12)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw14948 | Title: | HSRP vip ping failure after power off one side Router with SM module |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
HSRP vip ping failure after power off one side Router with SM module
Conditions:
After power off one side Router with SM module, at other side from SM module,
ping physical ip of router there is no problem, but ping vip at router failed.
Workaround:
Reconfig HSRP of the one with ping issue
Further Problem Description:
|
|
Last Modified: | 05-DEC-2015 |
|
Known Affected Releases: | 15.3(3)M4 |
|
Known Fixed Releases: * | 15.3(3)M6.2, 15.6(1.6)T, 15.6(1.9)T0.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu82082 | Title: | Memory corruption crash due to cont_scan_display_session |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
We see a lot of '%AP-1-AUTH_PROXY_AUTH_FAILURES_EXCEEDED' logs prior to the crash.
Not sure if they are related for now.
Conditions:
The crash is observed after the following CLI 'sh cws sess active ip-addr all' was executed.
However the crash is not consistently seen with the above CLI.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 15.4(3)M1 |
|
Known Fixed Releases: * | 15.6(1.12)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup67654 | Title: | ISM-VPN module crash due to memory leak;Traceback = 1000b8a0 or 1000b8c0 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
-ISM crashes on ISR G2 running 152-4.M6a
-ACE Crash Info file yields traceback of the following:
======== Stack Back Trace ========
-Traceback= 1000b8a0
or
-Traceback= 1000b8c0
-Logging buffer may show the following:
May 28 07:32:56.769: Reventon small chunk is not destroyable
May 28 07:32:56.769: Reventon medium chunk is not destroyable
May 28 07:32:56.769: Reventon big chunk is not destroyable
May 28 07:32:56.777: %VPN_HW-6-SHUTDOWN: shutting down
May 28 07:33:03.645: %CRYPTO-6-GDOI_ON_OFF: GDOI is OFF
May 28 07:33:03.645: Reventon small chunk is not destroyable
May 28 07:33:03.645: Reventon medium chunk is not destroyable
May 28 07:33:03.645: Reventon big chunk is not destroyable
May 28 07:33:03.645: %VPN_HW-6-SHUTDOWN: shutting down
Conditions:
-Have ISM-VPN module enabled and encrypting traffic in ISR G2 platform
-DMVPN may be a factor
Workaround:
-Disable ISM and use onboard crypto engine with command "no crypto engine slot 0"
-If ISM has crashed, the router must be reloaded to recover module
Further Problem Description:
|
|
Last Modified: | 05-DEC-2015 |
|
Known Affected Releases: | 15.2(4)M3.11, 15.2(4)M6.1, 15.3(3)M3 |
|
Known Fixed Releases: * | 15.2(4)M8, 15.3(3)M5.1, 15.3(3)M6, 15.4(3)M2.2, 15.6(1.9)T0.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv49227 | Title: | 'bfd interval' values only 999-999 in Port-channel sub-interface mode |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
1) BFD interval command missing after IOS upgrade.
2) The range of values available for the command 'bfd interva' under Port-channel sub-interface configuration is different between 15.1 and 15.3 IOS versions.
On Version 15.1(4)M6
!
interface Port-channel1.999
Router(config-subif)#bfd interval
<50-999> Milliseconds
min_rx
<50-999> Milliseconds
multiplier
<3-50> value used to multiply the interval
On Version 15.4(3)M3
!
interface Port-channel1.999
Router(config-subif)#bfd interval
<999-999> Milliseconds
min_rx
<999-999> Milliseconds
multiplier
<3-50> value used to multiply the interval
Conditions:
'bfd interval' configuration under Port-Channel sub-interface.
Workaround:
Use BFD-template instead.
For example:
R1 and R2 are directly connected via Port-Channel 1.2
The configuration for both devices and the 'show bfd neighbor' output are the following:
On R1
bfd fast-timers-on-slow-interface
!
bfd-template single-hop TEST
interval min-tx 150 min-rx 50 multiplier 3
!
interface Port-channel1.2
encapsulation dot1Q 2
ip address 192.168.2.1 255.255.255.0
bfd template TEST
end
R1#show bfd neighbors
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
192.168.2.2 1/1 Up Up Po1.2
R1#
*********************************************************************************************
On R2
bfd-template single-hop TEST
interval min-tx 150 min-rx 50 multiplier 3
!
interface Port-channel1.2
encapsulation dot1Q 2
ip address 192.168.2.2 255.255.255.0
bfd template TEST
!
R2#show bfd neighbor
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
192.168.2.1 1/1 Up Up Po1.2
R2#
More information via:
www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bfd/configuration/15-s/irb-15-s-book/irb-bfd-shop-auth.html
Further Problem Description:
On version 15.1(4)M6, the available configuration values for the command 'bfd interval', under interface Port-channel1.123 were <50-999>
Router(config-subif)#bfd interval
<50-999> Milliseconds
min_rx
<50-999> Milliseconds
multiplier
<3-50> value used to multiply the interval
After upgrading to 15.4(3)M3, the range of available values was changed to <999-999>
On Version 15.4(3)M3
!
interface Port-channel1.123
Router(config-subif)#bfd interval
<999-999> Milliseconds
min_rx
<999-999> Milliseconds
multiplier
<3-50> value used to multiply the interval
The consequence is that the command is ignored at boot-time when the Router is upgraded, which is not expected by customers.
At boot time, we can see the command previously available in 15.1 is no longer accepted and then ignored in 15.3 when the configuration is being loaded
bfd interval 50 min_rx 150 multiplier 3
^.
% Invalid input detected at '^' marker.
%Interface MTU set to channel-group MTU 1500.
%Interface MTU set to channel-group MTU 1500.
|
|
Last Modified: | 05-DEC-2015 |
|
Known Affected Releases: | 15.4(3)M2.2 |
|
Known Fixed Releases: * | 15.6(0.17)PI30e, 15.6(0.19)T, 15.6(1.9)T0.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua76337 | Title: | Watchdog Crash due to "no [ACL entry number]" |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: * | Symptoms: Device crashes upon removing a numbered ACL.
Conditions: The symptom is observed when traffic is hitting the policies where
ACL is being used.
Workaround: There is no workaround.
|
|
Last Modified: | 17-DEC-2015 |
|
Known Affected Releases: | 15.1(1)T2 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux38584 | Title: | crash at hqflayer_bypass_inline |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
3925 has crashed with reload reason "error - an unknown failure"
Conditions:
3925 running c3900e-universalk9-mz.SPA.152-4.M8 with QOS configured
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 11-DEC-2015 |
|
Known Affected Releases: | 15.2(4)M |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv24993 | Title: | NM-1-T3E3 input queue wedge on 3900e platform |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Cisco 3900e with a NM-1T3/E3 may experience the serial interface transitioning to UP/DOWN when one of the 3 onboard GigabitEthernet interfaces looses connectivity. When the problem occurs, the GigabitEthernet interface will be in a DOWN/DOWN state and the NM-1T3/E3 will be in a UP/DOWN state. The serial interface input queue with appear wedged:
Input queue: 76/75/91557/0 (size/max/drops/flushes); Total output drops: 0
The serial interface will recover when the GigabitEthernet interface restores connectivity.
Conditions:
This problem only occurs on the Cisco 3900e platform. The Cisco 2951 / 3900 platforms are not effected.
Workaround:
Increasing the serial input queue will workaround the issue. The following interface level command will increase the queue from the default of 75 to 4000:
hold-queue 4000 in
Further Problem Description:
|
|
Last Modified: | 05-DEC-2015 |
|
Known Affected Releases: | 15.1(4)M4 |
|
Known Fixed Releases: * | 15.6(1.9)T, 15.6(1.9)T0.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux27284 | Title: | MGCP country depedent caller ID table is not up-today |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The Hungary and Korea are not using ETSI for caller ID.
The India and Saudi Arabia are not using DTMF for caller ID
Conditions:
for mgcp call only
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 05-DEC-2015 |
|
Known Affected Releases: | 15.5(3.0a)M |
|
Known Fixed Releases: * | 15.5(3)S1.1, 15.6(1.15)S, 15.6(1.9)T, 15.6(1.9)T0.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut15147 | Title: | Spurious access produces invalid traceback and show align rework |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
1) The traceback that is printed as part of ALIGN-3-SPURIOUS is not a valid traceback
2) The output of "show align" is not populated with spurious access information after a spurious access occurs
Conditions:
seen on c2951 and c3900
Workaround:
no workaround
Further Problem Description:
|
|
Last Modified: | 05-DEC-2015 |
|
Known Affected Releases: | 15.4(3), 15.5(2)T, 15.5(2.5)T |
|
Known Fixed Releases: * | 15.3(3)M6, 15.4(3)M3.1, 15.4(3)M4, 15.5(3)M0.2, 15.5(3)M1, 15.6(0.5)T, 15.6(1.9)T0.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw19489 | Title: | 39xx DSP Crash due to Backplane Switch Lockup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
3900 router using a PVDM3 may experience simultaneous failure on several DSPs.
Conditions:
Memory errors and traceback :
****************************************
*Nov 17 12:30:29.736: %ALIGN-3-SPURIOUS: Spurious memory access made at 0x4391E2
0 reading 0x0
*Nov 17 12:30:29.736: %ALIGN-3-TRACE: -Traceback= 0x4391E00 0x4391DE0 0x4391DC0
0x46695A0 0x46693E0 0x4391D00 0x4391CE0
*Nov 17 12:30:30.068: %DSPRM-3-DSPALARMINFO: DSP (0/1) Host GIGE ack failed
*Nov 17 12:30:30.068: %DSPRM-3-DSPALARMINFO: Device (0/1) Host GIGE ack timeout
Workaround:
test image provided by the BU is available
Further Problem Description:
|
|
Last Modified: | 05-DEC-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: * | 15.6(0.26)T, 15.6(1.2)T, 15.6(1.9)T0.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu77844 | Title: | 3945E with EHWIC-1GE-SFP-CU/ GLC-LH-SMD= not suppport DOM |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
3945E with EHWIC-1GE-SFP-CU/ GLC-LH-SMD=
when use 155.2.T will got below:
show int tran detail:
Module 0 doesn't support DOM
Conditions:
HW:3945E/EHWIC-1GE-SFP-CU/ GLC-LH-SMD=
SW:c3900e-universalk9-mz.SPA.155-2.T.bin
Workaround:
no workaround
Further Problem Description:
first time the software is c3900e-universalk9-mz.SPA.153-3.M5.bin<<<
second time the software is c3900e-universalk9-mz.SPA.155-2.T.bin<<<
no other change.
when the cu first time use show interface tran detail got below :
first time
Transmit Power Threshold Threshold Threshold Threshold
Port (dBm) (dBm) (dBm) (dBm) (dBm)
---------- ----------------- ---------- --------- --------- ---------
Gi0/0/0 --2147483648.-2 -0.0 --2147483648.-2 --2147483648.-2 --2147483648.-2 <<<<<< this number is
second time got below :
3F-N5-20-C3945-A#show interfaces Gi0/0/0 transceiver
Module 0 doesn't support DOM
|
|
Last Modified: | 05-DEC-2015 |
|
Known Affected Releases: | 15.5(2)T |
|
Known Fixed Releases: * | 15.3(3)M6.2, 15.4(3)M3.2, 15.4(3)M4, 15.5(2)T2, 15.5(3)M0.2, 15.5(3)M1, 15.6(0.4)T, 15.6(1.9)T0.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw10370 | Title: | Router with ISM module crash when crypto enabled interface goes down |
|
Status: | Open |
|
Severity: * | 4 Minor |
Description: | Symptom:
Router with ISM module crash when crypto enabled interface goes down
Conditions:
Routers with ISM modules installed
Workaround:
No Workaround Available
Further Problem Description:
|
|
Last Modified: | 20-DEC-2015 |
|
Known Affected Releases: | 15.2(4)M |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq07987 | Title: | NBAR sometimes failed to recognize RTP flow based on SIP messages |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
After a SIP call gets connected, NBAR fails to recognize some initial RTP packets based on SIP messages such that these RTP packets fall into default class in the router QoS Service policy.
Conditions:
Under non-standard SIP negotiation conditions (errors/rejects/missing info etc.) the NBAR SIP parsing might fail to identify the RTP flow and NBAR fell back to identifying the RTP flow by itself.
Workaround:
It is ok to ignore the issue since the impact to voice quality is minimum.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 15.2(4)M |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux47169 | Title: | Super Echo Tail Length causes T38 MCF to be detected as fcs-BAD-sig-end. |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Super Echo Tail Length causes T38 MCF to be detected as EOP right after the DSP generates en EOP with DSP firmware below 35.1.8.
Starting 35.1.8 when the DSP generates an EOP if the Echo Tail is super long (around 450 ms or longer) it detects the MCF as a fcs-BAD-sig-end.
Fax is correctly transmitted, but at the end of the fax transmission, since the EOP is not acknowledge properly with the MCF, but gets the EOP in response if using lower Firmware version than 35.1.8 or gets fcs-BAD-sig-end in response if using Firmware 35.1.8 or latter, the Sending fax device thinks that the Fax transmission was not successful and re-tries the fax. This causes the sender to send multiple faxes.
Conditions:
Echo Tail is super long (around 450 ms or longer)
Workaround:
No workaround
Further Problem Description:
Super Echo Tail Length causes T38 MCF to be detected as EOP right after the DSP generates en EOP with DSP firmware below 35.1.8.
Starting 35.1.8 when the DSP generates an EOP if the Echo Tail is super long (around 450 ms or longer) it detects the MCF as a fcs-BAD-sig-end.
Fax is correctly transmitted, but at the end of the fax transmission, since the EOP is not acknowledge properly with the MCF, but gets the EOP in response if using lower Firmware version than 35.1.8 or gets fcs-BAD-sig-end in response if using Firmware 35.1.8 or latter, the Sending fax device thinks that the Fax transmission was not successful and re-tries the fax. This causes the sender to send multiple faxes.
|
|
Last Modified: | 09-DEC-2015 |
|
Known Affected Releases: | 15.3(3.0q)M5.1 |
|
Known Fixed Releases: | |
|
|
| |
:
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论