| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh88408 | Title: | High CPU due to dx_flush_dynamic |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Router with an etherswitch module sees high CPU under "dx_flush_dynamic" process.
Conditions:
This may occur due to a manual shutdown of the interface or any of the etherswitch ports/links going down.
Workaround:
Unknown
Further Problem Description:
|
|
Last Modified: | 25-JAN-2016 |
|
Known Affected Releases: | 15.1(4)M, 15.3(2.1)T |
|
Known Fixed Releases: * | 15.0(1)M, 15.0(1)M1, 15.0(1)M10, 15.0(1)M2, 15.0(1)M4, 15.0(1)M7, 15.0(1)M8, 15.0(1)M9, 15.0(1)XA, 15.0(1)XA1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv97051 | Title: | Trunk port as receiver port receives more traffic than sent in IPv6 MLD |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Trunk port as receiver port receives more traffic than sent in IPv6 MLD.
Conditions:
Trunk port as receiver port receives more traffic than sent in IPv6 MLD.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 22-JAN-2016 |
|
Known Affected Releases: * | 15.6(1.11)T, 15.6(1.9)T0.2, 15.6(2)T |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup29088 | Title: | sh snmp mib ifmib ifindex lists g0/2 port which doesn't exist on 1921 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Gigabit Ethernet 0/2 interface is listed in show snmp mib ifmib ifindex command output
Conditions:
show snmp mib ifmib ifindex
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 08-JAN-2016 |
|
Known Affected Releases: * | 15.3(2.3)T, 15.4(3.23)T, n/a |
|
Known Fixed Releases: | 15.5(0.12)T, 15.5(1.2.1a)GB |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv92742 | Title: | QoS(match precedence) is causing alignment errors on MLPPP E1 interfaces |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
QoS feature (service-policy input) is causing alignment errors that can be appreciated using 'show alignment' command.
Router#show alignment
C1900 Software (C1900-UNIVERSALK9-M), Version 15.4(3)M, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Compiled Mon 21-Jul-14 17:38 by prod_rel_team
Total Corrections 223306, Recorded 1, Reads 223306, Writes 0
Initial Initial
Address Count Access Type Traceback
C1C6849 26698 16bit read 0x211588A0z 0x2113EB80z 0x21161800z 0x21146C70z
0x21149E30z 0x210D3B90z 0x23CE0600z 0x214A76B4z
Conditions:
The trigger seems to be QoS applied in MLPPP E1 interface.
Workaround:
Disable QoS (service-policy command) on the interface.
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 15.5(2.25)T |
|
Known Fixed Releases: * | 15.4(3)M4.1, 15.5(3)M0.2, 15.5(3)M1, 15.6(0.17)PI30e, 15.6(0.18)T, 15.6(1.9)T0.1, 15.6(1.9)T0.2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw79748 | Title: | Cannot ping own tunnel interface |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
-After doing a trace route to a network on a different spoke we are not able to ping to our own int tun
- on the spokes the nhrp mappings for itself and the other spokes will keep changing to the NBMA address of the hub by mistake
Conditions:
DMVPN phase 3 on Version 15.3(3)M6,
Workaround:
without Crypto issue not seen
clearing the nhrp solves the problem momentarily
Further Problem Description:
|
|
Last Modified: | 01-JAN-2016 |
|
Known Affected Releases: | 15.3(3.0b)M6 |
|
Known Fixed Releases: * | 16.2(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw08074 | Title: | EHWIC-4ESG MAINBOARD_GE-3-PHYRESET and MAINBOARD_GE-3-PHYCONFIG output |
|
Status: * | Other |
|
Severity: * | 3 Moderate |
Description: | Symptom:
below error output every time when 1921 bootup
---------------------------------------------------
%MAINBOARD_GE-3-PHYRESET: GigabitEthernet0/2, PHY reset failed
%MAINBOARD_GE-3-PHYCONFIG: GigabitEthernet0/2, PHY configuration failed
Conditions:
EHWIC-4ESG
Workaround:
issue is not seen in 155-1.T1
Further Problem Description:
|
|
Last Modified: | 07-JAN-2016 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut16523 | Title: | NDR for given packet size is not within the reference range |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
NDR for given packet size is not within the reference range
Conditions:
NDR for given packet size is not within the reference range for latest PI27 versions
Workaround:
not known
Further Problem Description:
|
|
Last Modified: | 22-JAN-2016 |
|
Known Affected Releases: * | 15.5(1.23)T0.2, 15.5(2.14)T, 15.5(2.25)T, 15.5(2.5)T, 15.5(2.6)T, 15.6(0.12)T, 15.6(0.3)T, 15.6(1.11)T, 15.6(1.9)T0.2 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq64532 | Title: | Firebee router's PIM hellos dropped intermittently in Firebee port. |
|
Status: * | Terminated |
|
Severity: * | 4 Minor |
Description: | Symptom:
PIM peering from the Firebee router forming intermittently, when the neighbor is connected to a Firebee port.
Conditions:
Issue not seen when the Firebee module acts purely as a switch, and connects 2 PIM routers at a L2 level.
Issue is seen only when the PIM peering is between the Firebee router and a neighbor connected to a Firebee port.
Workaround:
Change the Firebee port.
Further Problem Description:
PIM peering from the Firebee router forming intermittently, when the neighbor is connected to a Firebee port.
Issue not seen when the Firebee module acts purely as a switch, and connects 2 PIM routers at a L2 level.
Issue is only when the PIM peering is between the Firebee router and a neighbor connected to a Firebee port.
The Firbee module that I tested with is a 8 port module.
Have seen the issue when the neighbor is connected to ports 1 and 2.
I have another neighbor connected to port 6, and there is no issue with that neighbor.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 15.5(0.7)T |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq67900 | Title: | Firebee - mrouter port does not time out, even after shutting it. |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
Mrouter port does not time out, even after shutting the mrouter port.
'show ip igmp snooping mrouter' continues to show the shutdown port as the dynamically learned mrouter port.
There is no impact to the IGMP snooping functionality however - multicast traffic is flooded out all ports.
Conditions:
shutdown a dynamically learned mrouter port.
Workaround:
Disable and enable IGMP snooping
Further Problem Description:
Shutdown a dynamically learned mrouter Firebee port.
Wait for as long as you want. - I have waited for more than an hour.
The admin shut port continues to show up as an mrouter port.
There is no impact to the IGMP snooping functionality however - multicast traffic is flooded out all ports.
|
|
Last Modified: | 22-JAN-2016 |
|
Known Affected Releases: * | 15.5(0.7)T, 15.6(1.11)T, 15.6(1.9)T0.2 |
|
Known Fixed Releases: | |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论