Cisco Notification Alert -Nexus 5000 Series Switch-04-Jul-2016 05:39 GMT

Feedback Sign Up Unsubscribe         End-of-Sale and End-of-Life Announcements - Nexus 5000 Series Switches Title: End-of-Sale and End-of-Life Announcement for the Cisco Nexus 5548P Switch Description: Cisco announces the end-of-sale and end-of-life dates for the Cisco Nexus 5548P Switch. The last day to order the affected product(s) is September 26, 2015. Customers with active service contracts will continue to receive support from the Cisco Technical Assistance Center (TAC) as shown in Table 1 of the EoL bulletin. Table 1 describes the end-of-life milestones, definitions, and dates for the affected product(s). Table 2 lists the product part numbers affected by this announcement. For customers with active and paid service and support contracts, support will be available under the terms and conditions of customers' service contract. Date: 16-JUN-2016 Find additional information in End-of-Sale and End-of-Life Products Field Notice - Nexus 5000 Series Switches Title: Field Notice: FN - 63893 - N55-PAC-1100W PSU Silent Reload Failure Description: A particular component failure in N55-PAC-1100W and N55-PAC-1100W-B power supply units (PSUs) can cause the entire N5500 switch to reload. Date: 14-JUN-2016 Find additional information in Field Notices Security Advisories & Responses - Nexus 5000 Series Switches Title: Cisco IOS Software Network Address Translation Denial of Service Vulnerability Description: A vulnerability in the Network Address Translation (NAT) feature of Cisco IOS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper translation of IP version 4 (IPv4) packets. Cisco has released software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140924-nat Note: The September 24, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep14.html Date: 01-JUN-2016 Title: Cisco Products IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability Description: A vulnerability in the IP Version 6 (IPv6) packet processing functions of multiple Cisco products could allow an unauthenticated, remote attacker to cause an affected device to stop processing IPv6 traffic, leading to a denial of service (DoS) condition on the device. The vulnerability is due to insufficient processing logic for crafted IPv6 packets that are sent to an affected device. An attacker could exploit this vulnerability by sending crafted IPv6 Neighbor Discovery (ND) packets to an affected device for processing. A successful exploit could allow the attacker to cause the device to stop processing IPv6 traffic, leading to a DoS condition on the device. This vulnerability is not Cisco specific: any IPv6 processing unit not capable of dropping such packets early in the processing path or in hardware is affected by this vulnerability. Cisco will release software updates that address this vulnerability. There are no workarounds that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160525-ipv6 Date: 01-JUL-2016 Find additional information in Cisco Security Advisories & Responses Software Updates for Nexus 5000 Series Switches Product Name: Nexus 5548P Switch Software Type: Data Center Network Manager Release Version: 10.0(1) Alert Type: New File File Name: dcnm-device-pack.10.0.1.DP.1.zip File Description: DCNM 10.0.1 Device Pack 1 File Release Date: 30-JUN-2016 Find additional information in Software Downloads index. Software Updates for Nexus 5000 Series Switches Product Name: Nexus 5010 Switch Software Type: Data Center Network Manager Release Version: 10.0(1) Alert Type: New File File Name: dcnm-device-pack.10.0.1.DP.1.zip File Description: DCNM 10.0.1 Device Pack 1 File Release Date: 30-JUN-2016 Find additional information in Software Downloads index. Software Updates for Nexus 5000 Series Switches Product Name: Nexus 5596UP Switch Software Type: Data Center Network Manager Release Version: 10.0(1) Alert Type: New File File Name: dcnm-device-pack.10.0.1.DP.1.zip File Description: DCNM 10.0.1 Device Pack 1 File Release Date: 30-JUN-2016 Find additional information in Software Downloads index. Software Updates for Nexus 5000 Series Switches Product Name: Nexus 5548UP Switch Software Type: Data Center Network Manager Release Version: 10.0(1) Alert Type: New File File Name: dcnm-device-pack.10.0.1.DP.1.zip File Description: DCNM 10.0.1 Device Pack 1 File Release Date: 30-JUN-2016 Find additional information in Software Downloads index. Software Updates for Nexus 5000 Series Switches Product Name: Nexus 5020 Switch Software Type: Data Center Network Manager Release Version: 10.0(1) Alert Type: New File File Name: dcnm-device-pack.10.0.1.DP.1.zip File Description: DCNM 10.0.1 Device Pack 1 File Release Date: 30-JUN-2016 Find additional information in Software Downloads index. Known Bugs - Nexus 5000 Series Switches Alert Type: Updated * Bug Id: CSCur54642 Title: N5K with ERSPAN enabled may face a slow leak in 'monitor' process Status: Fixed Severity: 1 Catastrophic Description: Symptom: Nexus 5000 switch with ERSPAN enabled may see a slow leak in the 'monitor' process, and that can potentially lead to an unexpected crash (monitor hap reset). The issue was first seen in a Nexus 5596 running 6.0(2)N1(2). Conditions: ERSPAN session enabled Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N1(2) Known Fixed Releases: * 6.0(2)N2(5.120), 6.0(2)N2(6), 7.0(1)ZN(0.703), 7.0(6)N1(0.209), 7.0(6)N1(1), 7.1(1)N1(0.468), 7.1(1)N1(1), 7.1(1)ZN(0.20), 7.1(3)ZN(0.313), 7.2(0)N1(1) Alert Type: Updated * Bug Id: CSCun54561 Title: Zone hap reset Status: Fixed Severity: 1 Catastrophic Description: -- Symptom: Cisco Nexus5548 reset due to Zone Hap reset running version 6.0(2)N2(2) The behavior occurs while activating a zoneset with atleast 2 zones associated with it. Conditions: Running version 6.0(2)N2(2). This bug was seen while trying to activate a zoneset with atleast 2 zones associated with it. Workaround: None Further Problem Description: -- Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(2), 7.0(1)N1(1) Known Fixed Releases: * 6.0(2)N2(4.64), 6.0(2)N2(5), 7.0(1)ZN(0.502), 7.0(4)N1(0.135), 7.0(4)N1(1), 7.1(0)N1(0.289), 7.1(0)N1(1), 7.1(0)ZN(0.382), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCur47731 Title: CSCur59789 5596UP / Crash, Reload after setting a FC Port shut/no shut Status: Fixed Severity: 1 Catastrophic Description: Symptom: After bringing up a FC interface - Nexus5k cored and reloaded Conditions: Flap the FC port, Either switch will crash or relead. Workaround: no Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(4) Known Fixed Releases: * 7.0(1)ZN(0.706), 7.0(2)FIP(0.6), 7.0(6)N1(0.211), 7.0(6)N1(1), 7.1(0)N1(0.419), 7.1(0)N1(1), 7.1(0)ZN(0.492), 7.1(1)N1(0.34), 7.1(1)N1(1), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCus64364 Title: N5K: carmelusd component got cored on O2 switch Status: Fixed Severity: 1 Catastrophic Description: Symptom: Nexus 5000 can experience crash 'carmelusd' process: ----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) --- 1) At 986420 usecs after Sat Dec 27 23:24:13 2014 Reason: Reset triggered due to HA policy of Reset Service: carmelusd hap reset Version: 5.2(1)N1(6) Conditions: N/A Workaround: N/A Further Problem Description: During the Carmel log display, Current log pointer got exceeded over End log pointer by one thread and at the same time another thread accessed current pointer for log wrapping scenario and tried memory set on left over memory. For memory set operation size is determined using End pointer subtracting Current pointer. This operation generated the negative size value for memset call, resulting memory crash. Due to this Carmel got Core. Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(6), 7.1(1)N1(1) Known Fixed Releases: * 7.0(7)N1(0.65), 7.0(7)N1(1), 7.0(7)ZN(0.141), 7.1(2)N1(0.565), 7.1(2)N1(1), 7.1(2)ZN(0.25), 7.1(3)ZN(0.313), 7.2(1)N1(0.245), 7.2(1)N1(1), 7.2(1)ZN(0.11) Alert Type: Updated * Bug Id: CSCux24542 Title: FCoE FLOGI from NPV switch gets LS_RJT due to solicit not done Status: Fixed Severity: 1 Catastrophic Description: Symptom:FCoE FLOGI from NPV switch gets LS_RJT due to FIP solicitation not done. The LS_RJT contains: Reason Code: 0x09 - "Unable to perform command" Reason Explanation: 0x29 - "Insufficient Resources for Login" Conditions:Occurs when there is an FCoE NPV to NPIV link only. Workaround:There are two known workarounds: 1 - Connect the devices involved into the NPIV switch itself. 2 - Change the NPV-NPIV link to a trunking connection where the port VSAN is a higher numbered VSAN than the VSAN being used by the devices. This should cause the NPV switch to choose that new higher numbered VSAN to do the FLOGI that brings the link up. Now the devices that FLOGI across that link using their VSAN without FLOGI failures. More Info:The problem occurs when there are two (or more) devices logging into the NPIV switch from the NPV switch. Both devices do the FIP solicitation and get the FIP Advertisement. The first device successfully logs in and then logs out before the second device logs in. Now, the second device sends in its FLOGI and it gets rejected because the NPIV switch turned off the indication that the FIP solicitation was done. Resolution Summary: The code has been modified to not turn off the "FIP Solicitation done" indication on the NPIV switch when processing the LOGO if there are other devices FLOGI'd in on the same VSAN. If the connection between the NPV switch and NPIV core switch is carrying more than one VSAN(trunking), and there is at least one FLOGI on another VSAN when the LOGO occurs, then the NPV switch will initiate a FIP Solicitation. However, this is existing function and has been unmodified. Last Modified: 28-JUN-2016 Known Affected Releases: 6.0(2)N1(2a), 7.0(7)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.136), 7.1(3)ZN(0.313), 7.1(4)N1(0.701), 7.1(4)N1(1), 7.2(2)N1(0.355), 7.2(2)N1(1), 7.2(2)ZN(0.39), 7.3(0)IZN(0.13), 7.3(0)N1(0.236), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuw19708 Title: Nexus 5000 crashes when removing VM tracker config from the interfaces Status: Fixed Severity: 2 Severe Description: Symptom: Switch crash with "vmtracker hap reset" Conditions: Removing VM tracker config from the range of interfaces Workaround: None Further Problem Description: Last Modified: 28-JUN-2016 Known Affected Releases: 7.1(2)N1(0.599) Known Fixed Releases: * 7.1(3)N1(0.633), 7.1(3)N1(1), 7.1(3)ZN(0.41), 7.2(2)N1(1), 7.3(0)N1(1), 7.3(0)ZN(0.123), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuw28001 Title: Switch reloads while ND ISSU with Lacp failure-maximum downtime exceeded Status: Fixed Severity: 2 Severe Description: Symptom: ISSU failure on N5672-8G switch during ISSU with error of LACP failure of "maximum downtime exceeded" The below string will be displayed to the user:- "Upgrade has failed. Return code 0x40930085 (lacp failure - maximum downtime exceeded)" Rebooting the switch to recover. [ 230.307510] Shutdown Ports.. [ 230.342086] writing reset reason 3, ISSU failure: 0x40930085 Conditions: During ISSU on 5672-8G switch. Workaround: None Further Problem Description: The LACP failure in this case was happening due to microcontrollers(these microcontrollers are used to access SFPs, only the control(LED status, SPROM data of SFP etc..) not the LOS/Datapath- datapath is controlled by bigsur) getting timedout during ISSU just after kexec of new kernel. These controllers are enumerated as USB devices in the kernel and need to re-probe and sync with the new kernel, some times these devices fail to get initialized and as the timeout for USB operations was 45 secs and in 5672 there are 3 microcontrollers and hence was causing a delay of more than 80 secs which is the maximum downtime for LACP. The reason for USB devices not responding is not clear and the failure is not consistent and as of now its reproduced more often on 5672UP platform only. Fix ==================================== There are 2 approaches taken for fixing the issue completely. 1. USB timeout is being reduced from 45 secs to around 2 sec. 2. If any of the device fails to respond, the a list of these devices is maintained in the kernel which will be fetched by the PFMA module during te system image bootup which will perform the reset of the device to bring it to operational state. These USB devices (microcontrollers used to access SFP) dont impact the datapath of the interface, hence wont have any impact on the interface functionality. This fix is applicable only for 5672-8G Last Modified: 28-JUN-2016 Known Affected Releases: 7.3(0)N1(0.131) Known Fixed Releases: * 7.1(3)N1(1.5), 7.1(3)N1(2), 7.1(3)ZN(0.318), 7.1(4)N1(0.851), 7.1(4)N1(1), 7.3(0)IZN(0.13), 7.3(0)N1(0.221), 7.3(0)N1(1), 7.3(0)ZN(0.198), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuw73332 Title: VTPv3 mode changes from client to transparent after PVLAN creation Status: Fixed Severity: 2 Severe Description: Symptom: VTPv3 mode changes from client to transparent: 2015 Oct 14 17:27:22 Nexus5500 %VTP-2-VTP_MODE_TRANSPARENT_CREATE_SEQ_FAILED: VTP Mode changed to transparent since VTP vlan create/update failed. Conditions: VTPv3 Primary Server is configured on Catalyst 4900M switch. Nexus switches have at least one port with the following configuration: * switchport mode private-vlan trunk promiscuous * switchport private-vlan trunk allowed vlan A,B-C,D * switchport private-vlan mapping trunk X Y-Z Workaround: None at the moment. Further Problem Description: After the PVLAN is added on the VTPv3 Primary Server, we can see that PVLAN resources are locked on the Nexus 5500 switches until eventually there is a timeout and the VTPv3 mode changes from client to transparent. Nexus5500# show system internal private-vlan info System info: ------------ Global LOCKED Private VLANs ------------ private-vlan 1:1800 vlan-type is "unknown(8)" LOCKED primary=0, otxns=1 state: PVLAN_VLAN_STATE_NORMAL_TO_PRIMARY_VLAN_MGR associations(0): Last Modified: 28-JUN-2016 Known Affected Releases: 7.2(0)N1(1) Known Fixed Releases: * 7.2(2)N1(0.341), 7.2(2)N1(1), 7.2(2)ZN(0.24), 7.3(0)IZN(0.13), 7.3(0)N1(0.219), 7.3(0)N1(1), 7.3(0)ZN(0.196), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCux33230 Title: "ipqosmgr hap reset" during ISSU 7.1(2)N1(1)->7.1(3)N1(1) Status: Fixed Severity: 2 Severe Description: Symptom: Switch crash: Reason: Reset triggered due to HA policy of Reset System version: 7.1(3)N1(1) Service: ipqosmgr hap reset Conditions: ISSU 7.1(2)N1(1)->7.1(3)N1(1) Workaround: None Further Problem Description: Last Modified: 28-JUN-2016 Known Affected Releases: 7.1(3)N1(1) Known Fixed Releases: * 7.0(8)N1(1), 7.1(3)N1(1.3), 7.1(3)N1(2), 7.1(3)ZN(0.157), 7.1(4)N1(0.712), 7.1(4)N1(1), 7.2(2)N1(0.402), 7.2(2)N1(1), 7.2(2)ZN(0.86), 7.3(0)IZN(0.13) Alert Type: Updated * Bug Id: CSCux06003 Title: N6K POAP is failing with SSH HOST KEY Status: Fixed Severity: 2 Severe Description: Symptom: N6K upgrade from 7.2(1)N1(1) to 7.3(0)N1(1) does not work using POAP. Conditions: POAP upgrade of switches from 7.2(1)N1(1) to 7.3(0)N1(1) after DCNM upgrade is done. Workaround: Manually upgrade switches from 7.2(1)N1(1) to 7.3(0)N1(1). Further Problem Description: N/A Last Modified: 28-JUN-2016 Known Affected Releases: 7.2(2.34), 7.3(0)N1(0.191) Known Fixed Releases: * 7.1(3)N1(2.12), 7.1(3)N1(4), 7.1(3)ZN(0.115), 7.1(4)N1(0.689), 7.1(4)N1(1), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZN(0.18), 7.3(0)IZN(0.13), 7.3(0)N1(0.214) Alert Type: Updated * Bug Id: CSCuw92560 Title: N6K kernel panic crash qh_urb_transaction Status: Fixed Severity: 2 Severe Description: Symptom: N6K kernel panic crash Conditions: This has been seen on N6K running 7.0(7)N1(1) code Workaround: Not known Further Problem Description: Last Modified: 28-JUN-2016 Known Affected Releases: 7.0(7)N1(1), 7.1(3)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.276), 7.1(3)ZN(0.313), 7.1(4)N1(0.810), 7.1(4)N1(1), 7.3(1)N1(0.376), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuz85110 Title: vsh crashes @ create_snmpv3_user_after_aaa_authenticate Status: Fixed Severity: 2 Severe Description: Symptom: "vsh" process constantly crashes and these logs are observed: %VSHD-2-VSHD_SYSLOG_EOL_ERR: EOL function create_snmpv3_user_after_aaa_authenticate from library libaaacli.so exited due to Signal 11 and %SYSMGR-2-LAST_CORE_BASIC_TRACE: : PID #### with message vsh(non-sysmgr) crashed, core will be saved Conditions: Nexus device must be managed by an automated system which uses Radius to authenticate. The issue has been identified to arise when a few Data Center Network Management tools are used to monitor one device. Workaround: Disable the automated management system operation on the affected Nexus device. Further Problem Description: If "vsh" crashes very often, the number of core files saved can cause: %SYSMGR-3-VAR_SYSMGR_FULL: System Manager file storage usage is unexpectedly high at 100%. This may impact system functions. Which indicates that /var/sysmgr memory region is full: SF-DERC-01-kastE1# Show system internal flash Mount-on 1K-blocks Used Available Use% Filesystem ... /var/sysmgr 2048000 2048000 0 100 none <-- ... Last Modified: 28-JUN-2016 Known Affected Releases: 7.2(0)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.324), 7.1(4)N1(0.857), 7.1(4)N1(1), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuy49328 Title: N5596 kernel panic on carmelusd process Status: Fixed Severity: 2 Severe Description: Symptom: From the Kernel Trace: <6>[4411461.598671] SI-VDC map entry <0, 0x0> does not exist! <6>[4411461.598734] SI-VDC map entry <0, 0x0> does not exist! <6>[4411461.598798] SI-VDC map entry <0, 0x0> does not exist! <6>[4411461.598862] SI-VDC map entry <0, 0x0> does not exist! <4>[6981473.282562] hrtimer: interrupt took 7878 ns <6>[10203605.520193] igb: eth0: igb_watchdog_task: NIC Link is Down <6>[10203610.680642] igb: eth0: igb_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None <6>[10203622.740383] igb: eth0: igb_watchdog_task: NIC Link is Down <6>[ 10203643.440626 ] igb: eth0: igb_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None <0>[26297887.215373] BUG: soft lockup - CPU#0 stuck for 11s! [carmelusd:3439] <6>[26297887.215373] Modules linked in: klm_procfs_init(P) klm_tlv(P) klm_sse(P) klm_kpss(P) klm_cmos(P) klm_i2c klm_sdwrap(P) klm_sprom(P) klm_pfmcmn(P) klm_nvram_mtd klm_kbootctrl(P) klm_inband_igb klm_isan_kthread(P) klm_modlock(P) klm_vdc_mgr klm_obfl klm_cctrl2(P) klm_nvram(P) klm_vdc klm_if_index(P) klm_8021q klm_rwsem(P) klm_muxif klm_pss(P) klm_kadb(P) klm_fcfwd(P) klm_aipc(P) klm_mts(P) klm_mping(P) klm_carmel(P) klm_usbserial klm_rdn(P) klm_inb_hmon(P) klm_atherton(P) klm_gpl(P) klm_nuovaxcvr(P) linux_kernel_bde(P) linux_user_bde(P) klm_kfsmutils(P) klm_ipt_state klm_ip_conntrack_tftp klm_utaker klm_bonding klm_sysmgr-hb klm_ip_conntrack_ftp klm_kgdb(P) klm_ls_notify(P) klm_gatosfcp(P) klm_misc klm_usd klm_sup_ctrl_mc(P) <6>[26297887.215373] <6>[26297887.215373] Pid: 3439, comm: carmelusd Tainted: P W (2.6.27.47 #1) <6>[26297887.215373] EIP: 0073:[<080c160c>] EFLAGS: 00000202 CPU: 0 <6>[26297887.215373] EIP is at 0x80c160c <6>[26297887.215373] EAX: ffffffff EBX: 00000001 ECX: 00000382 EDX: 7fc72f58 <6>[26297887.215373] ESI: 00000000 EDI: 00000006 EBP: 7fc73008 ESP: 7fc72dc0 <6>[26297887.215373] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b <6>[26297887.215373] CR0: 8005003b CR2: 6c30cc40 CR3: 60062000 CR4: 000006f0 <6>[26297887.215373] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 <6>[26297887.215373] DR6: ffff0ff0 DR7: 00000400 <6>[26297887.215373] ======================= <0>[26297897.922520] BUG: soft lockup - CPU#1 finds CPU#0 to be locked up for 21s!. <2>[26297898.007748] KGDB: Waiting for remote debugge Conditions: kernel panic Workaround: no workaround at this time. Further Problem Description: chn-waik-ear01# show logging onboard stack-trace ---------------------------- OBFL Data for Module: 1 ---------------------------- ------------------ LOG 01 ------------------- Logging time: Tue Jan 5 21:01:38 2016 1452027698:00000012 process watchdog/1 (8), jiffies 0x9cbef338 invalid opcode STACK CPU 1 Process watchdog/1 (8) Stack: eb8b1f80: eb8b1f80: 93206507 000003f9 80456c02 eb8b1fb4 93206500 00000400 80451ea7 12c98000 eb8b1fa0: 00000000 0175b731 eb8b1fd0 8015c85f 80456c02 8055e88c 00000001 00000000 eb8b1fc0: 00000001 00000001 8015c615 00000000 eb8b1fe0 8013ae14 8013add4 00000000 eb8b1fe0: 00000000 80104cc7 eb88df08 00000000 000000 Last Modified: 28-JUN-2016 Known Affected Releases: 6.0(2)N2(2) Known Fixed Releases: * 7.1(3)ZN(0.324), 7.1(4)N1(0.857), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCut89123 Title: Kernel panic due to "insmod" process Status: Fixed Severity: 2 Severe Description: Symptom: The N5K might crash due to kernel panic running process "insmod". The "show logging onboard stack-trace" output doesn't contain any call traces, but Last Kernel Messages from the some output contains following error message: <1>BUG: unable to handle kernel NULL pointer dereference at 00000000 There are no core files or process logs. Conditions: normal Workaround: unknown at this point Further Problem Description: Last Modified: 29-JUN-2016 Known Affected Releases: 5.2(3a)E2, 6.0(2)N2(2), 7.1(1)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.325), 7.1(4)N1(0.858), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCue80077 Title: FEX: Port flap request from SAP: MTS_SAP_SATMGR Status: Fixed Severity: 2 Severe Description: Symptom: FEX Fabric Links flap. Conditions: This caveat is seen in a condition where spanning tree instabilities caused flood of CFSoE packets. This in turn caused congestion at control plane and thereby resulting in Satellite Discovery Protocol packets to drop and hence causing FEX interfaces to flap. If there are no instabilities in Spanning tree and/or CFSoE packets are not flooded at control plane and if the FEX flaps are still happening, then it is not related to this caveat. Please investigate the cause of control plane congestion and FEX interface flaps separately. Workaround: Links seem to recover on their own. Further Problem Description: Last Modified: 30-JUN-2016 Known Affected Releases: 5.1(3)N1(1a) Known Fixed Releases: * 5.2(1)N1(7.119), 5.2(1)N1(8), 7.0(7)N1(1), 7.0(7)ZN(0.130), 7.1(3)N1(0.608), 7.1(3)N1(1), 7.1(3)ZN(0.13), 7.1(3)ZN(0.313), 7.2(1)N1(0.262), 7.2(1)N1(1) Alert Type: Updated * Bug Id: CSCuz52401 Title: Evaluation of nexus-5000-all for OpenSSL May 2016 Status: Fixed Severity: 2 Severe Description: * Symptom: This product includes a version of OpenSSL that is affected by the vulnerability identified by one or more of the following Common Vulnerability and Exposures (CVE) IDs: CVE-2016-2108 CVE-2016-2107 CVE-2016-2105 CVE-2016-2106 CVE-2016-2109 CVE-2016-2176 And disclosed in https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160504-openssl This bug has been opened to address the potential impact on this product. Cisco has analyzed the vulnerabilities and concluded that this product may be affected by the following vulnerabilities: Memory corruption in the ASN.1 encoder CVE-2016-2108 Padding oracle in AES-NI CBC MAC check CVE-2016-2107 EVP_EncodeUpdate overflow CVE-2016-2105 EVP_EncryptUpdate overflow CVE-2016-2106 ASN.1 BIO excessive memory allocation CVE-2016-2109 This product is not affected by the following vulnerability: EBCDIC overread CVE-2016-2176 Conditions: Exposure is not configuration dependent. Workaround: None Further Problem Description: PSIRT Evaluation: The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base CVSS score as of the time of evaluation is: 5.1 https://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:H/Au:N/C:P/I:P/A:P/E:ND/RL:ND/RC:ND 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. The score reflects the maximum score for all the vulnerabilities mentioned in this bug information 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 Last Modified: 01-JUL-2016 Known Affected Releases: 7.3(0)ZN(0.258) Known Fixed Releases: * 7.1(3)ZN(0.328) Alert Type: Updated * Bug Id: CSCul85203 Title: N5K Port in Internal-Fail errDisable : fu ha standby message queued Status: Fixed Severity: 2 Severe Description: Symptom: N5k Port connected to N1110X goes to "Internal-Fail errDisable" state if the N1110 Appliance is powered off for HA Testing. ----- this symptom will also happen when partner device is nexus. Conditions: Nexus 5000 ( 5548 ) Ver : 6.0(2)N2(1) Feature LLDP is turned off Feature FCoE is turn on Workaround: Turn on LLDP Further Problem Description: Last Modified: 01-JUL-2016 Known Affected Releases: 6.0(2)N2(1), 7.3(0)N1(0.141) Known Fixed Releases: * 7.1(3)ZN(0.157), 7.1(3)ZN(0.313), 7.1(4)N1(0.712), 7.1(4)N1(1), 7.2(2)N1(0.368), 7.2(2)N1(1), 7.2(2)ZN(0.51), 7.3(0)IZN(0.13), 7.3(0)N1(0.242), 7.3(0)N1(0.262) Alert Type: Updated * Bug Id: CSCuo74024 Title: STP BPDU received on vPC secondary not tunneled to vPC primary Status: Fixed Severity: 2 Severe Description: Symptom:After upgrading one of the Nexus 5500/6000 in VPC topology from 6.0(x) to 7.0(x) version whereas the other node still running old 6.0(x) version, STP disputes can be seen on upstream devices. If Bridge assurance is used, ports will be BA blocked. Conditions:Seen in set ups in double sided VPC and one Nexus 5500/6000 in the VPC set up is running 6.0 and the other has been upgraded to 7.0 and when the VPC primary switch is upgraded first to 7.0 Workaround:Once both Nexus 5500/6000 upgraded to same 7.0 release, the issue is resolved. This bug will be only seen during the time where there is NX-OS mismatch in the VPC pair of Nexus 5500/6000. This bug is resolved in NX-OS 7.0(6)N1(1) More Info: Last Modified: 02-JUL-2016 Known Affected Releases: 7.0(1)N1(1) Known Fixed Releases: * 7.0(1)ZN(0.748), 7.0(6)N1(0.246), 7.0(6)N1(1), 7.1(3)ZD(0.150), 7.1(3)ZN(0.309), 7.1(3)ZN(0.313), 7.1(4)N1(0.841), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCuq13396 Title: Nexus 5500 ethpc hap reset - SYSMGR_DEATH_REASON_FAILURE_HEARTBEAT Status: Fixed Severity: 2 Severe Description: * Symptom: N5k undergoes ETHPC hap reset/crash running 6.0(2)N2(3) and later releases. Reason: Reset triggered due to HA policy of Reset Service: ethpc hap reset Conditions: Exactly not known, however collection of DOM statistics via CLI "show interface transceiver [detail]" may result in such a crash. Though crashes have been observed in instances where such CLI was not issued. Workaround: None so far. Further Problem Description: In addition to the 6.x releases, this ethpc crash has also been seen in 7.0(2)N1(1). The defensive fix was added already as part of 7.0(3)N1(1) so this issue should not be seen with this release Last Modified: 15-JUN-2016 Known Affected Releases: 6.0(2)N2(3) Known Fixed Releases: 6.0(2)A6(0.74), 6.0(2)A6(1), 6.0(2)N2(5.98), 6.0(2)N2(6), 6.0(2)U6(0.74), 6.0(2)U6(1) Alert Type: Updated * Bug Id: CSCuf08921 Title: N5K fabricpath MAC address not re learnt on GARP Status: Fixed Severity: 2 Severe Description: Symptom: Nexus 5000 Fabricpath MAC entry not refreshed on receipt of a GARP on Fabricpath Conditions: Broadcast traffic stream sent through fabricpath network Workaround: None More Info: Last Modified: 16-JUN-2016 Known Affected Releases: 6.0(2)N1(1) Known Fixed Releases: * 5.2(1)N1(5), 6.0(2)N2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCva07047 Title: Dual-home FEX forces crash on eVPC peer Status: Open Severity: 2 Severe Description: * Symptom: Crash occurred when dual-homing FEX switch on a couple N5Ks using eVPC: N5K(config-if)# interface ethernet 1/1 N5K(config-if)# no shut 2016 Jun 5 07:41:29 N5K %$ VDC-1 %$ %PFMA-2-FEX_STATUS: Fex 101 is online 2016 Jun 5 07:41:29 N5K %$ VDC-1 %$ %NOHMS-2-NOHMS_ENV_FEX_ONLINE: FEX-101 On-line 2016 Jun 5 07:41:30 N5K %$ VDC-1 %$ %PFMA-2-FEX_STATUS: Fex 101 is online [ 850.099579] Shutdown Ports.. [ 850.133931] writing reset reason 16, fwm hap reset Broadcast message from root (console) (Sun J INIT: Sending processes the KILL signal Sending all processes the TERM signal... Jun 5 07:41:52 %LIBSYSMGR-3-SIGTERM_FORCE_EXIT Service "icmpv6" (PID 3893) is forced exit. Jun 5 07:41:52 %LIBSYSMGR-3-SIGTERM_FORCE_EXIT Service "arp" (PID 3892) is forced exit. Jun 5 07:41:52 %ICMPV6-3-MTS_RECV icmpv6 [3893] Error returned from mts_recv(), errno: Interrupted system call Jun 5 07:41:52 %LIBSYSMGR-3-SIGTERM_FORCE_EXIT Service "adjmgr" (PID 3857) is forced exit. Jun 5 07:41:52 %LIBSYSMGR-3-SIGTERM_FORCE_EXIT Service "ascii-cfg" (PID 5691) is forced exit. Sending all processes the KILL signal... Unmounting filesystems... [ 864.155902] Resetting board Conditions: Issue was first found on Nexus 5K running 7.2(1)N1(1) code (confirmation of other architectures and code pending). Workaround: None at this moment. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(1)N1(1) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCur63212 Title: FWM hap reset after issu on restoring fcoe mac addresses Status: Fixed Severity: 2 Severe Description: Symptom: A nexus 5000/5500 series switch may reset shortly after a non-disruptive upgrade due to 'fwm' process reset. This occurs when a vsan previously in-use has been deleted on a switch doing npv Conditions: In NPV switch, when a VSAN assoicated to VFC in NP mode is deleted, upgrading NPV switch to higher version causes FWM to crash. Workaround: No workaround. Further Problem Description: When a VSAN associated to VFC in NP mode on NPV switch is deleted, MAC entry associated with deleted VSAN is not deleted from runtime PSS and it becomes stale entry. While upgrading, FWM is not expecting this stale entry in runtime PSS. Thus FWM assert fails and causes FWM to crash. Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(7), 6.0(2)N2(4), 7.0(5)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.120), 7.1(2)N1(0.543), 7.1(2)N1(1), 7.1(2)ZN(0.2), 7.1(3)ZN(0.313), 7.2(0)AB(9), 7.2(0)N1(0.147), 7.2(0)N1(1), 7.2(0)ZN(0.151) Alert Type: Updated * Bug Id: CSCut97255 Title: dhcp_snoop reset on nexus 5000 Status: Fixed Severity: 2 Severe Description: Symptom: N5k crashed with 'dhcp_snoop hap reset' reset reason . Conditions: This crash can be seen even if the switch isn't configured for IPv6 or IPv6 DHCP relay. Workaround: If IPv6 DHCP relay is not configured on the switch, the following access list and vlan filter can be used to drop all IPv6 DHCP packets: switch(config)# ipv6 access-list DHCPv6_Filter_acl switch(config-ipv6-acl)# permit udp any eq 547 any switch(config-ipv6-acl)# permit udp any eq 546 any switch(config-ipv6-acl)# vlan access-map DHCPv6_Filter switch(config-access-map)# match ipv6 address DHCPv6_Filter_acl switch(config-access-map)# action drop switch(config-access-map)# vlan filter DHCPv6_Filter vlan-list However if IPV6 DHCP functionality is needed, there is no workaround. Further Problem Description: Crash is seen when device receives an ipv6 dhcp packet with an incorrect length. Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(5)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(1)ZN(0.99), 7.1(2)N1(0.523), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(0.191), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.193) Alert Type: Updated * Bug Id: CSCuq27230 Title: IBM Fex: upgrade cmmuc version to 1.10 Status: Fixed Severity: 2 Severe Description: Symptom: On CMM the bios or cmmuc version will be shown below 1.10 eg 1.09. Conditions: Will happen w/ old builds Workaround(s): None Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(0.272) Known Fixed Releases: * 7.1(0)N1(0.360), 7.1(0)N1(1), 7.1(0)ZN(0.435), 7.1(1)N1(0.37), 7.1(1)N1(1), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(0.2), 7.2(0)N1(1) Alert Type: Updated * Bug Id: CSCut56888 Title: PCI erros reporting in 5K/6K products Status: Fixed Severity: 2 Severe Description: Symptom: A Nexus 600x switch might hang with no response via console, mgmt0 or inband interfaces. In certain NX-OS error messages such as following are printed prior to switch being impacted. %USER-0-SYSTEM_MSG: 452: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm %USER-0-SYSTEM_MSG: 453: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm %USER-0-SYSTEM_MSG: 454: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm %USER-0-SYSTEM_MSG: 455: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm Conditions: Seen in Nexus 600x platforms Workaround: A debug plugin based workaround exists. Contact Cisco TAC to obtain the workaround. Further Problem Description: The correctable error notfication coming from PCI bus have been blocked to feed into NMI path ... Have implemented a counter based mechanism to implement this Two new syslogs are added ? ?Bus:Dev.Func 00:01.1 Vendor 0x8086 Device 0x105 is giving out high correctable Error ..? ?Syslog is given out if the device 0x8086 Device 0x105 at Bus 0, device 1 and function1 is found to have correctable error status for 30 seconds continuously. ? ?Bus:Dev.Func 00:01.1 Vendor 0x8086 Device 0x105 showing Invalid Config ...? ? Syslog is given out if device 0x8086 Device 0x105 at Bus 0, device 1 and function1 is found to have invalid configuration Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(1)N1(0.445), 7.2(0)N1(0.226), 7.2(0)N1(0.231) Known Fixed Releases: * 7.0(7)ZN(0.266), 7.0(8)N1(0.322), 7.0(8)N1(1), 7.1(3)N1(4), 7.1(3)ZN(0.313), 7.1(4)N1(0.718), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCuj36664 Title: SYSMGR-2-SERVICE cfs crashed unexpectedly Status: Fixed Severity: 2 Severe Description: Symptom: device may crash unexpectedly with CFS service generates core dump Conditions: normal operation Workaround: unknown at this point Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(6), 6.0(2)N3(0.231) Known Fixed Releases: * 7.1(3)ZN(0.283), 7.1(3)ZN(0.313), 7.1(4)N1(0.817), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCus16847 Title: HIF ports are down after ISSU Status: Fixed Severity: 2 Severe Description: Symptom: Few HIF ports are down with reason "vPC peerlink is down" after ISSU Conditions: On a vPC+ setup with AA fex connected, it is found that few HIF ports are down with reason "vPC peerlink is down" only on secondary vPC switch, though vPC peerlink shows UP on both peers. Workaround: Flapping the port in down state. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(6)N1(0.205), 7.0(6)N1(0.210), 7.1(1)N1(0.468), 7.1(1)N1(0.471) Known Fixed Releases: * 7.0(1)ZN(0.741), 7.0(4)N1(0.9), 7.0(4)N1(1a), 7.0(6)N1(0.242), 7.0(6)N1(1), 7.1(1)N1(0.478), 7.1(1)N1(1), 7.1(1)ZN(0.31), 7.1(3)ZN(0.313), 7.2(0)N1(0.114) Alert Type: Updated * Bug Id: CSCuo69417 Title: Nexus 6000/5600: Link degraded messages seen been port and fabric ASIC Status: Fixed Severity: 2 Severe Description: Symptom: In a Nexus 6000/5600 series switches, link degraded messages such as following can be seen between port ASIC and fabric ASIC. USER-2-SYSTEM_MSG: A fabric link on module 3 has degraded, some packets may be corrupted - bigsurusd USER-2-SYSTEM_MSG: A fabric link on module 3 has degraded, some packets may be corrupted - bigsurusd USER-2-SYSTEM_MSG: A fabric link on module 3 has degraded, some packets may be corrupted - bigsurusd Conditions: Seen during normal production. Fabric link can be degraded for other hardware related issues which this bug does not address. The root cause for this software issue is incorrect Fabric init issue. Workaround: A power cycle of LEM or switch might recover if the root cause is software fabric init issue Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(3)N1(0.47) Known Fixed Releases: * 7.0(1)ZN(0.474), 7.0(4)N1(0.126), 7.0(4)N1(1), 7.1(0)N1(0.254), 7.1(0)N1(0.256), 7.1(0)N1(1), 7.1(0)ZN(0.351), 7.1(0)ZN(0.353), 7.1(3)ZN(0.313), 7.3(0)ZN(0.190) Alert Type: Updated * Bug Id: CSCuu66185 Title: ptplc crash in pss related function in ASLR image Status: Fixed Severity: 2 Severe Description: Symptom: ptplc process crash Conditions: Crash seen only with ASLR image Workaround: None Further Problem Description: Process crash observed while performing PSS restore functionality(stack overflow because of the wrong size passed for memcpy) Last Modified: 18-JUN-2016 Known Affected Releases: 7.3(0)N1(0.8) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.126), 7.1(2)N1(0.551), 7.1(2)N1(1), 7.1(2)ZN(0.10), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.28), 7.2(1)N1(1), 7.3(0)N1(0.28) Alert Type: Updated * Bug Id: CSCuy91714 Title: N5K-C5596UP FWM Crash During ISSU to 7.2(1)N1(1) Status: Fixed Severity: 2 Severe Description: Symptom: FWM process may crash when performing an ISSU to NX-OS 7.2(1)N1(1). Conditions: None known. Workaround: None known. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(1)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.282), 7.1(3)ZN(0.313), 7.1(4)N1(0.816), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCuw45315 Title: statsclient hap reset seen on stand alone norcal device. Status: Fixed Severity: 2 Severe Description: Symptom: Switch got reloaded due to Statclient hap reset Conditions: statsclient got hanged during storm supression stats collection which is done periodically Workaround: None Further Problem Description: Stats client periodically collects storm supression stats. This involves blocking IOCTL call. In one of the scenario, statsclient is blocked for response from driver but not received the response. As a results, it got hanged and later switch went for reload. Last Modified: 18-JUN-2016 Known Affected Releases: 7.2(1)N1(0.313), 7.3(0)N1(0.144) Known Fixed Releases: * 7.1(3)ZN(0.140), 7.1(3)ZN(0.313), 7.1(4)N1(0.704), 7.1(4)N1(1), 7.2(2)N1(0.359), 7.2(2)N1(1), 7.2(2)ZN(0.43), 7.3(0)IZN(0.13), 7.3(0)N1(0.196), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCus72900 Title: Knob to Disbable ports after loop is detected not working as expected Status: Fixed Severity: 2 Severe Description: Symptom:When STM loop is detected: MCT link goes down Both the links goes down Conditions:When "mac address-table loop-detect port-down" is enabled & STM loops are detected Workaround:None Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(0.440), 7.1(1)N1(0.71) Known Fixed Releases: * 7.1(1)N1(0.477), 7.1(1)N1(1), 7.1(1)ZN(0.30), 7.1(3)ZN(0.313), 7.2(0)N1(0.114), 7.2(0)N1(1) Alert Type: Updated * Bug Id: CSCuq98662 Title: Norcal 96EFCR and EF chassis : link up issues with Copper cables Status: Fixed Severity: 2 Severe Description: Symptom: Links are either not coming up or taking a long time to come up in Norcal 96EFCR and EF chassis with CR and EF LEMs. The issue is noticed in link between the LEMs and in the ports with in the same LEM. Conditions: The link is not coming up if autonegotiation is enabled. Workaround: disable auto neg and do a shut no shut Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(4)N1(0.163) Known Fixed Releases: * 7.0(1)ZN(0.695), 7.0(6)N1(1), 7.1(0)EVN(0.18), 7.1(0)N1(0.373), 7.1(0)N1(1), 7.1(0)ZN(0.447), 7.1(3)ZN(0.313), 7.2(0)N1(0.2), 7.2(0)N1(1) Alert Type: Updated * Bug Id: CSCur05017 Title: N5K/N6K evaluation for CVE-2014-6271 and CVE-2014-7169 Status: Fixed Severity: 2 Severe Description: * Symptom: Symptoms: The N5k/N6K product family includes a version of bash that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs: CVE-2014-6271 CVE-2014-7169 This bug has been opened to address the potential impact on this product. All current versions of NX-OS on this platform are affected unless otherwise stated.. This bug will be updated with detailed affected and fixed software versions once fixed software is available. Exposure is not configuration dependent. Authentication is required to exploit this vulnerability. Conditions: Conditions: Telnet, SSH, HTTP (feature http-server) are attack vectors. A user must first successfully log in and authenticate via SSH to trigger this vulnerability. Exposure is not configuration dependant. Workaround: Workaround: Not available. More Info: Further Problem Description: 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 7.5/7.5: https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:P/A:P/E:H/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 Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(8a), 6.0(2)N2(5), 7.0(3)N1(0.1), 7.0(3)N1(0.125), 7.0(4)N1(1), 7.1(0)N1(0.349) Known Fixed Releases: * 5.2(1)N1(8.142), 5.2(1)N1(8b), 6.0(2)N2(4.3), 6.0(2)N2(4.5), 6.0(2)N2(5.105), 6.0(2)N2(5a), 6.0(2)N2(6), 7.0(1)ZN(0.615), 7.0(1)ZN(0.623), 7.0(5)N1(0.173) Alert Type: Updated * Bug Id: CSCuu03271 Title: Module/FEX gets into failure state with the NF Errors Status: Fixed Severity: 2 Severe Description: Symptom: The messages 'nfp: ACL abort fails' or 'nfp: ACL commit fails' appears on the console multiple times. This could be followed by fex modules going offline Conditions: ISSU of n6000 with netflow feature enabled from 7.2(0)N1(1) to a higher release version can cause this issue. Reload of a 7.2(0)N1(1) n6000 with netflow feature enabled also can cause this issue very rarely. Workaround: To avoid the issue, please remove netflow feature and configure it again once the ISSU or reload is done. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(0)N1(0.170) Known Fixed Releases: * 7.1(3)N1(0.626), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.33), 7.2(1)N1(0.282), 7.2(1)N1(1), 7.2(1)ZN(0.46), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuw73492 Title: N5K crash due to Service: stp hap reset Status: Fixed Severity: 2 Severe Description: Symptom: crash when performing non-distruptive ISSU from 6.0(2)N2(3) to 7.0(7)N1(1) Loading plugin 1: eth_plugin... ln: creating symbolic link `/lib/libcrypto.so.4': File exists ln: creating symbolic link `/lib/libssl.so.4': File exists ethernet switching mode INIT: Entering runlevel: 3 touch: cannot touch `/var/lock/subsys/n /isan/bin/muxif_config: fex vlan id: -f,4042 Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config Added VLAN with VID == 4042 to IF -:muxif:- 2015 Oct 6 15:40:38 dc3-nx5500-1 %$ VDC-1 %$ %USER-2-SYSTEM_MSG: CLIS: loading cmd files begin - clis [ 104.511925] Shutdown Ports.. [ 104.546432] writing reset reason 16, stp hap reset Conditions: The crash was observed on Nexus 5596 when performing non-distruptive ISSU from 6.0(2)N2(3) to 7.0(7)N1(1) Workaround: n/a Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(7)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.304), 7.1(3)ZN(0.313), 7.1(4)N1(0.836), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCun83889 Title: Dual homed FEX interface inactive in FP env. Status: Fixed Severity: 2 Severe Description: Symptom: FEX interface goes inactive after configured on a certain sequence. Conditions: Dual homed FEX interface, on a VPC with FP, interface gets inactive on doing the below command sequence. vlan ABC mode fabricpath int ethernet xxx/y/z switchport mode trunk switchport access vlan ABC switchport mode access Ethernet xxx/y/z is down (inactive) VLANs ABC on Interface Ethernetxxx/y/z are being suspended. (Reason: Compatibility check failed for port mode) Workaround: use default interface then configure it as mode access then add the vlan. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(5), 6.0(2)N2(2) Known Fixed Releases: * 7.0(1)ZN(0.698), 7.0(6)N1(0.207), 7.0(6)N1(1), 7.1(0)N1(0.291), 7.1(0)N1(1), 7.1(0)ZN(0.383), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCux10337 Title: N2348TQ tiburon fex devices crash repeatedly Status: Fixed Severity: 2 Severe Description: Symptom: N2348TQ fex device resets unexpected. Conditions: No additional symptoms are known at this point in time. Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(1)N1(1), 7.3(0)N1(0.46), 7.3(0)N1(0.47), 7.3(0)N1(0.50) Known Fixed Releases: * 7.0(3)I2(2e), 7.0(7)ZN(0.266), 7.0(8)N1(0.313), 7.0(8)N1(1), 7.1(3)N1(2.3), 7.1(3)N1(3), 7.1(3)ZN(0.128), 7.1(3)ZN(0.313), 7.1(4)N1(0.693), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCus68591 Title: Assess Nexus 5k for GHOST vulnerability (CVE-2015-0235) Status: Fixed Severity: 2 Severe Description: Symptom: The following Cisco Nexus products: Nexus 5624 Switch Nexus 5696 Switch Nexus 5672 Switch Nexus 56128 Switch Nexus 5596T switch Nexus 5596UP switch Nexus 5548UP switch Nexus 5548P switch Nexus 2348UPQ FEX Nexus 2348TQ FEX Nexus 2248PQ FEX Nexus 2232TM-E FEX Nexus 2232TM FEX Nexus 2232PP FEX Nexus 2248TP-E FEX Nexus 2248TP FEX Nexus 2224TP FEX Nexus 2148T FEX Nexus B22 DELL FEX Nexus B22 Fujitsu FEX Nexus B22 HP FEX Nexus B22 IBM FEX include a version of glibc that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) ID: CVE-2015-0235 This bug was opened to assess and address the potential impact on this product. Conditions: Device with default configuration. Workaround: None. Further Problem Description: All previously released versions of NX-OS software are affected. The fix will be delivered for currently supported releases as follows: 5.2(1)N1(9) 6.0(2)N2(7) 7.0(6)N1(1) 7.1(1)N1(1) 7.2(0)N1(1) Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html 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: 10/7.8 https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C/CDP:ND/TD:ND/CR:ND/IR:ND/AR:ND 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/en/US/products/products_security_vulnerability_policy.html Last Modified: 17-JUN-2016 Known Affected Releases: 5.1(3)N2(1), 6.0(2)N2(1) Known Fixed Releases: * 5.2(1)N1(8.153), 5.2(1)N1(8.161), 5.2(1)N1(8.168), 5.2(1)N1(9), 6.0(2)N2(6.127), 6.0(2)N2(6.136), 6.0(2)N2(6.142), 6.0(2)N2(7), 7.0(1)ZN(0.745), 7.0(1)ZN(0.778) Alert Type: Updated * Bug Id: CSCuv54348 Title: fwm aborted due to heartbeat failure Status: Fixed Severity: 2 Severe Description: Symptom: fwm process aborted/got killed by sysmanager because of the heartbeat failure Conditions: From the available logs, trigger for the problem is change in portchannel members Workaround: There is no workaround available. Further Problem Description: fwm process is performing route updates in a continues loop. Since this activity is time consuming and fwm process is loosing the heartbeat, Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(1) Known Fixed Releases: * 7.1(3)N1(0.605), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.8), 7.2(1)N1(0.283), 7.2(1)N1(1), 7.2(1)ZN(0.47), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuq66628 Title: VDC-MGR crash on N5k Status: Fixed Severity: 2 Severe Description: Symptom: A Nexus 5500 switch can experience a reload in process vdc_mgr leading to switch reboot. Reset reason would be displayed as following Reason: Reset triggered due to HA policy of Reset Service: vdc_mgr hap reset Conditions: Unknown Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(4) Known Fixed Releases: * 6.0(2)N2(5.108), 6.0(2)N2(6), 7.0(1)ZN(0.680), 7.0(6)N1(0.191), 7.0(6)N1(1), 7.1(0)N1(0.391), 7.1(0)N1(1), 7.1(0)ZN(0.465), 7.1(1)N1(0.17), 7.1(1)N1(1) Alert Type: Updated * Bug Id: CSCut61071 Title: N48Q: Serdes settings for 1G optics is not correct Status: Fixed Severity: 2 Severe Description: Symptom: Checking the serdes values for ports in 1G mode(as shown below) shows the attn value as 10 instead of 0 switch(config-if)# sh hardware internal bigsur asic 6 dfe-tuning-params | beg "MM" MM Tx Eq settings ------------------------------------------------------------------ SBus adr | attn | eq_pre | eq_post | slew | ------------------------------------------------------------------ 47 | 10 | 0 | 0 | 0 | ------------------------------------------------------------------ Conditions: Port configured at 1G speed Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(1)N1(0.499) Known Fixed Releases: * 7.1(1)ZN(0.113), 7.1(2)N1(0.534), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.28), 7.2(1)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCus17580 Title: eth_port_channel hap reset Status: Fixed Severity: 2 Severe Description: Symptom: A Nexus 5000 may reload unexpectedly due to a eth_port_channel hap reset. `show system reset-reason` ----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) --- 1)... Reason: Reset triggered due to HA policy of Reset Service: eth_port_channel hap reset ... Conditions: The exact conditions for this issue are unknown. Workaround: There are no known workarounds at this time. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(1)N1(1), 7.0(5)N1(0.184) Known Fixed Releases: * 7.0(7)N1(0.282), 7.0(7)N1(1), 7.0(7)ZN(0.159), 7.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.1(3)ZN(0.313), 7.2(1)N1(0.257), 7.2(1)N1(1), 7.2(1)ZN(0.21) Alert Type: Updated * Bug Id: CSCus04851 Title: N5k/6k -FP BCAST/MCAST broken on VPC edge ports after remote root change Status: Fixed Severity: 2 Severe Description: Symptom: If there is a root change in FP topology, broadcast/multicast on edge ports of VPC+ Nexus 5K/6K can be affected even though there were no local changes. Conditions: FP root change in the core part of the FP network Workaround: Shut/no shut the affected edge port on the VPC+ N5K/6K Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(1)N1(1), 7.0(2)N1(1), 7.0(5)N1(1), 7.1(0)N1(1) Known Fixed Releases: * 6.0(2)N2(6.134), 6.0(2)N2(7), 7.0(1)ZN(0.728), 7.0(6)N1(0.228), 7.0(6)N1(0.6), 7.0(6)N1(1), 7.1(1)N1(0.468), 7.1(1)N1(0.78), 7.1(1)N1(1), 7.1(1)ZN(0.20) Alert Type: Updated * Bug Id: CSCus38422 Title: fwm core triggered due to fex port-channel flap Status: Fixed Severity: 2 Severe Description: Symptom: FWM process crashes and core file is generated Conditions: FEX port chanel in 2 Layer VPC setup is flapped Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(2) Known Fixed Releases: * 7.0(6)N1(1), 7.1(1)N1(0.463), 7.1(1)N1(1), 7.1(1)ZN(0.16), 7.1(3)ZN(0.313), 7.2(0)AB(2), 7.2(0)N1(0.90), 7.2(0)N1(1), 7.2(0)ZN(0.108), 7.2(0)ZN(0.112) Alert Type: Updated * Bug Id: CSCuq00161 Title: Verizon CoPP: Nexus 5600 Support for CB-QOS MIB Status: Fixed Severity: 2 Severe Description: Symptom: Verizon operational standard requires CB-QOS MIB (or equivalent visibility) before allowing the device to be deployed. Conditions: Workaround: Further Problem Description: Committed changes to support phase 1 of CB QoS MIB, as listed in the FS. Second phase support in later release Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(2)N1(1) Known Fixed Releases: * 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)ES(0.7), 7.1(0)SIB(99.92), 7.1(1)N1(0.454), 7.1(1)N1(0.455), 7.1(1)N1(0.50), 7.1(1)N1(0.51), 7.1(1)N1(0.52) Alert Type: Updated * Bug Id: CSCus67475 Title: FCNS cores due to fcns hap reset Status: Fixed Severity: 2 Severe Description: Symptom: FCNS server process crashes unexpectedly Conditions: Whenever the corrupted fc frame is received by name server process during the registration process, the fcns process crashes. Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(4) Known Fixed Releases: * 7.1(3)ZN(0.284), 7.1(3)ZN(0.313), 7.1(4)N1(0.819), 7.1(4)N1(1), 7.2(2)N1(0.430), 7.2(2)N1(1), 7.2(2)ZN(0.138), 7.3(1)N1(0.358), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuu04099 Title: N5K: SAN port-channel has output discards when member links are added Status: Fixed Severity: 2 Severe Description: Symptom: Output discards are noticed on the san-port-channel, as well as on the newly added fc member links. Conditions: This happens only when the newly added members are from a different asic, than the already existing fc member links. Workaround: Depending on the NX-OS release that is being used, a shut/no shut on the san-port-channel may resolve the issue. Contact the TAC for additional details. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.1(3)N2(1b) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.543), 7.1(2)N1(1), 7.1(2)ZN(0.2), 7.1(3)ZN(0.313), 7.2(1)N1(0.243), 7.2(1)N1(1), 7.2(1)ZN(0.9), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCun88858 Title: Duplicate DHCPv4 discover packets seen on PVlan with DHCP relay Status: Fixed Severity: 2 Severe Description: Symptom: In release 7.0(2), on a VPC setup, the broadcast DHCP discover packets received from a private VLAN with DHCP relay on one switch are copied to CPU instead of redirected, hence the hardware still forwards the packets on the VLAN to the other switch. Conditions: The issue happens when running 7.0(2) image and having Private VLAN with DHCP relay. Workaround: Upgrade to 7.1(0) and above version. Further Problem Description: The issue was introduced in 7.0(2) image. It was fixed in 7.1(0) image. Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(1)N1(0.156) Known Fixed Releases: * 7.1(0)N1(0.1), 7.1(0)N1(0.202), 7.1(0)N1(1), 7.1(0)ZN(0.307), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCus58726 Title: LACP core + reload on N5K /N6K Status: Fixed Severity: 2 Severe Description: Symptom: LACP core after SNMP walk for lagMIBObjects or on running the command 'show lacp port-channel' from the cli. Conditions: It seems the issue happens only with Eth1/64 or Eth1/52/4 with port channel (LACP) configuration. Workaround: Do not use port Eth1/52/4 in a LACP Port-channel. Further Problem Description: issue happens only when we have a LACP po with port 1/64 as its member, it could be eth1/52/4 also, basically port number 64. internally ifindex for this port is 63. bmp64_t port_list; bmp64_set_bit(&port_list, (port+1)); here the bit setting is 0 based, but we are using it 1 based. so for port number 64, it goes outside the variable. and sets bit to 1 which modifies the variable num_mbrs. so after first iteration through the the value of this num_mbrs is 1, it gets modified to 129 and the loop continues causing crash. this issue has been resolved by increasing the bitmap size to bmp128. Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(3)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.457), 7.1(1)N1(1), 7.1(1)ZN(0.11), 7.1(3)ZN(0.313), 7.2(0)AB(2), 7.2(0)N1(0.90), 7.2(0)N1(1) Alert Type: Updated * Bug Id: CSCur75712 Title: N5K PTP intermittently sends Delay_Resp with rewinded timestamp Status: Fixed Severity: 2 Severe Description: Symptom: N5500 intermittently sends PTP Delay_Resp with rewinded timestamp to hosts. Conditions: Nexus5500 NXOS 5.2(1)N1(8a) ,6.0(2)N2(4) Workaround: unknown Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(8a), 6.0(2)N2(4), 7.1(1)N1(0.71) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(1)ZN(0.105), 7.1(2)N1(0.527), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(0.182), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.184) Alert Type: Updated * Bug Id: CSCup53176 Title: ethpm service crash on both VPC peers Status: Fixed Severity: 2 Severe Description: Symptom: N5K ethpm service crash. Conditions: Two N5Ks combined into VPC and has N2Ks as downstream connect to hosts the same config change was made on the N2K ports at the same time(using chat window tool on secure CRT or other tool to make config change at the same time) the crash may happen when we have physical ports in I state in portchannel and do the following example config change: N5K-2(config-if-range)# show port-ch s Flags: D - Down P - Up in port-channel (members) I - Individual H - Hot-standby (LACP only) s - Suspended r - Module-removed S - Switched R - Routed U - Up (port-channel) M - Not in use. Min-links not met -------------------------------------------------------------------------------- Group Port- Type Protocol Member Ports Channel -------------------------------------------------------------------------------- 100 Po100(SU) Eth NONE Eth1/1(P) Eth1/2(P) 101 Po101(SU) Eth NONE Eth1/3(P) 102 Po102(SU) Eth NONE Eth1/4(P) 200 Po200(SU) Eth NONE Eth102/1/4(P) Eth102/1/5(P) 814 Po814(SU) Eth LACP Eth101/1/1(P) Eth102/1/1(I) 816 Po816(SU) Eth LACP Eth101/1/2(P) Eth102/1/2(I) 818 Po818(SU) Eth LACP Eth101/1/3(P) Eth102/1/3(I) N5K-2(config-if-range)# int eth101/1/1,eth101/1/2,eth101/1/3 sw acc vlan 123 N5K-2(config-if-range)# sw acc vlan 123 int po814,po816,po818 Warning: operation not permitted, 0x1f640000[Eth101/1/1] is a member of port channel Warning: operation not permitted, 0x1f640040[Eth101/1/2] is a member of port channel Warning: operation not permitted, 0x1f640080[Eth101/1/3] is a member of port channel sw acc vlan 123 N5K-2(config-if-range)# int po814,po816,po818 N5K-2(config-if-range)# sw acc vlan 123 N5K-2(config-if-range)# 2014 Jun 26 11:21:20 N5K-2 %SYSMGR-2-SERVICE_CRASHED: Service "ethpm" (PID 3337) hasn't caught signal 11 (core will be saved). Broadcast message from root (console) (Thu Jun 26 11:21:28 2014): The system is going down for reboot NOW! Workaround: Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.1(3)N2(1c), 7.0(2)N1(1) Known Fixed Releases: * 5.2(1)N1(8.141), 5.2(1)N1(8b), 6.0(2)N2(5.79), 6.0(2)N2(6), 7.0(1)ZN(0.462), 7.0(3)N1(1), 7.1(0)FGI(0.6), 7.1(0)N1(0.257), 7.1(0)N1(1), 7.1(0)ZN(0.354) Alert Type: Updated * Bug Id: CSCug29190 Title: 'ethpc' hap reset tied to SFP diagnostics Status: Fixed Severity: 2 Severe Description: Symptom:'ethpc' process crash due to HAP reset. Specifically the process fails to respond to heartbeats and so the system restarts the process to recover it. Conditions:Process is running diagnostics on SFPs. This happens routinely by default. I don't believe it can be disabled. Workaround:None. More Info: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(4) Known Fixed Releases: * 5.2(1)N1(6), 6.0(2)N2(2), 7.0(1)ZN(0.710), 7.0(6)N1(0.214), 7.0(6)N1(1), 7.1(1)N1(0.468), 7.1(1)N1(1), 7.1(1)ZN(0.20), 7.1(3)ZN(0.313), 7.2(0)N1(1) Alert Type: Updated * Bug Id: CSCuw70493 Title: State/Reason error & Generic error Missing ACL cause crash. span monitor Status: Fixed Severity: 2 Severe Description: Symptom: Show monitor cmd will show ouput similar to Primary(config)# show monitor Session State Reason Description ------- ----------- ---------------------- -------------------------------- 1 error Generic error VLAN 100-131 to 1/29 2 error Generic error VLAN 132-163 to 1/30 If you proceed to issue shutdown for these interfaces, you will experience this crash: `show system reset-reason` ----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) --- 1) At 468521 usecs after Mon Nov 16 17:55:33 2015 Reason: Reset triggered due to HA policy of Reset Service: monitor hap reset Version: 7.1(1)N1(1) Conditions: The referenced ACL should not exist in the config. Use the output of show running-config aclmgr to inspect/verify about the referenced ACL's existence. Workaround: Always configure an ACL before referencing it in a span/monitor config Further Problem Description: Problem logs from a customer setup: 1. configure span session, set filter in it. 2. forget to configure access list or, make a typo in access list name. 3. do "show monitor session all" Logs: Switch(config)# feature interface-vlan Switch(config)# int vlan 62 Switch(config-if)# ip address 10.72.2.221 255.255.255.0 Switch(config-if)# no shut Switch(config)# monitor session 1 type erspan-source Switch(config-erspan-src)# filter access-group SPAN-PFAL Switch(config-erspan-src)# erspan-id 2 Switch(config-erspan-src)# vrf default Switch(config-erspan-src)# destination ip 10.72.2.22 Switch(config-erspan-src)# source vlan 188 Switch(config-erspan-src)# no shut Switch(config-erspan-src)# monitor erspan origin ip-address 10.1.1.2 global Switch# show monitor session all Service not enabled Switch# Broadcast message from root (console) (Mon Nov 16 17:55:33 2015): The system is going down for reboot NOW! Last Modified: 17-JUN-2016 Known Affected Releases: 7.3(0)N1(0.158) Known Fixed Releases: * 7.1(3)ZN(0.163), 7.1(3)ZN(0.313), 7.1(4)N1(0.717), 7.1(4)N1(1), 7.3(0)IZN(0.7), 7.3(0)N1(0.186), 7.3(0)N1(1), 7.3(0)ZN(0.169) Alert Type: Updated * Bug Id: CSCuo74918 Title: Carmelusd hap reset on ND ISSU Status: Fixed Severity: 2 Severe Description: Symptom: Switch crashes and generates carmelusd core. Conditions: Initiate ND ISSU. Workaround: N/A Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(2)N1(1) Known Fixed Releases: * 7.0(3)N1(1), 7.1(0)N1(1), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCuz62427 Title: Mts buffer with Opcode MTS_OPC_SYSMGR_UPGRADE_DONE and Vlan_mgr SAP Status: Fixed Severity: 2 Severe Description: Symptom: Mts buffer with Opcode MTS_OPC_SYSMGR_UPGRADE_DONE and Vlan_mgr SAP is seen after doing ND-ISSU. Conditions: NA Workaround: NA Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(4)N1(0.808) Known Fixed Releases: * 7.1(3)ZN(0.278), 7.1(3)ZN(0.313), 7.1(4)N1(0.812), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCuc72380 Title: Nexus 5500: IGMP Link Local Destination Packet Flooded Status: Fixed Severity: 2 Severe Description: Symptom: IGMP membership reports are looped within VLAN. Conditions: - Upstream vPC member port is IGMP mrouter port - Destination address is link-local multicast address (i.e., 224.0.0.252) - IGMP membership report for any address other than 0.0.0.0 - We have also seen this triggered due to a malformed IGMP packet with the multicast group in the IGMP header differing from the multicast group in the IP header Workaround: Remove affected VLAN from peer-link. Traffic will still be forwarded by vPC primary due to graceful consistency check. Further Problem Description: Last Modified: 18-JUN-2016 Known Affected Releases: 5.1(3)N2(1a), 6.0(2)N2(4) Known Fixed Releases: * 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.0(0)KMS(0.11), 7.0(7)N1(0.293), 7.0(7)N1(1), 7.0(7)ZN(0.188), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(2)N1(0.548) Alert Type: Updated * Bug Id: CSCuz42053 Title: N5K Crash in ethpm Due to Memory Leak in libutils.so.0.0.0 Status: Fixed Severity: 2 Severe Description: Symptom: A Nexus 5K may experience a crash in the ethpm process. This crash is cuased by a memory leak within this process. The reset reason will show the following: Reason: Reset triggered due to HA policy of Reset System version: 7.0(7)N1(1) Service: ethpm hap reset Conditions: mst_send fail messages are sent on port-channel interfaces , but this memory is not freed afterwards. Workaround: Unknown at this time. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(7)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.295), 7.1(3)ZN(0.313), 7.1(4)N1(0.829), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCur08894 Title: N5k/6k - FP BCAST broken on VPC edge port after root change on VPC+ peer Status: Fixed Severity: 2 Severe Description: Symptom: ARP Request is no longer flooded outside VPC+ Edge port after Fabricpath topology change. Conditions: Powering off the FTAG 1 root which is in the following vpc state: primary, operational secondary Workaround: After the reloaded restores the VPC+ edge ports are re-added to the Outgoing Interface List. Shutdown/ no shutdown of the impacted VPC+ edge ports. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(1)N1(1), 7.0(2)N1(1), 7.0(4)N1(1) Known Fixed Releases: * 7.0(1)ZN(0.697), 7.0(6)N1(0.206), 7.0(6)N1(1), 7.1(0)N1(0.1), 7.1(0)N1(0.372), 7.1(0)N1(1), 7.1(0)ZN(0.446), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCus75696 Title: N5K N55-M4Q GEM module port1 and port2 stay down after reboot Status: Fixed Severity: 2 Severe Description: Symptom: N5K N55-M4Q GEM module port1 and port2 connected on 2 N5K's back to back show "not connected" after reboot, also ports will go into "LinkFlapErrdisable" if manually flapped 3 times. Conditions: Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(5)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.126), 7.1(2)N1(0.561), 7.1(2)N1(1), 7.1(2)ZN(0.21), 7.1(3)ZN(0.313), 7.2(1)N1(0.236), 7.2(1)N1(1), 7.2(1)ZN(0.2), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCut09166 Title: fwm hap reset on vlan delete Status: Fixed Severity: 2 Severe Description: Symptom: Under rare circumstances, the deletion of a VLAN might result in a fwm hap reset: ----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) --- 1) ... Reason: Reset triggered due to HA policy of Reset Service: fwm hap reset Version: 5.2(1)N1(7) Conditions: This issue was originally seen in NX-OS 5.2(1)N1(7). Workaround: Unknown Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(7), 7.0(5)N1(1a) Known Fixed Releases: * 5.2(1)N1(8.153), 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(6.129), 6.0(2)N2(7), 6.0(2)U5(1.37), 6.0(2)U5(2) Alert Type: Updated * Bug Id: CSCuo10325 Title: igmp snooping flooded on stp blocking after stp change Status: Fixed Severity: 2 Severe Description: Symptom:IGMP reports are forwarded to router ports even if the port is in blocking state Conditions:Can happen if the port was originally in forwarding state and was learnt as a router port. And some change in STP topo causes the router port to go into blocking state. But the port is not removed from IGMP snoopings router port list. So until the router port gets timed out, any report received on this vlan, will be forwarded out of this blocked port as well. Workaround:Forwarding over blocked ports will stop once the router port gets timed out. If this is not acceptable, then disable IGMP snooping for the problem vlan. More Info:Note that the fix will not work if upgrading to an image with the fix using ISSU. It will only work if switch is reloaded and booted up with an image that has the fix. If switch is running an image which doesn't have the fix, and is upgraded to an image which has the fix using non-disruptive ISSU, then this fix will not work. If for some reason ISSU is the only way switches can be upgraded, please contact Cisco support to help provide steps which would avoid this IGMP loop issue. Last Modified: 17-JUN-2016 Known Affected Releases: 5.1(3)N2(1a) Known Fixed Releases: * 5.2(1)N1(7.114), 5.2(1)N1(8), 6.0(2)N2(5.94), 6.0(2)N2(6), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(1)ZD(0.254), 7.0(1)ZN(0.511), 7.0(1)ZN(0.523) Alert Type: Updated * Bug Id: CSCur43974 Title: DFA: VLAN Encapsulation error of fabric ports Status: Fixed Severity: 2 Severe Description: Symptom: 2014 Oct 24 15:42:28.295 BRNI0031TL2DM161 %HMM-3-AUTO_CONF_PROFILE_ERROR: hmm [4746] Data Snooping Host: Profile exec err for encap 0 on i/f Eth1/51: Profile conflicts with another profile. Cmd err vsh err 0 2015 Jun 1 16:25:11.044 5672-dfa %HMM-3-AUTO_CONF_PROFILE_ERROR: hmm [4867] VDP Host: Unable to find mapping for vni 10045 on interface Eth2/9 Conditions: UCS attached trunk port with virtual machines online within the UCS. Trunk port configured with standard configuration allowing 3 VLANs (900, 901, 950). Fabric ports using default DFA template configuration. DHCP Snooping enabled Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(0.1)VB(0.1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.135), 7.1(0)N1(0.391), 7.1(0)N1(1), 7.1(0)ZN(0.465), 7.1(1)N1(0.17), 7.1(1)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(0.12), 7.2(0)N1(1) Alert Type: Updated * Bug Id: CSCuw60947 Title: Nexus5600 :RSCN not send to zone member when zone member change Status: Fixed Severity: 2 Severe Description: Symptom:Nexus5600 doesn't send RSCN to connected devices when member in same zone disconnected/connected. You can check whether N5K send RSCN or not with following command. N5672# show rscn statistics vsan 100 Statistics for VSAN: 100 ------------------------- Number of SCR received = 8 Number of SCR ACC sent = 8 Number of SCR RJT sent = 0 Number of RSCN received = 0 Number of RSCN sent = 0 <===== not increment Number of RSCN ACC received = 0 Number of RSCN ACC sent = 0 Number of RSCN RJT received = 0 Number of RSCN RJT sent = 0 Number of SW-RSCN received = 0 Number of SW-RSCN sent = 0 Number of SW-RSCN ACC received = 0 Number of SW-RSCN ACC sent = 0 Number of SW-RSCN RJT received = 0 Number of SW-RSCN RJT sent = 0 Conditions:Nexus5600 NXOS: 7.1(3)N1(1),7.1(3)N1(2) Workaround:use other version than 7.1(3)N1(1),7.1(3)N1(2) More Info:This issue was side effect of CSCum17923 Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(3)N1(0.679), 7.3(0)N1(0.147), 7.3(0)N1(0.150) Known Fixed Releases: * 7.1(3)ZN(0.156), 7.1(3)ZN(0.313), 7.1(4)N1(0.711), 7.1(4)N1(1), 7.3(0)IZN(0.7), 7.3(0)N1(0.178), 7.3(0)N1(1), 7.3(0)ZN(0.162) Alert Type: Updated * Bug Id: CSCut12023 Title: Port channel service crashes after many 'show run' commands Status: Fixed Severity: 2 Severe Description: Symptom: Port channel service crashes after many 'show run' commands Conditions: FC feature enabled Workaround: If no FC feature needed, remove FC features and reload Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(5)N1(1a) Known Fixed Releases: * 7.0(1)ZN(0.772), 7.0(6)N1(0.264), 7.0(6)N1(1), 7.1(1)N1(0.492), 7.1(1)N1(1), 7.1(1)ZN(0.45), 7.1(3)ZN(0.313), 7.2(0)AB(9), 7.2(0)N1(0.134), 7.2(0)N1(0.146) Alert Type: Updated * Bug Id: CSCus89236 Title: Nexus 5672UP unable to ping other side ip after link flap Status: Fixed Severity: 2 Severe Description: Symptom: When Nexus 5672UP connected to any catalyst switch using 1gig link, it is unable to ping opposite side ip after link flap.The link will be shown up but unable to ping.Nexus will be able to see opposite side as cdp neighbor but opposite side will not. Conditions: 1. This problem is only seen on unified port of Nexus 5696UP 2. This problem is seen with 1Gig link only with "no negotiate auto" command configured Workaround: Remove the command "no negotiate auto" and re-apply it. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(5)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.272), 7.1(3)ZN(0.313), 7.1(4)N1(0.806), 7.1(4)N1(1), 7.2(1)N1(0.319), 7.2(1)N1(1), 7.2(1)ZN(0.81), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuu09610 Title: Switch sends large number of DHCPv4 packets in response Status: Fixed Severity: 2 Severe Description: Symptom: In a vinci setup the response side dhcp frames are looping in the core resulting in large number of dhcp response side frames processed by SUP. Conditions: When a DHCP relay receives a unicast dhcp response type frame from server with broadcast flag set, it converts the frame into broadcast (Dmac and Dip as all 1's) and floods it on the vlan. Thus it enters the core and since all nodes in vinci have relay configured each of them, they Rx these broadcast frame and further broadcast them back to core resulting in a flood. Workaround: If possible configure the DHCP server to not set broadcast flag in response packets even though the DHCP client has set it. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(0)N1(0.174) Known Fixed Releases: * 7.0(7)N1(0.70), 7.0(7)N1(1), 7.0(7)ZN(0.149), 7.1(2)N1(0.544), 7.1(2)N1(1), 7.1(2)ZN(0.3), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.3(0)BZN(0.7), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuu33047 Title: Roll back failed while applying allowed vlan command to a interface Status: Fixed Severity: 2 Severe Description: Symptom: Rollback operation fails. Conditions: Checkpointed configuration includes port-channel interfaces and other interfaces configured as members of these port-channel interfaces. Modification to remove member interfaces from port-channel interfaces. Workaround: None. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(0)N1(0.192), 7.2(0)N1(0.195), 7.2(0)N1(0.226) Known Fixed Releases: * 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.1(3)ZN(0.313), 7.2(1)N1(0.258), 7.2(1)N1(1), 7.2(1)ZN(0.22), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuo18604 Title: CTS change of any-any policy not effective after the first download Status: Fixed Severity: 2 Severe Description: Symptom: On a nexus 5000 series switch series, if the any/any or unknown/unknown policy is changed on ISE server, the policy may not appear correctly with "show cts role-based policy" and will not be effective after a first refresh/download. On a subsequent refresh, the policy appears correctly. The following error messages can be seen during the first refresh : 2014 Apr 7 13:51:22 GASTON %AFM-3-AFM_VERIFY_FAIL: Access control policy modification on all interfaces failed 2014 Apr 7 13:51:22 GASTON %CTS-2-SGT_DGT_RBACL_UPDATE_FAILED: Failed to apply RBACL:Permit IP to sgt:12407 dgt:11301 2014 Apr 7 13:51:22 GASTON %CTS-2-SGT_DGT_RBACL_UPDATE_FAILED: Failed to apply RBACL:Deny IP to sgt:65535 dgt:65535 Please note this is a race condition. It is timing dependent and dependent on the sequence of how the policies are changed. This problem can also happen to normal sgt policies. Not only the default catch all policy. Conditions: Workaround: The workaround is for all policy changes always to do a cts refresh role-based policy twice on the switch to make sure the correct policies are installed. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(4) Known Fixed Releases: * 6.0(2)N2(4.63), 6.0(2)N2(5), 7.0(1)ZN(0.309), 7.0(3)N1(0.45), 7.0(3)N1(1), 7.1(0)N1(0.138), 7.1(0)N1(1), 7.1(0)ZN(0.256), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCuv68967 Title: SNMP Timeout on CISCO-RMON-CONFIG-MIB Status: Fixed Severity: 2 Severe Description: * Symptom: While running CISCO-RMON-CONFIG-MIB (OID: 1.3.6.1.4.1.9.9.103) on Hafnium (N5672-UP-16G) seeing SNMP timeout issue. Conditions: Run snmpwalk -c public -v 2c 10.127.119.62 iso.3.6.1.4.1.9.9.103.1.4 on N5672UP-16G Issue is hit for walk on oids .1.3.6.1.4.1.9.9.109.1.1.1.1.2, .1.3.6.1.4.1.9.9.109.1.1.1.1.6, .1.3.6.1.4.1.9.9.109.1.1.1.1.7, .1.3.6.1.4.1.9.9.109.1.1.1.1.8, .1.3.6.1.4.1.9.9.109.1.1.1.1.9, .1.3.6.1.4.1.9.9.109.1.1.1.1.12 and .1.3.6.1.4.1.9.9.109.1.1.1.1.13. on setup 12Q, 24Q, 48Q and 96Q where SUP is on slot 0. Workaround: No workaround Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(1)N1(1), 7.3(0)N1(0.169), 7.3(0)N1(0.177), 7.3(0)N1(0.56) Known Fixed Releases: * 7.1(3)N1(4), 7.1(3)ZN(0.202), 7.1(3)ZN(0.313), 7.1(4)N1(0.745), 7.1(4)N1(1), 7.3(0)D1(0.171), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)IZN(0.13), 7.3(0)N1(0.225) Alert Type: Updated * Bug Id: CSCuy61164 Title: fwm core with "no int po102" after seeing "%ETHPORT-2-IF_SEQ_ERROR" Status: Fixed Severity: 2 Severe Description: Symptom: In a rare instance when ETHPM misses link up/down events in this case for fex NIF link and goes out of sync. Any subsequent triggers to recover fex fabric-po shut/no-shut, fex reload etc., doesn't recover out of sync state. when there is vpc switchover Fex might show down in both vpc switches. Giving "no int po-" for the fex fabric PO results in this crash. This is rare occurrence not reproducible in lab again. Conditions: * when Ethpm queue is full with mts messages (when new modules or fex interfaces come online, unstable network) and miss link up/down events. * vpc switchover, fex reload or fex nif link sh/no-shut * removing fex fabric po "no int po-x" Workaround: * We can prevent this crash, when ethpm misses any link up/down events particularly for fex NIF links, avoid triggers like ISSU, vpc switchover, fex reload etc., Allow network to stabilize and ethpm queue to drain and recover out of sync links first before proceeding further on maintenance activity. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.3(0)N1(0.295) Known Fixed Releases: * 7.1(3)ZN(0.307), 7.1(3)ZN(0.313), 7.1(4)N1(0.839), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCuh58418 Title: Ingress drop BIG_DROP_HIT_DROP_PORT_MAP_IDX w/ pbr next-hop is a ce port Status: Fixed Severity: 2 Severe Description: Symptom: Traffic drop seen when PBR next hop is FP vlan but PBR next-hop is via a CE port instead of L2MP core port . Conditions: Ifmap table switch id is programmed with own switch id instead of 0. This should be configured only for L2MP next hops. Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(1), 7.0(6)N1(0.7) Known Fixed Releases: * 6.0(2)N2(1), 7.0(7)N1(1), 7.0(7)ZN(0.119), 7.1(2)N1(0.549), 7.1(2)N1(1), 7.1(2)ZN(0.8), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCux83890 Title: N5K/6K: Crash due to provision hap reset- signal 6 Status: Fixed Severity: 2 Severe Description: Symptom: A Nexus 5K/6K can experience a crash in process provision leading to a switch reboot. `show system reset-reason` ----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) --- 1) At 891330 usecs after Sat Jan 9 05:12:01 2016 Reason: Reset triggered due to HA policy of Reset Service: provision hap reset Version: 7.1(1)N1(1) Conditions: The process crash is due to memory leak in provision process. Seen only in systems which have following configuration 1)FEX Module pre-provisioning but FEX is not online 2)Pre-provisioned FEX HIF ports are bound to vFC interfaces. 3)Commands such as show run, copy run are issued repeatedly which causes memory leak. Workaround: Remove FEX pre-provisioning for modules which are not online. Further Problem Description: The memory leak can be monitored using following command. esc-6001# show system internal provision mem-stats detail | grep PROVISION_MEM_char 34 PROVISION_MEM_char 1085760 1085761 42611616 42611652 In above illustration, memory utilization is around 42M. If it reaches around 200M, the switch can experience the process crash. Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(1)N1(1) Known Fixed Releases: * 7.0(7)ZN(0.268), 7.0(8)N1(0.326), 7.0(8)N1(1), 7.1(3)N1(3.17), 7.1(3)N1(4), 7.1(3)ZN(0.167), 7.1(3)ZN(0.313), 7.1(4)N1(0.721), 7.1(4)N1(1), 7.3(0)N1(0.271) Alert Type: Updated * Bug Id: CSCuj39540 Title: Port Cores After Running Script - Compliance Test - CISCO-FC-FE-MIB Status: Fixed Severity: 2 Severe Description: Symptom: The following SNMPSET command causes crash on the Nexus device : snmpset -v2c -c private 10.193.52.16 1.3.6.1.4.1.9.9.302.1.1.4.1.6.3000.32.2.3.4.5.6.7.136 i 1 Conditions: Vsan and FC Domain FCID must be configured on the switch. Workaround: The only workaround is to avoid running the snmpset command. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(5.83), 7.0(1)N1(0.138) Known Fixed Releases: * 7.0(7)N1(0.70), 7.0(7)N1(1), 7.0(7)ZN(0.149), 7.1(2)N1(0.576), 7.1(2)N1(1), 7.1(2)ZN(0.37), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.23), 7.2(1)N1(1) Alert Type: Updated * Bug Id: CSCuo65802 Title: N5K Incomplete CTS policies after port-channel coming up Status: Fixed Severity: 2 Severe Description: Symptom: On a nexus 5000 series switch in a cts enforcement scenario, not all policies for the configured security group tag may be appearing on the device after a port-channel is coming up. For example, for this interface configuration : interface Ethernet1/1 cts manual policy static sgt 0x64 trusted switchport mode fabricpath no snmp trap link-status logging event port link-status channel-group 11 mode active If this port-channel flaps, more specifically if we have two member ports of the port-channel coming shortly one after another, not all policies configured on ISE or ACS server with destination group tag 0x64 may be seen in show cts role-based policy Conditions: Workaround: Perform a "cts refresh role-based-policy" Further Problem Description: CSCuo79856 addresses this defect for nexus 5000 series switches Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(4) Known Fixed Releases: * 6.0(2)N2(4.64), 6.0(2)N2(5), 7.0(1)ZN(0.349), 7.0(3)N1(0.70), 7.0(3)N1(1), 7.1(0)N1(0.186), 7.1(0)N1(1), 7.1(0)ZN(0.293), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCuu59941 Title: FC ports errDisabled - SFP vendor not supported after upgrade to 6.x/7.x Status: Fixed Severity: 2 Severe Description: Symptom: FC ports are Error disabled - SFP vendor not supported after a NX-OS upgrade from 5.x to 6.x/7.x Conditions: Occurs after upgrade from NX-OS 5.x to 6.x/7.x when using SFPs that are not Cisco branded or with Cisco Ethernet SFPs in FC interfaces or UP ports configured for FC. Workaround: Use Cisco fibre channel transceivers Further Problem Description: Bug was introduced in NX-OS 6.0(2)N2(1). Fixed in 7.3(0)N1(1) 7.2(1)N1(1) 7.2(0)N1(1) 7.1(2)N1(1) 7.0(7)N1(1) This is how the interface appears: show interface brief ------------------------------------------------------------------------------- Interface Vsan Admin Admin Status SFP Oper Oper Port Mode Trunk Mode Speed Channel Mode (Gbps) ------------------------------------------------------------------------------- ...snip fc2/16 100 auto on errDisabled -- -- -- And: show interface fc2/16 fc2/16 is down (Error disabled - SFP vendor not supported) Hardware is Fibre Channel, SFP is Unknown(0) ...snip The following messages are seen: %KERN-3-SYSTEM_MSG: [5018764.606338] jiffies: 501846460, XCVR slot 1 port(lo-hi) 15-15: GBIC/SFP checksum error - kernel %PORT-5-IF_DOWN_FCOT_VENDOR_NOT_SUPPORTED: %$VSAN 100%$ Interface fc2/16 is down (Error disabled - FCOT vendor not supported) %KERN-3-SYSTEM_MSG: [5018765.646427] jiffies: 501846564, XCVR slot 1 port(lo-hi) 15-15: GBIC/SFP checksum error - kernel %KERN-3-SYSTEM_MSG: [5018765.646455] jiffies: 501846564, XCVR slot 1 port(lo-hi) 15-15: Failed reading information from transceiver - kernel Resolution Summary: After upgrading to a NX-OS version with the fix, the fc interfaces will come back up after a no shut. Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(1), 6.0(2)N2(7), 7.0(5)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.116), 7.1(2)N1(0.553), 7.1(2)N1(1), 7.1(2)ZN(0.12), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.25), 7.2(1)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuj56227 Title: IGMP proxy reports may loop on the network Status: Fixed Severity: 2 Severe Description: * Symptom:Proxy leaves and proxy reports looping between peer switches. it can create igmp loop which could affect the use of queuing by other transit traffic. therefore transit traffic can be dropped. Conditions:Nexus 5000 setup in vPC. Workaround:None. More Info:If a switch running affected release is upgraded to a fixed release using non-disruptive ISSU, this bug gets carried over. A switch reload/power-cycle is required. Last Modified: 22-JUN-2016 Known Affected Releases: 5.2(1)N1(5), 6.0(2)N2(1) Known Fixed Releases: 5.2(1)N1(6), 6.0(2)N2(3), 6.0(2)U3(0.661), 6.0(2)U3(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCux46963 Title: N5K kernel panic crash usd_mts_kthread Part II Status: Fixed Severity: 2 Severe Description: Symptom: A kernel panic crash is seen: ----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) --- 1) At 614595 usecs after Tue Dec 8 10:02:18 2015 Reason: Kernel Panic Service: The stack-trace shows the issue occurs in usd_mts_kthread: Nexus5000# show logging onboard stack-trace | no-more . . CPU 0 Process usd_mts_kthread (3379) Stack: 8a8479ec: Conditions: This issue is suspected to be cause by a high amount of traffic or a large burst of traffic hitting the Mgmt interface. We are still investigating the exact conditions. Workaround: None Known Further Problem Description: This issue is very similar to the CSCum35498 bug. The CSCum35498 seems to fix most issues. However, it looks like there is some corner case scenarios that can still trigger a crash in a similar way. Last Modified: 24-JUN-2016 Known Affected Releases: 6.0(2)N2(6), 7.0(6)N1(1), 7.1(0)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.275), 7.1(3)ZN(0.313), 7.1(4)N1(0.809), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCum35498 Title: N5K kernel panic crash usd_mts_kthread Status: Fixed Severity: 2 Severe Description: Symptom: N5k kernel panic crash observed on 6.0(2)N2(2) KERN-0-SYSTEM_MSG [2205608.520006] BUG: soft lockup - CPU#0 stuck for 11s! [usd_mts_kthread:3296] Conditions: It is suspected to be triggered by high volume of traffic hitting the management interface. The soft lockup may happen at different process, as the issue is triggered at the interrupt level. Workaround: None at this time. Further Problem Description: Last Modified: 24-JUN-2016 Known Affected Releases: 6.0(2)N1(2), 6.0(2)N2(2), 7.1(0)N1(0.129) Known Fixed Releases: * 5.2(1)N1(7.106), 5.2(1)N1(8), 6.0(2)N2(4.63), 6.0(2)N2(5), 7.0(3)N1(0.30), 7.0(3)N1(1), 7.1(0)N1(0.138), 7.1(0)N1(1), 7.1(0)ZN(0.256), 7.1(3)ZN(0.313) Alert Type: New Bug Id: CSCur01785 Title: N5K VPC+: FEX drops unknown unicast packet Status: Terminated Severity: 2 Severe Description: Symptom: unknown unicast packets are dropped in FEX(N2248 TP-E). Conditions: This issue can heppen when N5K meets these situation. - Using Fabric-Path - Using Dual-Homed FEX - Secondary VPC Peer is forwarding the packet to FEX. - N5Ks doesn't know MAC address of destination. Topology SOURCE | N7K -----+ | | FP NETWORK BETWEEN N7K and N5K | | N5K === N5K (VPC+) | | | | N2K -----+ (Dual Home) | DESTINATION Workaround: (1) expand the age timer of MAC table (2) reduce the ping interval and increase the number of monitor device. This issue can happen "(1/2)^num_of_device" (3) static mac (4) ping from HOST to monitor device Further Problem Description: none Last Modified: 24-JUN-2016 Known Affected Releases: 6.0(2)N2(1), 6.0(2)N2(5), 7.0(3)N1(0.99) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCva19832 Title: IGMP snooping getting disabled for a longer duration during NDISSU Status: Open Severity: 2 Severe Description: * Symptom: IGMP snooping disabled for ISSU duration. Conditions: ISSU Workaround: None Further Problem Description: Last Modified: 26-JUN-2016 Known Affected Releases: 7.1(4)N1(0.849) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCuy90720 Title: nexus 5600 kernel panic crash usb-storage usb_stor_control_thread Status: Fixed Severity: 2 Severe Description: Symptom: A kernel panic crash is seen on nexus 5600 switch: ----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) --- 1) At 535952 usecs after Thu Jan 14 18:04:06 2016 Reason: Kernel Panic Service: Version: 7.1(2)N1(1) The stack-trace shows the issue occurs in Process usb-storage Process usb-storage (72) Stack: 82439c98: Call Trace: [<802fc5a7>]usb_stor_control_thread+0x10f/0x198 (76) Conditions: We are still investigating the exact conditions. Workaround: none Further Problem Description: Last Modified: 26-JUN-2016 Known Affected Releases: 7.1(2)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.322), 7.1(4)N1(0.855), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCuw46514 Title: POAP: Inband POAP support for IP Fabric Status: Open Severity: 3 Moderate Description: Symptom: POAP over inband ports in the VxLAN/evpn Fabric does not work. Conditions: POAP over ip unnumbered interfaces in the IP Fabric does not work. Workaround: POAP can be done via management in the IP Fabric. POAP over IP numbered interfaces works as long as dhcp server is configured with unique subnet scopes for every layer 3 core-facing interface pair and IP dhcp relay is enabled under every core facing interface. The DHCP server can hang off some leaf attached to the default vrf. However, this does not work out of the box with the default POAP templates that ship with DCNM. With DCNM, only POAP via the management vrf is supported out of the box. Further Problem Description: Last Modified: 04-JUN-2016 Known Affected Releases: 7.3(0)N1(0.139) Known Fixed Releases: * 7.3(1)DX(0.45) Alert Type: Updated * Bug Id: CSCuv26876 Title: Unexplained BIG_DROP_INGRESS_PAUSE and BIG_DROP_INGRESS_ACL being seen Status: Fixed Severity: 3 Moderate Description: * Symptom: Drops are seen via the following command on a native Fiber Channel interface: show platform fwm info pif fc2/24 | i drop fc2/24 pd: tx stats: bytes 79021422840400 frames 46716457518 discard 0 drop 0 fc2/24 pd: rx stats: bytes 123757468990744 frames 74709425226 discard 1 drop 18699650 <------Drops Seen fc2/24 pd fcoe: tx stats: bytes 79021422849184 frames 46716457521 discard 0 drop 0 ucast 46716457537 fc2/24 pd fcoe: rx stats: bytes 123757468991088 frames 74709425229 discard 0 drop 0 ucast 74709425238 After finding out what global asic this is under: show platform fwm info pif fc2/24 | i asic fc2/24 pd: slot 1 logical port num 0 slot_asic_num 0 global_asic_num 7 fw_inst 0 phy_fw_inst 0 fc 0 You can then run the following command using the global_asic_num from above: Show platform fwm info asic-errors 7 BIG_DROP_INGRESS_ACL: res0 = 463079801 res1 = 0 [50] BIG_DROP_INGRESS_PAUSE: res0 = 463079722 res1 = 0 [65] If these are the counters incrementing for the drops then you are affected by this bug. Conditions: Nexus 56128P running 7.0(6)N1(1) and seeing drops incrementing under the following command: show platform fwm info pif fc2/24 | i drop fc2/24 pd: tx stats: bytes 79021422840400 frames 46716457518 discard 0 drop 0 fc2/24 pd: rx stats: bytes 123757468990744 frames 74709425226 discard 1 drop 18699650 <------Drops Seen fc2/24 pd fcoe: tx stats: bytes 79021422849184 frames 46716457521 discard 0 drop 0 ucast 46716457537 fc2/24 pd fcoe: rx stats: bytes 123757468991088 frames 74709425229 discard 0 drop 0 ucast 74709425238 You will not see discards on the show interface: sh int fc2/24 fc2/24 is up ...snip 1 minute input rate 302726024 bits/sec, 37840753 bytes/sec, 23624 frames/sec 1 minute output rate 282010616 bits/sec, 35251327 bytes/sec, 20320 frames/sec 99761966699 frames input, 161200777297624 bytes 0 discards, 0 errors 1 CRC, 0 unknown class 0 too long, 0 too short 64478281260 frames output, 105868255905716 bytes 0 discards, 0 errors ...snip Workaround: None These ASIC counters are implemented by hardware. There is no software control to stop these counters from incrementing. These ASIC counters are used for statistics about how many PAUSE frames are internally handled and dropped. Further Problem Description: These can be safely ignored when there is no discard observed by the CLI command show interface <> and there is no SCSI error observed by the host. In 56128UP card, all the native FC frames are internally converted as FCoE frames. The flow control used in FC world is buffer to buffer credit mechanism. The flow control used in FCoE world is the PAUSE mechanism. Before FC to FCoE conversion, buffer to buffer flow control is used. After FCoE conversion, PAUSE flow control is used. The PAUSE frames which we are seeing drops are internally generated frames for FCoE flow control. These internally generated PAUSE frames should not be forwarded to the end host. These frames should be handled and dropped by the forwarding engine itself. The BIG DROP INGRESS PAUSE counter is useful to find statistics about how many PAUSE frames are internally generated and dropped. An ACL is installed to block forwarding of non FCoE frames. The PAUSE frame is identified as non FCoE traffic. So the PAUSE frames will not be forwarded and will be dropped by INGRESS ACL. In summary a PAUSE frame is identified as both PAUSE frame and non FCoE frame. So both the counters BIG_DROP_INGRESS_PAUSE and BIG_DROP_INGRESS_ACL will increase for a single PAUSE frame. Last Modified: 15-JUN-2016 Known Affected Releases: 7.0(4)N1(1) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCub48277 Title: Flooding while switch is in POAP mode Status: Fixed Severity: 3 Moderate Description: Symptom: Frames are flooded while the switch is in the POAP discovery phase. Conditions: Check console for: 2012 Aug 7 14:54:41 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: Abort Power On Auto Provisioning and continue with normal setup ?(yes/no)[n]: 2012 Aug 7 14:54:49 switch %$ VDC-1 %$ %POAP-2-POAP_FAILURE: POAP DHCP discover phase failed Workaround: Do not connect multiple interfaces to network while bringing the switch online Last Modified: 16-JUN-2016 Known Affected Releases: 5.2(1)N1(1) Known Fixed Releases: * 6.0(2)N2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111), 7.3(0)ZN(0.190) Alert Type: Updated * Bug Id: CSCuf77723 Title: license grace-period does not work for BGP for Nexus 5k Status: Fixed Severity: 3 Moderate Description: Symptom: When enabling grace period for certain L3 features like BGP, it given an error No available license - LAN_ENTERPRISE_SERVICES_PKG error Feature does not have an installed license 'show license usage' shows there is no grace period enabled for the license. Conditions: Enabling grace period for certain L3 features like BGP, OSPF, etc on Nexus 5000 switches. Workaround: Purchase and install a permanent license instead of using the license grace-period feature Last Modified: 16-JUN-2016 Known Affected Releases: 5.2(1)N1(3) Known Fixed Releases: * 6.0(2)N2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCtg20592 Title: callhome message doesn't use correct timezone configured on the device Status: Fixed Severity: 3 Moderate Description: Symptom: Subject line of Callhome Message has GMT time rather than configured timezone, though it shows correct GMT time. Conditions: switch configured for callhome. Workaround: None. Last Modified: 16-JUN-2016 Known Affected Releases: 4.2(1)N1(0.317) Known Fixed Releases: * 6.0(2)N2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCtt26292 Title: Remove feature cimserver from switch CLI Status: Fixed Severity: 3 Moderate Description: Symptom: cimserver is not supported in nexus 5000/5500 switch starting 5.1(3)N1(1) release Conditions: enable feature cimserver on nexus 5000/5500 switch Workaround: if cimserver support is needed, then run a release prior to 5.1(3)N1(1) Last Modified: 16-JUN-2016 Known Affected Releases: 5.1(3)N1(0.302) Known Fixed Releases: * 5.1(3)N2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCua37878 Title: strict incompatibility CAP_FEATURE_SECURITY_SCP_SERVER while downgrade Status: Fixed Severity: 3 Moderate Description: Symptom: A nexus 5xxx switch might not be able to downgrade correctly due to strict incompatibility when attempting to downgrade from 5.1.3.N1.x based image to 5.0.3.N2.x based image. Conditions: using install all to downgrade Workaround: - change boot variables to point to the old image - copy run start (save image) - reload the switch Last Modified: 16-JUN-2016 Known Affected Releases: 5.1(3)N1(1) Known Fixed Releases: * 6.0(2)N1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCuh99773 Title: Can't save startup config on Nexus 5K Status: Fixed Severity: 3 Moderate Description: Symptom: "Copy startup-config " command may fail on Nexus 5000/6000 switch. It may throw error like Example: P1ACCS50# copy start test.lob sh: /var/tmp/vsh/P1ACCS50-startup-config: Permission denied Failed: "generic error" Conditions: Copy running-config startup-config or copy startup-config command was run from another terminal at same time. Workaround: Delete the temp file for which the "Permission denied" error was showing. Example: Switch # filesys delete /var/tmp/vsh/P1ACCS50-startup-config More Info: Last Modified: 16-JUN-2016 Known Affected Releases: 5.1(3)N2(1b) Known Fixed Releases: * 7.0(0)N1(0.330), 7.0(0)N1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCtk37419 Title: N5K: Option to Disable feature LLDP - no feature lldp - Status: Fixed Severity: 3 Moderate Description: There is no global command to disable feature LLDP. The workaround is to config disable lldp under interface. Last Modified: 16-JUN-2016 Known Affected Releases: 5.0(2)N1(1) Known Fixed Releases: * 5.2(1)N1(4), 7.1(3)ZN(0.312), 7.2(0)VZN(0.31), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCtq96832 Title: Warning Message for: Temporary N5K L3 licenses are lost after reload Status: Fixed Severity: 3 Moderate Description: Symptom: Temporary Nexus 5K L3 licenses L-N55-BAS1K9 are lost after reload of the switch and Layer 3 module goes down since L3 license is not installed Conditions: Only happens if the customer is using temporary licenses. Workaround: Workaround is after the reload of the switch clear the temporary L3 license and reinstall temporary license again. Last Modified: 16-JUN-2016 Known Affected Releases: 5.0(3)N1(1c), 5.0(3)N2(1) Known Fixed Releases: * 5.1(3)N1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCty07271 Title: Hidden 'filesys delete' command does not properly restrict input Status: Fixed Severity: 3 Moderate Description: Symptom: Cisco NX-OS software contains a directory traversal vulnerability within the command line interface that could allow a local, authenticated attacker to delete arbitrary files on the affected device. An attacker could leverage the NX-OS ?filesys delete? command to delete arbitrary files on the device. This vulnerability affects the following platforms which are based on Cisco NX-OS: Cisco Nexus 7000 Cisco MDS 9000 Cisco Nexus 6000 Cisco Nexus 5500 Cisco Nexus 5000 Cisco Nexus 4000 Cisco Nexus 3500 Cisco Nexus 3000 Cisco Nexus 1000V Cisco Connected Grid Router 1000 Series Cisco Unified Computing System Fabric Interconnect 6200 Cisco Unified Computing System Fabric Interconnect 6100 Conditions: Device is running an affected version of Cisco NX-OS software. Workaround: Restrict access to trusted users. Further Problem Description: This issue was discovered during internal testing by Cisco. 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.6/4.4 http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:N/I:C/A:N/E:F/RL:U/RC:C&version=2.0 CVE ID CVE-2012-4135 has been assigned to document this issue. Additional details about the vulnerability described here can be found at: http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-4135 Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html Last Modified: 16-JUN-2016 Known Affected Releases: 6.0(0)N1(0.119) Known Fixed Releases: * 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCub44028 Title: Nexus 5000: Need "errdisable recovery cause loopback" Status: Fixed Severity: 3 Moderate Description: Symptom: If a Nexus 5000 series switch error disables an interface due to UDLD Tx-Rx Loop condition, the interface does not come up after errdisable recovery interval expires and errdisable recovery cause udld configured. Command errdisable recovery cause loopback is needed but Nexus 5000 does not support this command. Conditions: UDLD Tx-Rx Loop condition in a Nexus 5000. Workaround: Configure errdisable recovery cause all as a workaround which enables errdisable recovery cause loopback. Manually remove recovery causes which are not needed. Further Problem Description: Last Modified: 16-JUN-2016 Known Affected Releases: 5.2(1)N1(1) Known Fixed Releases: * 6.0(2)A1(1), 6.0(2)N1(1), 6.0(2)N2(1), 6.0(2)U1(1), 7.1(3)ZN(0.312), 7.2(0)VZN(0.31), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCul92599 Title: N-64P- I-400: "feature eigrp/ospf" disable - URIB-3-SEND_FROM_ERROR seen Status: Fixed Severity: 3 Moderate Description: Symptom: "no feature eigrp/ospf" throws urib message Conditions: Workaround: None Further Problem Description: Last Modified: 16-JUN-2016 Known Affected Releases: 7.0(0)N1(0.400) Known Fixed Releases: * 6.0(2)N3(0.73), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)KM(0.37), 7.0(0)N1(0.73), 7.0(0)N1(0.89), 7.0(0)N1(1), 7.0(0)ZD(1.30), 7.0(0)ZN(1.66), 7.0(1)N1(0.135) Alert Type: Updated * Bug Id: CSCtq14143 Title: L3 protocols not coming up after ISSU, l3 license install and copy conf Status: Fixed Severity: 3 Moderate Description: Symptom: After an ISSU upgrade if Layer-3 license is installed Layer-3 routing will not fully take affect until a system reload Conditions: ISSU upgrade followed by Layer-3 license install Workaround: Reload the switch. A warning will be printed to prompt the user to reload Last Modified: 16-JUN-2016 Known Affected Releases: 5.0(3)N2(0.205) Known Fixed Releases: * 5.1(3)N1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCup74438 Title: N5K: ISSU upgrade from 5.2(1)N1(8) to 6.0(2)N2(5) and 7.x is disruptive Status: Fixed Severity: 3 Moderate Description: Symptom: A non disruptive upgrade from a Nexus 55xx switch running NX-OS 5.2(1)N1(8) to following specific versions will be disruptive 5.2(1)N1(8) to 6.0(2)N2(5) 5.2(1)N1(8) to 7.0(0)N1(1) 5.2(1)N1(8) to 7.0(1)N1(1) 5.2(1)N1(8) to 7.0(2)N1(1) Conditions: A NX-OS upgrade on L2 only Nexus 55xx switches which meet non disruptive ISSU upgrade requirements for STP and LACP Workaround: Perform an intermediate non-disruptive ISSU to 6.0(2)N2(4) and then to 6.0(2)N2(5)/7.x. This issue will be resolved in newer 6.x code such as 6.0(2)N2(6), 7.0(3)N1(1) and later. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(7.136) Known Fixed Releases: * 5.2(1)N1(7.138), 5.2(1)N1(8), 7.0(1)ZN(0.442), 7.0(3)N1(0.116), 7.0(3)N1(1), 7.0(5)N1(0.171), 7.0(5)N1(1), 7.1(3)ZN(0.312) Alert Type: Updated * Bug Id: CSCtr60851 Title: Flexlink:SVI is down even when corresponding flexlink ports are up Status: Fixed Severity: 3 Moderate Description: This defect has been fixed in 5.1(3)N1 Last Modified: 17-JUN-2016 Known Affected Releases: 5.1(3)N1(0.182) Known Fixed Releases: * 5.1(3)N1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCug24976 Title: N5k/6k: Need to expose knob "ip pim register-until-stop" Status: Fixed Severity: 3 Moderate Description: Symptom: PIM knob ip pim register-until-stop is not exposed to users in Nexus 5500/Nexus 6000 Conditions: PIM is configured on the Nexus 5500/6000 Workaround: None Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N1(2) Known Fixed Releases: * 5.2(1)N1(5), 6.0(2)N2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCtr22640 Title: error msg pm_update_mac_entry: mac update failed seen after TCN Status: Fixed Severity: 3 Moderate Description: Symptom: After STP Topology Change, an SVI interface is temporarily unavailable. This is caused by the 'pm_update_mac_entry: update failed mac' error right after the mac address table flush. the mac address does not get re-learned immediately. Conditions: No specifics Workaround: Add static mac address table entries for the addresses that fail to be relearned. Last Modified: 17-JUN-2016 Known Affected Releases: 5.0(3)N1(1c) Known Fixed Releases: * 5.1(3)N1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCub78357 Title: Vulnerability in OpenSSH Component Status: Fixed Severity: 3 Moderate Description: Symptoms: Cisco Nexus 5000 includes a version of OpenSSH that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs: CVE-2012-0814 This bug was opened to address the potential impact on this product. Conditions: Device with default configuration. Workaround: Not currently available. Further Problem Description: Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html 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 3.5/2.6: http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:M/Au:S/C:P/I:N/A:N/E:U/RL:OF/RC:C&version=2.0 CVE ID CVE-2012-0814 has been assigned to document this issue. Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(1) Known Fixed Releases: * 5.2(1)N1(4), 6.0(2)A1(1), 6.0(2)N1(1), 6.0(2)U1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCtr55489 Title: ipForwarding MIB OID returns 1 (enabled) for 55xx without L3 card Status: Fixed Severity: 3 Moderate Description: Symptom: ipforwarding MIB returns value indicating the nexus 55xx switch is enabled for L3 when in fact its not. Conditions: This problems is specific to SNMP ipforwarding MIB. Workaround: use the regular 'show mod', 'show license usage' 'show feature' commands etc to make sure we are enabled for L3. Last Modified: 17-JUN-2016 Known Affected Releases: 5.0(3)N1(1a) Known Fixed Releases: * 5.0(3)N2(2a), 5.1(3)N1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCtr72576 Title: upgrade to 5.0(3)N2(1) VFC initializing on FEX 2232 PORTS Status: Fixed Severity: 3 Moderate Description: Symptom: Servers connected to FEX interfaces may not be able to FLOGI into the fabric. The vfc interface will be stuck in init state: vfc1 is trunking (Not all VSANs UP on the trunk) Bound interface is Ethernet130/1/1 ... Port mode is TF Port vsan is 10 Trunk vsans (admin allowed and active) (10) Trunk vsans (up) () Trunk vsans (isolated) () Trunk vsans (initializing) (10) ... Connecting the same server directly to the Nexus switch (ie not using the FEX) will make them able to FLOGI. Condition: When servers interfaces are connected to a 2232 FEX switch running the affected versions. Workaround: You need to add VLAN 1 (or, more precisely, the native VLAN) to the allowed list under at least one of the FEX interface configuration. You may also need to flap (shut/no-shut) the VFCs which have not come up. It may or may be not necessary though. Last Modified: 17-JUN-2016 Known Affected Releases: 5.0(3)N2(1) Known Fixed Releases: * 5.0(3)N2(2b), 5.1(3)N1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCui50776 Title: OpenSSH LoginGraceTime Denial of Service Vulnerability Status: Fixed Severity: 3 Moderate Description: * Symptoms: Cisco includes a version of OpenSSH that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs: CVE-2010-5107 This bug was opened to address the potential impact on this product. Conditions: None Workaround: None Further Problem Description: Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html PSIRT Evaluation: The Cisco PSIRT has assigned this defect the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5.0/4.1: http://tools.cisco.com/security/center/cvssCalculator.x?vector=&version=2.0 dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C CVE ID CVE-2010-5107 has been assigned to document this issue. Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(1) Known Fixed Releases: * 5.2(1)N1(7.98), 5.2(1)N1(8), 6.0(2)N2(4.69), 6.0(2)N2(5), 7.0(1)ZN(0.403), 7.0(3)N1(0.94), 7.0(3)N1(1), 7.1(0)FGI(0.6), 7.1(0)N1(0.244), 7.1(0)N1(1) Alert Type: Updated * Bug Id: CSCtq64880 Title: not able to reach VRRP hsrp virtual address from n5k vpc peers vlan SVI Status: Fixed Severity: 3 Moderate Description: Symptom: Not able to reach HSRP virtual address from n5k vlan SVI. Problem does not happen with n5k forwarding the packets from host or other device Conditions: This bug can happen in either of the following conditions Case 1: n5ks are enabled for vlan svi and ping is initiated from the n5k to the upstream hsrp virtual address. there is no Layer 3 between the n5ks. Case 2: In addition to VPC peer link, Layer 2 trunk link is allocated to carry non- vPC VLANs between the N5ks. if vlan svi is allowed on that other trunk then the ping initiated from standby n5k to hsrp virtual address (between n5ks) will fail. Case 3: Nexus 5k switch is connected to a non-Cisco device like Juniper and that upstream Router/Switch is enabled for HSRP/VRRP Workaround: Case 1: The workaround is to configure 'hsrp use-bia' on the svi-vlan of the uplink devices that are doing HSRP. Case 2: The potential workaround are either of the below 1. put the svi vlan on the peer-link instead of other trunk link 2. configure 'hsrp use-bia' under svi-vlan on both N5ks. Case 3: Same as Case 1. Last Modified: 17-JUN-2016 Known Affected Releases: 5.0(3)N1(1c) Known Fixed Releases: * 5.1(3)N1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCua04442 Title: Nexus 5000: vFC down does not trigger callhome alert Status: Fixed Severity: 3 Moderate Description: Symptom: In a Nexus 5000/5500 switches configured for FCoE, callhome alerts are not seen for vFC down events after a NX-OS upgrade to 5.1(3)N1(1) or 5.1(3)N2(1). Conditions: Workaround: None Further Problem Description: Callhome alert for vFC down relies on severity 2 syslog message %PORT-2-IF_DOWN_ERROR_DISABLED: %$VSAN x%$ Interface vfc x is down (Error disabled) and this message is missing in NX-OS 5.1 Last Modified: 17-JUN-2016 Known Affected Releases: 5.1(3)N2(1) Known Fixed Releases: * 7.1(3)ZN(0.237), 7.1(3)ZN(0.313), 7.1(4)N1(0.773), 7.1(4)N1(1), 7.2(2)ZN(0.103), 7.3(1)N1(0.321), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuq78422 Title: Fabricpath - 1st CE port bringup places interface in L2G Blocking state Status: Fixed Severity: 3 Moderate Description: Symptom: In Fabricpath on N5k/N6k switches when the first Edge (CE) port comes up or flaps in working topology, L2 Gateway places this port in Blocking state detecting inconsistency: %STP-2-L2GW_BACKBONE_BLOCK: L2 Gateway Backbone port inconsistency blocking port ...... Conditions: Fabricpath configured with Pseudo configuration and Edge switch has the only CE edge port flapping or CE switch reloading. Workaround: Configuring more than one CE Edge port going to different CE switches or devices. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(4), 7.0(3)N1(0.125) Known Fixed Releases: * 7.1(1)N1(0.453), 7.1(1)N1(1), 7.1(1)ZN(0.7), 7.1(3)ZN(0.313), 7.2(0)AB(2), 7.2(0)N1(0.90), 7.2(0)N1(1), 7.2(0)ZN(0.108), 7.2(0)ZN(0.112), 7.3(0)N1(0.3) Alert Type: Updated * Bug Id: CSCuy23998 Title: N5k pbr next-hop adjacency not updated in hardware Status: Fixed Severity: 3 Moderate Description: Symptom: when the next-hop adjacency (ARP entry) of the PBR policy changes, PBR-routed traffic can still be forwarded to the old adjacency (old ARP information) of the next-hop Conditions: Nexus 5000 switch configured for policy-based routing (PBR), and the arp information of the next-hop IP address has changed Workaround: Issue the "clear ip arp force-delete" command will trigger a re-programmation of the PBR adjacency which will correct the adjacency. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(3)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.207), 7.1(3)ZN(0.313), 7.1(4)N1(0.749), 7.1(4)N1(1), 7.2(2)N1(0.402), 7.2(2)N1(1), 7.2(2)ZN(0.85) Alert Type: Updated * Bug Id: CSCus92726 Title: N5K link flaps with HP StoreEasy x5530 Status: Fixed Severity: 3 Moderate Description: Symptom: On a nexus 5500 series switches, 10GE links connected to an HP StoreEasy x5530 may flap until going to errdisabled state. Conditions: - This is seen on ports of N2K-C2232PP-10GE fex module as well as on nexus 5000 chassis ports. - This is seen on version later than 5.2(1)N1(1), links are not flapping on earlier NX-OS versions such that 5.1(3). Workaround: A debouce timer value of 300ms and higher stabilizes the links Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(4), 5.2(1)N1(8a), 6.0(2)N2(6), 7.1(0)N1(1), 7.3(0)N1(0.140) Known Fixed Releases: * 5.2(1)N1(9.184), 5.2(1)N1(9.185), 5.2(1)N1(9a), 7.1(3)ZN(0.222), 7.1(3)ZN(0.278), 7.1(3)ZN(0.313), 7.1(4)N1(0.762), 7.1(4)N1(0.812), 7.1(4)N1(1), 7.3(1)N1(0.339) Alert Type: Updated * Bug Id: CSCuz23976 Title: DHCP Snooping not working correctly if broadcast flag is set Status: Fixed Severity: 3 Moderate Description: Symptom: DHCP Snooping does not forward DHCP replies to DHCP client properly if broadcast flag is set; No such issue is seen if broadcast flag is not set on the packets; Conditions: The issue is seen if DHCP Snooping is enabled in the vlan of DHCP client; This is seen for DHCP packets sent by DHCP Relay to the DHCP client in case broadcast flag is set on the packets; Workaround: Disable DHCP Snooping Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(7)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.273), 7.1(3)ZN(0.313), 7.1(4)N1(0.807), 7.1(4)N1(1), 7.3(1)N1(0.340), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuq19419 Title: interface stuck in 'no switchport' Status: Fixed Severity: 3 Moderate Description: Symptom: An interface is configured with 'no switchport'. It is not possible anymore to move it to L2 interface or revert to default configuration Conditions: Configuration steps that lead to such a status are unknown Workaround: A reload is expected to fix the problem (to be confirmed) Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(1) Known Fixed Releases: * 7.1(0)N1(0.280), 7.1(0)N1(1), 7.1(0)ZN(0.377), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCun70630 Title: Filtering "sh cdp neigh" output does not yield all the entries Status: Fixed Severity: 3 Moderate Description: Symptom: Results incomplete or absent when running 'sh cdp neigh det' or 'sh cdp neigh | sec <>'. Conditions: Seen on a N5K running 5.2(1)N1(6). Workaround: Use only 'show cdp neigh'. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(6) Known Fixed Releases: * 6.0(2)N2(5.80), 6.0(2)N2(6), 7.0(1)ZN(0.694), 7.0(6)N1(0.203), 7.0(6)N1(1), 7.1(0)N1(0.298), 7.1(0)N1(1), 7.1(0)ZN(0.389), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCud70698 Title: show platform fwm info asic-errors all doesnt show asic-err for all ASIC Status: Fixed Severity: 3 Moderate Description: Symptom: Currently show platform fwm info asic-errors all on Nexus 5000/6000 prints FWM asic errors for the first ASIC in the system Conditions: Command show platform fwm info asic-errors all is run on a Nexus 5000/6000 Workaround: Issue command on a particular ASIC show platform fwm info asic-errors id Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N1(0.365) Known Fixed Releases: * 7.0(7)N1(1), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCus01129 Title: Iplus : vpc status shows "DOWN" in the fex uplink port PoCH output Status: Fixed Severity: 3 Moderate Description: Symptom: vpc status shows "DOWN" in the fex uplink port PoCH output Conditions: vpc status shows DOWN in the fex uplink port PoCH output. The vpc status is shown as UP for "show vpc (fex PoCH no)" No traffic impact but is a regression issue. Workaround: no Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(0.418), 7.1(1)N1(0.47) Known Fixed Releases: * 7.1(1)N1(0.448), 7.1(1)N1(0.76), 7.1(1)N1(1), 7.1(1)ZN(0.2), 7.1(3)ZN(0.313), 7.2(0)N1(0.78), 7.2(0)N1(1), 7.2(0)ZN(0.112), 7.2(0)ZN(0.96), 7.3(0)N1(0.3) Alert Type: Updated * Bug Id: CSCut22258 Title: clear counters interface vlan range does not clear the SVI counters Status: Fixed Severity: 3 Moderate Description: Symptom: clear counters interface vlan does not clear the svi counters. If we clear the svi counters individually then the counters are cleared. But when clearing the counters for a range of svi's it does not work. Conditions: "clear counters interface vlan 500-1000" does not clear the counters. "clear counters interface vlan 516" clears the svi 516 counters. Similarly for other svi interfaces. The issue is seen only if range of interfaces counters are cleared. L3 license should be installed. If l3 license is missing, then pfstat queries netstack using "ip_get_netstack_counters", for show commands ("show interface vlan 100-105 counters") and the desired output will not be shown Workaround: "clear counters interface vlan 500-1000" does not clear the counters. "clear counters interface vlan 516" clears the svi 516 counters. Similarly for other svi interfaces. The issue is seen only if range of interfaces counters are cleared. Further Problem Description: "clear counters interface vlan 500-1000" does not clear the counters. "clear counters interface vlan 516" clears the svi 516 counters. Similarly for other svi interfaces. The issue is seen only if range of interfaces counters are cleared. When an invalid SVI interface index is passed to the routine "pfstat_clear_intf_cntrs_hdlr" , it fails without sending an MTS messgae (MTS_OPC_PFSTAT_SRV_2_CL_VLAN) to stats_client. The subroutine which causes this failure is "pfstat_find_if_in_db" after a AVL lookup of the unconfigured SVI interface. Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(0)N1(0.124) Known Fixed Releases: * 7.1(1)ZN(0.115), 7.1(2)N1(0.536), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.12), 7.2(1)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuq27661 Title: N5k/6k - DHCP offers might not get relayed in Fabricpath topologies Status: Fixed Severity: 3 Moderate Description: * Symptom:In a Nexus 5500/5600/6000 switches in fabricpath environment, broadcast DHCP offers might not get relayed under certain conditions. Conditions:Fabricpath setup with DHCP relay configured on more than 1 switch. DHCP offer sent as broadcast follows multi-destination tree and hits another Relay agent in the setup. Instead of forwarding the offer down the multi-destination path DHCP offer is redirected to CPU and dropped. Workaround:Enable DHCP relay only on 1 switch in FP setup. More Info:Problem was resolved through CSCuj46069 in past, however issue could be seen in some corner cases and this bug provides a complete fix. Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(7.136), 6.0(2)N2(5) Known Fixed Releases: * 5.2(1)N1(7.140), 5.2(1)N1(8a), 6.0(2)N2(5.80), 6.0(2)N2(6), 7.0(1)ZN(0.706), 7.0(6)N1(0.211), 7.0(6)N1(1), 7.1(0)N1(0.1), 7.1(0)N1(0.289), 7.1(0)N1(1) Alert Type: Updated * Bug Id: CSCux95821 Title: show tech-support fcoe needs to contain all pertinent FC information Status: Fixed Severity: 3 Moderate Description: Symptom: Enhance show tech-support fcoe so that it includes all FC pertinent information. This should be similar to the MDS show tech-support details Conditions: Applicable to the Nexus 5000/5600/6000 switches using FC and/or FCoE. Workaround: Use individual show tech-support commands. For example: show tech-support zone show tech-support fcns show tech-support fcdomain show tech-support port etc... Further Problem Description: None. Resolution Summary: show tech-support fcoe will now contain the following commands: show switchname show inventory show interface show topology show logging log show logging nvram show accounting log show tech-support snmp show tech-support ha show tech-support cli show tech-support cdp show tech-support issu show tech-support clis show tech-support pltfm-config show tech-support flogi show tech-support pfstat show tech-support cfs show tech-support fcdomain show tech-support fcs show tech-support acl show tech-support port-channel show tech-support fc2 show tech-support port show tech-support fc show tech-support fcoe_mgr Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(7)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.243), 7.1(3)ZN(0.313), 7.1(4)N1(0.778), 7.1(4)N1(1), 7.2(2)N1(0.407), 7.2(2)N1(1), 7.2(2)ZN(0.107), 7.3(1)N1(0.325), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuw51779 Title: MAC not learned on AA HIF with port-security after vlan changed twice Status: Fixed Severity: 3 Moderate Description: Symptom: MAC address is no longer learned after the vlan membership changes two times. E.g. Initial vlan membership is 2222, we change it to 3333 and then back to 2222. Nexus5500# show interface eth100/1/1 switchport | i i "access mode vlan" Access Mode VLAN: 2222 (VLAN2222) Nexus5500# show interface eth100/1/1 switchport | i i "access mode vlan" Access Mode VLAN: 3333 (VLAN3333) Nexus5500# show interface eth100/1/1 switchport | i i "access mode vlan" Access Mode VLAN: 2222 (VLAN2222) Conditions: Port-security configured on a FEX HIF port from an Active-Active (Dual-Homed) FEX switch. The vlan membership change is done only on one of the Nexus 5500 peers to which the FEX is Dual-Homed to. Workaround: Make the same vlan membership changes on the peer Nexus 5500 switch. Shutdown/no shutdown of the HIF port. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N1(2a) Known Fixed Releases: * 7.1(3)ZN(0.224), 7.1(3)ZN(0.313), 7.1(4)N1(0.764), 7.1(4)N1(1), 7.2(2)N1(0.382), 7.2(2)N1(1), 7.2(2)ZN(0.64), 7.3(1)N1(0.320), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCus73291 Title: Kernel Panic for process fcoe_mgr Status: Fixed Severity: 3 Moderate Description: Symptom: Kernel Panic causes a reload of the active supervisor Conditions: Unknown Workaround: Unknown Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(7) Known Fixed Releases: * 7.1(3)ZN(0.303), 7.1(3)ZN(0.313), 7.1(4)N1(0.835), 7.1(4)N1(1), 7.2(2)N1(0.444), 7.2(2)N1(1), 7.2(2)ZN(0.152), 7.3(1)N1(0.371), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCui63827 Title: sh int fc <x/y> capabilities , shows fc <x/y> twice Status: Fixed Severity: 3 Moderate Description: Symptom: On running command "sh int fc capabilities" fc shows up twice Conditions: Trying to verify the fc port capabilities Workaround: none Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N1(2a) Known Fixed Releases: * 7.1(3)ZN(0.200), 7.1(3)ZN(0.313), 7.1(4)N1(0.743), 7.1(4)N1(1), 7.2(2)N1(0.397), 7.2(2)N1(1), 7.2(2)ZN(0.79), 7.3(1)N1(0.37), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuv03880 Title: Nexus 5696 Cant display DOM of TX RX power reading WSP-Q40GLR4L Status: Fixed Severity: 3 Moderate Description: Symptom: F340.12.22-N5K-C5696-1# sh ver Cisco Nexus Operating System (NX-OS) Software TAC support: http://www.cisco.com/tac Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_series_home.html Copyright (c) 2002-2015, Cisco Systems, Inc. All rights reserved. The copyrights to certain works contained herein are owned by other third parties and are used and distributed under license. Some parts of this software are covered under the GNU Public License. A copy of the license is available at http://www.gnu.org/licenses/gpl.html. Software BIOS: version 2.1.0 Power Sequencer Firmware: Module 1: v1.0 Module 1: v1.0 Module 2: v1.0 Module 8: v2.0 Fabric Power Sequencer Firmware: Module 0: version v3.0 Microcontroller Firmware: version v1.2.2.0 QSFP Microcontroller Firmware: Module 1: v1.7.0.0 Module 2: v1.7.0.0 CXP Microcontroller Firmware: Module not detected kickstart: version 7.1(1)N1(1) system: version 7.1(1)N1(1) BIOS compile time: 09/01/2014 kickstart image file is: bootflash:///n6000-uk9-kickstart.7.1.1.N1.1.bin kickstart compile time: 4/18/2015 10:00:00 [04/18/2015 20:23:20] system image file is: bootflash:///n6000-uk9.7.1.1.N1.1.bin system compile time: 4/18/2015 10:00:00 [04/18/2015 20:24:07] Hardware cisco Nexus 5696 Chassis ("Nexus 5696 Supervisor") Intel(R) Xeon(R) CPU @ 1.80 with 16511900 kB of memory. Processor Board ID FOC1832A5AE Device name: F340.12.22-N5K-C5696-1 bootflash: 7864320 kB Kernel uptime is 0 day(s), 1 hour(s), 24 minute(s), 47 second(s) Last reset Reason: Unknown System version: 7.1(1)N1(1) Service: plugin Core Plugin, Ethernet Plugin sh module F340.12.22-N5K-C5696-1# sh module Mod Ports Module-Type Model Status --- ----- ----------------------------------- ---------------------- ----------- 0 0 Nexus 5696 Supervisor N5K-C5696Q-SUP active * 1 12 Nexus 5696 12xQSFP Ethernet Module N5696-M12Q ok 2 12 Nexus 5696 12xQSFP Ethernet Module N5696-M12Q ok 8 20 Nexus 5696 20xUnified Port Module N6004X-M20UP ok Mod Sw Hw World-Wide-Name(s) (WWN) --- -------------- ------ --------------------------------------------------- 0 7.1(1)N1(1) 1.0 -- 1 7.1(1)N1(1) 1.0 -- 2 7.1(1)N1(1) 1.0 -- 8 7.1(1)N1(1) 1.0 -- Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 0 002a.6aed.3900 to 002a.6aed.391f FOC1832A5AE 1 ccd8.c180.51a8 to ccd8.c180.51b7 FOC18330H0X 2 0c68.0311.bb28 to 0c68.0311.bb37 FOC18330GPB 8 dca5.f4e1.70d0 to dca5.f4e1.70df FOC18038YLR F340.12.22-N5K-C5696-1# sh int eth 2/1 transceiver details Ethernet2/1 transceiver is present type is WSP-Q40GLR4L name is CISCO part number is FTL4C1QL1C-C1 revision is A serial number is FNS18440G0S nominal bitrate is 10300 MBit/sec Link length supported for SMF fiber is 2 km cisco id is -- cisco extended id number is 208 SFP Detail Diagnostics Information (internal calibration) ---------------------------------------------------------------------------- Current Alarms Warnings Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(1)N1(1) Known Fixed Releases: * 7.1(3)N1(0.620), 7.1(3)N1(1), 7.1(3)ZN(0.27), 7.1(3)ZN(0.313), 7.2(1)N1(0.298), 7.2(1)N1(1), 7.2(1)ZN(0.62), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCut91877 Title: Multiple 2300 FEX report FAN Failure reports intermittently Status: Fixed Severity: 3 Moderate Description: Symptom: Multiple FEX FAN minor alarm at different times. This is seen/applicable for 23xx series FEX's: %SATCTRL-FEXxxx-2-SOHMS_DIAG_ERROR: FEX-xxx System minor alarm on fans in fan tray 1 %SATCTRL-FEXxxx-2-SOHMS_DIAG_ERROR: FEX-xxx Recovered: System minor alarm on fans in fan tray 1 %SATCTRL-FEXyyy-2-SOHMS_DIAG_ERROR: FEX-yyy System minor alarm on fans in fan tray 1 %SATCTRL-FEXyyy-2-SOHMS_DIAG_ERROR: FEX-yyy Recovered: System minor alarm on fans in fan tray 1 Conditions: Based on wrong sensor values comparison for 2300 FEX's Workaround: None. Fix is through software upgrade. Further Problem Description: Last Modified: 18-JUN-2016 Known Affected Releases: 7.1(0)N1(1), 7.2(0)D1(1), 7.2(0)N1(1) Known Fixed Releases: * 7.1(3)N1(0.645), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.53), 7.2(2)N1(0.5), 7.2(2)N1(1), 7.3(0)IZN(0.7), 7.3(0)N1(0.181), 7.3(0)N1(1), 7.3(0)ZN(0.163) Alert Type: Updated * Bug Id: CSCuu38577 Title: N55xx,N56xx and N600x : link debounce timer may not work as configured Status: Fixed Severity: 3 Moderate Description: Symptom: link debounce timer may not work as configured Conditions: Applicable to all N6k Series and N55xx and N56xxx series. Software 7.1(3)ZN(1), 7.1(4)N1 onwards Workaround: unknown Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.159), 7.1(3)ZN(0.313), 7.1(4)N1(0.714), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCus22583 Title: Changing the port type doesn't remove the configuration from startup Status: Fixed Severity: 3 Moderate Description: Symptom: Changing the port type will not remove the configuration from startup configuration even after "copy run start" is performed. Conditions: Performing the port type change. Detail will be provided later. Workaround: None Further Problem Description: Configuration should have been removed during the port type change and shouldn't re-apply automatically when the port type change is revert it back. Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(3) Known Fixed Releases: * 7.1(3)ZN(0.276), 7.1(3)ZN(0.313), 7.1(4)N1(0.810), 7.1(4)N1(1), 7.2(2)N1(0.423), 7.2(2)N1(1), 7.2(2)ZN(0.131), 7.3(1)N1(0.352), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuq42482 Title: N5K dual homed vpc fex, hif speed change not always picked up N5K's Status: Fixed Severity: 3 Moderate Description: Symptom: Nexus 5k switches in vpc with dual homed fex devices. Server attached to the hif port on the fex is changing its link speed during bootup from 100 Mbit/s to 1 Gigabit/s. VPC process does not see this change of link speed if there is no link flap during the link speed change. Cusotmer has a large debounce timer configured on the fex host port in an effort to not drop dhcp offers that are received right around the time of the link flap. Conditions: Workaround: Dont change the link speed during bootup, or make sure the interface in question on the fex does have a link flap during the speed change. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(3)N1(0.99) Known Fixed Releases: * 7.0(1)ZN(0.739), 7.0(6)N1(0.238), 7.0(6)N1(1), 7.1(1)N1(1), 7.1(1)ZN(0.7), 7.1(3)ZN(0.313), 7.2(0)AB(2), 7.2(0)N1(1), 7.2(0)VZN(0.31), 7.2(0)VZN(0.7) Alert Type: Updated * Bug Id: CSCut07668 Title: N5k: Cisco IP phone voice vlan not working Status: Fixed Severity: 3 Moderate Description: Symptom: Cisco IP phone connected to N5k native port or N5k FEX port is not working Conditions: This is observed on 5.1 - 7.1 NX-OS releases Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(1) Known Fixed Releases: * 7.1(1)ZN(0.115), 7.1(2)N1(0.536), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.3), 7.2(1)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuq00984 Title: Place holder for SNMP changes in N7K bug CSCug60602 Status: Fixed Severity: 3 Moderate Description: * Symptom: Not all bridge ports are instantiated in the following tables in CISCO-STP-EXTENSIONS-MIB: stpxSMSTPortTable stpxRootGuardConfigTable stpxLoopGuardConfigTable Conditions: Workaround: Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(0)EV(0.5) Known Fixed Releases: * 7.1(3)ZN(0.227), 7.1(3)ZN(0.313), 7.1(4)N1(0.766), 7.1(4)N1(1), 7.3(1)N1(0.24), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCum93892 Title: VSAN is stuck in operational state down, but state is active. Status: Fixed Severity: 3 Moderate Description: Symptom: A VSAN's operational state may be listed as "down", but state shows "active" `show vsan` vsan 1 information name:VSAN0001 state:active interoperability mode:default loadbalancing:src-id/dst-id/oxid operational state:down This bug may also affect DCNM functionality, specifically when trying to configure zones for affected VSAN's. If the VSAN is "stuck" in the down state, DCNM will not be able to poll it correctly. If a switch is affected by this bug, DCNM will report the following error on DCNM 6.3(1) versions and above: "The login user does not have permission to edit zones for the switches in selected VSAN. To edit zones, please discover the switches in selected VSAN using SNMP User with read/write permission." DCNM versions 6.2(3) and below, this error is reported: "SNMP no device available" In the fmserver.log file you will see the following error: ("%INSTALL DIR%\Cisco Systems\dcm\fm\logs\fmserver.log") "cannot find VSAN # on the switch" Please note: You can still encounter this issue on DCNM and have the VSAN be in "operational state: up" If you suspect this bug, check for the "cannot find VSAN # on the switch" error in fmserver.log when trying to perform zoning via DCNM. If the VSAN exists on the switch (confirmed via CLI) and the switch user account has the correct read/write permissions, you are most likely encountering this bug. Conditions: N/A Workaround: Reboot the switch if the running image doesn't have the fix. In the switch whose running image has the fix, configure the command "no vsan suspend" after ISSU if the ISSU is non-disruptive. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N1(2a), 7.0(0)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.126), 7.1(2)N1(0.560), 7.1(2)N1(1), 7.1(2)ZN(0.21), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.30), 7.2(1)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCux78120 Title: Upgrade failure due to FEX file transfer error Status: Fixed Severity: 3 Moderate Description: Symptom: Sometimes the upgrade of system image on FEX fails Conditions: When we try to upgrade the system image on FEX Workaround: Need to manually umount & mount the file system & then the upgrade succeeds Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(8)N1(0.313) Known Fixed Releases: * 5.2(1)N1(9.188), 5.2(1)N1(9a), 7.0(7)ZN(0.270), 7.0(8)N1(0.328), 7.0(8)N1(1), 7.1(3)N1(4), 7.1(3)ZN(0.186), 7.1(3)ZN(0.313), 7.1(4)N1(0.733), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCuq04309 Title: nexus snmpd crash after mts queue full Status: Fixed Severity: 3 Moderate Description: Symptom: snmpd service crash Conditions: The crash was observed when MTS Queue became full. Workaround: The only workaround to avoid this crash is to stop the snmp polling done against the switch. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(3) Known Fixed Releases: * 6.0(2)A6(5.232), 6.0(2)A6(6), 6.0(2)A8(0.337), 6.0(2)A8(1), 6.0(2)U6(6.232), 6.0(2)U6(7), 6.0(2)U8(0.337), 6.0(2)U8(1), 7.0(1)ZN(0.695), 7.0(6)N1(1) Alert Type: Updated * Bug Id: CSCur47111 Title: Nexus 5500: delay restore value should not be less than 150 for L3 setup Status: Fixed Severity: 3 Moderate Description: Symptom: If you configure a value of 30 for delay restore on the Nexus 5500 switches, then after a reload it changes to 150. This is the expected behavior for L3 setup. The behavior is the same for Nexus 5600 and Nexus 6000 platforms. Conditions: Nexus 5500 with an L3 module and license installed Workaround: None, it is not advised to configure delay restore timer of less than 150 since the L3 module takes more time than the rest of the switch to come up. Further Problem Description: Behavior on the Nexus 5500: This bug is filed to not allow the timer to be less than 150 for L3 setup. Behavior on the Nexus 5600 and Nexus 6000: Behavior will not change since the L3 portion is integrated into the switch. As such it would not take longer for the L3 part to initialize as compared to the rest of the switch. If you configure a value of 30, default value of 150 would show up after a reload. If you configure any other value, it would be retained. Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(8a), 6.0(2)N2(5), 7.0(4)N1(1) Known Fixed Releases: * 7.1(0)EVN(0.18), 7.1(1)ZN(0.117), 7.1(2)N1(0.538), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(0.16), 7.2(0)N1(1), 7.2(0)ZN(0.112), 7.2(0)ZN(0.28), 7.3(0)N1(0.3) Alert Type: Updated * Bug Id: CSCuq81861 Title: Enabling peer-gateway breaks the fix for CSCui48861 Status: Fixed Severity: 3 Moderate Description: Symptom: Unable to comunicate with hosts in bridged vlans. Conditions: Nexus 6K/5600 has an L3 interface in a vlan which is bridged into an L2 vlan on the same switch. Peer gateway is enabled Workaround: Static the RMAC (SVI mac) for both Nexus switches on the bridged interface Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(1)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(1)N1(0.457), 7.1(1)N1(1), 7.1(1)ZN(0.11), 7.1(3)ZN(0.313), 7.2(0)AB(2), 7.2(0)N1(0.101), 7.2(0)N1(1), 7.2(0)ZN(0.112) Alert Type: Updated * Bug Id: CSCuw89463 Title: MTS buffer leaks for mcecm on the peer device with MCT flap Status: Fixed Severity: 3 Moderate Description: Symptom: Observed MTS buffer leaks on vPC secondary device with MCT flap Conditions: On a vPC setup, mts buffer leaks for vPC SAP (450) are seen after flapping MCT on vPC primary repeatedly around 20 times. Workaround: No workaround exists. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.3(0)N1(0.177) Known Fixed Releases: * 7.1(3)ZN(0.137), 7.1(3)ZN(0.313), 7.1(4)N1(0.702), 7.1(4)N1(1), 7.2(2)N1(0.356), 7.2(2)N1(1), 7.2(2)ZN(0.40), 7.3(0)IZN(0.13), 7.3(0)N1(0.211), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuv69160 Title: N5K: DHCP Snooping binding maintains incorrect port after a client move Status: Fixed Severity: 3 Moderate Description: Symptom: If a DHCP client moves and then renews its IP, a Nexus 5000 Series Switch will fail to update the DHCP Snooping binding with the new Interface. If DAI is enabled, this incorrect binding will prevent the client from resolving ARP for its gateway. Conditions: Nexus 5000 with DHCP Snooping enabled. Workaround: None. If DAI is disabled there will be no impact. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(0)N1(1) Known Fixed Releases: * 7.1(3)N1(0.634), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.42), 7.2(1)N1(0.301), 7.2(1)N1(1), 7.2(1)ZN(0.65), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCua77932 Title: N5k crashes due to fwm hap reset Status: Fixed Severity: 3 Moderate Description: Symptom: Nexus5548UP rebooted with reset reason: fwm hap reset Conditions: Workaround: Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.1(3)N2(1) Known Fixed Releases: * 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)N1(1), 6.0(2)U5(1.37), 6.0(2)U5(2), 6.0(2)U6(0.105), 6.0(2)U6(1), 7.0(7)N1(0.282) Alert Type: Updated * Bug Id: CSCus94969 Title: newly added FP vlan is not stp forwarding on the Po interface Status: Fixed Severity: 3 Moderate Description: Symptom: while creating a new Fabricpath vlan, its state is not stp forwarding on the po interface: mgd01sw0101zoi# show platform fwm info vlanif 352 port-channel 5 vlanif vlan 1.352 if 16000004 stp state: not forwarding Conditions: the command "switchport mode private-vlan trunk promiscuous" is configured on the port-channel interface Workaround: 1. resetting the port-channel interface resolves the issue: mgd01sw0101zoi(config)# int po 5 mgd01sw0101zoi(config-if)# shut mgd01sw0101zoi(config-if)# no shut mgd01sw0101zoi(config-if)# end mgd01sw0101zoi# show platform fwm info vlanif 352 port-channel 5 vlanif vlan 1.352 if 16000004 stp state: forwarding 2. Remove the specific vlan from the port-channel interface, add it as a FP vlan and then add the vlan back in the allowed vlan list of the port-channel interface: a) I've removed vlan 140 from the "switchport private-vlan trunk allowed vlan" list mgd01sw0101zoi(config)# int po 5 mgd01sw0101zoi(config-if)# switchport private-vlan trunk allowed vlan remove 140 mgd01sw0101zoi(config-if)# end mgd01sw0101zoi# sh run int po 5 membership interface port-channel5 description mgd01ro1010zoi switchport mode private-vlan trunk promiscuous lacp suspend-individual spanning-tree port type edge trunk logging event port link-status logging event port trunk-status switchport private-vlan trunk allowed vlan 1-139,141-3967,4048-4093 <<<<<<<<<<<<<< b) I've created VLAN 140 and put in mode fabricpath mgd01sw0101zoi(config)# vlan 140 mgd01sw0101zoi(config-vlan)# mode fab mgd01sw0101zoi(config-vlan)# exit mgd01sw0101zoi(config)# show platform fwm info vlanif 140 port-channel 5 vlanif vlan 1.140 if 16000004 stp state: not forwarding <<<<<<<<<<<<<<< mgd01sw0101zoi(config)# mgd01sw0101zoi(config)# show platform fwm info vlanif 140 port-channel 5 vlanif vlan 1.140 if 16000004 stp state: not forwarding mgd01sw0101zoi(config)# show platform fwm info vlanif 140 port-channel 5 vlanif vlan 1.140 if 16000004 stp state: not forwarding c) I've added the VLAN 140 to the "switchport private-vlan trunk allowed vlan" list mgd01sw0101zoi(config)# mgd01sw0101zoi(config)# int po 5 mgd01sw0101zoi(config-if)# switchport private-vlan trunk allowed vlan add 140 mgd01sw0101zoi(config-if)# exit mgd01sw0101zoi(config)# show platform fwm info vlanif 140 port-channel 5 vlanif vlan 1.140 if 16000004 stp state: forwarding <<<<<<<<<<<<<<<<<<<<< mgd01sw0101zoi(config)# Further Problem Description: adding normal vlans is not an issue as the stp state is forwarding on the port-channel interface. Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(7) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.542), 7.1(2)N1(1), 7.1(2)ZN(0.1), 7.1(3)ZN(0.313), 7.2(0)N1(0.166), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.169) Alert Type: Updated * Bug Id: CSCuh17299 Title: N6k/N5k: ethanalyzer display filters do not work when written to file Status: Fixed Severity: 3 Moderate Description: Symptom: In a Nexus 55xx or Nexus 6000, Ethanalyzer filters not working when output is written to a file. Conditions: Ethanalyzer output is captured to a file. Workaround: Do not write output to a file. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N1(2a) Known Fixed Releases: * 7.1(2)N1(0.543), 7.1(2)N1(1), 7.1(2)ZN(0.2), 7.1(3)ZN(0.313), 7.2(0)AB(2), 7.2(0)N1(0.90), 7.2(0)N1(1), 7.2(0)ZN(0.108), 7.2(0)ZN(0.112) Alert Type: Updated * Bug Id: CSCup77720 Title: cts manual command not allowed with fex pre provisioning Status: Fixed Severity: 3 Moderate Description: Symptom: cts manual command can not be pre provisioned for fex interfaces in a active/active Nexus 5k Nexus 2k environment. Conditions: when you try to install another or replace another switch in a N55K with active / active fex attachement the switch will not accept cts manual command for preprovisioning the fex interfaces Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(4) Known Fixed Releases: * 6.0(2)N2(5.101), 6.0(2)N2(6), 7.0(1)ZN(0.681), 7.0(6)N1(0.192), 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.446), 7.1(1)N1(1) Alert Type: Updated * Bug Id: CSCup70139 Title: N5K fwm hap reset Status: Fixed Severity: 3 Moderate Description: Symptom: ----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) --- 1) At 983601 usecs after Wed Jun 18 14:35:19 2014 Reason: Reset triggered due to HA policy of Reset Service: fwm hap reset Version: 5.2(1)N1(3) %SYSMGR-2-SERVICE_CRASHED: Service "fwm" (PID 3358) hasn't caught signal 11 (core will be saved). %SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "fwm" in vd c 1 has had a hap failure Conditions: this crash was seen on Nexus5548 running code 5.2(1)N1(3) Workaround: there is no workaround Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(3) Known Fixed Releases: * 5.2(1)N1(9.178), 5.2(1)N1(9a), 7.0(7)N1(0.66), 7.0(7)N1(1), 7.0(7)ZN(0.142), 7.1(2)N1(0.547), 7.1(2)N1(1), 7.1(2)ZN(0.6), 7.1(3)ZN(0.313), 7.2(1)N1(0.242) Alert Type: Updated * Bug Id: CSCuu87608 Title: N56-M24UP2Q interfaces are not listed in IF-MIB snmp walk Status: Fixed Severity: 3 Moderate Description: Symptom: N56-M24UP2Q interfaces are not listed in IF-MIB snmp walk Conditions: Nexus 5600 switches with a N56-M24UP2Q GEM Expansion module and some ports configured to operate in Fibre Channel mode. slot 2 port 1-6 type fc Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(1)N1(1) Known Fixed Releases: * 7.0(7)N1(0.280), 7.0(7)N1(1), 7.0(7)ZN(0.157), 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.1(3)ZN(0.313), 7.2(1)N1(1), 7.2(1)ZN(0.19), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCus19792 Title: "show fcns database", "show fcs ie" not correctly populated after ISSU Status: Fixed Severity: 3 Moderate Description: Symptom: After upgrading 6.0(2)N2(5a) on Nexus switch, outputs from "show fcns database" on NPV devices changed: the following fields are reporting: connected interface :Virtual Device switch name (IP address) :Not Available Instead of the previous release output: connected interface :fcx/y switch name (IP address) :NPV1 (192.168.1.1) This is affecting NPV devices from Cisco or 3rd party vendor. Conditions: ISSU to 6.0(2)N2(5a) on Nexus 5k acting as NPIV device for connected NPV in following topology: NPIV coreNPIV intermediate npv-device Workaround: 1)Downgrade NX-OS to previous release or After upgrade to affected version, flap the ISL (if applicable, whole port-channel) between NPIV core and Intermediate NPIV switches. This is disruptive. It will trigger a new NPV discovery and databases will be updated on FCS IE + FCNS DATA on NPIV core, also DCNM will be able to gather NPV information on switch and attached HBAs. or 2)Disable CFS over Ethernet on NPIV devices since if not needed (confirm no ethernet feature using it) Further Problem Description: Note to an ISSU to a fixed release in the future from affected 6.0(2)N2(6) will need a disruptive upgrade (planned reboot; ISL flap) since the correct entries won't be populated after the upgrade without the first workaround above applied. An ISSU from unaffected version 5.2(1)N1(6) or 6.0(2)N2(5a) to a future fixed release should not require that workaround since FCS IE and FCNS databases will have proper information. Resolution summary: Fabric Configuration Server (FCS) stores the switch and node data, maintained by other servers/services on the switch, in order to respond to management application queries. But some of its data is not persistent, so after ISSU, that data is lost. The way FCS discovers this data after ISSU is that when any show CLI is run, FCS will contact the appropriate servers to learn/discover that data. Bug fix does this for the attribute "switchname". Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(5) Known Fixed Releases: * 7.1(1)N1(0.457), 7.1(1)N1(1), 7.1(1)ZN(0.11), 7.1(3)ZN(0.313), 7.2(0)AB(2), 7.2(0)N1(1), 7.2(0)VZN(0.7), 7.2(0)ZN(0.120) Alert Type: Updated * Bug Id: CSCub16077 Title: FRAME DISCARD message seen after bringing up multi-hop FCoE vfc intf Status: Fixed Severity: 3 Moderate Description: Symptom: A Nexus 5000 switch configured to be in NPV mode might print following messages every 20 minutes for NP mode vFC interfaces. 2012 Aug 2 23:00:17 20-08-5548-B %NPV-5-FRAME_DISCARDED: %$VSAN 200%$ Frame with unexpected FC2 status 0xc received on interface vfc548 2012 Aug 2 23:20:17 20-08-5548-B %NPV-5-FRAME_DISCARDED: %$VSAN 200%$ Frame with unexpected FC2 status 0xc received on interface vfc548 Conditions: Nexus 5000 switch has NPV mode configured and multi-hop FCoE is configured with NP vFC interfaces. Workaround: Messages does not have any impact. Logging level could be changed to warnings with command logg level npv 4 Further Problem Description f the nexus 5k switch is in npv mode with native FC interfaces configured with upstream NPIV switch and if the same errors occurs for FC interfaces going to upstream NPIV switch the problem is tracked via CSCtz79193 Frame discard observed in NPV when NP is brought up. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N1(0.292) Known Fixed Releases: * 6.0(2)A1(1), 6.0(2)U1(1), 7.1(3)ZN(0.258), 7.1(3)ZN(0.313), 7.1(4)N1(0.793), 7.1(4)N1(1), 7.2(2)N1(0.411), 7.2(2)N1(1), 7.2(2)ZN(0.118), 7.3(1)N1(0.338) Alert Type: Updated * Bug Id: CSCun80333 Title: pbr-statistics counter issue in multi-sequence PBR Status: Fixed Severity: 3 Moderate Description: Symptom: When multi-sequece PBR, which is supported since Vinci, is configured, only the second sequence counts up even if packets hit the first sequence in PBR: Conditions: multi-sequence PBR is configured as follows: route-map PBR deny 10 match ip address 100 route-map PBR permit 20 match ip address 101 set ip next-hop 172.16.0.1 Workaround: none. PBR itself seems to work properly. Further Problem Description: When multi-sequece PBR, which is supported since Vinci, is configured following, only the second sequence counts up even if packets hit the first sequence in PBR: route-map PBR pbr-statistics route-map PBR deny 10 match ip address 100 route-map PBR permit 20 match ip address 101 set ip next-hop 172.16.0.1 interface Ethernet1/11 no switchport ip address 10.1.0.254/24 ip policy route-map PBR Switch# show route-map PBR pbr-statistics route-map PBR, deny, sequence 10 Policy routing matches: 0 packets <<==This counter should also count up. route-map PBR, permit, sequence 20 Policy routing matches: 15 packets <<==This counter works even if the packet is applied to the first sequence. It is confirmed that multi-sequence PBR itself did work correctly since the first sequence of "deny" was applied to the packet through the N5K. Thus, this is counter issue for multi-sequence PBR. Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(1)N1(1) Known Fixed Releases: * 7.0(1)ZN(0.724), 7.0(6)N1(0.227), 7.0(6)N1(1), 7.1(0)N1(0.1), 7.1(0)N1(0.238), 7.1(0)N1(1), 7.1(0)ZN(0.336), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCut64547 Title: LACP port-channel show wrong ifType Status: Fixed Severity: 3 Moderate Description: Symptom: The SNMP IfType for a PC or vPC is giving back propVirtual (53) instead of ieee8023adLag (161) Conditions: When a PC or vPC is configured Workaround: no workaround Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(3)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.111), 7.1(2)N1(0.544), 7.1(2)N1(1), 7.1(2)ZN(0.3), 7.1(3)ZN(0.313), 7.2(0)N1(0.167), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.170) Alert Type: Updated * Bug Id: CSCus77310 Title: vpc hap reset vpc process crashed Status: Fixed Severity: 3 Moderate Description: Symptom: vpc hap reset in a vpc configuration a vpc peer switch has a vpc process hap reset. Conditions: vpc environment. (So far is it seen only once in customer setup). Workaround: none Further Problem Description: Last Modified: 17-JUN-2016 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)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) Alert Type: Updated * Bug Id: CSCur04843 Title: LLDP with tlv length 0 are dropped Status: Fixed Severity: 3 Moderate Description: Symptom: Customer is reporting the following syslog message: 014 Aug 5 17:22:45 mr0s5k03 %LLDP-FEX103-3-INVALID_LLDP_RECEIVED: Received an invalid LLDP on Eth103/1/15 (can also be on chassis ports) Conditions: An LLDP peer is including an optional TLV in the LLDP frame with a length of 0. On nexus side can be checked in lldp event logs : show system internal lldp event-history errors ... Event:E_DEBUG, length:44, at 746661 usecs after Fri Aug 8 08:53:11 2014 [102] lldp_pkt_parse : Bad tlv: type/len 5/0 ... Workaround: Only to get rid of that log message: 1) disable lldp receive on interface no lldp receive 2)reduce log level for LLDP : conf t logging level lldp 2 end copy running-config startup-config If LLDP is needed for other features to be operational - no workaround. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(1a) Known Fixed Releases: * 7.1(0)EVN(0.18), 7.1(1)ZN(0.120), 7.1(2)N1(0.541), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(0.27), 7.2(0)N1(1), 7.2(0)ZN(0.112), 7.2(0)ZN(0.39), 7.3(0)N1(0.3) Alert Type: Updated * Bug Id: CSCug11795 Title: vlans error disabled over Peer-link Status: Fixed Severity: 3 Moderate Description: Symptom:This is a modification on the product to adopt new secure code best practices to enhance the security posture and resiliency of the product. Conditions:Device configured with default configuration. Workaround:Not applicable or available. More Info:This issue was found during an internal security audit of the product. This issue should not be made public as it is an internal hardening issue to be considered for integration. Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N1(0.1) Known Fixed Releases: * 6.0(2)N2(5.78), 6.0(2)N2(6), 7.0(1)ZN(0.533), 7.0(4)N1(0.149), 7.0(4)N1(1), 7.1(0)N1(0.297), 7.1(0)N1(1), 7.1(0)ZN(0.388), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCus65288 Title: ERSPAN outer ip header length exceeds the maximum limit for a packet Status: Fixed Severity: 3 Moderate Description: Symptom: Nexus 5500 and 6000 series switches may send ERSPAN encapsulated packets where the outer total ip length is incorrect. Conditions: Workaround: Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(0.116), 7.1(0)N1(1) Known Fixed Releases: * 7.0(1)ZN(0.742), 7.0(6)N1(0.243), 7.0(6)N1(1), 7.1(1)N1(0.468), 7.1(1)N1(1), 7.1(1)ZN(0.20), 7.1(3)ZN(0.313), 7.2(0)N1(1) Alert Type: Updated * Bug Id: CSCue08601 Title: Show interface trunk shows all interfaces as fabric path forwarding Status: Fixed Severity: 3 Moderate Description: Symptom: The 'sh int trunk' shows all interfaces as ""Port Vlans Forwarding on FabricPath"." Conditions: This is seen on a Nexus5K running 5.2(1)N1(2a). Workaround: None. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(2a), 6.0(2)N2(0.71) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.540), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(1)N1(0.240), 7.2(1)N1(1), 7.2(1)ZN(0.6), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCum99674 Title: manual reload is not always recorded in accounting log Status: Fixed Severity: 3 Moderate Description: Symptom: Manual reload of the switch is not always stored in the accounting log Conditions: This is not really a impacting issue. Customer reloads a nexus 5500 switch manually and the reload command is not shown in the accounting log. show system reset-reason does show the reload reason correct. Issue is of a cosmetic type. But accounting log is used to verify who did what operation on the switch. Workaround: None Further Problem Description: Last Modified: 18-JUN-2016 Known Affected Releases: 5.2(1)N1(6), 7.0(0)N1(1) Known Fixed Releases: * 7.0(7)N1(0.292), 7.0(7)N1(1), 7.0(7)ZN(0.187), 7.1(3)N1(0.608), 7.1(3)N1(1), 7.1(3)ZN(0.13), 7.1(3)ZN(0.313), 7.2(1)N1(0.271), 7.2(1)N1(1), 7.2(1)ZN(0.35) Alert Type: Updated * Bug Id: CSCuy93128 Title: N5K ttyd process core when ISSU to 7.0(7)N1(1) Status: Fixed Severity: 3 Moderate Description: Symptom: N5K ISSU upgrade from 7.0.5.N1.1 to 7.0.7.N1.1 caused a ttyd core. Conditions: Seen during ISSU and causes an ISSU upgrade to be disruptive. Workaround: Unknown at this time. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(8)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.270), 7.1(3)ZN(0.313), 7.1(4)N1(0.804), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCuq91075 Title: DFA: DHCP fix for Infoblox Status: Fixed Severity: 3 Moderate Description: Symptom: Infoblox DHCP server failed to integrate with Cisco DFA with version 7.1.0N1(1) or older Conditions: Infoblox GUI has a limitation in that it does not allow the user to match using a portion of the Circuit ID in option 82. This limitation makes it impossible for Cisco DFA DHCP to work with Infoblox server to generate class and choose the right scope using the classing mechanism. Workaround: There is no workaround with Infoblox GUI The user will have to manually configure dhcpd without using Infoblox Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(2)NF(0.17) Known Fixed Releases: * 7.1(1)N1(0.471), 7.1(1)N1(1), 7.1(1)ZN(0.24), 7.1(3)ZN(0.313), 7.2(0)N1(0.5), 7.2(0)N1(1), 7.2(0)ZN(0.4) Alert Type: Updated * Bug Id: CSCuf82423 Title: Nexus 5596 ethpm hap reset Status: Fixed Severity: 3 Moderate Description: Symptom: A Nexus 5596UP with version 5.2(1)N1(1) reloaded with a system reset reason of "ethpm hap reset". Conditions: This happend while the command `show system internal ethpm info all`. Workaround: Unknown Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(1) Known Fixed Releases: * 5.2(1)N1(7.121), 5.2(1)N1(8), 6.0(2)N2(5.88), 6.0(2)N2(6), 7.0(1)ZN(0.705), 7.0(6)N1(0.210), 7.0(6)N1(1), 7.1(0)N1(0.131), 7.1(0)N1(1), 7.1(0)ZN(0.249) Alert Type: Updated * Bug Id: CSCur99939 Title: FWM core @ipsada_entry_delete called from mfib_big_alt_route_del w/stres Status: Fixed Severity: 3 Moderate Description: Symptom: FWM process crash Conditions: Issue observed when 30K+ PIM-SSM mroutes in the system Workaround: none Further Problem Description: Because of missing NULL check, process crashed while deleting the entry from internal data structures Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(0.418) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.117), 7.1(2)N1(0.547), 7.1(2)N1(1), 7.1(2)ZN(0.6), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.20), 7.2(1)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCup96375 Title: crash flogi process on both N5k's at the same time due to null pointer Status: Fixed Severity: 3 Moderate Description: Symptom: Both N5ks reload at the same time due to a flogi process crash + core Conditions: host performs a flogi Workaround: none Further Problem Description: flogi process will write a core file that can be examined by cisco tech support personel. Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(2)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.543), 7.1(2)N1(1), 7.1(2)ZN(0.2), 7.1(3)ZN(0.313), 7.2(0)ZN(0.249), 7.2(1)N1(0.234), 7.2(1)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCur18043 Title: N6K "ntp access-group peer" wont show up in running config Status: Fixed Severity: 3 Moderate Description: Symptom: "ntp access-group peer" wont show up in running config if "ntp access-group serve-only" is configured Conditions: show run ntp will show both "ntp access-group peer " and "ntp access-group serve-only", but the "ntp access-group peer " is missing from general show run Workaround: show run ntp Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(1)N1(0.444) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.554), 7.1(2)N1(1), 7.1(2)ZD(0.10), 7.1(2)ZN(0.13), 7.1(3)ZN(0.313), 7.2(1)D1(0.65), 7.2(1)D1(1), 7.2(1)N1(0.294) Alert Type: Updated * Bug Id: CSCuv54185 Title: SNMPd keeps logging "svi_counter_cache_fetch: destroying stale results" Status: Fixed Severity: 3 Moderate Description: * Symptom: Logs like %SNMPD-3-ERROR: SNMP log error : svi_counter_cache_fetch: destroying stale results for ifindex=0x9010001 appearing in syslog. Conditions: Nexus 5k. Workaround: Enable "logging level snmpd 2" in global config mode. Further Problem Description: A similar defect exists on N7k platform and is tracked under CSCue68934 Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(9) Known Fixed Releases: * 7.1(3)N1(0.630), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.37), 7.2(2)N1(1), 7.3(0)BZN(0.41), 7.3(0)N1(0.89), 7.3(0)N1(1), 7.3(0)ZN(0.84) Alert Type: Updated * Bug Id: CSCul93120 Title: startup-config for FEX HIF could be removed under pre-provision Status: Fixed Severity: 3 Moderate Description: Symptom: FEX interface configuration is removed in startup-config under the condition with pre-provision, after connecting FEX to N5K. Conditions: vPC topology with a dual-homed FEX (N2K-C2248TP-E-1GE) to a pair of N5K's. The problem occurs after connecting FEX with image download, when config for FEX is already set by using pre-provision like below: N5K# sh run ... slot 101 provision model N2K-C2248TP-E-1GE ... interface Ethernet101/1/1 description interface Ethernet101/1/1 ... Workaround: If the problem occurs already, "copy run start" should restore the config for FEX interfaces because the config in running-config would not be removed. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(2) Known Fixed Releases: * 7.1(0)N1(0.250), 7.1(0)N1(1), 7.1(0)ZN(0.347), 7.1(3)ZN(0.313), 7.3(0)N1(0.3), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuu25462 Title: UDLD NOT to be enabled on the port previously configured fex-fabric Status: Fixed Severity: 3 Moderate Description: Symptom: UDLD can't be enabled to the access port which previously configured fex-fabric port. Conditions: Configure fex-fabric first and then enable UDLD feature Workaround: Once disable UDLD feature, then enable UDLD feature again Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(5)N1(1) Known Fixed Releases: * 7.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.1(3)ZN(0.313), 7.2(2)N1(0.340), 7.2(2)N1(1), 7.2(2)ZN(0.23), 7.3(0)BZN(0.41), 7.3(0)N1(0.76), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuu70111 Title: FWM service crash at FWM_FWIM_IF_GET_NEXT_LIF Status: Fixed Severity: 3 Moderate Description: Symptom: FWM service crash. Three consecutive FWM crashes with different instances may lead to a hap reset and bring down the entire switch. %SYSMGR-2-SERVICE_CRASHED: Service "fwm" (PID 3907) hasn't caught signal 11 (core will be saved). Conditions: VPC and fcoe is configured between two . The exact conditions are still unknown at this time. Workaround: None at this time. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(5)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.207), 7.1(3)ZN(0.313), 7.1(4)N1(0.749), 7.1(4)N1(1), 7.2(2)N1(0.402), 7.2(2)N1(1), 7.2(2)ZN(0.85), 7.3(1)N1(0.300), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuj90930 Title: Nexus 55xx: crash in ipfib when FIB is exhausted. Status: Fixed Severity: 3 Moderate Description: Symptom: A Nexus 55xx switch with L3 module can crash in ipfib process if FIB TCAM is exhausted and more routes need to be programmed. Conditions: FIB TCAM is exhausted. Messages such as following would be seen IPFIB-2-FIB_TCAM_RESOURCE_EXHAUSTION: FIB TCAM exhausted Workaround: Make sure the limits of the switch are not exceeded. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(2) Known Fixed Releases: * 7.0(1)ZN(0.732), 7.0(6)N1(0.232), 7.0(6)N1(1), 7.1(0)N1(0.210), 7.1(0)N1(1), 7.1(0)ZN(0.314), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCut19721 Title: logging source-interface loopback does not work for ipv6 Status: Fixed Severity: 3 Moderate Description: Symptom: Configuring "logging source-interface loopback" for ipv6 loopback interface does not work. You would see the following error: N6K-3(config)# logging source-interface loopback 60 Configuring logging source-interface will open UDP/syslog socket(514). Configuration Failed, no IP address associated with the loopback interface interface loopback60 description IPV6 Management Loopback ipv6 address 2001:558:2a0::3/128 Conditions: ipv6 address is configured on the loopback Workaround: none Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(2)N1(1), 7.1(0)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.548), 7.1(2)N1(1), 7.1(2)ZN(0.7), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.21), 7.2(1)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuo49098 Title: show flogi event-history is broken when using FPORT SAN-Port-Channel. Status: Fixed Severity: 3 Moderate Description: Symptom: show flogi event-history command on an TFport san-Port-Channel is broken. Returns a blank entry. Conditions: using NPV-NPIV TFport san-Port-Channel event-history command. Workaround: none Further Problem Description: none Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(6) Known Fixed Releases: * 7.1(3)ZN(0.219), 7.1(3)ZN(0.313), 7.1(4)N1(0.760), 7.1(4)N1(1), 7.2(2)N1(0.403), 7.2(2)N1(1), 7.2(2)ZN(0.94), 7.3(1)N1(0.306), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCul25050 Title: N2K-B22HP-P: Down interface are logged ETHPORT-5-IF_DOWN_ERROR_DISABLED Status: Fixed Severity: 3 Moderate Description: Symptom: Not connected N2K-B22HP-P HIF interfaces may generate next syslog messages: ETHPORT-5-IF_DOWN_ERROR_DISABLED: Interface EthernetA/B/C is down (Error disabled. Reason:ekeying triggered) Conditions: Problem happens only for "not connected" interfaces. Also this issue may happen despite on "no logging event port link-status" or "logging level ethpm 4" configuration. Workaround: In order to override this problem, you need: *** shutdown unused ports; *** configure these interfaces with 'no logging event port link-status' (per defect CSCud78339) Further Problem Description: N/A Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(2), 5.2(1)N1(4), 5.2(1)N1(5) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(1)ZN(0.115), 7.1(2)N1(0.536), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(1)N1(0.9), 7.2(1)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCus52683 Title: Port-channel on FEX down when fex-fabric up Status: Fixed Severity: 3 Moderate Description: Symptom:Port-channel interface configured on FEX down when connecting fex-fabric port. Conditions:FEX is connected to 2 Nexus 5000 series via vPC(Daul-home). shutdown the one of fex-fabric port, then no shutdown on that port. Port-channel on FEX is configured as LACP, however connected device has no LACP capability, which leads port on FEX into Individual(I) state. Workaround:Use LACP and form port-channel properly on FEX. This problem does not happen when port-channel on FEX is correctly formed by LACP. More Info:Problem is identified and fix has been provided by software. Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(4) Known Fixed Releases: * 7.1(3)N1(0.621), 7.1(3)N1(1), 7.1(3)ZN(0.28), 7.1(3)ZN(0.313), 7.2(2)N1(0.363), 7.2(2)N1(1), 7.2(2)ZN(0.46), 7.3(0)BZN(0.41), 7.3(0)N1(0.75), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuq85982 Title: N55xx link debounce time not working as expected Status: Fixed Severity: 3 Moderate Description: Symptom: "link debounce timer" command does not work as expected on Nexus 55xx devices. The interface runs a fixed 30 msec timer when the link is lost to determine if this link loss needs to be detected or not. Conditions: Normal operation. Workaround: N/A Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(2)N1(1) Known Fixed Releases: * 7.0(1)ZN(0.687), 7.0(6)N1(0.197), 7.0(6)N1(1), 7.1(0)N1(0.387), 7.1(0)N1(1), 7.1(0)ZN(0.461), 7.1(1)N1(0.17), 7.1(1)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(1) Alert Type: Updated * Bug Id: CSCui46326 Title: FCoE-60 sec delay in traffic recovery after shutdown of NIFF PO int Status: Fixed Severity: 3 Moderate Description: Symptom: FCoE traffic experiences ~60 second delay Conditions: When a NIF port-channel member interface experiences link failure/shutdown FCoE traffic, traversing the port-channel will have ~60sec delay Workaround: Directly connect the FCoE host to an N5K base port Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(5) Known Fixed Releases: * 7.1(0)N1(0.1), 7.1(0)N1(0.221), 7.1(0)N1(0.223), 7.1(0)N1(1), 7.1(0)ZN(0.322), 7.1(0)ZN(0.324), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCum62759 Title: CTS: N5K ignores CTS timers from ISE Status: Fixed Severity: 3 Moderate Description: Symptom: The Nexus does not refresh policies periodically. It should comply with the 'Download SGACL lists' and "Download Environment Data" timers sent from ACS or ISE Conditions: Occurs when CTS policies have been downloaded to the Nexus. Default 'Download SGACL lists' timer in ACS or ISE is 1 day or 86400 seconds. Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(2) Known Fixed Releases: * 7.1(3)N1(0.628), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.35), 7.2(2)N1(0.5), 7.2(2)N1(1), 7.3(0)BZN(0.41), 7.3(0)N1(1), 7.3(0)ZN(0.79) Alert Type: Updated * Bug Id: CSCul23467 Title: Iluka:Port-monitor and FC slow drain configurable on NPV switch Status: Fixed Severity: 3 Moderate Description: Symptom: Slow drain clis do not block FC slowdrain on NPV configured switches Conditions: Slow drain configs exist on NPV switches Workaround: Do not enable slow drain on NPV switches Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N3(0.289) Known Fixed Releases: * 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.243), 7.1(0)N1(0.301), 7.1(0)N1(0.303), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.31), 7.1(0)PDB(0.191), 7.1(0)RTG(0.32) Alert Type: Updated * Bug Id: CSCux09406 Title: Null L2 destination address in ACC(PLOGI) frame Status: Fixed Severity: 3 Moderate Description: Symptom: FCoE hosts experiencing storage connectivity issues. Fabric login is successful but not able to login to zoned/associated storage. Conditions: This issue is seen with Nexus 56xx(x). First found in 7.0(6)N1(1) and 7.2(0)N1(1) Workaround: Change the "fabripatch switch-id", which will not create collision with the existing adjacency index allocation. Example: switch# show platform fwm info fwim-pss all | i adj_idx adj-entry: adj_idx: 1, lif_index: 0x1117000, vlan: 0 adj-entry: adj_idx: 2, lif_index: 0x4000001, vlan: 0 adj-entry: adj_idx: 3, lif_index: 0x1116000, vlan: 0 adj-entry: adj_idx: 4, lif_index: 0x1115000, vlan: 0 adj-entry: adj_idx: 5, lif_index: 0x1114000, vlan: 0 adj-entry: adj_idx: 6, lif_index: 0x1113000, vlan: 0 adj-entry: adj_idx: 7, lif_index: 0x1112000, vlan: 0 adj-entry: adj_idx: 8, lif_index: 0x1111000, vlan: 0 adj-entry: adj_idx: 9, lif_index: 0x1110000, vlan: 0 Configure fabricpath switch-id, where the last byte of switch id is not 1-9. Further Problem Description: Confirm this issue with a SPAN of the interface directly connected to FCoE host. Investigating the L2 header of the ACC(PLOGI) you'll see the L2 destination address is 0000.0000.0000. VFT header will be inserted in the ACC(PLOGI). Check the adjacency index allocated to the E or VE ports in the switch by using the following command: switch# show platform fwm info fwim-pss all | i adj_idx adj-entry: adj_idx: 1, lif_index: 0x1117000, vlan: 0 adj-entry: adj_idx: 2, lif_index: 0x4000001, vlan: 0 adj-entry: adj_idx: 3, lif_index: 0x1116000, vlan: 0 adj-entry: adj_idx: 4, lif_index: 0x1115000, vlan: 0 adj-entry: adj_idx: 5, lif_index: 0x1114000, vlan: 0 adj-entry: adj_idx: 6, lif_index: 0x1113000, vlan: 0 adj-entry: adj_idx: 7, lif_index: 0x1112000, vlan: 0 adj-entry: adj_idx: 8, lif_index: 0x1111000, vlan: 0 adj-entry: adj_idx: 9, lif_index: 0x1110000, vlan: 0 ======> Check the fabricpath switch-id configured. fabricpath switch-id 521 The hexadecimal equivalant of 512 is 0x209. Take the last byte of the switch id. It is 0x09 here. The following adj-entry has the index 9. adj-entry: adj_idx: 9, lif_index: 0x1110000, vlan: 0 This tells there is a collision in the adjacency table index allocation. This confirms that the issue is same as the reported by this one. Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(0)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.213), 7.1(3)ZN(0.313), 7.1(4)N1(0.755), 7.1(4)N1(1), 7.2(2)N1(0.403), 7.2(2)N1(1), 7.2(2)ZN(0.90), 7.3(1)N1(0.300), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuq85841 Title: Wrong Nvgening of multiple snmp context Status: Fixed Severity: 3 Moderate Description: Symptom: When configuring more than one SNMP context, only the most recently configure context shows up in the config. 6004A(config)# snmp-server context test1 vrf test1 6004A(config)# snmp-server context test2 vrf test2 6004A(config)# 6004A(config)# 6004A(config)# show run | i snmp-server context snmp-server context test2 vrf test2 Conditions: This has been seen on 7.0.2.N1.1 on the N6K. It is NOT seen in 6.0.2.N2.2. This could also affect the N5K & N7K. For the N7K, please see CSCuo46225 for the same defect on that platform. Workaround: A possible workaround is to address this from the SNMP polling station, so that you walk the ContextMib to learn/correlate Context Names to their VRFs, then poll those using the community@context method Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(0.328) Known Fixed Releases: * 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.283), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.356), 7.1(0)N1(1), 7.1(0)OTT(0.39), 7.1(0)PDB(0.235) Alert Type: Updated * Bug Id: CSCuv75852 Title: AA dual-homed FEX HIF suspended due to speed during server boot process Status: Fixed Severity: 3 Moderate Description: Symptom: AA dual-homed FEX HIF ports are suspended due to speed parameter mismatch during server boot process. The suspend reason of "Compatibility check failed for speed" can be seen using the following commands: show vpc consistency-parameters interface show system internal vpcm info interface Conditions: Servers are attached to AA / dual-homed FEX HIF ports. During the servers boot process, the speed is changed between 10Mbps and 1Gbps. There is a large link debounce timer configured on the FEX HIF port to omit the link flap. Workaround: A manual 'shut/no shut' or physical interface flap (%ETHPORT-3-IF_DOWN_LINK_FAILURE / %ETHPORT-3-IF_UP) clears the suspended interface state. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(1)N1(1) Known Fixed Releases: * 7.1(3)N1(0.660), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.68) Alert Type: Updated * Bug Id: CSCut50912 Title: DHCP offer is send on vpc orphan port with dhcp snooping enabled Status: Fixed Severity: 3 Moderate Description: Symptom: DHCP offer messages from our DHCP server are not flooded out the VPC orphan port toward the clients. Conditions: The issue only occurs when DHCP snooping is enabled and the offer is send across the peer-link to a VPC orphan port. Workaround: Disable DHCP snooping. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(7) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.543), 7.1(2)N1(1), 7.1(2)ZN(0.2), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCuo08490 Title: vpc+ : ftag 1 active on both switches and ftag 2 inactive on both Status: Fixed Severity: 3 Moderate Description: Symptom: In vpc+ scenario, ftag 1 is active on both switches and ftag 2 inactive on both. You can check following commands to N5K-1# show system internal m2rib ftag ======================================================================== Ftag|Topo| Flags | State |Pending: | Errors | | | |inputs:events| ======================================================================== 1| 0| MCAST|ACTIVE|UCAST| M2RIB_FTAG_SEQ_END| 0: 0| 0 2| 0| MCAST|INACTIVE| M2RIB_FTAG_SEQ_END| 0: 0| 0====================? Both shows ftag 2 as inactive N5K-2# show system internal m2rib ftag ======================================================================== Ftag|Topo| Flags | State |Pending: | Errors | | | |inputs:events| ======================================================================== 1| 0| MCAST|ACTIVE|UCAST| M2RIB_FTAG_SEQ_END| 0: 0| 0 2| 0| MCAST|INACTIVE| M2RIB_FTAG_SEQ_END| 0: 0| 0====================? Both shows ftag 2 as inactive Conditions: Both switches are configured for vpc+ auto-recovery This issue gets triggered after following steps: 1) both switches are vpc primary due to vpc auto-recovery (peer-link and keepalive are down) 2)Then, if peer-link and keepalive comes up, the vpc role gets negotiated properly At this point, the switch will be in broken state Workaround: This issue is only triggered if there is vpc auto-recovery. So you can disable vpc auto-recovery avoid this issue There are couple of workarounds if you are in broken state. 1) Reload one of the switch or 2) Flap the vpc peer-link Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(1)N1(1) Known Fixed Releases: * 7.0(1)ZN(0.283), 7.0(3)N1(0.30), 7.0(3)N1(1), 7.1(0)N1(0.134), 7.1(0)N1(1), 7.1(0)ZN(0.252), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCun30488 Title: N 55K series switch does not show more than 255 tx credits on fc int Status: Fixed Severity: 3 Moderate Description: Symptom: Nexus 5500 switch is displaying on native fc interfaces the tx b2b credits that are in use wrong under the following condition. If the other end has the ability to configure more than 240 credits, 240 is the limit on the N5500 switches series. The N55K will not display more than 255 b2b credits correct. Conditions: I.e. MDS connected to N55K via san-port-channel. MDS configures 500 rx b2b buffers, these are exchanged with the N55K at flogi time. The N55K however displays those as 244. This does not cause a immediate issue but if you would i.e. configured 256 buffers on the mds switch it would show up as 1 on the N55K. The N55K can not display, handle, more than 255 buffers for the tx b2b credits per fc interface. Workaround: configure the number of b2b credits on the partner device, i.e. mds switch, accordingly. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(7) Known Fixed Releases: * 7.1(3)ZN(0.246), 7.1(3)ZN(0.256), 7.1(3)ZN(0.313), 7.1(4)N1(0.781), 7.1(4)N1(0.791), 7.1(4)N1(1), 7.2(2)N1(0.407), 7.2(2)N1(0.409), 7.2(2)N1(1), 7.2(2)ZN(0.108) Alert Type: Updated * Bug Id: CSCud12401 Title: sed command missing in Nexus 5000/6000 NX-OS Status: Fixed Severity: 3 Moderate Description: Symptom: The | sed option is missing from the cli. Conditions: Executing a show command and trying to edit the output with sed. Workaround: None. Further Problem Description: example of sed missing as an option after | switch# show clock | s section sort Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N2(1), 6.0(2)N1(2), 7.0(0)N1(1) Known Fixed Releases: * 7.1(0)N1(0.164), 7.1(0)N1(1), 7.1(0)ZN(0.277), 7.1(3)ZN(0.313), 7.2(0)ZN(0.93), 7.3(0)ZN(0.190) Alert Type: Updated * Bug Id: CSCue62640 Title: N5K/6K: TCP ports 21, 512-514 are opened after enabling FCoE Status: Fixed Severity: 3 Moderate Description: Symptom: TCP ports 21, 512-514 appears open without additional configuration thatmay have opened it. Conditions: The ports are opened after enabling FCoE. Workaround: None. PSIRT Evaluation: The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via normal resolution channels. If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another evaluation. Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html Further Problem Description: The fix for this issue is to remove the auto enabling of the following services: ftp, rexec, rlogin, rsh. They can still be opened manually if needed. Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N1(1) Known Fixed Releases: * 5.2(1)N1(8.146), 5.2(1)N1(8b), 6.0(2)N2(5.104), 6.0(2)N2(6), 7.0(1)ZN(0.678), 7.0(6)N1(0.187), 7.0(6)N1(1), 7.1(0)N1(0.354), 7.1(0)N1(1), 7.1(0)ZN(0.432) Alert Type: Updated * Bug Id: CSCup99146 Title: Iplus:ERSPAN Type2 & Type3 packet have incorrect outer IP length . Status: Fixed Severity: 3 Moderate Description: Symptom: Nexus 5500 and 6000 series switches may send ERSPAN encapsulated packets where the outer total ip length is incorrect. Conditions: Workaround: Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(0.252) Known Fixed Releases: * 7.0(1)ZN(0.703), 7.0(6)N1(0.209), 7.0(6)N1(1), 7.1(0)N1(0.1), 7.1(0)N1(0.294), 7.1(0)N1(1), 7.1(0)ZN(0.385), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCui97117 Title: "sh int mgmt 0 capabilities " does not give any output Status: Fixed Severity: 3 Moderate Description: Symptom: On running the command does not produce any output : N5K-1# sh int mgmt 0 capabilities N5K-1# Conditions: Trying to find out the capabilities of the port. Workaround: none Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(1)ZN(0.114), 7.1(2)N1(0.535), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)AB(2), 7.2(0)N1(1), 7.2(0)VZN(0.7), 7.2(0)ZN(0.117) Alert Type: Updated * Bug Id: CSCut68629 Title: N5K: customized CoPP config back to default after reload Status: Fixed Severity: 3 Moderate Description: Symptom: Some of customized CoPP class go back to default after reload Conditions: none. reload is the trigger. Workaround: none Further Problem Description: Here is a one comparison b/w running-config & startup-config but it happens with other classes. N5548# sh run copp | sec hsrp class copp-system-class-hsrp-vrrp police cir 1024 kbps bc 256000 bytes N5548# sh sta copp | sec hsrp class copp-system-class-hsrp-vrrp police cir 2024 kbps bc 256000 bytes The following is running-config after the issue happened (=after reload). In this example, CIR in all class is added by 1000 kbps before reload but some class went back to default value. N5548# sh run copp !Command: show running-config copp !Time: Tue Mar 31 11:57:55 2015 version 7.1(0)N1(1a) policy-map type control-plane copp-system-policy-customized class copp-system-class-igmp police cir 2024 kbps bc 65535 bytes class copp-system-class-pim-hello police cir 2024 kbps bc 4800000 bytes ------ snip ------ class copp-system-class-mcast-last-hop police cir 512 kbps bc 3200000 bytes class copp-system-class-onep-dpss police cir 625 kbps bc 3200000 bytes control-plane service-policy input copp-system-policy-customized Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(1)ZN(0.112), 7.1(2)N1(0.533), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(1)N1(0.7), 7.2(1)N1(1), 7.3(0)N1(1), 8.3(0)CV(0.174) Alert Type: Updated * Bug Id: CSCut08809 Title: Bug CSCuj56227 gets carried over ISSU upgrade. Status: Fixed Severity: 3 Moderate Description: Symptom: Bug CSCuj56227 is getting carried over a non disruptive ISSU to a release which has fix of CSCuj56227. Due to this the IGMP looping issue can still be seen after the upgrade. Conditions: Non disruptive ISSU performed on a Nexus 5K/6K from a release which is affected by CSCuj56227 to a release which has the fix Workaround: Reload the switch after the non disruptive ISSU Further Problem Description: While doing a non-disruptive ISSU, SupByPass Table was not getting programmed for the ISSUed versions. Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(6) Known Fixed Releases: * 5.2(1)N1(8.155), 5.2(1)N1(9), 6.0(2)N2(6.132), 6.0(2)N2(7), 7.0(7)N1(1), 7.0(7)ZN(0.124), 7.1(2)N1(0.542), 7.1(2)N1(1), 7.1(2)ZN(0.1), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCuj86736 Title: Need to optimize DFE tuning in 55xxUP series switches - RX CRC Errors Status: Fixed Severity: 3 Moderate Description: Symptom: Ingress CRCs seen on Nexus 55xxUP switches when using twinax cabling. Conditions: Nexus 55xx. May occur after rapid link flaps. Workaround: shut/no shut the interface experiencing this issue. May require several repetitions. Further Problem Description: This problem can be verified from carmel ASIC on Nexus 5500 series switches. Nexus# show hardware internal carmel eye +-------+------------+-------------+------------+----------------------------+--+--+--+--+--+--+--+--+--+--+ | Port | Eye Height | Eye Width | Raw values | Time measured |St|20|21|22|23|24|25|26|2E|2F| +-------+------------+-------------+------------+----------------------------+--+--+--+--+--+--+--+--+--+--+ (...) Eth 1/7 |37 mv| 359 mUI | c/ 17 | 08/13/2014 14:25:19.743224 |00|00|00|00|00|00|00|00|00|00| Eye hight of 37 mv is below expectations. Nexus# show hardware internal carmel eye +-------+------------+-------------+------------+----------------------------+--+--+--+--+--+--+--+--+--+--+ | Port | Eye Height | Eye Width | Raw values | Time measured |St|20|21|22|23|24|25|26|2E|2F| +-------+------------+-------------+------------+----------------------------+--+--+--+--+--+--+--+--+--+--+ Eth 1/1 |106 mv| 734 mUI | 22/ 2f | 09/11/2014 08:29:28.379302 |a9|d7|86|18|30|57|86|18|88|00| Eye height of 106 mv is within expected results. Similar bug exists on UCS and it tracked under - CSCuo76425 Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(6), 6.0(2)N2(3) Known Fixed Releases: * 5.2(1)N1(7), 6.0(2)N2(5.94), 6.0(2)N2(6), 7.0(1)ZN(0.495), 7.0(4)N1(0.132), 7.0(4)N1(1), 7.1(0)N1(0.268), 7.1(0)N1(1), 7.1(0)ZN(0.363), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCus09929 Title: Nexus 55548/5596 detect link up/down without cabling Status: Fixed Severity: 3 Moderate Description: * Symptom: 55548/5596 detect link up/down without cabling Conditions: when insert the SFP to N55-M16P ( not happen on native port on N5K) Workaround: shut the port or connect cable and link up the port Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(5)N1(0.184) Known Fixed Releases: * 7.1(3)ZN(0.154), 7.1(3)ZN(0.313), 7.1(4)N1(0.709), 7.1(4)N1(1), 7.2(2)N1(0.365), 7.2(2)N1(1), 7.2(2)ZN(0.48), 7.3(1)N1(0.365), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCut84977 Title: High cpu and fabricpath mroutes missing after upgrade to 7.0(5)N1(1) Status: Fixed Severity: 3 Moderate Description: Symptom: After upgrade to 7.0(5)N1(1), switch may experience high CPU due to the IGMP snooping process and fabricpath mroute missing. Conditions: Workaround: Reloading the switch Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(5)N1(1) Known Fixed Releases: * 7.0(7)N1(0.63), 7.0(7)N1(1), 7.0(7)ZN(0.138), 7.1(2)N1(0.575), 7.1(2)N1(1), 7.1(2)ZN(0.36), 7.1(3)ZN(0.313), 7.2(1)N1(0.245), 7.2(1)N1(1), 7.2(1)ZN(0.11) Alert Type: Updated * Bug Id: CSCut36200 Title: Ports towards the N2K-B22HP-P do not come up after a server reboot Status: Fixed Severity: 3 Moderate Description: Symptom: HP B22 FEX Host Interface ports connected to HP FLB560 NIC (intel chip) auto negotiate to 1gig during initial link bringup (ie when the blade chassis server is rebooted or installed). Conditions: HP FLB560 NIC connected to HP B22 FEX Workaround: - Hardcode the speed to 10000 - shut / no-shut the interface Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(7) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.545), 7.1(2)N1(1), 7.1(2)ZN(0.4), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.25), 7.2(1)N1(1), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCus23186 Title: CDP gets automatically re-enabled after a reload Status: Fixed Severity: 3 Moderate Description: Symptom: The Unified Fabric Innovation POAP template from the Cisco Prime DCNM applies by default the following configuration: interface mgmt0 no lldp transmit no lldp receive no cdp enable vrf member management ip address 192.168.100.11/24 After a "copy r s" and a reload the command line "no cdp enable" is removed, which is an incorrect behavior. This could lead on the DCNM dashboard faulty topology view. Conditions: Using DCNM POAP template CDP disabled on the mgmt0 interface Workaround: manually disable cdp on the mgmt0 interface Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.0(1)ZN(0.305), 7.1(0)N1(0.426), 7.1(0)N1(1) Known Fixed Releases: * 7.1(1)N1(0.466), 7.1(1)N1(1), 7.1(1)ZN(0.18), 7.1(3)ZN(0.313), 7.2(0)N1(1) Alert Type: New Bug Id: CSCva14540 Title: Nexus 5000 Upgrade documentation for supported upgrades improvements Status: Open Severity: 3 Moderate Description: Symptom: Nexus 5000 Release notes need to be more explicit on where to find upgrade information. Conditions: All doing ISSU on Nexus 5000 Workaround: None. Further Problem Description: None. Last Modified: 21-JUN-2016 Known Affected Releases: 5.2(1)N1(3), 7.0(7)N1(1) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCuf57615 Title: Nexus 5596UP/600x: Silent reload with i2code cause 0x0800 or 0x2 Status: Terminated Severity: 3 Moderate Description: * Symptom:A Nexus 5596UP or a Nexus 600x switch or a UCS 6296 Fabric Interconnect might reset with reason of unknown. Conditions:The reset-reason is 'unknown'. The reset-reason can be verified with 'show system reset-reason' or 'show version'. A PSU will report a fail/shut status. This can be verified with 'show environment power'. The i2c cause code is 0x2. The i2c cause code is collected by Cisco TAC. Workaround:This is a hardware failure with power supply and no software fix exists. Please contact Cisco TAC to verify the reset-reason and to get replacement for the failed Power Supply. More Info:The reload only happens when a PS fails due to bug CSCuf57615. This is also detailed within Cisco Field Notice FN-63893. If the remaining PSUs in the chassis are currently working, customer can remove the PSs and replace them one at a time without trigger the reload. The PSU failover will work because both current PSUs in the chassis are working Last Modified: 21-JUN-2016 Known Affected Releases: 5.1(3)N1(1), 5.1(3)N2(1) Known Fixed Releases: Alert Type: New Bug Id: CSCva18410 Title: Error disabled due to Flexlink error, Reason:Interface does not exist Status: Open Severity: 3 Moderate Description: Symptom: A link doesn't come up and go error disable with the message below after the link flap. %ETHPORT-5-IF_SEQ_ERROR: Error ("Interface does not exist") communicating with MTS_SAP_FLEXLINK for opcode MTS_OPC_ETHPM_PORT_CTRL_UP (RID_PORT: Ethernet1/x) - Ethpm didn't receive a Link UP from the driver on time or had an internal error, check Port Client and Ethpm logs and deb %ETHPORT-5-IF_DOWN_ERROR_DISABLED: Interface Ethernet1/x is down (Error disabled. Reason:Interface does not exist) Conditions: Workaround: Change to another port or reboot Further Problem Description: Last Modified: 22-JUN-2016 Known Affected Releases: 6.0(2)N2(7) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCuy27585 Title: N5K: Incorrect startup for allowed vlans in port-profile type ethernet Status: Fixed Severity: 3 Moderate Description: Symptom: After a non-disruptive ISSU newly added vlans on the allowed vlan list of a port-profile are not saved in startup Example: port-profile type ethernet Test switchport trunk allowed vlan add 237 show run port-profile: port-profile type ethernet Test switchport trunk allowed vlan 237, 700-763, 769, 804 state enabled show startup port-profile: port-profile type ethernet Test switchport trunk allowed vlan 700-763, 769, 804 state enabled Conditions: Seen after a non-disruptive issue to 7.0(7)N1(1) Workaround: As a temporary fix an alias can be used. cli alias name wr copy run bootflash:startup ; copy bootflash:startup startup To recover from this problem state: 1. copy run bootflash:startup 2. copy bootflash:startup startup 3. Reload the switch After the reload the allowed vlan-list is correctly updated in startup. Further Problem Description: Last Modified: 28-JUN-2016 Known Affected Releases: 6.0(2)N1(2), 7.0(6)N1(1), 7.0(7)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.256), 7.1(4)N1(0.791), 7.1(4)N1(1), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuw31547 Title: N5k/N6k stale param-lists in config which user cannot Status: Fixed Severity: 3 Moderate Description: Symptom: Unable to delete stale param-list manually with the no command: Leaf11(config)# no param-list param_list_name_instance_vni_30000_205 ERROR: Parameter instance being used cannot be deleted Leaf11(config)# no param-list param_list_name_instance_vni_30004_4 ERROR: Parameter instance being used cannot be deleted Leaf11(config)# no param-list param_list_name_instance_vn Conditions: This error was seen after copy run start and reload of leaf nodes, it is possible that stale \ param-lists remain and cause the issues with future instantiations of vlans. Workaround: None Further Problem Description: Last Modified: 28-JUN-2016 Known Affected Releases: 7.1(1)N1(1) Known Fixed Releases: * 7.1(3)N1(0.671), 7.1(3)N1(1), 7.1(3)ZN(0.83), 7.3(0)IZN(0.7), 7.3(0)N1(0.151), 7.3(0)N1(1), 7.3(0)ZN(0.139), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuw33247 Title: N6K: SNMP configuration lost after upgrade to 7.0(6) Status: Fixed Severity: 3 Moderate Description: Symptom: SNMP configuration lost after upgrading the switch to 7.0(6)N1(1) Conditions: the SNMP configuration has non-alphanumeric characters (#$%! etc) Workaround: do not use non-alphanumeric characters Further Problem Description: it is a issue on 7_X_X onwards not related to any upgrade whenever a snmp-server community name contains the string !# in the middle of it, there is an issue Last Modified: 28-JUN-2016 Known Affected Releases: 7.0(2)N1(1), 7.2(1)N1(1), 7.3(0.16) Known Fixed Releases: * 7.0(3)I3(0.276), 7.0(3)I3(1), 7.1(3)ZN(0.234), 7.1(4)N1(0.770), 7.1(4)N1(1), 7.3(0)IZN(0.7), 7.3(0)N1(0.184), 7.3(0)N1(1), 7.3(0)ZN(0.166), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuy27650 Title: N5K kernel panic seen with e1000_get_hw_semaphore_generic Status: Fixed Severity: 3 Moderate Description: Symptom: N5K will experience a kernel panic due to a CPU lockup. %KERN-0-SYSTEM_MSG: [8348809.761281] BUG: soft lockup - CPU#2 stuck for 11s! [events/2:29] - kernel The call trace will show that this is related to the e1000 drivers Conditions: Unknown at this time Workaround: None at this time Further Problem Description: Last Modified: 28-JUN-2016 Known Affected Releases: 7.0(7)N1(1) Known Fixed Releases: * 7.0(7)N1(0.10), 7.0(7)N1(0.3), 7.0(7)N1(0.9), 7.0(7)N1(1a), 7.1(3)ZN(0.296), 7.1(3)ZN(0.311), 7.1(3)ZN(0.313), 7.1(4)N1(0.830), 7.1(4)N1(0.843), 7.1(4)N1(1) Alert Type: New Bug Id: CSCuq23929 Title: after ISSU plugging N55-M16P causes CFP encapsulation wrong via PL Status: Other Severity: 3 Moderate Description: Symptom: Traffic destined to the vPC peer is sent on the peer-link with the Local SwitchID in the FabricPath Header Conditions: Issue is seen after ISSU when a GEM is inserted Workaround: shut - no shut of the SVI or the Vlan should resolve the issue Further Problem Description: Last Modified: 29-JUN-2016 Known Affected Releases: 5.2(1)N1(7) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCuz29569 Title: Error during pre-provisioning the module of type N5696-M20UP Status: Fixed Severity: 3 Moderate Description: Symptom: Provision Model command gives lots of options but not all are supported. Please remove unsupported options Example DCB45-N5K-4(config-slot)# provision model ? N2K-B22DELL Fabric Extender 16x10G Module N2K-B22FJ Fabric Extender 16x10G Module N2K-B22HP Fabric Extender 16x10G Module N2K-B22IBM Fabric Extender 14x10G Module N5K-M1600 Cisco 6-port 10 Gigabit Ethernet SFP Module 6 x SFP N5K-N5696-M20UP Cisco Nexus 20X10GE Eth/FC Linecard Expansion Module N6004-M12Q Cisco 48x10G 12x40G Linecard Expansion Module DCB45-N5K-4(config-slot)# slot 1 DCB45-N5K-4(config-slot)# provision model N5K-N5696-M20UP ERROR: Invalid module type Conditions: customer trying to provision modules which are not supported for module provisioning Workaround: None Further Problem Description: Last Modified: 01-JUL-2016 Known Affected Releases: 7.1(4)N1(0.809), 7.3(0)N1 Known Fixed Releases: * 7.1(3)ZN(0.328), 7.1(4)N1(0.859), 7.1(4)N1(1), 7.3(1)N1(0.348), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCva07536 Title: FWM core on N5K Status: Fixed Severity: 3 Moderate Description: Symptom: N5K fwm process crash. Conditions: This is seen on a N5K running code 7.1(3)N1(1). exact condition/trigger is still under investigation. Workaround: Further Problem Description: Last Modified: 02-JUL-2016 Known Affected Releases: 7.1(3)N1(1) Known Fixed Releases: * 7.3(1)NS(0.390), 7.3(1)NS(1) Alert Type: Updated * Bug Id: CSCub22567 Title: Error message needs to be cleaned up. Status: Fixed Severity: 4 Minor Description: Symptom: In a Nexus 5000 switch, applying an ACL with log keyword to a routed interface results in the following error. 20-08-5596-A(config-if)# ip access-group acl-log-test in ERROR: policy rule not supported 2012 Jul 24 13:56:45 20-08-5596-A %AFM-3-AFM_VERIFY_FAIL: Access control policy modification on vlan 572 failed 2012 Jul 24 13:56:45 20-08-5596-A %ACLMGR-3-ACLMGR_VERIFY_FAIL: Verify failed: client 40000290, policy rule not supported Conditions: An ACL with log keyword is applied to a routed interface. Workaround: None ACL with log keyword is only supported on management interface(mgmt0) Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.2(1)N1(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.543), 7.1(2)N1(1), 7.1(2)ZN(0.2), 7.1(3)ZN(0.313), 7.2(0)N1(0.189), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.191) Alert Type: Updated * Bug Id: CSCug19662 Title: MemLimit missing from show processes memory command on the Nexus 5K/2K Status: Fixed Severity: 4 Minor Description: Symptom: The show processes memory command does not have a MemLimit field. This can make it difficult to monitor the memory and estimate when a memory leak is going to cause a process crash. Conditions: The MemLimit field is missing on the Nexus 5K. It is available on the the Nexus 7K. Workaround: If the process has crashed before, you can try looking at the RLIMIT in the 'show process log detail' output. Last Modified: 16-JUN-2016 Known Affected Releases: 6.0(2)N1(2) Known Fixed Releases: * 5.2(1)N1(5), 6.0(2)N2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCut52768 Title: Vinci: dvp interface command should appear with "show run interface all" Status: Fixed Severity: 4 Minor Description: Symptom: When dvp is enabled on a per interface level (default), the config is not visible with the command "show run interface <> all". Conditions: None Workaround: None Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(0)N1(0.438) Known Fixed Releases: * 7.1(3)N1(0.628), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.35), 7.2(1)N1(0.239), 7.2(1)N1(1), 7.2(1)ZN(0.5), 7.3(0)N1(1) Alert Type: Updated * Bug Id: CSCuv14425 Title: Nexus Unassigned Zone Count Misleading Status: Fixed Severity: 4 Minor Description: Symptom: The output of "show zone analysis vsan #" displays a number next to the "Unassigned Zones" section but does not display any zone names as unassigned. For example: Switch# show zone analysis vsan 300 Zoning database analysis vsan 300 Full zoning database Last updated at: 10:46:24 EDT Jul 02 2015 Last updated by: Local [ CLI ] Number of zonesets: 1 Number of zones: 2 Number of aliases: 0 Number of attribute groups: 0 Formatted size: 368 bytes / 2048 Kb Unassigned Zones: 1 << No zone names listed under this section When comparing the active zoneset, full zoneset, and zone DB they are consistent. Conditions: Any Nexus switch. Zone(s) were added to zoneset but removed prior to activating the zoneset Workaround: Add a "dummy" zone with members, add the zone to the zoneset and activate the zoneset. Then remove the zone from the zoneset and delete the zone. Otherwise wait for the next zoning change to be made with an activation. Further Problem Description: If the following steps are performed the Unassigned Zone count will increment (with no zone names appearing): 1. Create one or more zones and add members 2. Add zone(s) to the zoneset but do not activate it 3. Remove the zones 4. Check the output of "show zone analysis vsan #" to see the "Unassigned Zone" counter has incremented but no zone names appear Performing the workaround will clear the unassigned zone counter. However, if the steps above are issued again the unassigned zone counter will reappear and will increment starting from the previous value. Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(2) Known Fixed Releases: * 7.1(3)ZN(0.289), 7.1(3)ZN(0.313), 7.1(4)N1(0.823), 7.1(4)N1(1), 7.2(2)N1(0.431), 7.2(2)N1(1), 7.2(2)ZN(0.139) Alert Type: Updated * Bug Id: CSCva20789 Title: FCOT Vendor Not Supported caused by hardware error - I2C_READ_FAILED Status: Open Severity: 4 Minor Description: * Symptom: An fc interface will not come up. show logging log contains %PORT-5-IF_DOWN_FCOT_VENDOR_NOT_SUPPORTED: %$VSAN 11%$ Interface fc1/27 is down (Error disabled - FCOT vendor not supported) %KERN-3-SYSTEM_MSG: [13837695.140194] proton_sys_fcot_info_read(): fcot read failed err 0x426e000a [failed to read response(-11) - exp 26 act 0] - kernel %KERN-3-SYSTEM_MSG: [13837695.140200] jiffies: 1383739514, XCVR slot 0 port(lo-hi) 26-26: Failed reading GBIC/SFP info via I2C interface - kernel %KERN-3-SYSTEM_MSG: [13837695.140222] jiffies: 1383739514, XCVR slot 0 port(lo-hi) 26-26: Failed reading information from transceiver - kernel Message being logged that states "PORT-5-IF_DOWN_FCOT_VENDOR_NOT_SUPPORTED" when in fact, the FCOT can not be read. Problem could be caused by a bad SFP ( FCOT ) or a hardware error on the switch port. NEXUS# show interface fc1/27 fc1/27 is down (Error disabled - SFP vendor not supported) Hardware is Fibre Channel, SFP is Unknown(0) ..... NEXUS# show interface fc1/27 transceiver details fc1/27 sfp is present but not supported Name is Manufacturer's part number is Revision is Serial number is Cisco part number is FC Transmitter type is Unknown(0) FC Transmitter supports Unknown(0) link length Transmission medium is Unknown(0) Supported speeds are - Min speed: 0 Mb/s, Max speed: 0 Mb/s Nominal bit rate is 0 Mb/s Failed to get runtime SFP state info. Invalid calibration Shut / no shut has no effect, port stays in Error Disabled State. Conditions: Check the output of this command: show hardware internal transceiver slot port info and look for the field "FCOT read return code: Example: FCOT read return code I2C_READ_FAILED [failed to read response(-11) - exp 26 act 0] Workaround: Ignore the "vendor not supported" message because the SFP cannot be read. Further Problem Description: The messages indicates a bad port on the switch or a defective FCOT ( SFP ). Resolution Summary: To be completed when the bug is resolved. Last Modified: 26-JUN-2016 Known Affected Releases: 7.2(0)N1(1) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCux76712 Title: FC interface disabled due to 'bit error rate too high' when rate is low Status: Fixed Severity: 4 Minor Description: Symptom: A Fibre Channel interface is disabled and has the following status even though the bit error rate of the interface is below the threshold specified in the Fibre Channel standards: show interface fcx/y is down (Error disabled - bit error rate too high) The following type of syslog messages are logged for the interface: show logging log %PORT-5-IF_DOWN_BIT_ERR_RT_THRES_EXCEEDED: %$VSAN v%$ Interface fcx/y is down (Error disabled - bit error rate too high) Conditions: This issue applies to all FC interfaces on the Nexus 5000 and Nexus 6000 models. show platform software fcpc event-history errors Event:E_DEBUG, length:102, at 571407 usecs after Tue Jan 5 05:33:02 2016 [102] CREDITMON_EVENT_ERR_COUNT, if_index 1105000: cur=0x2acfd01e76de prev=0x2acfd01e76dd occurances=3 If the time between occurances=1 to occurances=15 for the interface if_index is greater than 5 minutes, then this bug has been hit. Workaround: shut and then no shut the fc interface to recover. Further Problem Description: Even though the rate of bit errors on the affected link may not have been at as high as the rate specified in the Fibre Channel standards, there were still bit errors occurring. This causes the interface to be error disabled prematurely. However, persistent bit errors on a link are undesirable and the problem should still be corrected. To find the fc interface, use the if_index show system internal fcfwd idxmap interface-to-port | i 1105000 01105000 fc3/6 | 105| 0| 05| 01 | 02 | 05 | 0101| 00 | 00 Resolution Summary: Occurrences counter is reset to zero after 5 minutes of error free frames. Last Modified: 30-JUN-2016 Known Affected Releases: 7.0(7)N1(1) Known Fixed Releases: * 7.1(4)N1(0.860), 7.1(4)N1(1), 7.3(1)N1(0.303), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuw09598 Title: ethanalyzer inband-hi only capturing inbound FIP frames Status: Open Severity: * 4 Minor Description: Symptom:Ethanalyzer FIP only capturing inbound frames. Conditions:ethanalyzer capturing FIP frames. Workaround:Open two connections to the switch. On one connection start an ethanalyzer trace with interface inband-hi. On the other connections start an ethanalyzer trace with interface inband-low. Using both traces, you can see the traffic in each direction. Last Modified: 01-JUL-2016 Known Affected Releases: 7.2(0)N1(1) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCtj93509 Title: pauseRateLimitErrDisable not in show interface status err-disabled Status: Fixed Severity: 4 Minor Description: Symptom: show interface status err-disabled does not display a port down due to pause frame Conditions: When an ethernet port gets error disabled due to reaching too many pause frames to match pauseRateLimit. Workaround: use the show interface command to find the state Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 4.2(1)N2(1) Known Fixed Releases: * 7.0(0)N1(0.118), 7.0(0)N1(1), 7.1(0)ZN(0.235), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCuh78381 Title: SAN Port-channel reports as going down when a member link fails Status: Fixed Severity: 4 Minor Description: Symptom: San-port-channel reports as going down in the logs. Conditions: When one of the member links of the san-port-channel fails, the logs indicate that san-port-channel is down. Workaround: None at this time. Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.0(3)N1(1c), 5.2(1)N1(2) Known Fixed Releases: * 7.1(3)ZN(0.227), 7.1(3)ZN(0.313), 7.1(4)N1(0.766), 7.1(4)N1(1), 7.2(2)N1(0.403), 7.2(2)N1(1), 7.2(2)ZN(0.96), 7.3(1)N1(0.313), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCtz06873 Title: (cmd_rep_send_cookie_rsp_type) Invalid Tx Handle - urib seen in logs Status: Terminated Severity: 5 Cosmetic Description: * Symptom: 2012 Mar 30 09:06:13 %USER-2-SYSTEM_MSG: (cmd_rep_send_cookie_rsp_type) Invalid Tx Handle - urib 2012 Mar 30 09:06:13 %USER-2-SYSTEM_MSG: (cmd_display_text_on_cli) Invalid Tx Handle - urib Conditions: none Workaround: none - cosmetic Further Problem Description: Last Modified: 15-JUN-2016 Known Affected Releases: 5.0(3)N1(1c) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCtz88781 Title: Fex port showing bpdufilter enabled in port-channel Status: Fixed Severity: 5 Cosmetic Description: Symptom: Fex ports show bpdu-filter enabled when in a port-channel interface Ethernet108/1/48 no description lacp port-priority 32768 lacp rate normal priority-flow-control mode auto lldp transmit lldp receive no switchport block unicast no switchport block multicast no hardware multicast hw-hash no hardware vethernet mac filtering per-vlan cdp enable switchport switchport mode trunk no switchport dot1q ethertype no switchport priority extend spanning-tree port-priority 128 spanning-tree cost auto spanning-tree link-type auto spanning-tree port type edge spanning-tree bpduguard enable no spanning-tree bpdufilter Static-5596-B# sh spanning-tree interface po31 detail Port 4126 (port-channel31, vPC) of VLAN0001 is designated forwarding Port path cost 1, Port priority 128, Port Identifier 128.4126 Designated root has priority 0, address 0000.0000.0000 Designated bridge has priority 0, address 0000.0000.0000 Designated port id is 0.0, designated path cost 0 Timers: message age 0, forward delay 0, hold 0 Number of transitions to forwarding state: 1 The port type is edge by port type edge trunk configuration Link type is point-to-point by default Bpdu guard is enabled Bpdu filter is enabled by default <--------- BPDU: sent 0, received 0 Conditions: Configure fex ports in a port-channel and run 'show spanning-tree interface poX detail' Workaround: None; cosmetic as bpdu-filter is not on by default Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 5.1(3)N2(1) Known Fixed Releases: * 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.547), 7.1(2)N1(1), 7.1(2)ZN(0.6), 7.1(3)ZN(0.313), 7.2(0)N1(0.167), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.170) Alert Type: Updated * Bug Id: CSCto57719 Title: "spanning-tree port-priority" changed to "0" from "128" in show run all" Status: Fixed Severity: 5 Cosmetic Description: * Symptom: "spanning-tree port-priority 128" will appear as "spanning-tree port-priority 0" in "show run all" output when I manually configure "spanning-tree port type xxx" from system default. It will appear priority is "0" in "show run all" but the actual priority seems not to be changed. So this is likely cosmetic issue. Conditions: From system default, when chage "spanning-tree port type" to whichever type. If the priority is set manually prior to the type change, it will not be corrupted. Workaround: No impact. Cosmetic issue. Over-writing the type fixes the cosmetic issue Further Problem Description: Last Modified: 28-JUN-2016 Known Affected Releases: 5.0(2)N2(1), 5.0(3)N1(1a) Known Fixed Releases: * 7.1(3)ZN(0.324), 7.1(4)N1(0.857), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCuz29352 Title: copp config isn't in show run all Status: Fixed Severity: 5 Cosmetic Description: Symptom: show run all doesn't show config about copp Conditions: Nexus5672 NXOS7.2(0)N1(1) ,7.3(0)N1(1) Workaround: use "show copp status" to check applied copp policy Further Problem Description: Last Modified: 29-JUN-2016 Known Affected Releases: 7.2(0)N1(1) Known Fixed Releases: * 7.1(3)ZN(0.325), 7.1(4)N1(0.858), 7.1(4)N1(1) Alert Type: New Bug Id: CSCup76086 Title: auto-config vlan xlate: clean up unit test code in cli Status: Fixed Severity: 5 Cosmetic Description: Symptom: mobility domains api/api0 cannot be created. Conditions: Workaround: Further Problem Description: Last Modified: 17-JUN-2016 Known Affected Releases: 7.2(0.1)PR(0.1) Known Fixed Releases: 7.1(0)N1(0.255), 7.1(0)N1(1), 7.1(0)ZN(0.352), 7.1(3)ZN(0.313) Alert Type: Updated * Bug Id: CSCux44029 Title: XML support for show interface fcx/y transceiver details Status: Fixed Severity: 6 Enhancement Description: Symptom: XML support for show interface fcx/y transceiver details Conditions: Feature support in future release Workaround: None Further Problem Description: None Last Modified: 17-JUN-2016 Known Affected Releases: 7.1(2)N1(0.2) Known Fixed Releases: * 7.1(3)ZN(0.205), 7.1(3)ZN(0.313), 7.1(4)N1(0.747), 7.1(4)N1(1), 7.2(2)N1(0.402), 7.2(2)N1(1), 7.2(2)ZN(0.83), 7.3(1)N1(0.299), 7.3(1)N1(1) Alert Type: Updated * Bug Id: CSCuy80838 Title: "errdisable recovery cause security-violation" for N5k/N6k Status: Fixed Severity: 6 Enhancement Description: Symptom: dot1x configured Port can go into sec-violation state. Conditions: dot1x configured Port can go into sec-violation state due to different error conditions. one such condition is when we have a single host mode and receive packets with more than one source MAC address. Workaround: flap the port through "shut" and "no shut" to recover from error disabled state. Further Problem Description: We need to enable support "errdisable recovery cause security-violation" config so that ports which are error-disabled due to sec-violation would auto-recover. This config is available in N7K but missing in N5K/N6K platforms. Last Modified: 17-JUN-2016 Known Affected Releases: 7.3(1)N1(0.308) Known Fixed Releases: * 7.1(3)ZN(0.285), 7.1(3)ZN(0.313), 7.1(4)N1(0.819), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCus71581 Title: need to copy cores from show cores into bootflash by default Status: Fixed Severity: 6 Enhancement Description: Symptom: N5K switch cannot save more than 1 core dump under show cores command. Cores may be lost when reloading. Conditions: When device crashes more than once and/or a reload occurs. Workaround: no workaround Further Problem Description: This defect is to add a 'system core bootflash:' command similar to N3K and enable it by default. This will automatically copy the core to bootflash when crashing so it will not be lost. Last Modified: 17-JUN-2016 Known Affected Releases: 6.0(2)N2(6) Known Fixed Releases: * 7.1(3)ZD(0.112), 7.1(3)ZN(0.242), 7.1(3)ZN(0.313), 7.1(4)N1(0.777), 7.1(4)N1(1) Alert Type: Updated * Bug Id: CSCue25984 Title: Show Transceivers in the ENTITY-MIB Status: Fixed Severity: 6 Enhancement Description: Added the support for xcvr sensor information in the EntitySensorMib (1.3.6.1.4.1.9.9.91) for n5k/n6k switches. Symptom: Snmp walk on the EntitySensorMib (1.3.6.1.4.1.9.9.91) Snmp walk on the entPhysicalTable (1.3.6.1.2.1.47.1.1.1) When we do snmp walk on the above 2 MIBs. it was not dislaying the Transciever Entity MIB Sensor information. Added Support to display these Transcievers DOM sensor Information via this bug. Caveat: This works only for the Transcievers plugged into the n5k/n6k switch and not for the transcievers plugged on the Fex (N2K platforms). Conditions: Plug in Xcvr's which has DOM support and run the SNMP walk on the below MIB's. Snmp walk on the EntitySensorMib (1.3.6.1.4.1.9.9.91) Snmp walk on the entPhysicalTable (1.3.6.1.2.1.47.1.1.1) Workaround: None. Further Problem Description: None Last Modified: 17-JUN-2016 Known Affected Releases: 5.0(3)N2(2), 5.1(3)N1(1), 5.2(1)N1(4), 6.0(2)N1(0.25), 6.0(2)N1(1) Known Fixed Releases: * 7.1(0)N1(0.156), 7.1(0)N1(1), 7.1(0)ZN(0.273), 7.1(3)ZN(0.313), 7.2(0)VZN(0.31) Alert Type: Updated * Bug Id: CSCug28099 Title: Enh: Knob to Disbable ports after loop is detected on N5k. Status: Fixed Severity: 6 Enhancement Description: Symptom: The Current behavior when loop (FWM-2-STM_LOOP_DETECT: Loops detected in the network among ports and vlan >vlan_id> - Disabling dynamic learn notifications for 180 seconds) is detected , is after 120 seconds of loop detection , we would rapid age out all the MAC and then relearn them rather than aging the whole mac address table . Due to this behavior we would not learn the new mac for 120 sec but still if the loops is consistently present it can cause significant impact to network as we would rapid age mac from all vlan. Conditions: MAC Flap Workaround: none Further Problem Description: http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/sw/layer2/7x/b_5600_Layer2_Config_7x/b_6k_Layer2_Config_7x_chapter_01010.html#task_78C359C5D24F457EB1EE1DA2DCCEE718 For 55XX and 56XX above command was introduced you can configure the action of bringing down the port instead of disabling dynamic learn. Last Modified: 16-JUN-2016 Known Affected Releases: 5.2(1)N1(3), 6.0(2)N1(2) Known Fixed Releases: * 6.0(2)N2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111), 7.2(0)ZN(0.93) Alert Type: Updated * Bug Id: CSCts50544 Title: feature scp-server Status: Fixed Severity: 6 Enhancement Description: Symptom: allow to configure this platform as an scp server Conditions: this is an enhancement request for the ''feature scp-server'' Workaround: use another device for scp server and this switch as Last Modified: 16-JUN-2016 Known Affected Releases: 5.0(3)U2(1) Known Fixed Releases: * 6.0(2)A1(1), 6.0(2)N1(1), 6.0(2)N2(1), 6.0(2)U1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCuc38377 Title: Adding NTP master functionality for N5k Status: Fixed Severity: 6 Enhancement Description: Symptom: This is an enhancement request filed to support Nexus 5000 as NTP server. Conditions: Nexus 5000 configured as NTP server. Workaround: Support for Nexus 5000 as NTP server is from Release 6.0.2.N2.1 and later. Last Modified: 16-JUN-2016 Known Affected Releases: 6.0(2)N1(1) Known Fixed Releases: * 6.0(2)N2(1), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) Alert Type: Updated * Bug Id: CSCts64173 Title: Enh: Need better debugging capability for TxPPP in FCoE deployments. Status: Open Severity: 6 Enhancement Description: * B>Symptom: This is an enhancement request to add troubleshooting hooks in software to troubleshoot TxPPP issue in FCOE deployments. Conditions: 1)Congestion on FC/uplink FCoE which gets back pressured to initiators via TxPPP 2)Instantaneous congestion(10G---2/4/8G FC). Workaround: none. This bug will be fixed as part of Slow Drain feature coming out in ILUKA release targetted for Q1CY2014. Last Modified: 07-JUN-2016 Known Affected Releases: 5.0(3)N2(2) Known Fixed Releases: Alert Type: Updated * Bug Id: CSCur48104 Title: fcoe fcf mac address should not be checked out for non fcoe port-channel Status: Fixed Severity: 6 Enhancement Description: Symptom: In our current fcoe implementation we check out a fcf mac address from a pool of fcf mac addreses when a ethernet port-channel is created. Regardless if we bind a vfc interface to this port-channel or not. This imposes unnecessary restrictions to the fcoe configuration / implementation. Conditions: fcoe with ethernet port-channels Workaround: bind vfc interfaces to physical ethernet interfaces and not ethernet port-channels whenever possible. Further Problem Description: Last Modified: 13-JUN-2016 Known Affected Releases: 7.0(4)N1(1) Known Fixed Releases: * 8.3(0)CV(0.427), 8.3(0)MVA(0.14), 8.3(0)SPB(0.42) Find additional information in Bug Search index.   2015 Cisco and/or its affiliates. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks