| |
|
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: | 13-JAN-2016 |
|
Known Affected Releases: | 15.5(3)S |
|
Known Fixed Releases: * | 15.5(3)M1.1, 15.6(0.22)S0.12, 15.6(1.12)T |
|
|
| |
| |
|
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: | 23-JAN-2016 |
|
Known Affected Releases: * | 15.2(4)M6, 15.5(3)M1.1 |
|
Known Fixed Releases: | 15.4(3)M4.1, 15.6(0.25)T, 15.6(1.1)T, 15.6(1.9)T0.1, 15.6(1.9)T0.2 |
|
|
| |
| |
|
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: | 07-JAN-2016 |
|
Known Affected Releases: | 15.3(3)M4 |
|
Known Fixed Releases: * | 15.3(3)M6.2, 15.5(3)M1.1, 15.6(1.6)T, 15.6(1.9)T0.1, 15.6(1.9)T0.2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto81814 | Title: | Router crash when SSH over IKEv2 tunnel to manage the router |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms: When SSH is attempted over an IKEv2 tunnel using ECDSA certificates, the router crashes.
Conditions: This symptom is observed only when ECDSA certificates are used for IKEv2 and not with RSA certificates or with IKEv1.
Workaround: There is no workaround.
|
|
Last Modified: | 31-JAN-2016 |
|
Known Affected Releases: | 15.1(4)M |
|
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: | 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: | 20-JAN-2016 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: * | 15.4(3)M4.1, 15.5(3)M1.1, 15.6(0.26)T, 15.6(1.2)T, 15.6(1.9)T0.1, 15.6(1.9)T0.2 |
|
|
| |
| |
|
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: | 20-JAN-2016 |
|
Known Affected Releases: | 15.1(4)M4 |
|
Known Fixed Releases: * | 15.4(3)M4.1, 15.6(1.9)T, 15.6(1.9)T0.1, 15.6(1.9)T0.2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw54917 | Title: | LMR port stuck in S_TRUNK_PEND after T1/E1 reports LOF |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The LMR port will stay in S_TRUNK_PEND state after T1/E1 reported LOF. The LMR port can recover by shutdown and no shutdown the LMR port.
Conditions:
LMR port configured in connection trunk setup
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 15.1(4)M9 |
|
Known Fixed Releases: * | 15.4(3)M4.1, 15.4(3)S4.6, 15.5(1)S2.19, 15.5(1)S3, 15.5(1)T2.1, 15.5(1)T3, 15.5(2)S2.1, 15.5(3)M1, 15.5(3)S0.14, 15.5(3)S1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv01746 | Title: | DLEP VRF aware support request |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Physical interface configured under a certain VRF, breaks DLEP adjacency with radio device.
For instance:
interface GigabitEthernet0/0.99
ip address 192.168.1.25 255.255.255.0
vrf forwarding VRF-TEST <<< If we add this line, the DLEP adjacency goes down.
!
interface Virtual-Template99
!
interface vmi99
ip unnumbered GigabitEthernet0/0.99
vrf forwarding VRF-TEST <<< DLEP works fine with VMI interface configured with a VRF. However since it uses IP unnumbered, the IP address is not considered part of the VRF Routing table and remains in Global Routing table.
!
Conditions:
VRF configured under a physical interface which we intend to use for DLEP adjacency.
Workaround:
Do not configure a physical interface intended to be used for DLEP under any VRF.
Further Problem Description:
VMI interface used by DLEP is going down and neighbor getting deleted when physical interfaces is configured under a VRF (not in Global Routing table).
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 15.4(3)M |
|
Known Fixed Releases: * | 15.4(3)M3.2, 15.4(3)M4, 15.5(1)T2.1, 15.5(1)T3, 15.5(2)T2, 15.5(3)M0.2, 15.5(3)M1, 15.6(0.9)T, 15.6(1.9)T0.1, 15.6(1.9)T0.2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv09635 | Title: | H320 gateway strips rtp marker bits |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Choppy or pixelated video
Conditions:
H320 call flow when newer mcu code or dx endpoints are used.
Workaround:
run older mcu code, no workaround for dx endpoints
Further Problem Description:
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 15.4(3) |
|
Known Fixed Releases: * | 15.2(4)M9, 15.3(3)M6.2, 15.4(3)M3.2, 15.4(3)M4, 15.5(1)T2.1, 15.5(1)T3, 15.5(2)T2, 15.5(3)M0.2, 15.5(3)M1, 15.6(0.18)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh58718 | Title: | Unable to reduce IO memory allocated |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Error messages received related shortage of memory .
This shortage is in the processor pool since the IO pool is assigned a huge amount of memory by default that may never be used.
Conditions:
Normal Operation
Workaround:
Starting IOS Release 154-3M, the software will let you tweak the memory allocated to IO pool instance to a minimum of 15% (default 25%)
Further Problem Description:
|
|
Last Modified: | 16-JAN-2016 |
|
Known Affected Releases: | 15.3(1.15)T, 15.3(1.16)T, 15.3(1.17)T |
|
Known Fixed Releases: | 15.4(2.17)T, 15.4(2.18)T, 15.4(2.20)T, 15.4(3)M |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux86014 | Title: | IP IGMP static-group * packet loss |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
When configuring the comaand ip IGMP static-group * on an interface located on a Rendezvous Point and initiating multicast traffic from a source, the Rendezvous Point drops the first encapsulated PIM register packet. Although the Rendezvous point is able to create the (*,G) group associated with the multicast destination (due to the ip gimp static group * command), it looks like the creation of the (*,G) state does not happen in time for the first PIM register Packet to be decapsulated and forwarded down the (*,G) shared tree. This causes a RPF failure and the first register packet is subsequently dropped. This behavior can be seen by enabling the following debugs:
*Jan 13 20:15:13.352: MRT(0): Add GigabitEthernet2.523/225.1.1.1 to the olist of (*, 225.1.1.1), Forward state - MAC built
*Jan 13 20:15:13.352: MFIBv4(0x0): Pkt (1.1.1.1,225.1.1.1) from Tunnel0 (PS) Acceptance check failed ? dropping
Although the (*,G) has been successfully created, that creation is happening simultaneously with the packet being dropped. When the static-group command is used to specify the necessary mcast group and the (*,G) entry is pre-existing in the OIL, all packets are forwarded.
This behavior is easily reproduce-able by enabling the correct debug commands, configuring a single interface on an RP with the igmp static-group * command and observing the failure of the first PIM Register packet in a MCAST flow.
Conditions:
An interface on a Rendezvous Point must be configured with the igmp static-group * command. At that point, traffic to any multicast destination will exhibit the forwarding failure of the first PIM Register packet.
Workaround:
Enable Specific static Igmp groups instead of using the ip igmp static-group * command. This pre-creates the (*,G) entry associated with the desired MCAST group, allowing the first PIM register packet to be forwarded.
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 15.5(1.20)T |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur66196 | Title: | OvrTh value is wrong in enhanced-history distribution stats |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
OvrTh value is wrong in enhanced-history distribution stats
Conditions:
Cisco 3900 running 15.1(3)T4
Workaround:
Verify the over threshold operations using "show ip sla statistics"
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 15.1(3)T4 |
|
Known Fixed Releases: * | 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(1)IE101.187, 15.5(1.13)T, 15.5(2)S, 15.5(2.1)S, 16.1(0.5), 7.0(0)BZ(0.98), 7.0(3)I2(0.47) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux24258 | Title: | Gateway interprets interdigit timeout as no input timeout |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Let the gateway play the prompt , press 1 digit to interrupt the audio. The gateway should wait for inter digit timeout and return the value to CVP. In this case inter digit timeout was 3 seconds.
In IOS 15.4(3)M3 , the gateway waits for 30 seconds( which is no digit timeout ) and then returns the value to CVP.
The behavior is seen only when 1 digit is entered. The gateway works perfectly fine if 2 or more digits are entered.
Conditions:
Issue seen in IOS 15.4(3)M3
Workaround:
Use IOS 15.2(4) M3.
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 15.4(3.0p)M3 |
|
Known Fixed Releases: * | 15.4(3)S4.10, 15.5(3)M1.1, 15.5(3)S1.5, 15.6(0.22)S0.12, 15.6(1.12)T |
|
|
| |
| |
|
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: | 07-JAN-2016 |
|
Known Affected Releases: | 15.5(3.0a)M |
|
Known Fixed Releases: * | 15.5(3)M1.1, 15.5(3)S1.1, 15.6(1.15)S, 15.6(1.9)T, 15.6(1.9)T0.1, 15.6(1.9)T0.2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsw94392 | Title: | Incorrect verifier shown in show soft auth run for reload /verify warm |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
If image is loaded using warm upgrade, "show software authen run" CLI indicates Rommon as the verifier instead previous IOS image.
Conditions:
Problem only occurs if image is loaded using warm upgrade.
Workaround:
use normal reload not "reload warm" command for loading image
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 12.4TPI |
|
Known Fixed Releases: * | 15.0(1)M10, 15.0(1)M2.2, 15.0(1)M4, 15.0(1)M7, 15.0(1)M8, 15.0(1)M9, 15.0(1.19)DPA6, 15.0(1.19)DPB3, 15.0(2.12)DPB1, 15.0(3.1)SID |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv16044 | Title: | CUBE-HA PortChannel Support |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
CUBE-HA fails to preserve media if PortChannel is used, among other feature issues not further tested.
Conditions:
CUBE-HA is configured on CUBE and PortChannel is used instead of single interfaces.
CUBE-HA single attached & dual attached.
Workaround:
Use single interfaces.
Further Problem Description:
|
|
Last Modified: | 06-JAN-2016 |
|
Known Affected Releases: | 15.4(3)M |
|
Known Fixed Releases: | |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论