| |
Bug Id: | CSCut25697 |
Title: | 'service not responding' error on add/delete vlans: N6001 706_259 |
|
Description: | Symptom:
"Service not responding" is seen while adding PVLAN config again in an access switch connected to vpc pair of switches.
Conditions:
switch is connected to vpc pair N6001's . Removed pvlan from vpc pair of switches then removed it on the switch . Copied pvlan config back on VPC switches. But when we paste the same commands on the switch , the console of switch got stuck with 'service not responding'.
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 07-MAY-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.258) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut49745 |
Title: | Nexus 6001 Silent Reload with I2C Cause Code 0x0100 |
|
Description: | Symptom:
A Nexus 6001 chassis may experience an unexpected reload. The reset-reason will be listed as "Unknown".
The I2C cause code, which should be recorded in 'show logging onboard internal reset-reason' on all released code for the N6K, will be recorded as 0x0100 ("ADM1066 Power Good Triggered Reset").
Reset Reason for this card:
Image Version : 6.0(2)N2(3)
Reset Reason (LCM): Unknown (0) at time Fri Feb 20 13:30:02 2015
Reset Reason (SW): Unknown (0) at time Fri Feb 20 07:32:04 2015
Service (Additional Info):
Reset Reason (HW): uC reset code: 0x0100
ADM1066 Power Good Triggered Reset at time Fri Feb 20 07:32:04 2015
Conditions:
This has thus far been observed on N6K-C6001-64P switches with Platinum power supplies (NXA-PAC-1100W).
This defect is currently under investigation and so an exact trigger or other possible conditions are not currently known.
Workaround:
None known.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 08-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N2(3), 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup85771 |
Title: | Nexus 6000 resets SSH intermittently |
|
Description: | Symptom:
A java script is ran to fetch show run interface outputs from a windows machine.
Topology:
Nexus 6001---windows machine
The script establishes a SSH session to collect the outputs. After fetching 3 interface running configurations outputs through the script, the Nexus 6000 switch disconnects the ssh session.
packet capture on the management interfaces shows a RST packet sent from the switch towards the pc to disconnect the SSH session which is buggy.
This script works fine with 6.0(2)N1 code. The issue is seen only on 6.0(2)N2 versions.
Sample working & Non-working output:
Is session connected: true
exit-status: 0
!Command: show running-config interface Ethernet1/1
interface Ethernet1/1
description testing range
switchport mode trunk
switchport trunk allowed vlan 1
spanning-tree port type edge trunk
Non-working:
Is session connected: true
exit-status: -1
Please note that during non-working scenario the script can collect the outputs 3 times, but the 4th try fails because of the RST signal from Nexus 6000 which needs to be investigated.
Please find the attached Java script & outputs under the file name "labrecreate detailed" attached to the bug
Conditions:
seen only on 6.0(2)N2
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | 5.2(1)N1(8.152), 5.2(1)N1(9), 6.0(2)N2(6.129), 6.0(2)N2(7), 7.0(1)ZN(0.683), 7.0(6)N1(0.194), 7.0(6)N1(1), 7.1(0)N1(0.402), 7.1(0)N1(0.404), 7.1(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCut56369 |
Title: | ARP Ingress packets dropped due to 'BIG_DROP_SRC_VLAN_MBR' |
|
Description: | Symptom:
ARP Ingress packets dropped due to 'BIG_DROP_SRC_VLAN_MBR'
Conditions:
On a vpc+ setup having Iluka image 7.0(6)N1(1), it is observed that ARP ingress packets are dropped on FEX interface connected to PVLAN host when STP mode is changed from PVST to MST.
Workaround:
No workaround exits, should not change STP mode
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.258) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus36208 |
Title: | PTPLC core due to mem leak |
|
Description: | Symptom:
PTPLC may crash unexpectedly.
Conditions:
This was first seen on a N6K running 7.0(2)N code.
Workaround:
Unknown at this point.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.739), 7.0(6)N1(0.238), 7.0(6)N1(1), 7.1(1)N1(0.447), 7.1(1)N1(0.77), 7.1(1)N1(1), 7.2(0)AB(2), 7.2(0)N1(1), 7.2(0)VZN(0.7), 7.2(0)ZN(0.120) |
|
|
| |
| |
Bug Id: | CSCun69004 |
Title: | Nexus 5K/6k sends untagged BPDUs on vPC when leg on vPC Primary is down |
|
Description: | Symptom:
switch connected via a vPC will see the following STP state:
Switch# show spanning-tree interface port-channel 17
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg BKN*1 128.4112 P2p *PVID_Inc
VLAN0200 Desg BKN*1 128.4112 P2p *PVID_Inc
VLAN0500 Desg BKN*1 128.4112 P2p *PVID_Inc
Conditions:
Two Nexus switches running 7.0(0)N1(1)
vPC leg on vPC Primary is down
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-MAY-2015 |
|
Known Affected Releases: | 7.0(0)N1(1.1) |
|
Known Fixed Releases: | 7.0(1)N1(0.154), 7.0(1)N1(1), 7.1(0)N1(0.120), 7.1(0)N1(1), 7.1(0)ZN(0.239) |
|
|
| |
| |
Bug Id: | CSCun54576 |
Title: | Nexus6000: License grace period is shown after disabling grace period |
|
Description: | Symptom:
N96-OPTICS(config)# sh lic us
Feature Ins Lic Status Expiry Date Comments
Count
--------------------------------------------------------------------------------
ENTERPRISE_PKG No - Unused Grace 116D 17H
FC_FEATURES_PKG No - Unused Grace 119D 9H
--------------------------------------------------------------------------------
Under comments column, grace period is shown even when license is unused.
Conditions:
Always reproducible as per the problem statement
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 7.0(1)N1(0.115) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu13462 |
Title: | Port-profile hap resets after enabling fabricpath |
|
Description: | Symptom:
The issue was originally seen in a Nexus 6000 running 6.0(2)N2(6):
[ 352.974066] Shutdown Ports..
[ 353.013281] writing reset reason 16, port-profile hap reset
Aug 14 16:53:20 %LIBSYSMGR-3-SIGTERM_FORCE_EXIT Service "u2rib" (PID 5141) is forced exit.
Aug 14 16:53:20 %LIBSYSMGR-3-SIGTERM_FORCE_EXIT Service "vshd" (PID 3555) is forced exit.
Aug 14 16:53:20 %LIBSYSMGR-3-SIGTERM_FORCE_EXIT Service "urib" (PID 3651) is forced exit.
...
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Unmounting filesystems...
[ 362.939993] Resetting board
(c) Copyright 2012, Cisco Systems.
NC-64 BIOS v.1.6.0, Mon 10/21/2013, 12:26 PMKernel uptime is 0 day(s), 0 hour(s), 2 minute(s), 33 second(s)
Last reset at 397089 usecs after Sun Aug 14 20:34:22 2011
Reason: Reset triggered due to HA policy of Reset
System version: 6.0(2)N2(6)
Service: port-profile hap reset
Conditions:
VLANs converted to fabricpath mode.
Workaround:
N/A
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur12427 |
Title: | 5672UP unable to read sensors temperature |
|
Description: | Symptom:
In a Nexus 5672 series switch running NX-OS 7.0(4)N1(1) and 7.0(5)N1(1), fans run at full speed all the time and output of show environment temperature giving an empty output at all
time:
Nexus5672# sh environment temperature
Temperature
-----------------------------------------------------------------
Module Sensor MajorThresh MinorThres CurTemp Status
(Celsius) (Celsius) (Celsius)
-----------------------------------------------------------------
Nexus5672#
Conditions:
Seen in 5672UP running NX-OS 7.0(4)N1(1) and 7.0(5)N1(1). This issue does NOT affect Nexus 55xx,56128 or Nexus 600x platforms.
Workaround:
None. NX-OS 7.1(0)N1(1) and 7.0(5)N1(1a) do have the fix.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 7.0(4)N1(1), 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.679), 7.0(1)ZN(0.740), 7.0(5)N1(1a), 7.0(6)N1(0.2), 7.0(6)N1(0.240), 7.0(6)N1(1), 7.1(0)N1(0.405), 7.1(0)N1(1), 7.1(0)ZN(0.480), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCut29939 |
Title: | Nexus 6k Kernel Panic with Corrupted CPU Process Name |
|
Description: | Symptom:
Kernel Panic reload, with a corrupted CPU process:
CPU 5
Process ??????]???????????u??????}????????????]??????????& (-2020868097)
Conditions:
Unknown
Workaround:
Unknown
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 19-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur09539 |
Title: | Series:Unknown MDS Chassis for N72 and N128 |
|
Description: | Symptom:
when call home message is sent, the message content does not contain correct product series for N72 and N128 chassis
Conditions:
none
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.349) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.299), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.373), 7.1(0)N1(1), 7.1(0)OTT(0.41) |
|
|
| |
| |
Bug Id: | CSCup79161 |
Title: | N6K - slow snmp response when polling ciscoVlanMembershipMIB |
|
Description: | Symptom:
slow snmp response occurred from N6k switch
Conditions:
NMS server is polling ciscoVlanMembershipMIB to N6K switch.
Workaround:
none
Further Problem Description:
none
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N1(2), 7.0(0)N1(1.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut69584 |
Title: | SNMP process crash with DCNM discovery with new SNMP username |
|
Description: | Symptom:
Device sees a snmpd process crash.
Logs might show similar to:
2015 Mar 30 15:14:27.949 ipt-zbl103-m-fb-02 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 8266) hasn't caught signal 11 (core will be saved).
2015 Mar 30 15:14:38.354 ipt-zbl103-m-fb-02 %$ VDC-1 %$ 30 15:14:38 %KERN-0-SYSTEM_MSG: [ 4691.029783] Shutdown Ports.. - kernel
2015 Mar 30 15:14:38.358 ipt-zbl103-m-fb-02 %$ VDC-1 %$ 30 15:14:38 %KERN-0-SYSTEM_MSG: [ 4691.064149] writing reset reason 16, snmpd hap reset - kernel
Conditions:
The issue appears to occur with DCNM discovery with new SNMP username authenticated through tacacs.
This is specific to a situation where the tacacs server is configured to give 2 roles to the username that is used
authenticate on the switches via dcnm.
I.e. tacacs gives the role "network-admin" AND "vdc-admin"
Workaround:
from the tacacs server, remove the role "vdc-admin" only apply the role "network-admin" to the userid, used by dcnm to manage the switches.
Further Problem Description:
Customer Issue:
---------------------
Customer basically implemented a new DCNM server within the same subnet connected to same switch and restore the old LDAP database backup. After this, Customer changed the SNMP username in the switch to a dedicated username. Earlier switch was having default username (admin). This new dedicated SNMP username is through Tacacs. Also the switch login username is same as SNMP username and is also through Tacacs.
So DCNM ssh to Switch with same username as SNMP username.
Crash happened after customer changed the SNMP username in the switch and is keep on crashing.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq61734 |
Title: | ACLMGR crash on 'show startup-configuration' after access-list deletion |
|
Description: | Symptom:
A Nexus 5000 or Nexus 6000 switch may reload unexpectedly after the 'show startup-configuration' command is issued.
Conditions:
This issue is observed if an ACL which is applied to one or more interfaces or lines is deleted, and then the 'show startup-config' command is issued.
The removal of the ACL causes an inconsistency in an internal data structure, which leads to a crash and reload when 'show startup-config' is issued.
Workaround:
After the removal of the access-list, issue:
'copy running-config startup-config'
After that, all commands can be issued as normal, including 'show startup-config'.
Further Problem Description:
After rebooting a core file is generated for the "aclmgr" process.
Hardware
cisco Nexus 6004 Chassis ("Nexus 6004 Supervisor")
Intel(R) Xeon(R) CPU @ 2.00 with 16520224 kB of memory.
Processor Board ID FOC18070HSK
Device name: NEXUS-6K
bootflash: 7823360 kB
Kernel uptime is 0 day(s), 0 hour(s), 9 minute(s), 27 second(s)
Last reset at 597646 usecs after Wed Jul 30 17:26:21 2014
Reason: Reset triggered due to HA policy of Reset
System version: 7.0(2)N1(1)
Service: aclmgr hap reset <--------------------
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.549), 7.0(4)N1(0.156), 7.0(4)N1(1), 7.1(0)N1(0.319), 7.1(0)N1(1), 7.1(0)ZN(0.404) |
|
|
| |
| |
Bug Id: | CSCur01134 |
Title: | Nexus 6000: Powered-down due to fan policy trigger after ISSU |
|
Description: | Symptom:
A Nexus 6000 switch might power down itself after an ISSU upgrade. show version and show system reset-reason would indicate Powered-down due to fan policy trigger as reason.
esc-6004-rack16# show system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 920408 usecs after Fri Oct 10 09:42:01 2014
Reason: Powered-down due to fan policy trigger
Service:
Version: 7.0(4)N1(1)
Conditions:
Usually seen if a FAN is OIRed or fails during ISSU process.
Workaround:
None. Manually power cycle switch.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.0(4)N1(1), 7.1(0)N1(0.344) |
|
Known Fixed Releases: | 7.0(1)ZN(0.625), 7.0(5)N1(0.177), 7.0(5)N1(1), 7.0(6)N1(0.3), 7.0(6)N1(1), 7.1(0)EVN(0.18), 7.1(0)N1(0.372), 7.1(0)N1(1), 7.1(0)ZN(0.445), 7.1(2)N1(0.2) |
|
|
| |
| |
Bug Id: | CSCuq48578 |
Title: | Nexus5600/6000: Spico firmware crash after reload |
|
Description: | Symptom:
Intermittently some interfaces do not come up after reload with the latest SERDES SPICO FW. This is due to the SPICO crashing which prevents the link init from succeeding. The crash is caused when the page swapping required for link training is somehow interrupted and doesn't complete successfully.
Conditions:
This issue can occur during the booting or reload of Nexus 5600/6000 switches. May also be seen during normal runtime. This is seen for 40G ports.
Workaround:
A reload of the switch or if affected port is on an expansion module or LEM, a soft reset could recover the port.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.0(4)N1(0.138) |
|
Known Fixed Releases: | 7.0(4)N1(1), 7.1(0)N1(0.312), 7.1(0)N1(1), 7.1(0)ZN(0.398) |
|
|
| |
| |
Bug Id: | CSCut55443 |
Title: | FWM mac trace buffer memory corruption |
|
Description: | Symptom:
FWM crash and switch reloads.
Conditions:
No specific trigger; Mostly happens with PVLAN configuration.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.0(4)N1(0.10) |
|
Known Fixed Releases: | 7.1(1)N1(0.511), 7.1(1)N1(1), 7.1(1)ZN(0.67), 7.2(0)N1(0.180), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCus39651 |
Title: | N6000/N5600: CRC errors on random 40 Gig port after reload |
|
Description: | Symptom:
Random 40 gig interfaces may see CRC errors after the module or switch is reloaded.
Conditions:
Issue seen on Nexus 6000/5600 40G ports.
Affects both 6.x and 7.x release.
Workaround:
Shut/no shut of the interface fixes the issue. This bug is resolved in NX-OS 6.0(2)N2(7), 7.0(6)N1(1) and 7.1(1)N1(1). Note the NX-OS needs to be upgraded on both the transmitting and receiving side for the bug to be cleared.
Further Problem Description:
Note CRC errors could occur for other reasons too such as bad cabling, stomping etc. Signature of this defect.
1)On the switch seeing the CRC errors, the errors are counted as RX_PKT_CRC_NOT_STOMPED
Spine-2# sh int ethernet 1/1 | inc CRC
0 runts 0 giants 445226948 CRC 0 no buffer
Spine-2# show hardware internal bigsur port ethernet 1/1 counters rx | inc CRC
RX_PKT_CRC_NOT_STOMPED | 445226948 | 445226948 | 4641
RX_PKT_CRC_STOMPED | 0 | 0 | 0
Spine-2#
On the other side of the link, the frames are not leaving corrupted.
2)If it is due to this bug, a shut/no shut of the interface will clear the problem.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: | 6.0(2)N2(6.130), 6.0(2)N2(7), 7.0(6)N1(1), 7.1(1)N1(0.477), 7.1(1)N1(1), 7.1(1)ZN(0.30), 7.2(0)N1(0.114), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuq05505 |
Title: | Slowness in bringing vlan up on a vpc setup |
|
Description: | Symptom:
Slow bringup in svi interface after auto-config is applied.
Conditions:
When a new VLAN and vn-segment is added during auto-config in vPC setup. For example, the delay happens when a VRF /segment is not available on the leaf where a VM host is moved to.
Workaround:
None. VLAN will be in suspended state for about 20 - 30 seconds. It will resume operational automatically after vlan consistency check failure is cleared by the system.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.0(3)N1(0.76) |
|
Known Fixed Releases: | 7.0(1)ZN(0.763), 7.0(6)N1(1), 7.1(0)N1(0.279), 7.1(0)N1(1), 7.1(0)ZN(0.376) |
|
|
| |
| |
Bug Id: | CSCut35476 |
Title: | Bigsur FAULTY slot 0 asic 3, bigsur_stm_dma_monitor_timer_hdlr |
|
Description: | Symptom:
On a Nexus 6000/5600, an ASIC might get declared faulty and following log messages can be seen.
%USER-2-SYSTEM_MSG: Bigsur FAULTY slot 0 asic 3, bigsur_stm_dma_monitor_timer_hdlr - bigsurusd %BIGSURUSD-3-BIGSUR_SYSLOG_ERROR: EDMA update channel faulty on slot 0 asic 3
Several ports on the ASIC will be impacted due to this channel being stuck.
Conditions:
Seen on N6000/5600 during layer 2 instabilities such as L2 bridging loop.
Workaround:
If seen on a LEM, reload LEM. If seen on fixed switch, reload switch.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.134) |
|
Known Fixed Releases: | 6.0(2)N2(6.135), 6.0(2)N2(7), 7.0(6)N1(0.267), 7.0(6)N1(1), 7.1(1)N1(0.493), 7.1(1)N1(1), 7.1(1)ZN(0.46), 7.2(0)N1(0.162), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCul96045 |
Title: | Video traffic quality (MOS score) degraded when vpc+ peer-devices fails |
|
Description: | Symptom:
Video quality of MOS score degradation is seen for long 2 minutes when one of the VPC+ peer-devices fails then restores.
Conditions:
VPC+ configuration.
Workaround:
Unknown
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu16775 |
Title: | NVE config is missing after doing ISSU from IPLUS_1A to JANJUC_191 |
|
Description: | Symptom:
VXLAN traffic will get dropped due to missing Network virtualization interface (interface nve) configuration.
Conditions:
Vxlan feature configured on Nexus OS version 7.1.x and upgrading from this version to Nexus OS version 7.2.
Workaround:
Copy the saved running-configuration to switch's running configuration using the command "copy running-config". This will restore the missing configuration related to nve interfaces. Since other parts of configuration already existed prior to the operation of copying save file to running-config, certain warnings will be displayed. These warnings can be ignored.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.191) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut74135 |
Title: | Fabricpath mode transit - control packets tagged with internal vlan 4041 |
|
Description: | Symptom:
On a Nexus 6000/5600 running fabricpath , when fabricpath mode transit is configured, the switch is sending control packets like CDP, LACP, ISIS tagged with internal VLAN ID 4041.
This causes a switch like N7K drop the packet. None of the protocols are able to negotiate and come up
Conditions:
Command fabricpath mode transit is configured.
Workaround:
Disable transit mode and reload the switch.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.269), 7.1(1)N1(0.508), 7.2(0)N1(0.147) |
|
Known Fixed Releases: | 7.0(1)ZN(0.780), 7.0(6)N1(1), 7.1(1)N1(0.511), 7.1(1)N1(1), 7.1(1)ZN(0.67), 7.2(0)N1(0.167), 7.2(0)N1(0.180), 7.2(0)N1(1), 7.2(0)ZN(0.170) |
|
|
| |
| |
Bug Id: | CSCur30099 |
Title: | Nexus 6000 : evaluation of SSLv3 POODLE vulnerability |
|
Description: | Symptom:
This product includes a version of SSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-3505
CVE-2014-3506
CVE-2014-3507
CVE-2014-3508
CVE-2014-3510
CVE-2014-3566 (POODLE)
This bug has been opened to address the potential impact on this product.
Conditions:
The POODLE Security issue CVE-2014-3566 exists if we configure LDAP as part of DFA configuration
Something like this
fabric database type network
server protocol ldap ip 10.95.126.166 vrf management
Or
Onep is configured with "transport type tls ..." option
Or
vmtracker configuration
Workaround:
1. Avoid any LDAP configuration
2. For DFA configuration use XMPP "server protocol xmpp .." or "server protocol radius ..." instead of LDAP
3. Do not use onep
Further Problem Description:
A POODLE attack requires a man in the middle attack between the nexus5000/6000 switch (the LDAP client)
and the LDAP server. It would also require a protocol downgrade attack since, by default, nexus5000/6000
uses TLS protocol.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the
time of evaluation are: 2.6/2.5
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 24-MAY-2015 |
|
Known Affected Releases: | 7.9(0)ZD(0.4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut77417 |
Title: | APRIL 2015 NTPd Vulnerabilities |
|
Description: | Symptom:This product includes a version of ntpd that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-1798 and CVE-2015-1799
This bug has been opened to address the potential impact on this product.
Conditions:The configurations that can expose the vulnerability are
ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234
ntp peer 1.2.3.4 key 1
Exposure is configuration dependent
Workaround:Not available
More Info:PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 4.3/3.2
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:P/A:N/E:U/RL:OF/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 24-MAY-2015 |
|
Known Affected Releases: | 7.1(0)ZN(91.305) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup76343 |
Title: | Missing XML output for "show feature-set" on N6K |
|
Description: | Symptom:
Show feature output not available in XML format
Conditions:
N/A
Workaround:
Use 'show feature' cli.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 6.0(2)ZK(99.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur30631 |
Title: | Nexus 6000: FWM crash with not enough core files saved |
|
Description: | Symptom:
A Nexus 6000 switch running 6.0(2)N2(3) might crash in FWM process.
Conditions:
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: | 5.2(1)N1(8.157), 5.2(1)N1(9), 6.0(2)A5(1.37), 6.0(2)A5(2), 6.0(2)A6(1.105), 6.0(2)A6(2), 6.0(2)N2(5.114), 6.0(2)N2(6), 6.0(2)U5(1.37), 6.0(2)U5(2) |
|
|
| |
| |
Bug Id: | CSCul27531 |
Title: | N6K - TX_PKT_FRAME_ERROR |
|
Description: | Symptom:
output errors on interfaces, no input errors
Conditions:
It was found that the IDS checksum error checking was contributing to the output errors.
Workaround:
None. Confirmed issues are not seen after upgrading to 6.0(2)N2(3).
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuh44731 |
Title: | Packets with incorrect L4 header checksum: CRC stomped at FWE |
|
Description: | Symptom:
Nexus 5k and Nexus 6k ASICs can potentially cause packets sent by the ASA CCL link to become corrupted and dropped due to CRC errors. This is because the ASA adds additional information to the end of the CCL packets which causes the Layer 4 header to experience checksum failures. The Nexus 5k and 6k causes these checksum issues to become L2 checksum failures. As a result, the problem ends up as CRC errors on the ASA.
Conditions:
This is primarily caused when the ASA is configured with clustering and the CCL links are connected to a N5K or N6K.
Workaround:
None. Do not use the N5K and N6K interfaces for the ASA CCL links.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N2(0.136), 6.0(2)N3(1) |
|
Known Fixed Releases: | 6.0(2)N2(1) |
|
|
| |
| |
Bug Id: | CSCus28101 |
Title: | N5K/6K: Inband TACACS traffic matched against exception-class in CoPP |
|
Description: | Symptom:
In a Nexus 5600/6000, TACACS/Radius traffic coming in on in band SVI interfaces hits class-exception class in Control plane policers.
Conditions:
TACACS/Radius used for access control and in band SVIs used for management Nexus 5600/6000. If there is violations in exception class, authentication failures can be seen due to this issue.
Workaround:
Use mgmt0 interfaces for managing Nexus 5600/6000 switches.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: | 6.0(2)N2(6.129), 6.0(2)N2(7), 7.0(1)ZN(0.726), 7.0(6)N1(0.227), 7.0(6)N1(1), 7.1(1)N1(0.468), 7.1(1)N1(1), 7.1(1)ZN(0.20), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCut71208 |
Title: | traffic not forwarded from fwm to pktmgr |
|
Description: | Symptom:
pings towards SVI are not responded
Conditions:
currently unknown
Workaround:
start pinging from the affected chassis.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu24951 |
Title: | ACL Label Applied on Primary SVI Does Not Get Set On Secondary VLAN |
|
Description: | Symptom:
Traffic is not getting dropped by access-list applied to private vlan primary SVI.
Conditions:
Traffic is ingressing the switch on a standard L2 trunk in the secondary vlan and is to be routed, via the primary vlan SVI.
Workaround:
Apply the access-list to the physical ingress interface as a PACL instead of to the SVI as a RACL.
Further Problem Description:
This issue occurs because the ACL label only gets applied to the primary vlan, and not the secondary vlan:
Current running group id counter: 22
Group 21 configuration for asic id 4:
Label Table: [vacl]-[valid:1, size:512, used:65029]
In use labels:
0-4,512-65535
Global Label Table: [used:65029]
In use labels:
0-4,512-65535
Label:4 group:21, logical operators: <===================== Label 4
vlan 1.118: pi vacl_label 4 span_ssn_id 255 <================ Label 4 is programmed on the Primary vlan
vlan 1.118: pi vacl_label 4 span_ssn_id 255
vlan 1.118 pd: int-vlan 19 state table idx 19 vacl_label 4 mbr_bitmap_idx 19, vlan_flags 0x1
vlan 1.119: pi vacl_label 0 span_ssn_id 255 <================ Label 4 is not programmed on the Secondary vlan
vlan 1.119: pi vacl_label 0 span_ssn_id 255
vlan 1.119 pd: int-vlan 18 state table idx 18 vacl_label 0 mbr_bitmap_idx 18,
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.7) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut60043 |
Title: | N6004 - 40g transceivers have delay for link-up on module boot |
|
Description: | Symptom:
On Nexus 6004 chassis or module reload 40g interfaces can take up to 50 minutes to come online and forward traffic. Seen with QSFP-40G-LR and WSP-Q40GLR4L, though we do not expect it to be limited to just these transceivers
Conditions:
Reloading a chassis or LEM module that contains at least one 40g transceiver in a 6004 chassis
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 7.0(2)N1(1), 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo87565 |
Title: | N5k/6k suspends vPC+ legs on primary after replacing the vPC+ peer |
|
Description: | Symptom:
N5k/6k suspends vPC+ legs on Primary switch after replacing the vPC+ secondary peer.
Conditions:
- replace vpc+ peer, and then vpc peer-link become down.
- down reason is "suspended by vpc"
- in "show system internal vpcm info all", existing vpc peers table does not update.
Workaround:
As the vPC+ peers table times out after 20 minutes, wait 20+ minutes before replacing a vPC+ peer.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N2(3), 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue02576 |
Title: | N5K / N6K: port-profile service crash after VLAN changes |
|
Description: | Symptom:
Port-profile crash when VLAN topology is modified.
2013 Jan 11 17:46:45 SWITCH %SYSMGR-2-SERVICE_CRASHED: Service "port-profile" (PID 3599) hasn't caught signal 11 (core will be saved).
2013 Jan 11 17:46:45 SWITCH %SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "port-profile" in vdc 1 has had a hap failure
This crash has also been seen in a FabricPath environment when issuing 'show platform fwm info l2mp ftag <>' for a non-existent ftag id.
In some cases, due to CSCue55816, there may not be any core file available for investigation.
The 'show process log' can be used to decode the stack and confirm whether this bug is being hit.
Conditions:
This is a corner case condition which has been seen in several situations, all of which involving changes to the VLAN topology.
- In a FabricPath environment, when moving VLAN(s) from one topology to another
- In a classical ethernet environment, when removing the access VLAN from a port
- After a reboot of a connected FEX, which triggers VLAN reprogramming on the parent switch
There are likely other, unknown triggers as well.
Workaround:
No known workaround.
Further Problem Description:
This issue is fixed in the version 5.2(1)N1(7) as it is found on 5.2(1)N1(5)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N1(0.376), 6.0(2)N1(1) |
|
Known Fixed Releases: | 5.2(1)N1(5), 5.2(1)N1(6), 5.2(1)N1(7), 9.9(0)BS(0.13) |
|
|
| |
| |
Bug Id: | CSCus55778 |
Title: | A Nexus 6000 may reload unexpectedly due to a vPC hap reset |
|
Description: | Symptom:
A Nexus 6000 may reload unexpectedly due to a vPC hap reset induced by a memory leak.
Conditions:
This issue has been observed after an ISSU upgrade to 7.1(0)N1(1).
Workaround:
There are no known workarounds at this time.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.1(1)N1(0.471), 7.1(1)N1(0.475), 7.1(1)N1(0.485), 7.2(0)N1(0.65) |
|
Known Fixed Releases: | 6.0(2)A5(1.37), 6.0(2)A5(1.41), 6.0(2)A5(1.43), 6.0(2)A5(2), 6.0(2)A6(1.104), 6.0(2)A6(1.117), 6.0(2)A6(1.127), 6.0(2)A6(2), 6.0(2)U5(1.37), 6.0(2)U5(1.41) |
|
|
| |
| |
Bug Id: | CSCut67164 |
Title: | [SS fex] rx queue-limit not working |
|
Description: | Symptom:
Rx queue-limit will not work as per configured value
Conditions:
Rx queue-limit will not work as per configured value
Workaround:
NA
Further Problem Description:
Rx queue-limit will not work as per configured value
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.149) |
|
Known Fixed Releases: | 7.2(0)N1(0.172), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.174) |
|
|
| |
| |
Bug Id: | CSCuq61301 |
Title: | FEX FCOE FCNS FC4-TYPE:FEATURE incomplete, empty. |
|
Description: | Symptom:
FEX attached FCoE host showing FCNS FC4 is incomplete, empty.
FCoE initiator lose access to Storage
Conditions:
This issue affects both N6K-600x and N56xx
FCOE Host attached to FEX
Workaround:
Connect Host to Base N6K.
or
Reload N6K/N5K to restore connectivity
Further Problem Description:
Resolution Summary:
Please Note: If you hit this issue and upgrade to a fixed release, you will still need to reload the switch in order to resolve the issue permanently.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | 6.0(2)N2(5.98), 6.0(2)N2(6), 7.0(1)ZN(0.699), 7.0(6)N1(0.207), 7.0(6)N1(1), 7.1(0)N1(0.347), 7.1(0)N1(1), 7.1(0)ZN(0.425) |
|
|
| |
| |
Bug Id: | CSCut08643 |
Title: | N5K CoPP does not match router ISIS packets |
|
Description: | Symptom:
Router ISIS packets are not matched by the ISIS copp class and router ISIS packets will be hit by class defualt
Conditions:
none
Workaround:
Cannot add customer class map to N5K CoPP.
Can increase class default rate to allow more packets to the cpu
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a), 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.2(0)AB(9), 7.2(0)N1(0.157), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.161) |
|
|
| |
| |
Bug Id: | CSCus29400 |
Title: | FCPC cores and triggers hap reset while allocating response payload |
|
Description: | Symptom:
A Nexus 6000 or 56xx switch running 7.0(3)N1(1) may trigger a hap reset due to an unexpected FCPC crash:
N6K %$ last message repeated 1 time
N6K%$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "fcpc" (PID 4247) hasn't caught signal 6 (core will be saved).
N6K %$ VDC-1 %$ %SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "fcpc" in vdc 1 has had a hap failure
N6K %$ VDC-1 %$ 22 05:35:42 %KERN-0-SYSTEM_MSG: [12049989.661356] Shutdown Ports.. - kernel
N6K %$ VDC-1 %$ 22 05:35:42 %KERN-0-SYSTEM_MSG: [12049989.698850] writing reset reason 16, fcpc hap reset - kernel
Conditions:
FCPC crash can be seen with around 32 physical FC ports in the switch. The leak is less and can take days to crash. Happens only on 56xx nexus switch.
Workaround:
Reload the box to restore the memory to normal
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 7.0(3)N1(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.776), 7.0(6)N1(0.267), 7.0(6)N1(1), 7.1(1)N1(0.495), 7.1(1)N1(1), 7.1(1)ZN(0.48), 7.2(0)N1(0.162), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.164) |
|
|
| |
| |
Bug Id: | CSCur02975 |
Title: | Nexus56xx/6k switches may take ~25 sec to respond to some show CLI's |
|
Description: | Symptom:
Nexus 56xx/6k switches may see a ~25-30 seconds delay on executing "show running-config" or "show startup-config"
Also seen with "show running-config interface <>" CLI's.
Worse case scenario leads to crash as well on executing above CLI's.
Conditions:
Switches running 7.0.x releases with breakout interface configuration:
interface breakout slot 1 port 49-52 map 10g-4x
During internal and external test above symptoms were only observed with 7.0(4)N1(1) and later releases.
Workaround:
To view running or startup config exclude cdp:
- show running-config exclude cdp
- show startup-config exclude cdp
Do not execute "show running-config interface <>" CLI and use the above two listed. Same with startup-config.
7.1(0)N1(1) and later release currently have the fix and not impacted by this issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.344) |
|
Known Fixed Releases: | 7.0(1)ZN(0.724), 7.0(6)N1(0.227), 7.0(6)N1(1), 7.1(0)N1(1), 7.2(0)N1(1), 7.2(0)ZN(0.91), 7.3(0)N1(0.3), 7.3(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCup78930 |
Title: | 'fex' process crash after switches in fabric-path are reset |
|
Description: | Symptom:
A switch may experience a HAP reset due to the 'fex' process crashing.
Conditions:
At this time, the only possible known condition for this crash is that the switches that reset are in the same fabric-path of other switches which also reset.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-MAY-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 6.0(2)N2(5.87), 6.0(2)N2(6), 7.0(1)ZN(0.514), 7.0(4)N1(0.142), 7.0(4)N1(1), 7.1(0)ZN(0.385) |
|
|
| |
| |
Bug Id: | CSCut95490 |
Title: | JanJuc166 Vinci FE - traffic issue when core links are shut |
|
Description: | Symptom:on a vinci FE set up ,when the links to the spine are shut ,the traffic is not going through mct.
Conditions:
Workaround:
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.174), 7.2(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo28747 |
Title: | N5K/6K: FWM core during ISSU |
|
Description: | Symptom:A Nexus 5K/6K switch may experience a crash in the fwm process upon ISSU in NX-OS 7.x
Conditions:An double step ISSU is performed on Nexus 5K/6K. For example from a 6.x release to a 7.0 and another ISSU to a subsequent 7.0/7.1 release
Workaround:Disable IGMP snooping before the first ISSU is performed from 6.x to 7.0 release. Re-enable IGMP snooping after first ISSU to 7.0 release is complete. If running Fabricpath, IGMP snooping needs to be disabled in all switches in the fabric
More Info:This bug gets triggered due to duplicate multicast entries in PSS during first ISSU to 7.0 release.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu46633 |
Title: | interface vethernet X enters interface range configuration mode |
|
Description: | Symptom:
When configuring "interface vethernet X", the configuration mode changes to interface range mode when it should change to interface mode.
Conditions:
Nexus5600# sh run | i i "system default switchport"
no system default switchport
Nexus5600#
Nexus5600# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Nexus5600(config)# int vethernet 7777
Nexus5600(config-if-range)# bind ?
^
% Invalid command at '^' marker.
Workaround:
Nexus5600(config)# system default switchport
Nexus5600(config)# no interface vethernet 7777
Nexus5600(config)# int vethernet 7777
Nexus5600(config-if)# bind ?
interface Interface
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup45280 |
Title: | kernel panic in ethpm |
|
Description: | Symptom:
Kernel panic crashes in ethpm:
sc1-c08-6k1-1# show system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 359759 usecs after Fri Jun 3 14:52:27 2011
Reason: Kernel Panic
Service:
Version: 7.0(2)N1(1)
sc1-c08-6k1-1# show logging onboard stack-trace
Logging time: Fri Jun 3 14:52:25 2011
1307137945:79999999 process ethpm (3966), jiffies 0x2a17a30
invalid opcode
STACK
CPU 6
Process ethpm (3966)
Stack:
Call Trace:
[<801813fc>]page_remove_rmap+0xc6/0xfc
[<8017a4c3>]unmap_vmas+0x344/0x598 (116)
[<8017e2bb>]exit_mmap+0x68/0xe4 (40)
[<80128062>]mmput+0x33/0x86 (12)
[<8012b7b4>]exit_mm+0xe9/0xf1 (32)
[<8012cceb>]do_exit+0x1dd/0x745 (68)
[<8012d2b6>]do_group_exit+0x63/0x8a (20)
[<801358d1>]get_signal_to_deliver+0x2df/0x2f6 (48)
[<80102c33>]do_notify_resume+0x70/0x779 (220)
[<80103b2e>]work_notifysig+0x13/0x25 (-8112)
Conditions:
Unknown
Workaround:
None at this time
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu06261 |
Title: | N6k Vinic-Forwarding: Multicast failing to reciever after leaf reload |
|
Description: | Symptom:
Receiver off leaf failing to receive multicast traffic after leaf reload and after resending igmp joins.
Conditions:
Leaf reload with a multicast receiver hanging off of it.
Workaround:
Preform a shut/no shut on the VRF to which the impacted receiver belongs to.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut05530 |
Title: | IPLUS_464_VXLAN_SCALE_Testbed: FWM core after flapping NIF ports |
|
Description: | Symptom:
FWM Core.
Conditions:
After flapping NIF port in scale topology.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.1(1)N1(0.464) |
|
Known Fixed Releases: | 7.1(1)ZN(0.116), 7.1(2)N1(0.537), 7.1(2)N1(1a), 7.2(0)AB(9), 7.2(0)N1(0.153), 7.2(0)N1(1), 7.2(0)ZN(0.156) |
|
|
| |
| |
Bug Id: | CSCuu00391 |
Title: | N5K/6K: BCAST flag missing for FTAG 2 |
|
Description: | Symptom:
In a Nexus 5K/6K configured for vPC+, broadcast flag will be missing for FTAG 2 on the vPC+ switch which has affinity for FTAG2
5596A# sh platform fwm info l2mp ftag 2 hw
L2MP FTAG
--------------------------------------------------------------
ftag[0x9ed03e4] id: 2 (0x2)
Topology ID: 0 (0x0)
Ftag flags: MCAST ACTIVE <<------Broadcast Flag is missing
Is stale: FALSE
alternate: 0
ftag_ucast_index: 0
ftag_flood_index: 0
ftag_mcast_index: 65
ftag_alt_mcast_index: 80
rpf: (null)
ftag_mask[0xa54f62c]
Conditions:
Seen in switches where both vPC+ pair go VPC Active/Active due to VPC auto-recovery
Workaround:
Reload the switch in question
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.1(1)N1(0.2), 7.1(1)N1(1a), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCut94663 |
Title: | JJ170: N128 device crashed with FWM cores |
|
Description: | $$IGNORE
Symptom:
FWM process crashes and switch reloads
Conditions:
Issue observed with script run and it happens with PVLAN configuration
Workaround:
No workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.170), 7.2(0)N1(0.182) |
|
Known Fixed Releases: | 7.2(0)N1(0.194), 7.2(0)N1(1), 7.2(0)ZN(0.197) |
|
|
| |
| |
Bug Id: | CSCur89241 |
Title: | N2K-C2348 FEX does not come up due to "SDP timeout/SFP Mismatch" |
|
Description: | Symptom:
A Nexus N2K-C2348TQ-10GE or N2K-C2348UPQ-10GE FEX connected to a Nexus 5K/6K parent might not come up at all or intermittently fail to come up after reloads. A show interface on the parent switch will indicate the FEX fabric interfaces to be in SDP timeout/SFP Mismatch state
N6K(config-if-range)# show int eth 1/21-28 brief
--------------------------------------------------------------------------------
Ethernet VLAN Type Mode Status Reason Speed PortInterface Ch #
--------------------------------------------------------------------------------
Eth1/21 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/22 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/23 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/24 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/25 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/26 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/27 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/28 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Conditions:
Seen in a N2K-C2348TQ-10GE or N2K-C2348UPQ-10GE FEX connected to a Nexus 5K/6K. This issue is resolved in NX-OS 7.1(1)N1(1)
Workaround:
Upgrade the parent N5K/6K to NX-OS 7.1(1)N1(1) and power cycle the the FEX few times with fabric connection to the parent in place. If the FEX does not come online contact TAC
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.412) |
|
Known Fixed Releases: | 7.1(1)N1(1), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuq46228 |
Title: | FWM hap reset at fwm_ds_trace_add() |
|
Description: | Symptom:FWM core happens at fwm_ds_trace_add() routine.
Conditions:If FWM trace buffer size is configured as 300MB,then this problem can occur
Workaround:Configure FWM trace buffer size as 20,40 or 80MB.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 31-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.291) |
|
Known Fixed Releases: | 7.1(0)N1(0.1), 7.1(0)N1(0.363), 7.1(0)N1(1), 7.1(0)ZN(0.438), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.2(0)N1(0.2), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCut83532 |
Title: | 5600 vPC Pair loops back unknown unicast packets |
|
Description: | Symptom:
MAC move notifications on switch connected to 5600 vPC pair.
Conditions:
Nexus 5600 in vPC, unknown unicast packets hitting the switch.
Workaround:
We can static the MAC addresses on the connected swtich(es) to avoid looping the frames in the network and losing flows when the flap occurs, but this is not a good option if the MAC moves under a normal network circumstance, e.g. Vmotions in a VMware environment.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 31-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.1(1)N1(0.512) |
|
Known Fixed Releases: | |
|
|
| |
没有评论:
发表评论