| |
Bug Id: | CSCus95026 |
Title: | High CPU utilization seen with E-Line circuit and mac-learning disabled |
|
Description: | Symptom:
High CPU utilization seen with E-Line circuit and mac-learning disabled
Conditions:
High CPU utilization seen with E-Line circuit and when mac-learning is disabled
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 15.4(1)S |
|
Known Fixed Releases: | 15.4(3)S2.9, 15.4(3)S3, 15.5(1)S1.1, 15.5(2.17)S |
|
|
| |
| |
Bug Id: | CSCuh69434 |
Title: | ME-3600X-24FS-M/15.3(2)S1 newly created AToM pseudowires are down |
|
Description: | Symptom:
newly created AToM pseudowires are down
Conditions:
ME-3600X-24FS-M/15.3(2)S1
after the software upgrade from 15.2(2)S1 to 15.3(2)S1
Workaround:
not awailable
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 02-JUN-2015 |
|
Known Affected Releases: | 15.3(2)S1 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus96411 |
Title: | Incorrect routing with static routes present |
|
Description: | Symptom:
Incorrect routing with static routes present
Conditions:
ip route vrf QPB_NMR 10.0.0.0 255.0.0.0 170.16.195.74
ip route vrf QPB_NMR 10.35.255.0 255.255.255.0 170.16.195.74
Workaround:
clear ip route
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 15.4(2)S |
|
Known Fixed Releases: | 15.5(2.12)S |
|
|
| |
| |
Bug Id: | CSCus83064 |
Title: | l2vpn traffic drop as tagControlSelect not set properly |
|
Description: | Symptom:
EoMpls traffic dropped as packer egress without vlan tag
Conditions:
you can see this issue while SVI based core with EVC based Xconnect
Workaround:
none
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 15.5(1)S |
|
Known Fixed Releases: | 15.5(1)S0.10, 15.5(1)S1, 15.5(1)SN1, 15.5(2.12)S |
|
|
| |
| |
Bug Id: | CSCuq96419 |
Title: | WH2: Address MCB timeout issue on VSC8574x |
|
Description: | Symptom:
The following log is observed after the system bootup (and continues to be observed later as well):
000268: Aug 29 08:46:00.269 brz-3: SPI pause fail!, port 340020368
000269: Aug 29 08:46:00.269 brz-3: MCB timeout, port_no 340020264
When this issue occurs, some 1G port in the system (due to another bug in the software, the port number is not displayed correctly in above log message), has an issue in dealing with PTP packets. The timestamp module on those ports in the PHY does not work correctly and the recovered clock accuracy could go bad. No other traffic is impacted when this symptom is seen.
Conditions:
The problem could occur when the switches have Rev.D PHY chips with a very thin frequency (of about 2-3 times a year with multiple reboots). From the observations of this issue, the occurrence has been linked to the bootup of the box with the PTP configuration.
Workaround:
Router reload is the only workaround, based on the strong observation so far that the occurrence rate is very thin.
Further Problem Description:
The issue is reasoned out to be a bug in the PHY chip that results in a lockup inside the chip resulting in the 1588 registers being not accessible. So, further 1588 register read/write access on the PHY fails that presents this issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 15.4(1)S |
|
Known Fixed Releases: | 15.4(1)S2.23, 15.4(1)S3, 15.4(2)S2.2, 15.4(2)S3, 15.4(3)S1.5, 15.4(3)S2, 15.5(1)S1.1, 15.5(1)S2, 15.5(1)S2.1, 15.5(1.13)S |
|
|
| |
| |
Bug Id: | CSCuq28176 |
Title: | Media-type changes to rj45 after reload on a k9 image |
|
Description: | Symptom:
On a ME3600X, media-type incorrectly changes to rj45 after reload. This is seen on gig ports containing SFP & configured for media-type sfp prior to reload. This causes an outage as link does not come up with wrong media type.
Conditions:
ME3600X running a k9 154.2.S and 154.2.S1 image. Not seen on non k9 images.
Workaround:
Run a non k9 image or downgrade to 153.3.S3.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 15.4(2)S |
|
Known Fixed Releases: | 15.4(2)S2 |
|
|
| |
| |
Bug Id: | CSCug31165 |
Title: | VIP mac address over RVPLS disappear with Tunnel Flap |
|
Description: | Symptom:
Upon flapping of Tunnel Interface over which RVPLS destination address is learnt, VIP MAC disappears
Conditions:
The MAC disappears for a few secs, comes back.
Workaround:
NA
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 15.3(1)S, 15.3(3)S |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu77218 |
Title: | AN: AN not using user configured native vlan as channel |
|
Description: | Symptom:
AN not using user configured native vlan as channel
Conditions:
When connected to a L3 device
Workaround:
N/A
Further Problem Description:
Whales when connected to a L3 device, is not using user configured native vlan interface as channel to form neighborship.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 15.5(3)S |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc14594 |
Title: | MPLSTPoSVI: Traffic not switching to Standby on shut Active interface |
|
Description: | Symptom:
There is a drop in Static PW over mpls-tp traffic.
Conditions:
By default, static Pseudowires are configured in vc_type4 mode. Since vc_type4 was not configured correctly, there was a drop in traffic.
Workaround:
This behaviour can be changed by setting interworking in pw-class as Ethernet.
pseudowire-class static-pw-interworking
encapsulation mpls
interworking ethernet
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 15.3(1)S |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua20623 |
Title: | IGMP snooping over PW shows incorrect values of PWid and peer ip |
|
Description: | Symptom:
Pseudowire ID and neighbor ID is shown wrong for IGMP snooping
Conditions:
When sending all traffic combination with IGMP join, leave and multicast traffic IGMP snooping entry is showing wrong value
Workaround:
No
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 15.3(1)S |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo31527 |
Title: | OSPF packets NOT forwarded |
|
Description: | Symptom:
OSPF neighbourship will not form, and all other control plane which uses Multicast address will be affected. This issue is a timing issue, so it wont be seen always.
Conditions:
the timing issue should happen to the first EFP which is added. if the problem doesnt happen for the first EFP, further efp's created will not have a problem
Workaround:
Disable igmp snooping and enable again.
Further Problem Description:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 15.3(3)S |
|
Known Fixed Releases: | 15.3(3)S3.6, 15.3(3)S4, 15.4(1)S2.7, 15.4(1)S3, 15.4(2)S2, 15.4(2.17)S0.11, 15.4(3)S, 15.5(0.10)S |
|
|
| |
| |
Bug Id: | CSCur34990 |
Title: | CPUHOG and Traceback seen with MSTP and EFP configurations |
|
Description: | Symptom:
CPU-HOG seen when configuring (adding/removing) EFP with MST running
Conditions:
MST running
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 15.5(1)S |
|
Known Fixed Releases: | 15.5(2.7)S |
|
|
| |
| |
Bug Id: | CSCuq85326 |
Title: | ME3600 | Ping to HSRP vIP fails or packet drops observed to reach vIP |
|
Description: | Symptom:
HSRP Virtual IP ping fails
or
there are duplicate ICMP responses/ packet loss seen when pinging HSRP VIP.
Conditions:
HSRP Virtual IP ping fails when the intermediate ME3600 device configured with other HSRP groups
or
ME switch shows NO entry for the MAC address of HSRP vIP in 'sho mac-add add ' although the arp table shows the entry for HSRP vIP with vMAC!
Workaround:
Remove the intermediate ME3600 device HSRP configuration, then HSRP virtual IP ping gets success.
or
Use 'standby use-bia' or move to HSRP version 2, issues not seen with HSRP version 2.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUN-2015 |
|
Known Affected Releases: | 15.4(3)S |
|
Known Fixed Releases: | 12.2(52)EY4, 15.2(1)S, 15.2(1)S1, 15.2(2)SA, 15.2(2)SA1, 15.2(2)SA2, 15.2(2)SNI, 15.2(4)S1c, 15.2(4)S2, 15.2(4)S3 |
|
|
| |
| |
Bug Id: | CSCuu76064 |
Title: | AN: Whales establishing ACP to non directly connected devices |
|
Description: | Symptom:
Whales is establishing neighborship and ACP to devices which are not directly connected.
Conditions:
Default scenario
Workaround:
N/A
Further Problem Description:
Whales is establishing neighborship and ACP to devices which are not directly connected even tough there is no active L2 channel to the non directly connected devices.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 15.5(3)S |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur98665 |
Title: | ciscoipc process crashed when do swap ptp master/slave role |
|
Description: | Symptom:
ciscoipc process crashed , service disruptive
Conditions:
you can see this issue while swap the ptp role
Workaround:
The PTP processor could be reloaded to apply the configuration again through the following command:
test platform software ptp reset
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 15.4(1)S |
|
Known Fixed Releases: | 15.4(3)S2.3, 15.4(3)S3, 15.5(1)S1.1, 15.5(1)S2, 15.5(1)S2.1, 15.5(2.21)S0.5 |
|
|
| |
| |
Bug Id: | CSCut45184 |
Title: | Duplicate PIM hellos received in mVPN setup |
|
Description: | Symptom:
Duplicate PIM hellos may be received at each hop running in a mVPN topology. The duplicate count will rise exponentially as the number of hops grows.
Conditions:
mVPN is configured across multiple devices in a serial/ring topology.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 15.5(1)S |
|
Known Fixed Releases: | 15.4(3)S2.9, 15.4(3)S3, 15.5(1)S2.3, 15.5(2.18)S |
|
|
| |
| |
Bug Id: | CSCus56197 |
Title: | ME1200 controller: ME3600 reloads in 15.4(3)S1 |
|
Description: | Symptom:
Customer reported ME3600 reload with NID controller support added in the image.
Conditions:
ME3600 running 15.4(3)S1
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 15.4(3)S1.1 |
|
Known Fixed Releases: | 15.4(3)S3.3, 15.5(1)S0.10, 15.5(1)S1, 15.5(1)SN1, 15.5(1.18)S0.9, 15.5(2.10)S |
|
|
| |
| |
Bug Id: | CSCus16820 |
Title: | High cpu due to virtual exec or non-qos events process |
|
Description: | Symptom:
High cpu can be observed caused by two processes:
1. When service-policy is being applied/removed, high cpu caused by virtual exec is observed and vty session hangs
2. When switchport trunk allowed vlan command is executed, high cpu is caused by non-qos events process
Duration of high cpu (and vty session hangs) depends on number of vlans allowed on switch. Changing number of allowed vlans to small value doesn't fix the problem.
In some rare cases this may lead to crash of metro ethernet switch.
Conditions:
Problem starts when we apply command switchport trunk allowed vlan with big range of vlans which are also in vlan database (more than 500) and service-policy on same interface. After that problem is propagated to all other interfaces regardless what is configured there. Problem is also there when we remove both configuration lines (only removing configuration and reload fix the problem).
So far problem was not seen in IOS 15.4(2)S, 15.4(3)S and 15.5(1)S
Workaround:
Do not have interface configuration with service-policy and switchport trunk allowed vlan (more than 500 vlans).
Upgrade to 15.4(2)S, 15.4(3)S or 15.5(1)S
Problem is also not seen in version 15.4(1)S1. Last IOS where problem is seen is 15.4(1)S
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 15.3(3)S1, 15.4(1)S |
|
Known Fixed Releases: | 15.5(1)S1.1, 15.5(1)S2, 15.5(1)S2.1, 15.5(1)SN1 |
|
|
| |
| |
Bug Id: | CSCus96586 |
Title: | Ptp clock stuck on ACQUIRING state for very long time |
|
Description: | Symptom:
PTP slave stuck on ACQUIRING state for very long time . seems to be large mean path delay and clock offset .
Conditions:
you could see this issue with ptp config .
Workaround:
not known
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 15.4(3)S |
|
Known Fixed Releases: | 15.4(3)S2.5, 15.4(3)S3, 15.5(1)S1.1, 15.5(1)S2, 15.5(1)S2.1, 15.5(2.21)S0.5 |
|
|
| |
| |
Bug Id: | CSCuu49953 |
Title: | Unicast Flooding is observed on a Customer routed Pseudo wire network |
|
Description: | Symptom:
Unicast Flooding is observed on a Customer routed Pseudo wire network
Conditions:
Topology
========
HostA === SW1 === SW2 === HostB
1. Configure a Routed Pseudowire between SW1 and SW2.
2.Configure a routed port between SW1 to router HostA working as NAT.
3. Create a loopback ip address on HostA router.
4. Ping the loopback ip address from SW2.
5. We could see the packets are flooded to pirent2.
customer is trying to ping the lopopback address which is located on cisco HostA router from SW2.
Ping packet are flodded to all the ports in vlan 10 .
On our topogy, It going out to HostB.
Workaround:
NA
Further Problem Description:
NA
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 15.4(3)S2.1 |
|
Known Fixed Releases: | 15.4(3)S3.3, 15.5(1)S2.3, 15.5(2.21)S0.8, 15.6(0.4)S |
|
|
| |
| |
Bug Id: | CSCuu71516 |
Title: | AN: Channel not getting formed in Whales. |
|
Description: | Symptom:
CD channel is not getting formed in whales platform.
Conditions:
With default interface config.
Workaround:
N/A
Further Problem Description:
Continuous channel creation and deletion observed and hence neighborship, ACP etc won't get established.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 15.5(3)S |
|
Known Fixed Releases: | 15.5(2.21)S0.8 |
|
|
| |
| |
Bug Id: | CSCuu13846 |
Title: | MET resource exhaustion with IGMP Snooping |
|
Description: | Symptom:
MET exhaustion message may be seen.
*Apr 23 05:04:52.804: platform assert failure: 0: ../src-nile/src-asic-nile/nile_adjmgr_utils.c: 832: adjmgr_free_met
*Apr 23 05:04:52.804: -Traceback= 776728z 263995Cz 277A9C0z 275CC7Cz 27610C4z 2EEBEC8z 2EED8ACz 20DDEB0z 20EE1E0z 20C2294z 3918E40z 391405Cz
*Apr 23 05:04:52.804: Bad adjmgr_met_free type=3 err=4
*Apr 23 05:04:52.804: platform assert failure: 0: ../src-nile/src
Conditions:
Issue is seen when IGMP snooping is enabled and IGMP join/leave messages are frequently received. MET entries are leaking on every igmp timeout/leave/ interface shut/no shut.
Workaround:
disable igmp snooping
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 15.4(3)S2.1 |
|
Known Fixed Releases: | 15.4(3)S3.2, 15.5(1)S2.3, 15.5(2.21)S0.6, 15.6(0.2)S |
|
|
| |
| |
Bug Id: | CSCus78700 |
Title: | Incorrect classification at egress |
|
Description: | Symptom:
Egress classification is not classified properly and all the traffic flowing through the default class no matter what ever the classification.
Conditions:
apply policy in the egress interface for vlan range and issue will be seen
Workaround:
There is no workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 15.5(1)S |
|
Known Fixed Releases: | 15.5(1)S0.12, 15.5(1)S1, 15.5(1)SN1, 15.5(2.12)S |
|
|
| |
| |
Bug Id: | CSCuv04392 |
Title: | ME3600X: VLAN MET programming issue on NIL |
|
Description: | Symptom:
ISIS not coming up after moving link to Gi0/1
Conditions:
ME3600 with ISIS on Gi0/1 access port
Workaround:
Use another interface
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 15.3(3)S4 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut17914 |
Title: | ME3600 doesn't respond to unicast ARP req destined to HSRP virtual mac |
|
Description: | Symptom:
ME3600 doesn't respond to unicast ARP req destined to HSRP virtual mac. However, ME3600 sends ARP reply properly when ARP request is destined to broadcast mac (FF:FF:FF:FF:FF:FF).
Conditions:
Steps to reproduce:
1. Configure SVI Vlan100 and enable HSRP group in SVI vlan100.
2. Configure service instance for the bridge domain 100 in physical port where Ixia is connected.
3. Send ARP request for HSRP virtual IP from Ixia with destination mac address as HSRP virtual mac (unicast).
4. Observe ME3600 doesn't send ARP reply.
5. Send ARP request for HSRP virtual IP from Ixia with destination mac address as broadcast (FF:FF:FF:FF:FF:FF)
6. Observe ME3600 sends ARP reply properly.
Workaround:
ME3600 sends ARP reply properly when ARP request is destined to broadcast mac (FF:FF:FF:FF:FF:FF)
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 15.4(3)S2.1 |
|
Known Fixed Releases: | 15.4(3)S2.9, 15.4(3)S3, 15.5(1)S2.2, 15.5(2.16)S |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论