| |
Bug Id: | CSCur11599 |
Title: | Nexus 5k/6k - Memory leak in pfstat process causing hap reset |
|
Description: | Polling SVI If-Index to collect packet statistics via SNMP.
Or,
using CLI "show interface [vlan #] counter [detail]"
The above results in memory leak in pfstat process. Once process runs out of its designated memory space, leads to crash/hap reset.
Symptom:Memory leak in pfstat process results in HAP reset.
Reason: Reset triggered due to HA policy of Reset
Service: pfstat hap reset
Conditions:Polling SVI If-Index to collect packet statistics via SNMP.
Or,
using CLI "show interface [vlan #] counter [detail]"
The above results in memory leak in pfstat process. Once process runs out of its designated memory space, leads to crash/hap reset.
Switch should be operating in L2 mode (no L3 license) to hit the issue.
Workaround:Excluding SVI if_indexes from SNMP polling for interface statistics collection. Avoiding running "show interface counter" globally or for SVI.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUN-2015 |
|
Known Affected Releases: | 7.0(3)N1(0.125) |
|
Known Fixed Releases: | 7.0(1)ZN(0.684), 7.0(6)N1(0.194), 7.0(6)N1(1), 7.1(0)EVN(0.18), 7.1(0)N1(0.372), 7.1(0)N1(1), 7.1(0)ZN(0.445), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.2(0)N1(0.2) |
|
|
| |
| |
Bug Id: | CSCuq43947 |
Title: | N5K Kernel panic in SNMPd process at update_curr |
|
Description: | Symptom:
Nexus 5596 switch may reboot unexpectedly. Last reset reason is seen as "Kernel Panic"
Reason: Kernel Panic
System version: 6.0(2)N2(2)
Service:
Conditions:
This has been observed on NX-OS 6.0(2)N2(2). Exact conditions and trigger are unknown.
Workaround:
unknown at this time.
Further Problem Description:
engineer believes the issue was addressed in CSCuc26047
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtu05113 |
Title: | Nexus 55xx core in fcpc -- heartbeat failure |
|
Description: | Symptom:
Nexus 55xx crash in fcpc
Conditions:
This is seen in normal working conditions. This is an excerpt of "show logging
nvram" post-crash:
%SYSMGR-2-SERVICE_CRASHED: Service "fcpc" (PID 5028) hasn't caught %signal 6
(core will be saved).
%SYSMGR-2-LAST_CORE_BASIC_TRACE: core_client_main: PID 29887 with %message
filename = 0x101_fcpc_log.5028.tar.gz .
%SYSMGR-2-LAST_CORE_BASIC_TRACE: copy_cores_to_logflash: PID 29887 with
%message filename = 1315449474_0x101_fcpc_log.4946.tar.gz .
%KERN-0-SYSTEM_MSG: Shutdown Ports.. - kernel
%KERN-0-SYSTEM_MSG: writing reset reason 16, fcpc hap reset - kernel
Workaround:
1. Upgrade to Nexus 5k NX-OS 5.2(1)N1(2) or to 5.2(1)N1(2a) to get the workaround.
2. The workaround disables DOM monitoring for FC ports that is contributing to the issue. Configure the following to disable DOM monitoring for FC ports:
conf t
no fcpc diag info
exit
switch# show fcpc diag info status
FCPC Diag Info Status : disabled
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 5.0(3)N1(1c) |
|
Known Fixed Releases: | 5.2(1)N1(4), 6.0(2)N1(2) |
|
|
| |
| |
Bug Id: | CSCuu66220 |
Title: | MSP crashes and Nexus 5K reboots while deleting port-profiles |
|
Description: | Symptom:
Nexus 5K reboots after deleting a port-profile configured for switchport mode trunk.
$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "msp" (PID 3858) hasn't caught signal 6 (core will be saved).
$ VDC-1 %$ %SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "msp" in vdc 1 has had a hap failure
# show system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 302566 usecs after Tue Jul 13 16:05:22 2010
Reason: Reset triggered due to HA policy of Reset
Service: msp hap reset
Version: (5.2(1)N1(9))
Conditions:
Delete a port-profile configured in trunking mode.
Workaround:
Change the port-profile configuration to access mode before deleting it.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(7), 5.2(1)N1(9) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui96694 |
Title: | N5k DHCP relay not working due to TCAM entry missing |
|
Description: | Symptom:
DHCP relay is not working for some vlans on Nexus 55xx switch.
Conditions:
This was seen on Nexus 55xx switch running 6.0(2)N1(2a)
Workaround:
Setup a DHCP server local to the affected vlan.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N1(2a) |
|
Known Fixed Releases: | 5.2(1)N1(7.120), 5.2(1)N1(8), 6.0(2)N2(2.43), 6.0(2)N2(3), 7.0(0)N1(0.368), 7.0(0)N1(0.394), 7.0(0)N1(1), 7.0(0)ZN(0.88), 7.1(0)ZN(0.183) |
|
|
| |
| |
Bug Id: | CSCut39470 |
Title: | DHCP V6hosts not able to get v6 address when they are in different leaf |
|
Description: | Symptom:
In a DFA Network DHCPv6 hosts not able to get the Ipv6 address when the external Dhcp server CPNR and the dhcp clients are placed in different leaf switches. This is seen under following
Conditions:
DHCPv6 : Host Src on Default VRF, Server in Default VRF
DHCPv6 : Host Src on non-Default VRF, Server in non-default VRF
DHCPv6 : Host Src on non-default VRF, Server in Default VRF
We do not have the required profiles to support these via Auto configuration.
Conditions:
This issue seen with external dhcp server used like CPNR when user wants V6 DHCP clienst to get ipv6 address via Auto configuration without doing any manual config at the switch.
Workaround:
When dhcpv6 server in default vrf and dhcp client in default vrf user can make this work using manual configuration at the switch:
Global config:
IPv6 dhcp relay
Ipv6 dhcp relay option VPN
In the control Vlan : remove ipv6 forward and and configure ipv6 address.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.124) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuf77936 |
Title: | Issue with entPhysicalContainedIn position for Nexus device |
|
Description: | Symptom:
On a Nexus 5000 when polling (entPhysicalContainedIn) 1.3.6.1.2.1.47.1.1.1.1.4, the returned values may be erroneous.
One of the values returned gives back an non-existing index:
entPhysicalContainedIn.24 = INTEGER: 220
This issue may result in inventory collection failures when the device is being polled by LMS.
Conditions:
This issue is observed when running 6.0(2)N1(2).
Workaround:
Either avoid polling the respective OID.
Alternatively, downgrade the nexus 5000 to a version which is not affected. 5.2(1)N1(5) has been confirmed to not been affected.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N1(1), 6.0(2)N2(3), 9.4(1)N1(6.8) |
|
Known Fixed Releases: | 5.2(1)N1(7.102), 5.2(1)N1(8), 7.0(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCtx54852 |
Title: | ARP entry not created for packets routed out of same interface |
|
Description: | Symptoms
A N5k with layer 3 module is not routing traffic
Conditions
* The next hop is on the same interface as the traffic source
* ARP table contains no entry for the next hop
Workaround
Put a static ARP mapping for the next hop
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 5.0(3)N2(2), 5.0(3)N2(2a), 5.1(3)N1(1) |
|
Known Fixed Releases: | 5.1(3)N2(1) |
|
|
| |
| |
Bug Id: | CSCuq98662 |
Title: | Norcal 96EFCR and EF chassis : link up issues with Copper cables |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
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.2(0)N1(0.2), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCtz21055 |
Title: | MTS buffer leak in Fcoe_mgr & F_Port Server low priority requ |
|
Description: | Symptom:
In a Nexus 5500 series switch running NX-OS 5.1(3)N1(1), fabric services such as name
server logins(PLOGI) for FCoE hosts can get affected leading to FCoE hosts not able to see storage LUNs.
Workaround:
Reload the switch to recover. The fix is to upgrade to NX-OS 5.2(1)N1(1) and later.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N1(1) |
|
Known Fixed Releases: | 5.2(1)N1(1) |
|
|
| |
| |
Bug Id: | CSCut12023 |
Title: | Port channel service crashes after many 'show run' commands |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
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.2(0)AB(9), 7.2(0)N1(0.134), 7.2(0)N1(0.146), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuo74918 |
Title: | Carmelusd hap reset on ND ISSU |
|
Description: | Symptom:
Switch crashes and generates carmelusd core.
Conditions:
Initiate ND ISSU.
Workaround:
N/A
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | 7.0(3)N1(1), 7.1(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCur75712 |
Title: | N5K PTP intermittently sends Delay_Resp with rewinded timestamp |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
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(1a), 7.2(0)N1(0.182), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.184), 7.3(0)N1(0.25) |
|
|
| |
| |
Bug Id: | CSCub46846 |
Title: | N5K Physical Replacement caused fex link flapping with pre-provision |
|
Description: | Symptom:
Active/Active FEX interfaces connected to vPC pair of Nexus 5000 switches can flap during Nexus 5000 replacement even with FEX
pre-provisioned.
Conditions:
Seen during Nexus 5000 switch replacement.
Workaround:
None. This issue is resolved in NX-OS 5.2(1)N1(2)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N2(1a) |
|
Known Fixed Releases: | 5.2(1)N1(2) |
|
|
| |
| |
Bug Id: | CSCuu76648 |
Title: | ND ISSU failure from 7.1(0)N1(1a) or 7.1(0)N1(1b) to higher versions |
|
Description: | Symptom:
Non disruptive upgrade failure with "failed to free memory in the file system" error
Conditions:
upgrading from 7.1(0)N1(1a) or 7.1(0)N1(1b) to 7.1(1)N1(1) or 7.2(0)N1(1) with N2K-C2348TQ-10G in the setup
Workaround:
None
Further Problem Description:
This failure results in a switch reboot. To preserve the configs steps in "Steps to restore breakout configs" note are recommended to be followed before upgrading.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.226) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut59888 |
Title: | After MAC Flap, MAC is not relearned correctly on one of the VPC Peers. |
|
Description: | Symptom:
After a short MAC-address flapping we can see on a VPC-Peer that
one VPC peer has the MAC address pointing to a single source interface
Other VPC peer has the MAC address pointing to the different source interface
Example:
Switch_A# sh mac add dy vlan 10
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link
VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+------------------
* 10 0000.0c07.ac00 dynamic 120 F F 333.0.0
Switch_B# sh mac add dy vlan 10
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link
VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+------------------
* 10 0000.0c07.ac00 dynamic 10 F F Po6
And traffic is sourced from source-mac 0000.0c07.ac00 only on Po6
Conditions:
2 Variations have been seen of the issue:
- MAC is wrong till MAX-age and corrects
- MAC is not cleared on MAX-age
This is only seen when only one leg of the VPC is receiving the traffic and one leg is not receiving *any* traffic from the affected source-mac address.
Workaround:
Clear the MAC manually
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo05800 |
Title: | HIF of N2232PP 1G link can't up with 3rd device |
|
Description: | Symptom:
N2232PP fexes are connected to parent n7009 switch via F248E module, when fex use GLC-SX-MM /
1000Base-SX module to connect a 3-rd device, the HIF interfaces cant be up. however, if the same SFP/cable is inserted into the F2E, the interface can be up normally.
Conditions:
only fex interfaces has such issue, F2E linecards don't have it.
Workaround:
none
Further Problem Description:
none
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur37507 |
Title: | N128: ISSU from 7.0(2)N1(1) to Imaint MR4 - PCIe critical FAILURE error |
|
Description: | Symptom:
Following error message is shown in the logs
%$ VDC-1 %$ %USER-0-SYSTEM_MSG: 000: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
Conditions:
This error is shown on boot up.
Workaround:
none
Further Problem Description:
This is a cosmetic s/w bug with no functional impact
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(0.179) |
|
Known Fixed Releases: | 7.0(1)ZN(0.640), 7.0(5)N1(0.182), 7.0(5)N1(1), 7.1(0)N1(0.388), 7.1(0)N1(1), 7.1(0)ZN(0.462), 7.2(0)N1(1), 7.2(0)ZN(0.91) |
|
|
| |
| |
Bug Id: | CSCul51416 |
Title: | Iluka - FCOE Slowdrain - Pause events not detected for bind mac config |
|
Description: | Symptom:
FCOE slow drain functionality does not work for VFCs bound to a mac. FCOE slow drain works for VFCs bound to physical interfaces
Conditions:
VFCs are bound to a mac using bind-mac
Workaround:
Use VFC binding to physical interface instead of binding to mac
Further Problem Description:
Dynamically bound VFCs to macs are not Supported
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(0.350) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuf62028 |
Title: | Nexus 5000: 'zone' service crash and unexpected reboot |
|
Description: | Symptom:
Nexus 5500 switch crash due to zone hap reset:
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
Reason: Reset triggered due to HA policy of Reset
Service: zone hap reset
Conditions:
This has been observed on the Nexus 5500 running 6.0(2)N1(2) and 6.0(2)N2(3).
Zone modifications were being made at the time (additions, deletions, etc).
It is currently unknown what conditions will lead to this crash.
Workaround:
None
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N1(2), 6.0(2)N2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj86321 |
Title: | Iluka - pause events not seen if slow drain is enabled before VFC is up |
|
Description: | Symptom:
FCOE Slowdrain does not take effect for VFCs that that are bound after the global slow drain commands are configured
Conditions:
1. FCOE slowdrain commands are configured and show up in running config
2. New VFC are created and bound to physical ports
Workaround:
1. Remove the slow drain global configs and reapply them
2. Ensure that all VFC are up before configuring slowdrain
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(0.277) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur54642 |
Title: | N5K with ERSPAN enabled may face a slow leak in 'monitor' process |
|
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:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 16-JUN-2015 |
|
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.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuq68431 |
Title: | EIGRP crash in eigrp_cmi_enqueue |
|
Description: | Symptom:
EIGRP crash in eigrp_cmi_enqueue
Conditions:
EIGRP receives a SNMP request before it's completely initialized
Workaround:
No known workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(1)ZN(0.693), 7.0(6)N1(0.202), 7.0(6)N1(1), 7.1(0)AV(0.38), 7.1(0)D1(0.326), 7.1(0)EV(0.116), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283) |
|
|
| |
| |
Bug Id: | CSCuu81648 |
Title: | N6K Port-Channel wont establish after upgrade to 7.0(6)N1(1) |
|
Description: | Symptom:
N6K-1(config)# show flogi internal event-history errors
2) Event:E_DEBUG, length:147, at 528090 usecs after Mon Jun 8 23:55:26 2015
[102] fs_flogi_send_flogi_reject(5726):fs_flogi_send_flogi_reject: flogi_fc2_req is FALSE pwwn[20:1c:00:2a:6a:9a:f3:80] vsan[21] ifindex [0x108c000]
3) Event:E_DEBUG, length:73, at 347922 usecs after Mon Jun 8 23:55:26 2015
[102] fs_flogi_send_flogi_reject: mts_q == 0, ifindex 0x108a000, port 0x0
4) Event:E_DEBUG, length:147, at 347918 usecs after Mon Jun 8 23:55:26 2015
[102] fs_flogi_send_flogi_reject(5726):fs_flogi_send_flogi_reject: flogi_fc2_req is FALSE pwwn[20:1b:00:2a:6a:9a:f3:80] vsan[21] ifindex [0x108a000]
5) Event:E_DEBUG, length:124, at 985824 usecs after Mon Jun 8 23:42:37 2015
[102] fs_fc2_msg_flogi: ifindex[0x108c000] pwwn[20:1c:00:2a:6a:9a:f3:80] physical flogi rejected, waiting for the port mode
Conditions:
After upgrade to 7.0(6)N1(1) on the N6K, FI OUI of "002a6a", "8c604f", "00defb" cannot establish port-channel.
Workaround:
Remove SAN Portchannel config - use individual links between UCS and 5k - not san-port-channels.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N4(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur05017 |
Title: | N5K/N6K evaluation for CVE-2014-6271 and CVE-2014-7169 |
|
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCup05323 |
Title: | Fwm core while executing fabric port flap |
|
Description: | Symptom:
fwm service crash. Following errors are seen during a crash:
SYSMGR-2-SERVICE_CRASHED: Service "fwm" (PID 3756) hasn't caught signal 11 (core will be saved).
vpc-vl1# sh system reset-reason
System reset reason would be similar to this:
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
Reason: Reset triggered due to HA policy of Reset
Service: fwm hap resetConditions:
Conditions:
This is observed during frequent fabric port flaps
Workaround:
Possible workaround is to stop the fabric port flaps.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.174), 7.1(0)N1(0.186) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo79180 |
Title: | copy run start fails: Service "flogi" failed to store its configuration |
|
Description: | Symptom:
A "copy run start" can fail with the following message:
2014 May 10 00:01:23 N5548UP SYSMGR-3-CFGWRITE_SRVTIMEOUT Service "flogi" failed to store its configuration in the timeout period
2014 May 10 00:01:23 N5548UP SYSMGR-2-CFGWRITE_ABORTED Configuration copy aborted.
2014 May 10 00:01:26 N5548UP SYSMGR-3-CFGWRITE_FAILED Configuration copy failed (error-id 0x401E0045).
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo59839 |
Title: | N5k 6.0(2) CarmelUSD Kernel Panic |
|
Description: | Symptom:
Nexus 5500 crash due to kernel panic
Conditions:
This was observed on Nexus 5500 switch running 6.0(2)N2(2). Other releases may also be affected
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus17580 |
Title: | eth_port_channel hap reset |
|
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:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(5)N1(0.184) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj85007 |
Title: | vPC+: After Reload FEX MAC is not Synced Resulting in Traffic Black-Hole |
|
Description: | Symptom:
MAC address entries may not be synced or experience delay to be synced to the peer switch which causes traffic to be black-holed until the entries are synced.
Conditions:
This can occur for both spine and leaf switches in a FabricPath deployment running vPC+ NIF or HIF interfaces:
- For Nexus 5500/6000 (when switch is reloaded)
- For Nexus 7000 (when switch is resuming from reload)
Workaround:
For the Nexus 7000 running a release prior to 6.2(8), contact TAC for an EEM script to prevent this issue. Fabric-path link-up delay is enabled by default 6.2(8) and later on the Nexus 7000.
For the Nexus 5500/6000, increase the link-up delay from the default of 10 seconds:
fabricpath timers linkup-delay 60 (should be increased based on time it takes for all FEX to come online)
Further Problem Description:
In an environment running 6.2(x) on the Nexus 7000, 7.0(x) on the Nexus 5500/6000, and later on all FabricPath devices, it is recommended in addition to modifying the link-up timers, to configure IS-IS overload bit on start-up:
fabricpath domain default
set-overload-bit on-startup 300 (should be increased based on time it takes for all FEX to come online)
This will prevent the device from being used for transit FabricPath traffic until the timer expires.
CSCud25862 is for a similar issue relating to unknown unicast flooding being black-holed.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtw70392 |
Title: | N5k: snmpd crash due to heartbeat failure |
|
Description: | Symptom:
SNMP process crash due to heartbeat failure on Nexus 5000
Conditions:
None
Workaround:
None
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.0(3)N2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua54088 |
Title: | Nexus 5500 FC san-port-channel interface member has increasing drops |
|
Description: | Symptom:When a new member port from a new asic gets added to the san-port-channel or
only/last member from
any asic of a san-port-channel is flapped, ingress FC frames are dropped at
that member port due to
lif vlan membership check failure
Conditions:
The issue happens when in a san-port-channel the last member from any ASIC is
flapped.
Another condition is when a new member from a fresh asic is added to the
existing san-port-channel.
This issue might also happen if the nexus 5500 switch is reloaded and the san port-channel comes back up after the switch comes back up.
Workaround:- Adding another member port from the same asic
- Flapping the san-port-channel
- Fix is available in 5.2(1)N1(2)
- Even if the switch is running an image with the fix, we might still need to
flap the san-port-channel once to clear from the problem.
Please note: Flapping the san-port-channel does not always work as a workaround.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N2(1), 5.1(3)N2(1a), 5.2(1)N1(1a) |
|
Known Fixed Releases: | 5.2(1)N1(1b), 5.2(1)N1(2) |
|
|
| |
| |
Bug Id: | CSCui12905 |
Title: | Nexus 5K Switch Crashes While Zoning Through DCNM |
|
Description: | Symptom:
Nexus 5k switch crashes during zone reconfiguration:
ZONE-2-ZS_MERGE_FAILED VSAN X Zone merge failure, isolating interface fcx/x reason: Zoning object mismatch:[reason:0]
ZONE-2-ZS_MERGE_FAILED VSAN X Zone merge failure, isolating interface fcx/x reason: Zoneset name mismatch:[reason:0]
SYSMGR-2-SERVICE_CRASHED Service "zone" (PID XXXXhasn't caught signal 11 (core will be saved).
Conditions:
Zones being reconfigured in DCNM.
Workaround:
None known.
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N1(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj70799 |
Title: | Powered-down due to fan policy trigger after SFP insert |
|
Description: | Symptom:
sh system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 331091 usecs after Mon May 25 19:19:07 2015
Reason: Powered-down due to fan policy trigger
Service:
Rare occurrence.
Conditions:
Insertion of bad SFP
Workaround:
Remove the SFP from the switch
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N2(1), 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul15987 |
Title: | FEX modules disconnected during file copy to bootflash |
|
Description: | Symptom:
Some FEX modules got disconnected from the parent Nexus 5000 switch during an external file copy to disk.
When this happens, the VTY session and the file transfer progress hangs as well.
Conditions:
This was observed under the following conditions:
- Nexus 5020 switch with multiple FEX modules connected to it.
- /var/sysmgr internal directory is at high usage. This can be checked using command:
# show system internal flash
- The file transfer was made via the mgmt0 interface.
Workaround:
Contact Cisco TAC for assistance in reducing the usage of the /var/sysmgr directory.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(5) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut60406 |
Title: | IlukaMR5: discover pkts not reaching to server in L2MP & snoop enabled |
|
Description: | Symptom:
The dhcp packets received by SUP through fabric path port are dropped in SUP bigsur in transmit direction. Hence the packets will not be seen on egress classical ethernet port which is connected to server. Here DHCP Snooping is only making packets to be sent to SUP.
Conditions:
It occurs in L2 Fabric path setup and only if dhcp snooping is enabled.
Workaround:
Remove dhcp snooping so that hardware switching of dhcp packets can occur.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.125) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108) |
|
|
| |
| |
Bug Id: | CSCus89838 |
Title: | Nexus 5000 'fwm' process crash while updating multicast routes |
|
Description: | Symptom:
Nexus 5000 may crash while updating multicast routes. System reset-reason shows 'fwm hap reset'.
Conditions:
Not known
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)ZN(0.113), 7.1(2)N1(0.534), 7.2(0)N1(0.183), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.185), 7.3(0)N1(0.25), 7.3(0)N1(1), 7.3(0)ZN(0.24) |
|
|
| |
| |
Bug Id: | CSCut97255 |
Title: | dhcp_snoop reset on nexus 5000 |
|
Description: | Symptom:
N5k crashed with 'dhcp_snoop hap reset' reset reason
Conditions:
IPv6 dhcp functionality enabled
Workaround:
Disable IPv6 DHCP
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)ZN(0.99), 7.1(2)N1(0.523), 7.2(0)N1(0.191), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.193), 7.3(0)N1(0.25), 7.3(0)N1(1), 7.3(0)ZN(0.24) |
|
|
| |
| |
Bug Id: | CSCuu04099 |
Title: | N5K: SAN port-channel has output discards when member links are added |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N2(1b) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(2)N1(0.543), 7.1(2)ZN(0.2) |
|
|
| |
| |
Bug Id: | CSCut45896 |
Title: | Nexus 5k/6k - MARCH 2015 OpenSSL Vulnerabilities |
|
Description: | Symptom:
This product includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-0286, CVE-2015-0287, CVE-2015-0289, CVE-2015-0292, CVE-2015-0293, CVE-2015-0209, CVE-2015-0288
This bug has been opened to address the potential impact on this product.
Conditions:
If DFA configurations are used with 'enable-ssl'
Something like this
fabric database type network
server protocol ldap ip 10.95.126.166 enable-ssl
Or
Onep is configured with "transport type tls ..." option
Or
vmtracker configuration
Workaround:
1. Avoid any "fabric database" configuration with keyword "enable-ssl".
For example:
fabric database type network
server protocol ldap ip 172.29.21.2 enable-ssl
2. Make sure the 'secure LDAP' option is unchecked when defining POAP template on DCNM.
3. Do not use onep
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.1/6.9
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.1) |
|
Known Fixed Releases: | 5.2(1)N1(8.169), 5.2(1)N1(9), 6.0(2)N2(6.143), 6.0(2)N2(7), 7.0(7)ZN(0.108), 7.1(1)ZN(0.109), 7.1(2)N1(0.531), 7.2(1)N1(0.4), 7.2(1)N1(1) |
|
|
| |
| |
Bug Id: | CSCtt10736 |
Title: | Traffic from peer-link dropped after secondary reload and pka reconnect |
|
Description: | Symptom:
In a Nexus 55xx switches configured for vPC and auto-recovery enabled,
IP connectivity across peer-link can be affected. For example, one could not
be able to ping physical IP address of the other Nexus 55xx or HSRP virtual IP
address across the peer-link. If running into this bug, issue following
command and see if my switch id is 2748" on both the vPC peers.
Please note vPC and vPC+ deployments are affected by this issue.
5548-A# show platform fwm info l2 myswid
switch id
-------------------------------------------------------------------
switch id manager
-------------------------------------------------------------------
vpc role: 0 <<<<-------
my switch id: 2748 (0xabc)
emu switch id: 2750 (0xabe)
peer switch id: 2749 (0xabd)
5548-A#
5548-B# show platform fwm info l2mp myswid
switch id
-------------------------------------------------------------------
switch id manager
-------------------------------------------------------------------
vpc role: 0 <<<<-------
my switch id: 2748 (0xabc)
emu switch id: 2750 (0xabe)
peer switch id: 2749 (0xabd
5548-B#
In a good vpc state one switch should say 2748 and the other 2749.
Workaround:
Reloading BOTH Nexus 55xx in the vPC pair will recover from this
condition. If vPC auto-recovery feature is not enabled, this bug will
not be triggered and hence can be used as a workaround.
Further Problem Description:
This is usually seen when both switches come up as vPC primary(dual active
state when both keep-alive and peer-link are down and during switch reboot)
due to vPC auto-recovery enabled.
In some cases you might see that both vPC/vPC+ peers have the vpc role = 0 when you hit this issue.
Basically anytime the two N5ks have auto-recovery kick in because they cannot detect the peer-link and keepalive link when they bootup then we will run into this bug.
Scenario 1:
1. Configure the N5ks with vpc and auto-recovery
2. Shut down the N5ks (for example when moving to production site)
3. Power on both N5ks but the peer-link and keepalive link are not connected
4. Auto-recovery kicks in after 240 seconds (default)
5. Then the keepalive and peerlink are connected between the two N5ks.
6. Now we are in the problematic state.
7. You have to reload both N5ks to get out of this state.
Scenario 1 workaround:
Avoid configuring auto-recovery on the N5ks until after the keepalive is connected. For example, before
you move the N5ks to production and powering them on with the keepalive disconnected you should
unconfigure auto-recovery prior to powering them on in the new site. After the keepalive is connected
then you can reconfigure auto-recovery.
Scenario 2:
When replacing a N5k switch that has "auto-recovery" configured on it. This will be updated in the
operations guide replacement switch procedure.
Scenario 2 workaround:
1. Remove the "auto-recovery" command on the new replacement N5k
2. Connect the vpc keepalive link and the peer-link between the new replacement N5k and the vpc peer
3. Add the "auto-recovery" command back to the new replacement N5k.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N1(0.347), 5.1(3)N2(1), 5.1(3)N2(1a) |
|
Known Fixed Releases: | 5.1(3)N2(1c), 5.2(1)N1(4), 5.2(1)N1(6), 6.0(2)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu50142 |
Title: | Nexus 7k stopped authenticating |
|
Description: | Symptom:
tacacs authentication fails on nexus 7K with the following error in tacacs debugs
tplus_make_author_request: enterin2014 Mar 25 09:32:28 ALT-CORE-SW3 %USER-3-SYSTEM_MSG: Unable to create temporary user x655501. Error 0xffffffff (0) - sshd
Conditions:
unknown
Workaround:
Workaround-1:
None.. could temporarily get users working by creating local usernames on nexus
Workaround-2:
Multi-Sup > Do manual switchover using "system switchover"
Single/Multi-sup >
I. Load Debug Plugin
ii. kill -9
Note: Get PID from "sh system internal sysmgr service name securityd"
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 7.0(3)N1(0.28), 7.2(1)N1(0.5) |
|
Known Fixed Releases: | 7.0(7)ZN(0.111), 7.1(2)N1(0.550), 7.1(2)ZN(0.9) |
|
|
| |
| |
Bug Id: | CSCus68591 |
Title: | Assess GHOST vulnerability for Nexus 5k (CVE-2015-0235) |
|
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 address the potential impact on this product.
Conditions:
Device with default configuration.
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 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCuu50240 |
Title: | N5k System reloads due to TACACS+ process crash |
|
Description: | Symptom:
NX-OS system running 5.2.5 may reload due to TACACS+ process crash.
Conditions:
This issue may occur when TACACS+ is configured for remote accounting. It is caused by a high rate of invalid accounting packets (2 to 3 every second) which create "invalid_ip@" records in the accounting log. This may be confirmed with the following command:
show accounting log | i invalid_ip@
Workaround:
Disable the remote accounting for tacacs.
This can done by removing the aaa accounting config statement for tacacs.
ex:
switch(config)# no aaa accounting default xxxx
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 7.0(3)N1(0.28), 7.2(1)N1(0.5) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)ZN(0.114), 7.1(2)N1(0.535), 7.2(1)N1(0.11), 7.2(1)N1(1) |
|
|
| |
| |
Bug Id: | CSCut01850 |
Title: | MAC violation during failover in Active/Standby server to dual-homed FEX |
|
Description: | Symptom:
MAC security violation is triggered during failover of links for server with active/standby NIC.
Conditions:
Seen on N5Ks running 6.0(2)N2(6).
Workaround:
Performing shut/no shut of active link will restore the connectivity.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtn71292 |
Title: | N5K %SYSMGR-2-VOLATILE_DB_FULL: high usage in /dev/shm |
|
Description: | Symptom:
-The following message may be seen in the log:
%SYSMGR-2-VOLATILE_DB_FULL: System volatile database usage is unexpectedly high at xx%.
-The output of "show system internal flash" will also high usage in the /dev/shm folder
-There may also be other failures in the log suggesting a lack of space.
-Once we totally run out of space a reload may also be seen.
Conditions:
This is seen when a very large number of small files are created in the /dev/shm folder of the volatile memory. If enough of these files are created we can exhaust the memory.
The files are created when we execute "show run" with a large output, or "show run switch-profile" with any sized output.
It takes a very high number of these files to exhaust the memory, so no concern is needed when executing show run directly. However concern is advised if we are automating execution of show run i.e via a script every few minutes.
Workaround:
There is no workaround to clear the volatile memory apart from a reload of the device.
The issue can be prevented by making sure we have no automated polling of the running configuration.
Note if you still get these messages after an upgrade by using ISSU (In service software upgrade), you may need to clean up these files with TAC assistance or perform a reload.
/dev/shm no longer needs these files in it:
csm_acfg_*
csm_sp_acfg_*
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 5.0(2)N2(1), 5.1(3)N2(1) |
|
Known Fixed Releases: | 5.0(3)N2(1) |
|
|
| |
| |
Bug Id: | CSCuo69417 |
Title: | Nexus 6000/5600: Link degraded messages seen been port and fabric ASIC |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCuf21588 |
Title: | ISSU pre-upgrade fails due STP Preupgrade Check failure |
|
Description: | Symptom:
"show install all status"
Compatibility check is done:
Module bootable Impact Install-type Reason
------ -------- -------------- ------------ ------
1 yes disruptive reset STP Preupgrade Check failed on VPC peer switch
...
STP Preupgrade Check failed on VPC peer switch
Conditions:
1) Issue happens because of presence of 'feature adapter-fex' in the
configuration. This feature CLI parser command is available on 5.0(3) based
Nexus 5000 releases however not present later 5.2 based release.
2)Issue is seen on vpc peer switch when the other switch which had performed
ISSU had 'feature adapter-fex' configured and then removed from its
configuration before performing ISSU.
3) No STP instability in network
4) "show spanning-tree issu impact" does not see any issues
Workaround:
- 'feature adapter-fex' is not supported in older 5.0.3 release. It is
supported since 5.1 release.
- after removing 'feature adapter-fex' from the configuration, please reload
the switch before doing ISSU.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus42980 |
Title: | JANUARY 2015 OpenSSL Vulnerabilities |
|
Description: |
Symptom:
This product includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-0291, CVE-2015-0204, CVE-2015-0290, CVE-2015-0207, CVE-2015-0286, CVE-2015-0208, CVE-2015-0287, CVE-2015-0289, CVE-2015-0292, CVE-2015-0293, CVE-2015-1787, CVE-2015-0285, CVE-2015-0288
This bug has been opened to address the potential impact on this product.
Conditions:
If DFA configurations are used with 'enable-ssl'
Something like this
fabric database type network
server protocol ldap ip 10.95.126.166 enable-ssl
Or
Onep is configured with "transport type tls ..." option
Or
vmtracker configuration
Workaround:
1. Avoid any "fabric database" configuration with keyword "enable-ssl".
For example:
fabric database type network
server protocol ldap ip 172.29.21.2 enable-ssl
2. Make sure the 'secure LDAP' option is unchecked when defining POAP template on DCNM.
3. Do not use onep
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.1/6.9
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq94445 |
Title: | ISSU failed: maximum downtime exceeded (0x4093003B) |
|
Description: | Symptom:
ISSU fails with the reason code 0x4093003B (maximum downtime exceeded)
Conditions:
Carmel ASIC based systems (i.e. 55xx series), with FCOE enabled and with a scaled setup: interface scale and qos policies.
Upgrade in this specific case is from 7.1(0)N1(1) to 7.1(0u)N1(1u).
Workaround:
None.
Further Problem Description:
Same problem seen in ISSU upgrade from 6.0(2)N2(5) > 7.0(5)N1(1a) > 7.1(0)N1(1a)
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 80169 usecs after Thu Mar 12 10:17:39 2015
Reason: Reset Requested due to Fatal System Error
Service: ISSU failure: 0x4093003B
Version: 7.1(0)N1(1a)
2) At 331870 usecs after Thu Mar 12 10:15:23 2015
Reason: Reset due to upgrade
Service:
Version: 7.0(5)N1(1a)
3) At 785798 usecs after Thu Mar 12 09:53:19 2015
Reason: Reset due to upgrade
Service:
Version: 6.0(2)N2(5)
`show logging nvram`
2015 Mar 12 10:17:39 FS01PPGHDL %$ VDC-1 %$ %SYSMGR-2-ISSU_FAILED: The ISSU has failed: maximum downtime exceeded (error-id 0x4093003B)
2015 Mar 12 10:17:39 FS01PPGHDL %$ VDC-1 %$ Mar 12 10:17:39 %KERN-0-SYSTEM_MSG: [ 134.045810] Shutdown Ports.. - kernel
2015 Mar 12 10:17:39 FS01PPGHDL %$ VDC-1 %$ Mar 12 10:17:39 %KERN-0-SYSTEM_MSG: [ 134.080176] writing reset reason 3, ISSU failure: 0x4093003B - kernel
2015 Mar 12 10:17:39 FS01PPGHDL %$ VDC-1 %$ Mar 12 10:17:39 %KERN-0-SYSTEM_MSG: [ 134.080178] - kernel
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 7.0(0)N1(1.1), 7.1(0)N1(0.335), 7.1(0)N1(0.342), 7.2(0)N1(0.116) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu90244 |
Title: | DHCP client not getting negotiated when snooping is enabled |
|
Description: | Symptom:
Snooping is enabled in a VPC+ setup, with server connected to orphan port and client sending packet with broadcast bit not set.
Conditions:
Broadcast bit not set in client
Workaround:
set broadcast bit
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.187) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu32997 |
Title: | Roll Back Failed while applying removed breakout interface config |
|
Description: | Symptom:
Verification of rollback fails.
Conditions:
Checkpoint includes configuration pertaining to port-channels and interfaces configured as members of those port-channels. Post checkpoint, running configuration is modified to remove the members from port-channels.
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 20-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.195) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu94699 |
Title: | Nexus 5596 upgrade from 5.2.1.N1.6 to 7.1.1.N1.1 cause FEX config loss |
|
Description: | Symptom:
upgrade Nexus 5596 from 5.2.1.N1.6 to 7.1.1.N1.1 cause FEX config loss
Conditions:
the pair of 5596 was not upgraded at the same time. So There was a version mismatch of the FEXs.
Workaround:
configure lost FEX commands back
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 20-JUN-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup53176 |
Title: | ethpm service crash on both VPC peers |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCut99511 |
Title: | BFD flaps with the 50 ms default timer |
|
Description: | Symptom:
ISIS-BFD randomly flapping with the 50ms default timer.
Conditions:
Using default bfd timer.
Workaround:
Increase the BFD timer to 250 ms
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 20-JUN-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.7), 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCub31212 |
Title: | N5k System restart due to "ipfib" hap reset. |
|
Description: | Symptom:
Any Nexus 5000 switch , which has "LAN_BASE_SERVICES_PKG" Installed on the Switch can potentially restart due to "ipfib hap reset" . Following can be
observed in the output of show system reset-reason
Reason: Reset triggered due to HA policy of Reset
Service: ipfib hap reset
The issue is due to Memory Leak in ipfib processes .
The leak is around 1.8-2MB per day which results in a crash after almost 130 days . (250MB is the limit)
To identify the current memory allocation for ipfib process , please use the following command and check
for MemAlloc. If you observe the MemAlloc is close to 250000000(250MB) you are on
the risk of a crash .
5500# show processes memory
PID MemAlloc StkSize RSSMem LibMem StackBase/Ptr Process
---- ------- ------- ------- ------- ------------- ---------
1 159744 86016 618496 1716224 bffc4e50/bffc4940 init
3272 261722112 86016 284368896 37801984 bfc95ec0/bfc94b5c ipfib
You can also check if the license is installed by using the following
554up# sh license usage
Feature Ins Lic Status Expiry Date Comments
Count
--------------------------------------------------------------------------------
LAN_BASE_SERVICES_PKG Yes - In use Never -
--------------------------------------------------------------------------------
Conditions:
This is observed on any N5k with "LAN_BASE_SERVICES_PKG" installed (with or without L3 module) , running any 5.1(3) release.
Workaround:
Following fix and workarounds are available.
1)Upgrade to NX-OS 5.2(1)N1(1) and later release
2)If not using version 2 Layer 3 cards or any 5.1 features, downgrade to a 5.0(3) release.
3)If switch cannot be upgraded, reload the box proactively to avoid a crash at unexpected time.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N2(1) |
|
Known Fixed Releases: | 5.1(3)N2(1b) |
|
|
| |
| |
Bug Id: | CSCul27686 |
Title: | Nexus 55xx P Devices: After Upgrade Interface Down & Unrecoverable |
|
Description: | Symptom:
After an upgrade to 5.2(1)N1(6) or 6.0(2)N2(2), interfaces might go down or start flapping. It could be few days after the upgrade before they can go down or start flapping.
Conditions:
- Nexus 5548P or 16P Gigabit Ethernet Modules (GEMs)
- 5.2(1)N1(6) or 6.0(2)N2(2)
Workaround:
Move to any version other than 5.2(1)N1(6) or 6.0(2)N2(2).
Further Problem Description:
- Interfaces cannot be recovered by flapping the link
- If connected to a FEX, the FEX might go offline.
- Not seen on unified port (UP) switch ports or non-P GEMs
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(6), 6.0(2)N2(2) |
|
Known Fixed Releases: | 5.2(1)N1(6.93), 5.2(1)N1(7) |
|
|
| |
| |
Bug Id: | CSCut38855 |
Title: | n5k DR does not register S,G when acting as first hop router |
|
Description: | Symptom:
a n5k acting as first hop router running 7.1(0)N1.1 will not generate PIM register messages.
Conditions:
Workaround:
no workaround known at this time
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu96554 |
Title: | OIFL not programmed correctly for FP ports |
|
Description: | Symptom:
sh vlan id XXX shows the port belongs to that vlan. But OIFL is not taking the port for broadcast
Conditions:
Port is moved from CE to FP
Workaround:
Reload the box
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.210) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu14439 |
Title: | Connectivity problem with solarflare NIC after server reload |
|
Description: | Symptom:
Connectivity problem with solarflare NIC SFN5122F-R64 following server reload.
Despite interface up, switch doesn't see traffic from the serer. Server doesn't receive anything from the switch (including broadcasting) .
Ethernet1/45 is up
RX
0 unicast packets 0 multicast packets 0 broadcast packets
0 input packets 0 bytes
TX
0 unicast packets 10613 multicast packets 0 broadcast packets
10613 output packets 1152256 bytes
Conditions:
Server coming with solarflare NIC SFN5122F-R64 NIC
Workaround:
Shut / no shut
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu33047 |
Title: | Roll back failed while applying allowed vlan command to a interface |
|
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:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.195) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu59941 |
Title: | FC ports error disabled with non-Cisco SFPs after upgrade to 6.x/7.x |
|
Description: | Symptom:
FC ports with non-Cisco SFPs are error disabled 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.
Workaround:
Use Cisco FC transceivers
Further Problem Description:
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:
To be determined once resolved.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(1), 6.0(2)N2(7), 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.116), 7.1(2)N1(0.553), 7.1(2)ZN(0.12), 7.2(1)N1(0.25), 7.2(1)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu21853 |
Title: | Sometimes downgrade fails from 7.2.x to 7.1.x |
|
Description: | Symptom:
Sometimes downgrade will fails from 7.2.x to 7.1.X with reason "imghdr library error".
Conditions:
It is a intermittent issue and may occur when the memory utilization for the /tmp folder is high.
Workaround:
Reload the switch
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.186) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut61071 |
Title: | N48Q: Serdes settings for 1G optics is not correct |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
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.2(1)N1(0.28), 7.2(1)N1(1) |
|
|
| |
| |
Bug Id: | CSCue22038 |
Title: | Unable to poweron the module after poweroff the module |
|
Description: | Symptom:
On powering off a module, there is a timeout of the linecard removal sequence resulting in the slot becoming unusable and requiring a reload
Conditions:
This occurs in a scaled environment where there are very large number of ports associated only to this LEM that is being powered off. When the LEM is powered off, the port manager starts a bring down sequence for all the ports on the LEMs. In this example the SPDC testbed had 8 fexes and 500 VFCs along with the LEM ports that were going down. On the NIV setup the problem was worse with 4 fexes and 2000 veths going down. This bring down sequence takes much longer than 5 minutes which is the LC removal sequence timeout. This results in the timeout and PFM making the slot unusable
Workaround:
Shut the individual ports on the LEM before powering off the module.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N1(0.385), 6.0(2)N3(0.350) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun92485 |
Title: | Unable to modify VLAN Failed to run the commands. Please try again later |
|
Description: | Symptom:
Unable to change VLAN mode to fabricpath
gf-agg2# conf
Enter configuration commands, one per line. End with CNTL/Z.
gf-agg2(config)# vlan 501-1000
gf-agg2(config-vlan)# mode fabricpath
gf-agg2(config-vlan)#
Failed to run the commands. Please try again later.
Conditions:
Workaround:
Issue the command in enable mode
"terminal reset vlan-config-mutex"
After this you will be able to change VLAN mode
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.705), 7.0(6)N1(0.210), 7.0(6)N1(1), 7.1(0)N1(0.195), 7.1(0)N1(1), 7.1(0)ZN(0.302), 7.2(0)ZN(0.93) |
|
|
| |
| |
Bug Id: | CSCuu21919 |
Title: | VPC Role is getting changed with Maint mode on VPC Secondary |
|
Description: | Symptom:On Nexus5k and Nexus6k ,after entering maintenance mode and coming out of it on vPC(virtual Port channel) secondary switch,vPC role changes to operational primary on secondary switch .Primary switch then becomes operational secondary, because of which A-A Fex(Active Active Fabric Extender) goes offline for about 3-4 minutes on both the vpc peers.
Conditions:On vPC secondary switch, executing the command and then executing will change the roles of both switches. This is seen only when Layer 3 interface (SVI - Switch Virtual Interface) and default vrf is used for vPC keep-alive packets.
Workaround:This issue is not seen when management interface is configured for peer-keepalive packets.
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.192) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCum35498 |
Title: | N5K kernel panic crash usd_mts_kthread |
|
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.
Workaround:
None at this time.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N1(2), 6.0(2)N2(2) |
|
Known Fixed Releases: | 5.2(1)N1(7.106), 5.2(1)N1(8), 6.0(2)N2(4.63), 7.0(3)N1(0.30), 7.1(0)N1(0.138), 7.1(0)N1(1), 7.1(0)ZN(0.256) |
|
|
| |
| |
Bug Id: | CSCum56237 |
Title: | N5k:Delay in advertising Msdp Sa-Cache when null pim register received. |
|
Description: | Symptom:
MSDP SA-Cache advertisement delay when null pim register message received.
Conditions:
MSDP configured on 2 N5k running VPC. This bug is specific to VPC and on N5k platform only.
When both the N5k VPC peers are FHRs, if the packet happens to ingress through the VPC bind VRF vlan on one VPC peer before coming on the correct vlan ,then due to RPF failure, there might be delay in setting routes.
Also, if PIM protocol creates a route based on receiving a NULL register instead of a register then SA messages are not sent right away. This might add delay too.
Workaround:
Currently there is no workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N1(2) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)KM(0.64), 7.0(0)N1(0.504), 7.0(0)N1(1), 7.0(0)ZD(0.213), 7.0(0)ZN(0.211), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60) |
|
|
| |
| |
Bug Id: | CSCuu14128 |
Title: | 5500 ND issu failing with FCoE enabled |
|
Description: | Symptom:Non Disruptive issu to janjuc is failing for 5k with FCoE enable
If ISSU is performed from Iluka MR5 to janjuc , it will always be disruptive and sometimes GEM modules may go missing
Conditions:FCoE enabled setup in Non-NPV mode
Workaround:ISSU on 5k to Janjuc with FCoE enabled will always be disruptive (WA not available to make it non disruptive)
Reload the switch to recover GEM Modules
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.180) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu13486 |
Title: | Traffic issue in some vrf on setup with 100 vrf |
|
Description: | Symptom:asm multicast issue for some vrf in scaled setup
Conditions:when asm traffic started for 100 vrfs each with 50 s,g
Workaround:do not start for so many at the same time
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.186) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq68153 |
Title: | Fexes go offline when removing the detectable vlan cmd |
|
Description: | Symptom:
FEXes going offline was seen on scaled setup, under various conditions, including removing the mobility domain detectable vlan range config, or simple switch reboot. This failure does not seem to be related to the
mobility domain feature, but rather an infrastructure issue, as it was seen even without mobility domain
feature configured.
Conditions:
Scaled setup with 16+ FEXes.
Workaround:
FEXes can come back up after going offline for a while
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.315) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut37604 |
Title: | Vfc port-channel is not coming up with the error |
|
Description: | Symptom:
On Cisco Nexus 5696Q series and Cisco Nexus 5624Q series switches, a port channel interface consisting of virtual fibre channel (VFC) interfaces does not come up.
Conditions:The problem is seen on Cisco Nexus 5696Q series and Cisco Nexus 5624Q series switches which have a Bigsur ASIC of revision B in it.
The problem is only seen when the fibre channel interfaces on the switches are connected to another Cisco Nexus 5696Q series or 5624Q series switch that has a Bigsur ASIC of revision C in it.
Workaround:There is no workaround.
More Info:The Bigsur ASIC revision on the switch can be found out using the command show hardware internal bigsur asic 0 and looking at the "revision" field. Revision 1 would indicate Revision B and Revision 2 would indicate Revision C.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.134) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu23398 |
Title: | [SPAN]: "Service not responding" err on shut/unshut of ssn with more src |
|
Description: | Symptom:
Span session with more than 32+ source interface will throw "Service not responding" error
upon doing shut/no shut of the moitor session
Conditions:
"Service not responding " error messages are seen upon doing "shut"/"no shut" of the span session having
32+ source interfaces
Workaround:
Workaround is to wait until the session comes up, even after the "Service not responding" error is thrown
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.192) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut55768 |
Title: | HSRP VMAC entries doesn't get programmed in MyIpr table post MCT flap |
|
Description: | Symptom:
HSRP VMAC(Virtual-MAC) entries doesn't get programmed in hardware post MCT (vPC peer-link) flap and we might see traffic impact due to this.
Conditions:
This is observed on a scale vPC pair setup comprising of Cisco Nexus 6000 having mix of HSRP and VRRPs configured.
This issue was observed when I had around ~400 FHRP Groups (HSRP and VRRP combined) along with L3 Sub-interfaces configured.
Workaround:
If we perform shut/no shut on the impacted or problematic interface-vlan (SVI) having HSRP or VRRP, issue gets resolved and we will see the corresponding FHRP VMAC getting programmed in hardware.
Further Problem Description:
In some cases, if we reload any one of the vPC pair switch, we will see this problem wherein Virtual-MACs of the FHRP groups doesn't get programmed in hardware resulting into traffic loss.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.144) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus68610 |
Title: | N5K/N6K - Silent reset with uC reset code: 0x4800 |
|
Description: | Symptom:
A Nexus 5600 may reset with unknown reason
From the "show logging onboard internal reset-reason",
Reset Reason (HW): uC reset code: 0x4800 <<<<
Prior to reset/hang, syslog messages such as following can be displayed.
2015 Mar 16 11:50:28 N5672 %USER-0-SYSTEM_MSG: 2032: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
2015 Mar 16 11:50:58 N5672 %USER-0-SYSTEM_MSG: 2033: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
2015 Mar 16 11:52:29 N5672 %USER-0-SYSTEM_MSG: 2034: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
2015 Mar 16 11:53:29 N5672 %USER-0-SYSTEM_MSG: 2035: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
Conditions:
Currently being investigated at this time.
Workaround:
If this issue is suspected, please reach out to TAC for assistance and diagnosis of the problem.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)N1(0.513), 7.1(1)N1(1), 7.1(1)ZN(0.69), 7.2(0)N1(0.167), 7.2(0)N1(0.180), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.170), 7.3(0)N1(0.25) |
|
|
| |
| |
Bug Id: | CSCup22365 |
Title: | Multiple Vulnerabilities in OpenSSL - June 2014 |
|
Description: | Symptom:
The following Cisco products
Cisco Nexus 5000 Series of switches
Cisco Nexus 6000 Series of switches
Cisco Nexus 5600 Series of switches
Cisco Nexus 2000 Series of switches
include a version of openssl that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-0076 - Fix for the attack described in the paper "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
CVE-2014-0224 - SSL/TLS MITM vulnerability
CVE-2014-3470 - Anonymous ECDH denial of service
This bug has been opened to address the potential impact on this product.
Conditions:
Following application uses SSL library
1) Fabric Management feature in N5K uses XMPP protocol to talk to XMPP servers. This internally uses openssl library. If the customer network uses Fabric Management feature, the network is vulnerable to above issues.
Configuration :
switch(config)# feature fabric access
2) If the customer n/w has Vinci DFA autoconfig feature, it uses openssl to contact LDAP server. and network is vulnerable to security
Configuration :
switch(config)# fabric database type network
server protocol ldap {ip } | {host }
db-table ou=networks,dc=cisco,dc=com key-type 1
fabric database type profile
server protocol ldap {ip } | {host }
db-table ou=profilesIPFabric,dc=cisco,dc=com
fabric database type partition
server protocol ldap {ip } | {host }
db-table ou=partitions,dc=cisco,dc=com
3) Vmtracker - N5k/n6k uses this application to connect to "Vmware Vcenter". If customer uses this feature in the network, then the network is vulnerable.
Configuration :
switch(config)# feature vmtracker
4) ONE PK for open routing APIs uses SSL for communication thus network is vulnerable to security
configuration :
switch(config)# onep
switch(config-onep)# ?
datapath One Platform datapath
history One Platform history trails
logging One Platform logging
no Negate a command or set its defaults
service ONEP service set
session One Platform session
transport Transport command
end Go to exec mode
exit Exit from command interpreter
pop Pop mode from stack or restore from name
push Push current mode to stack or save it under name
where Shows the cli context you are in
Workaround:
Not available.
Further Problem Description:
The Nexus 2000 Series Fabric Extenders retrieve their software from the master switch that they are attached too.
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.8/7.5:
https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(0.91), 7.2(0)VX(0.9), 7.2(0.1)PR(0.1), 9.4(1)N1(6.8) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu90977 |
Title: | DHCPv6 client not getting negotiated when relay is enabled |
|
Description: | Symptom:
DHCPv6 client behind FP cloud with relay enabled on the switch connected to the client, and server on an orphan port
Conditions:
when broadcast bit is set
Workaround:
Disable broadcast bit
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.187) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup22663 |
Title: | Multiple Vulnerabilities in OpenSSL - June 2014 |
|
Description: | Symptom:
The following Cisco products
Cisco Nexus 5000 Series of switches
Cisco Nexus 6000 Series of switches
Cisco Nexus 5600 Series of switches
Cisco Nexus 2000 Series of switches
include a version of openssl that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-0076 - Fix for the attack described in the paper "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
CVE-2014-0224 - SSL/TLS MITM vulnerability
CVE-2014-3470 - Anonymous ECDH denial of service
This bug has been opened to address the potential impact on this product.
Conditions:
Following applications Utilize the OpenSSL library packaged with NX-OS
1) Fabric Management feature in N5K uses XMPP protocol to talk to XMPP servers. This internally uses openssl library. If the customer network uses Fabric Management feature, the network is vulnerable to above issues.
Configuration :
switch(config)# feature fabric access
2) If the customer n/w has Vinci DFA autoconfig feature, it uses openssl to contact LDAP server. and network is vulnerable to security
Configuration :
switch(config)# fabric database type network
server protocol ldap {ip } | {host }
db-table ou=networks,dc=cisco,dc=com key-type 1
fabric database type profile
server protocol ldap {ip } | {host }
db-table ou=profilesIPFabric,dc=cisco,dc=com
fabric database type partition
server protocol ldap {ip } | {host }
db-table ou=partitions,dc=cisco,dc=com
3) Vmtracker - N5k/n6k uses this application to connect to "Vmware Vcenter". If customer uses this feature in the network, then the network is vulnerable.
Configuration :
switch(config)# feature vmtracker
4) ONE PK for open routing APIs uses SSL for communication thus network is vulnerable to security
Configuration :
switch(config)# onep
switch(config-onep)# ?
datapath One Platform datapath
history One Platform history trails
logging One Platform logging
no Negate a command or set its defaults
service ONEP service set
session One Platform session
transport Transport command
end Go to exec mode
exit Exit from command interpreter
pop Pop mode from stack or restore from name
push Push current mode to stack or save it under name
where Shows the cli context you are in
Workaround:
Not Applicable
Further Problem Description:
The Nexus 2000 Series Fabric Extenders retrieve their software from the master switch that they are attached too.
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.8/7.5:
https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(0.91), 7.2(0)VX(0.9), 7.2(0.1)PR(0.1), 9.4(1)N1(6.8) |
|
Known Fixed Releases: | 5.2(1)N1(8.145), 5.2(1)N1(8b), 6.0(2)N2(5.91), 6.0(2)N2(6), 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(1)ZN(0.739), 7.0(1)ZN(0.740), 7.0(6)N1(0.238), 7.0(6)N1(0.240) |
|
|
| |
| |
Bug Id: | CSCur30094 |
Title: | Nexus 5000 : evaluation of SSLv3 POODLE vulnerability |
|
Description: | Symptom:
This product includes a version of SSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-3505
CVE-2014-3506
CVE-2014-3507
CVE-2014-3508
CVE-2014-3510
CVE-2014-3566 (POODLE)
This bug has been opened to address the potential impact on this product.
Conditions:
The POODLE Security issue CVE-2014-3566 exists if we configure LDAP as part of DFA configuration
Something like this
fabric database type network
server protocol ldap ip 10.95.126.166 vrf management
Or
Onep is configured with "transport type tls ..." option
Or
vmtracker configuration
Workaround:
1. Avoid any "fabric database" configuration with keyword "enable-ssl".
For example:
fabric database type network
server protocol ldap ip 172.29.21.2 enable-ssl
2. Make sure the 'secure LDAP' option is unchecked when defining POAP template on DCNM.
3. Do not use onep
Further Problem Description:
A POODLE attack requires a man in the middle attack between the nexus5000/6000 switch (the LDAP client)
and the LDAP server. It would also require a protocol downgrade attack since, by default, nexus5000/6000
uses TLS protocol.
Current schedule for the fix :
- 7.1(1)N1(1) March or early April 2015 (was postponed from Feb 2015)
- 7.2 release April 2015
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the
time of evaluation are: 2.6/2.5
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(0.91), 7.0(4)N1(1), 7.1(0)ZN(91.34), 7.2(0)N1(0.76), 7.2(0)N1(0.82), 7.2(0)N1(0.85), 7.2(0)N1(0.88), 7.2(0)VX(0.9), 7.2(0.1)PR(0.1), 7.9(0)ZD(0.4) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.74), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.1(1)N1(0.482), 7.1(1)N1(1), 7.1(1)ZD(0.19), 7.1(1)ZN(0.33), 7.2(0)AB(9) |
|
|
| |
| |
Bug Id: | CSCur14826 |
Title: | WRL 5: GNU Bourne Shell "Shellshock" Vulnerability for kernel migration |
|
Description: | Symptom:
The following Cisco products with NXOS:
N7K
include a version of Bash that may be affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-6271
CVE-2014-6277
CVE-2014-6278
CVE-2014-7169
CVE-2014-7186
CVE-2014-7187
Conditions:
Not applicable
Workaround:
Not applicable
Further Problem Description:
Additional details about those vulnerabilities can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has evaluated those issues and they do not meet the criteria for PSIRT ownership or involvement. Those issues will be addressed via normal resolution channels.
If you believe that there is new information that would cause a change in the severity of those issues, 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/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 0.1 |
|
Known Fixed Releases: | 7.0(0)KM(0.87) |
|
|
| |
| |
Bug Id: | CSCur15901 |
Title: | N2K-C2348UPQ FEX does not come up due to "SDP timeout/SFP Mismatch" |
|
Description: | Symptom:
A Nexus N2K-C2348UPQ-10GE FEX connected to a Nexus 5K/6K parent might not come up at all or intermittently fail to come up after reloads. A show interface on the parent switch will indicate the FEX fabric interfaces to be in SDP timeout/SFP Mismatch state
N6K(config-if-range)# show int eth 1/21-28 brief
--------------------------------------------------------------------------------
Ethernet VLAN Type Mode Status Reason Speed PortInterface Ch #
--------------------------------------------------------------------------------
Eth1/21 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/22 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/23 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/24 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/25 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/26 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/27 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/28 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Conditions:
Seen in a N2K-C2348UPQ-10GE FEX connected to a Nexus 5K/6K
Workaround:
Power cycle the the FEX few times with fabric connection to the parent in place. If the FEX still does not come online, contact TAC
Further Problem Description:
Note: There is another bug CSCur89241 related to this issue. Final fix is in NX-OS 7.1(1)N1(1)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.362) |
|
Known Fixed Releases: | 7.0(1)ZN(0.724), 7.0(2)FIP(0.6), 7.0(6)N1(0.227), 7.0(6)N1(1), 7.1(0)N1(0.410), 7.1(0)N1(1), 7.1(0)ZN(0.485), 7.2(0)N1(1), 7.2(0)ZN(0.91), 7.3(0)N1(0.3) |
|
|
| |
| |
Bug Id: | CSCuc72380 |
Title: | Nexus 5500: IGMP Link Local Destination Packet Flooded |
|
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
Workaround:
Remove affected VLAN from peer-link. Traffic will still be forwarded by vPC primary due to graceful consistency check.
Further Problem Description:
This is a hardware limitation specific to the vPC implementation Nexus 5500 series.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N2(1a), 6.0(2)N2(4) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.74), 7.1(2)N1(0.548), 7.1(2)ZD(0.5), 7.1(2)ZN(0.7), 7.2(0)BA(0.12), 7.2(0)D1(0.467), 7.2(0)D1(1), 7.2(0)N1(0.160) |
|
|
| |
| |
Bug Id: | CSCuu47031 |
Title: | N6004 single fan OIR may cause multiple fans to fail |
|
Description: | Symptom:
Fan modules may show removed/failed in software when a fan is removed or re-seated. This can cause the switch to start a 120 second countdown to power-off if more than 2 fans are shown to be removed. This can affect either just the fan that was removed, or other fans in the chassis
The fan module may not show at all, or it may show as failed for read failures for fan speed
2011 Feb 7 20:22:26 switch %$ VDC-1 %$ %NOHMS-2-NOHMS_ENV_ERR_FANS_UP: Recovered: From System major alarm on fans: Multiple fans missing or failed
2011 Feb 7 20:22:26 switch %$ VDC-1 %$ %PFMA-0-SYS_SHUTDOWN_FAN_REMOVAL: System shutdown in 120 seconds due to fan removal
2011 Feb 7 20:22:27 switch %$ VDC-1 %$ %NOHMS-2-NOHMS_ENV_ERR_FAN_SPEED: System minor alarm in fan tray 3: fan speed is out of range on fan 3. 6890 to 12500 rpm expected. 0 rpm read
2011 Feb 7 20:22:27 switch %$ VDC-1 %$ %NOHMS-2-NOHMS_ENV_ERR_FAN_SPEED: System minor alarm in fan tray 3: fan speed is out of range on fan 4. 6890 to 12500 rpm expected. 0 rpm read
2011 Feb 7 20:22:27 switch %$ VDC-1 %$ %NOHMS-2-NOHMS_ENV_ERR_FANS_DOWN: System major alarm on fans: Multiple fans missing or failed
Conditions:
Nexus 6004 fan module is either removed, or re-inserted to the chassis. This may not occur every time the action is performed.
Workaround:
Re-seat the fan module showing as failed or absent
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus83365 |
Title: | N48Q: Switch reloads when there is no fan or when temp cross maj thresh |
|
Description: | Symptom:
System goes for a reboot(instead of shutdown) after a major alarm like SYS_SHUTDOWN_FAN_REMOVAL or SYS_SHUTDOWN_FAN_DIR_MISMATCH.
Conditions:
1) Multiple fans failed or removed
2) Incompatible fans
3) High Temperature
Workaround:
Manually poweroff the system or recover the error state(by having sufficient no of fans/compatible fans)
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.1(1)N1(0.494) |
|
Known Fixed Releases: | 7.1(2)N1(0.563), 7.1(2)N1(1a), 7.1(2)ZN(0.23), 7.3(0)N1(0.30), 7.3(0)N1(1), 7.3(0)ZN(0.33) |
|
|
| |
| |
Bug Id: | CSCuu06028 |
Title: | interface config doesn't apply properly after Disruptive Downgrade |
|
Description: | Symptom:
After performing ISSD from Nexus version 7.2 to a lower version such as 7.1, configuration of some interfaces will get modified with other commands.
Example:
Configuration in version 7.2 is below:
version 7.2(0)N1(1)
interface port-channel2
switchport mode trunk
switchport trunk allowed vlan 2
Configuration modified after ISSD to version 7.1 is below:
version 7.1(1)N1(1)
interface Ethernet1/48
switchport mode trunk
switchport trunk allowed vlan 2
channel-group 2 mode active >>>>> this command is incorrectly added to configuration of Ethernet1/48
Conditions:
Switch should have breakout interfaces configured.
Workaround:
The following steps should be executed before performing ISSD from Nexus 7.2 to lower version.
1. Save current running configuration to a file on bootflash.
2. Execute the command "default interface Eg,. default interface ethernet 1/49/1-4,eth1/50/1
3. Modify the running-configuration to remove breakout interface config (no interface breakout slot 1 port 49-52 map 10g-4)
Perform ISSD.
After ISSD procedure is complete, execute the following steps to reconfigure interface breakout configuration.
1. Configure breakout interfaces and reload
2. Copy saved running-config to switch's current running configuration.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.178) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc26047 |
Title: | Nexus 5k/6k reset due to Kernel Panic |
|
Description: | Symptom:
A Nexus5000/6000 switch will reset with a kernel panic. The process seen when the kernel panic occurs can vary and is not specific to any particular service. If this issue is suspected, collect the output for 'show logging onboard stack-trace' and contact TAC to verify this.
Conditions:
This has been seen on a N5k/N6K platform. There are no specific conditions to hit the problem currently.
Workaround:
None at this time.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 5.0(3)N2(2b), 5.2(1)N1(3), 6.0(2)N2(2) |
|
Known Fixed Releases: | 5.2(1)N1(7.132), 5.2(1)N1(8), 6.0(2)N2(5.85), 6.0(2)N2(6), 7.0(1)ZN(0.716), 7.0(6)N1(0.219), 7.0(6)N1(1), 7.1(0)N1(0.309), 7.1(0)N1(1), 7.1(0)ZN(0.395) |
|
|
| |
| |
Bug Id: | CSCue71612 |
Title: | Nexus 5548P/5548UP: Silent Reload with i2c code 0x0100 |
|
Description: | Symptom:
A Nexus 5548P/5548UP might experience a reboot and after switch comes up, show version indicates reset-reason as Unknown
Conditions:
This issue is only seen in Nexus 5548P/5548UP model of Nexus 5500 series. Other Nexus 5K family switches such as Nexus 5010/5020 and 5596s are not affected by this issue.
uC reset code can be checked with the following command on NX-OS 5.2(1)N1(4) or later one.
Nexus5548# show logging onboard internal reset-reason
Reset Reason for this card:
Image Version : 5.2(1)N1(4)
Reset Reason (LCM): Unknown (0) at time Tue Apr 22 16:38:52 2014
Reset Reason (SW): Unknown (0) at time Tue Apr 22 15:39:38 2014
Service (Additional Info):
Reset Reason (HW): uC reset code: 0x0100 <<<<<<<<<
ADM1066 Power Good Triggered Reset at time Tue Apr 22 15:39:38 2014
Workaround:
None.
Further Problem Description:
This issue is caused by power-railing problem, and the fix is applied by packaging a new power-controller into NX-OS 5.2(1)N1(8), 6.0(2)N2(5), 7.0(3)N1(1) and later. If a switch is running fixed version of Nexus OS, a Nexus 5548P will have power-sequencer version at 5.0 and a 5548UP will have power-sequencer version at 3.0. Note after a switch running older NX-OS has been upgraded to fixed version using install all process, the switch needs to be power-cycled or command reload power-cycle issued for the new power-sequencer to take effect.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N2(1) |
|
Known Fixed Releases: | 5.2(1)N1(7.128), 5.2(1)N1(8), 6.0(2)N2(4.66), 6.0(2)N2(5), 7.0(1)ZN(0.369), 7.0(3)N1(0.76), 7.0(3)N1(1) |
|
|
| |
| |
Bug Id: | CSCum91234 |
Title: | Install has failed.Return code 0x40930020 Non-disruptive upgrade failed |
|
Description: | Symptom:
ISSU failed after Fex image download image failed.
Conditions:
ISSU.
Workaround:
After the failure re-initiate the ISSU with the 'install all' command one more time.
Further Problem Description:
This issue was seen only on one of the 7 Nexus 5k that were upgraded.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.0(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCug29190 |
Title: | 'ethpc' hap reset tied to SFP diagnostics |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
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.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCut55653 |
Title: | interface-vlan info is not propagated to vPC leading to inconsistency |
|
Description: | Symptom:
We will not see interface-vlans (SVI) information not getting propagated to vPC resulting into SVI Type-2 vPC inconsistency
Conditions:
On a vPC pair switches (Nexus 5k/6k), have multiple SVIs (interface-vlans) configured and perform either one of the switch reload or MCT (vPC peer-link) flap.
Workaround:
There is no workaround for this issue.
Further Problem Description:
This being vPC type-2 consistency, we will not see any functionality impact and vPC remains up on both the vPC pair Nexus switches.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.144) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq80334 |
Title: | N5k:Upgrade from 5.2(1)N1(4) to 5.2(1)N1(6) causes ucast ARP to drop |
|
Description: | Symptom:
N5k:Upgrade from 5.2(1)N1(4) to 5.2(1)N1(6) causes ucast ARP to drop
Conditions:
ISSU from 5.2(1)N1(4) to 5.2(1)N1(6) in Fabripath environment
Workaround:
Upgrade to 6.0 version where the problem is not seen
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(4), 5.2(1)N1(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo02240 |
Title: | N5K carmelusd core |
|
Description: | Symptom:
Nexus 5500 switch crash due to carmelusd hap reset
Conditions:
This was observed on 6.0(2)N2(3). Other releases may be affected as well.
Workaround:
None.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(3), 7.2(0)N1(0.192) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue80077 |
Title: | FEX: Port flap request from SAP: MTS_SAP_SATMGR |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
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)ZN(0.130) |
|
|
| |
| |
Bug Id: | CSCuj84269 |
Title: | Nexus 5000 switch reloaded due to gatosusd hap reset |
|
Description: | Symptom:
A Nexus 5000 switch reloads after gatosusd process crashes.
`show system reset-reason`
Reason: Reset triggered due to HA policy of Reset
Service: gatosusd hap reset
Conditions:
Following log messages can be seen in the syslog file:
- KERN 2 SYSTEM_MSG usd process 3372, uuid 657 (0x291) failed to send heartbeat - kernel *
- SYSMGR 2 SERVICE_CRASHED Service "gatosusd" (PID 3372) hasn''t caught signal 6 (core will be saved). *
- SYSMGR 2 HAP_FAILURE_SUP_RESET System reset due to service "gatosusd" in vdc 1 has had a hap failure *
And the following messages can be seen in the output of `show processes log details` command:
- Invalid Desc Fetch Index detected on Channel 0, asic 4
- ERR: Disabling STM update DMA channel on gatos 4 due to error
Workaround:
No known workarounds at the moment.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(3.50) |
|
Known Fixed Releases: | 5.2(1)N1(6.95), 5.2(1)N1(7), 7.0(1)ZN(0.689), 7.0(6)N1(0.198), 7.0(6)N1(1), 7.1(1)N1(0.463), 7.1(1)N1(1), 7.1(1)ZN(0.16), 7.2(0)AB(9), 7.2(0)N1(0.133) |
|
|
| |
| |
Bug Id: | CSCut92605 |
Title: | "port-profile hap reset" after switch-profile commit |
|
Description: | Symptom:
Switch crashes with a signal 6:
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 428034 usecs after Thu Apr 2 11:53:45 2015
Reason: Reset triggered due to HA policy of Reset
Service: port-profile hap reset
Version: 7.1(0)N1(1a)
2) At 536528 usecs after Thu Feb 26 22:52:10 2015
Reason: Disruptive upgrade
Service:
Version: 6.0(2)N2(5)
`show processes log details`
Service: port-profile
Description: Port Profile Manager
Executable: /isan/bin/ppm
Started at Thu Feb 26 22:55:08 2015 (260301 us)
Stopped at Thu Apr 2 11:53:31 2015 (168566 us)
Uptime: 34 days 12 hours 58 minutes 23 seconds
Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
Last heartbeat 15.43 secs ago
RLIMIT_AS: 1369308160
System image name: n5000-uk9.7.1.0.N1.1a.bin
System image version: 7.1(0)N1(1a) S0
PID: 3453
Exit code: signal 6 (core dumped)
cgroup: 184:devices,memory,cpuacct,cpu:/1
Threads: 3460 3459 3458 3457
CWD: /var/sysmgr/work
RLIMIT_AS: 1369308160
Virtual Memory:
CODE 08048000 - 08A30440
DATA 08A31440 - 08A3EF80
BRK 09474000 - 095AB000
STACK 7FB96EF0
TOTAL 389940 KB
after a config sync commit is issued.
Thu Apr 2 11:52:48 2015:type=update:id=vsh.7381:user=admin:cmd=NTP: commit initiated
Thu Apr 2 11:52:50 2015:type=update:id=vsh.7381 (sp-commit):user=admin:cmd=configure sync ; ntp commit (SUCCESS)
Thu Apr 2 11:52:50 2015:type=stop:id=vsh.7381:user=admin:cmd=
Thu Apr 2 11:52:50 2015:type=update:id=172.16.1.240@pts/0:user=nuh:cmd=configure sync ; switch-profile N5K ; commit (FAILURE)
Conditions:
It appears one of the config changes done "no switchport trunk allowed vlan.." has triggered the crash and there is no memory depletion.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.109), 7.1(1)N1(0.3), 7.1(1)N1(1a) |
|
|
| |
| |
Bug Id: | CSCty07729 |
Title: | perl scripts runn on linux srvr cause kernel panic on n5k |
|
Description: | Symptom:
A Cisco Nexus 5000 switch might unexpectedly fail with kernel panic. This has been known to be seen when a device polls the nexus switch every few minutes. In addition polling the switch frequently could trigger the issue as well.
The root cause is a timing issue internally to the switch.
Conditions:
Nexus 5000 switch being polled from the CLI or via SNMP. The following commands could potentially trigger the kernel panic:
show int trans detail | no-more
show env fan detail
show interface | include "interface reset"
show interface snmp-ifindex
Workaround:
Reducing the polling frequency would reduce the chances of running into this timing issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N1(1) |
|
Known Fixed Releases: | 5.1(3)N2(1a), 5.2(1)N1(1) |
|
|
| |
| |
Bug Id: | CSCus75696 |
Title: | N5K N55-M4Q GEM module port1 and port2 stay down after reboot |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.126), 7.1(2)N1(0.561), 7.1(2)N1(1a), 7.1(2)ZN(0.21), 7.2(1)N1(0.236), 7.2(1)N1(1), 7.2(1)ZN(0.2) |
|
|
| |
| |
Bug Id: | CSCus64364 |
Title: | N5K: carmelusd component got cored on O2 switch |
|
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:
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(6) |
|
Known Fixed Releases: | 7.1(2)N1(0.565), 7.1(2)N1(1a), 7.1(2)ZN(0.25) |
|
|
| |
| |
Bug Id: | CSCuc98585 |
Title: | IPQOS: HIF port goes to 'Internal-Fail errDisable' when added to PoChan |
|
Description: | Symptom:
Not able to add an interface to a previously configured port channel which now does not show any members.
Adding in the new interface will result in the interface state as "(Internal-Fail errDisable)" in show interface ethernetx/y(/z).
An error message will be logged to syslog with the following details:
%ETHPORT-5-IF_SEQ_ERROR: Error ("Object doesn't exist") communicating with MTS_SAP_IPQOS_MGR for opcode MTS_OPC_ETHPM_BUNDLE_MEMBER_BRINGUP (RID_PORT: Ethernet111/1/20) - Ethpm didn't receive a Link UP from the driver on time or had an internal error, check Port Client and Ethpm l
Conditions:
'channel-group' was removed from the phy interface while in the down state (not shut down, nor admin down, but 'no shut' with no link connected). - STILL CONFIRMING
The new and the old interface are of different types. Additionally, the interface is still left in reference to ipqos port-node index (stale data).
The PC Pointer on the ethernet interface will be pointing to the 'pointer' on the port-channel. We can also see that the interface is a member of the port channel when looking at the port-node port-channel output:
- "show system internal ipqos port-node ethernetx/y(/z)"
- "show system internal ipqos port-node port-channel N"
NOTE: If the interface still referenced in the port-node output is in place BUT the show run no longer reflects this AND the new interface and the old interface are of the same type, ipqos port-node for the port-channel will have both interfaces. However, nothing else in the system is using both interfaces. Bringing up the initial interface will result in similar logs noted in the Symptom.
Workaround:
1. Remove the configuration while the interface is still in an up state initially and this problem will never be seen. - STILL CONFIRMING
2. Bring up the initial link into the port-channel that is referenced to with the PC Pointer and remove the 'channel-group' while the interface is still in an up state.
3. Remove the port-channel interface and have the phy point to a different port-channel.
a. Remove any links using it from the running config via
- interface ethernet x/y
- no channel-group N
b. Remove th port-channel
- no interface port-channel N
c. Assign phy to a new port-channel
- interface ethernet x/y
- channel-group N+1 mode [on|active|passive]
d. Check that the PC pointer is now pointing to the new pointer.
- "show system internal ipqos port-node ethernetx/y"
- "show system internal ipqos port-node port-channel N+1"
e. Create port-channel N if you wish again.
A secondary issue which may arise, which is still under investigation, is regarding the link that is introduced to the initial port-channel when the stale data is present. Once it touches the affected port-channel, it is not able to be added to any port-channel that does not have the issue (including PoN from step 3e above). - STILL UNDER INVESTIGATION
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui40707 |
Title: | TACACSd and RADIUSd Writing Uncompressed Cores to var/sysmgr/work |
|
Description: | Symptom:
A Nexus 5K switch may experience high memory utilization as reflected by "show system resources." This can raise several memory-related alarms and could lead to a system crash. In addition, "show system internal flash" will show that the "/var/sysmgr" directory is at or near 100% utility, meaning that the folder is full.
SWITCH# show system internal flash
Mount-on 1K-blocks Used Available Use% Filesystem
/var/sysmgr 1024000 1024000 0 100 none <<<<
The "work" sub-directory will be full of partially-generated core files:
SWITCH# show system internal dir /var/sysmgr/work
...
core.10057 105451520
core.10055 105451520
(etc.)
Additional this issue can also lead to repeated failures in aaa authentication and authorization with both tacacs and radius.
The software change will fix the crashes in tacacsd or radiusd on the Nexus 5000 switch and this will also
solve the authentication errors that some customers are seeing repeatedly.
Conditions:
TACACS or RADIUS is enabled. Core files are generated when TACACS or RADIUS raises an exception while trying to resolve a hostname.
Workaround:
Remove all TACACS or RADIUS configuration and use local authentication.
Note: This workarounds prevent the generation of further core files to "/var/sysmgr/work." To delete existing cores, you can power cycle the switch -- core files are cached to a temporary directory that is reinitialized at power-on. Alternately, contact the TAC to have an engineer manually remove files from the directory during system uptime.
See CSCui52144 "Nexus 5k - Uncompressed Cores Filling Up /var/sysmgr/work ", which has been filed specifically to address an issue where-in core files can use more memory than expected. This is a separate issue from the trigger of the core file itself.
Further Problem Description:
Because there's no obvious indicator as to what process is generating the partially-complete core files, please contact the TAC to validate that these are indeed being generated by the TACACS daemon and that you're hitting the criteria for this bug.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(5) |
|
Known Fixed Releases: | 5.2(1)N1(6), 6.0(2)N3(0.73), 7.0(0)N1(0.73), 7.0(0)N1(1), 7.0(0)ZN(0.79), 7.1(0)N1(0.1), 7.1(0)N1(1), 7.1(0)ZN(0.183) |
|
|
| |
| |
Bug Id: | CSCui28946 |
Title: | Nexus 5596T fails to boot |
|
Description: | Symptom:
A Nexus 5596T switch running NX-OS 5.2(1)N1(5) fails to boot up after a loss of power. No output is seen on console session. This issue is specific to Nexus 5596T model switch and other
Nexus 5xxx switches such as Nexus 5010, 5020, 5548P, 5548UP and 5596UP are NOT affected.
Conditions:
This issue is seen if a Nexus 5596T is upgraded to 5.2(1)N1(5) from an older NX-OS prior to
5.2(1N1(4) and then power-cycled.
Workaround:
Perform an intermediate upgrade of the Nexus 5596T first to NX-OS 5.2(1)N1(4) and then to 5.2(1)N1(5). However, if a 5596T is already in this condition, it cannot be recovered in the field and
needs to be replaced.
Further Problem Description:
If the Nexus 5596T is upgraded directly to 5.2(1)N1(5) from an older release other than 5.2(1)N1(4), the power-sequencer is upgraded to version 3.0 which is causing the problem. If NX-OS is upgraded to 5.2(1)N1(4) first, the power-sequencer version will be at version 2.0 and this problem is not seen.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(5) |
|
Known Fixed Releases: | 6.0(2)N3(0.73), 7.0(0)N1(0.73), 7.0(0)N1(1), 7.0(0)ZN(0.79), 7.1(0)ZN(0.183) |
|
|
| |
| |
Bug Id: | CSCuu34346 |
Title: | vlan down even n5k has active interface |
|
Description: | Symptom:
when customer shutdown a HIF of access vlan 104 port on vpc primary device, vlan 104 was down. But at that moment, PL and other vlan 104 access ports were up, these ports were marked with 'forwarding'.
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut96776 |
Title: | Bidir souced from remote not sent to receiver by LHR |
|
Description: | Symptom:
bidir multicast traffic reaches LHR but not sent to receiver joining with s,g
Conditions:
always
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.174) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu94685 |
Title: | Nexus 5596 upgrade from 5.2.1.N1.6 to 7.1.1.N1.1 cause configure loss |
|
Description: | Symptom:
tacacs+ distribute command cause configure loss after upgrade from 5.2.1.N1.6 to 7.1.1.N1.1
Conditions:
Workaround:
Configure lost configure back
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu07598 |
Title: | Nexus 5548P/N55-M16P : After Upgrade Interface Down & Unrecoverable |
|
Description: | Symptom:
After an upgrade to NX-OS 7.0(6)N1(1) or 7.1(1)N1(1), interfaces on Nexus 5548P and N55-M16P module might go down or start flapping. It could be few days after the upgrade before they can go down or start flapping.
Conditions:
Seen in Nexus Nexus 5548P or 16P Gigabit Ethernet Module N55-M16P after an upgrade to NX-OS 7.0(6)N1(1) or 7.1(1)N1(1). This bug does not apply to Nexus 5548UP, Nexus 6000/5600 or N55-M16UP GEM
Workaround:
Once switch is in this state, it will need to be reloaded to recover. However, after an upgrade or reload, following debug command can be enabled to avoid running into this issue
debug hardware internal carmel dom-thread disable
Note that the command is not saved in NVRAM and needs to be applied on subsequent reloads. An EEM script can be used to automatically configure this after reloads.
event manager applet dom-disable
event syslog pattern "MOD_STATUS_ONLINE"
action 1 cli debug hardware internal carmel dom-thread disable
action 2 syslog priority alerts msg Disabling DOM monitoring
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.272), 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur01470 |
Title: | N5K/6K fails to respond to unicast ARP request and may loop it back |
|
Description: | Symptom:
Unicast ARP requests for HSRP address coming into HSRP active VPC switch over the peer-link does not get responded to by. In certain conditions, the HSRP unicast ARP request can also get looped back on the vPC it came in on causing downstream switches to register a MAC flap.
Conditions:
N5K/6Ks are in VPC topology and HSRP configured on them.
Workaround:
Contact Cisco TAC
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.2(0)N1(0.38) |
|
Known Fixed Releases: | 6.0(2)N2(6.131), 6.0(2)N2(7), 7.0(1)ZN(0.721), 7.0(6)N1(0.223), 7.0(6)N1(1), 7.2(0)N1(0.83), 7.2(0)N1(1), 7.2(0)ZN(0.101), 7.2(0)ZN(0.112), 7.3(0)N1(0.3) |
|
|
| |
| |
Bug Id: | CSCus16847 |
Title: | HIF ports are down after ISSU |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
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.2(0)N1(0.114), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu24709 |
Title: | nfm hap-reset while disabling the feature fabricpath |
|
Description: | Symptom:
NFM - NetflowManager reset on disabling feature fabric path
Conditions:
Disabling feature fabric path while netflow is configured on the vlan interfaces.
Netflow is configured on huge number of interfaces. These intefaces reconfigured under CE.
Workaround:
No workaround exist
Further Problem Description:
Disabling feature fabricpath which causes interfaces to reconfigure under CE is rare and less preferred.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.186) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun67627 |
Title: | LACP Hap Reset while executing "show lacp interface" |
|
Description: | Symptom:
Nexus 5000 switches may experience a LACP HAP Reset while executing CLI "show lacp interface"
SYSMGR-2-SERVICE_CRASHED Service "lacp" (PID xxxx) hasn't caught signal 11 (core will be saved).
SYSMGR-2-HAP_FAILURE_SUP_RESET System reset due to service "lacp" in vdc 1 has had a hap failure
Conditions:
Seen rarely while executing "show lacp interface". Not every instance of execution results in crash.
Workaround:
None, avoid the mentioned CLI for the time being.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(1) |
|
Known Fixed Releases: | 5.2(1)N1(7.121), 5.2(1)N1(8), 6.0(2)N2(4.62), 6.0(2)N2(5), 7.0(1)ZN(0.291), 7.0(3)N1(0.33), 7.0(3)N1(1) |
|
|
| |
| |
Bug Id: | CSCub68098 |
Title: | 1%KERN-3-SYSTEM_MSG: packet_sendmsg: packet size 9250 > MTU 9230 |
|
Description: | Symptom:
When n5k with L3 module is trying to send a packet with size of 9216 , the following is observed in the logs
2012 Jul 24 19:59:14 554up Jul 24 19:59:14 %KERN-3-SYSTEM_MSG: packet_sendmsg: packet size 9250 > MTU 9230 - kernel
The corresponding packet is dropped by the switch and never leaves the switch even though the switch is configured for MTU of 9216 .
Conditions:
Jumbo MTU (9216) configured under System Qos and L3 interface .
Workaround:
Configure the MTU to 9000 for L3 interface .
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N2(1), 6.0(2)N1(1), 6.0(2)N2(0.141), 7.0(0)ZD(0.135), 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo56514 |
Title: | In VPC+ environment, ARP reply may be sourced from SID, rather then ESID |
|
Description: | Symptom:
While running FHRP on FabricPath spine chassis, you may encounter intermittent traffic drops.
This should not affect intra-vlan traffic forwarding.
Conditions:
This issue may happen under next conditions:
*** spine switches are running FHRP;
*** spine switches are running VPC+, thus vIP/vMAC bound to Emulated Switch ID (ESID).
Workaround:
None
Further Problem Description:
Problem happens due to fact, that HSRP active switch, which replies on ARP requests, may source such packets from SID, rather then ESID.
Thus vMAC address on downstream FP switch will be flapping between SID and ESID. In both cases, traffic will be forwarded towards FHRP spine chassis.
But whenever packet destined to the vMAC, forwarded towards spine based on SID, packet will be dropped.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.0(0)N1(1), 7.0(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur63212 |
Title: | FWM hap reset after issu on restoring fcoe mac addresses |
|
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.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(7), 6.0(2)N2(4), 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.120), 7.1(2)N1(0.543), 7.1(2)ZN(0.2), 7.2(0)AB(9), 7.2(0)N1(0.147), 7.2(0)N1(1), 7.2(0)ZN(0.151), 7.3(0)N1(0.25), 7.3(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCun33975 |
Title: | 'ppm' process crashes soon after upgrading N5K |
|
Description: | Symptom:
After upgrading a N5K to a 7.x release, the 'ppm' process may crash soon after the box comes online.
Conditions:
Upgrade is done. The process fails due to memory exhaustion.
Port-security configuration in port profiles applied to port-channels seems to cause this issue. See More-info for sample config.
Workaround:
Upgrade to 6.0(2)N2(4) before upgrading to 7.0 releases
Further Problem Description:
port-profile type port-channel portChanDefaults
switchport port-security violation shutdown
switchport port-security aging type inactivity
switchport port-security aging time 15
state enabled
interface port-channel116
inherit port-profile portChanDefaults
description DM2 etherchannel
switchport access vlan 300
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.0(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(2)N1(0.567), 7.1(2)N1(1a), 7.1(2)ZN(0.27) |
|
|
| |
| |
Bug Id: | CSCut09166 |
Title: | fwm hap reset on vlan delete |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(7) |
|
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) |
|
|
| |
| |
Bug Id: | CSCuj87061 |
Title: | Unified fc interfaces come up as Ethernet after disruptive upgrades |
|
Description: | Symptom:
In Cisco Nexus 5000 series switches, a disruptive upgrade with reason incompatible image causes the Unified Ports configured as FC ports to come up as Ethernet ports after upgrade.
However, the FC port configuration still exists in the running configuration.
Conditions:
Upgrade between any two incompatible images and the fc interfaces are unified interfaces requiring the slot and port commands,
slot z
port x - y mode fc
Workaround:
Proactive:
Do ISSU only between compatible images. Please check the result of install command for image compatibility.
Reactive:
After the disruptive ISSU between incompatible images, do the following:
a. "copy startup-config bootflash:"
b. "copy running-config startup-config"
c. "reload"
After reload:
d. "copy bootflash: running-config
e. "copy running-config startup-config"
Now the device should have the same configurations as before upgrade.
Further Problem Description:
Even without ISSU - on configuration change for Unified Ports using the command "port type fc", the new configuration is displayed immediately in "show running-config".
However, the new configuration is effective only after configuration is saved to startup-config and the switch/module is reloaded.
Now, in this case of Disruptive ISSU with incompatible image, the system reloads with ascii-replay, i.e. all the commands are actually executed line-by-line.
Hence, after reload, the command "port type fc" too is executed by the system and hence this is displayed in "show running-config".
However, this would be effective only after configuration save and reload and hence other configurations for FC interfaces (e.g. "switchport mode F") cannot be effective at this time.
After reload, the FC interfaces become effective, however we need to copy other configurations related to these FC interfaces, which are in earlier saved startup-config.
In case of Disruptive ISSU with other reasons (e.g. "Non-disruptive install not supported if L3 was enabled"), the system is reloaded with binary config and hence do not need to save the config and reload the switch.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.0(3)N2(2a), 5.2(1)N1(6), 6.0(2)N2(1), 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCsv08059 |
Title: | NEXUS 5000 crashes after certain TCP packets |
|
Description: | Multiple Cisco products are affected by denial of service (DoS) vulnerabilities that manipulate the state of Transmission Control
Protocol (TCP) connections. By manipulating the state of a TCP connection, an attacker could force the TCP connection to remain
in a long-lived state, possibly indefinitely. If enough TCP connections are forced into a long-lived or indefinite state, resources on a
system under attack may be consumed, preventing new TCP connections from being accepted. In some cases, a system reboot
may be necessary to recover normal system operation. To exploit these vulnerabilities, an attacker must be able to complete a
TCP three-way handshake with a vulnerable system.
In addition to these vulnerabilities, Cisco Nexus 5000 devices contain a TCP DoS vulnerability that may result in a system crash.
This additional vulnerability was found as a result of testing the TCP state manipulation vulnerabilities.
Cisco has released free software updates for download from the Cisco website that address these vulnerabilities. Workarounds
that mitigate these vulnerabilities are available.
This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20090908-tcp24.shtml.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.0(1a)N1(0.1) |
|
Known Fixed Releases: | 4.0(1a)N1(1) |
|
|
| |
| |
Bug Id: | CSCsu08988 |
Title: | Barc:Telnet access available after reload with "no telnet server enable" |
|
Description: | Problem Description:
With 'no telnet server enable' in running configuration telnet access to the switch is blocked. However when this configuration is saved to startup-config, after a reload the configuration is not taking effect. i.e. Telnet access to the switch is not blocked after a reload.
Workaround: After a reload re-executing the following command blocks telnet access to the switch
switch(config)# no telnet server enable
================= ORIGINAL ==========================
Symptom:
Telnet access is available after reload of Nexus 5020 with "no telnet server enable" running command and telnet service not enabled.
Conditions:
Telnet is only available after a "reload" occurs on the Nexus 5020.
Workaround:
Even you have the "no telnet server enable" command on the running command executing it one more time after the reload fixes this issue. Additionally, filters can be applied to the SVI to only allow trusted hosts to communicate to the system.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.0(0)N1(0.55) |
|
Known Fixed Releases: | 4.0(0)N1(2a) |
|
|
| |
| |
Bug Id: | CSCus35706 |
Title: | VIC 1225 not compatible with Adapter FEX in N5k 5.2(1)N1(8a) |
|
Description: | Symptom:
vNICs/Port profiles disappearing on UCS server, FC aborts in host resulting in datastore disconnects
Conditions:
Adapter FEX using VIC 1225 and N5k on 5.2(1)N1(8a)
Workaround:
At this time, no known workarounds exist that allow the switch to remain on 8a code. In observed behavior, downgrade and reboot switch(es) one additional time to restore service.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(7), 5.2(1)N1(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur91280 |
Title: | N5k mst interop with cat6k: 30 sec convergece after TCN |
|
Description: | Symptom:
+30sec MSTP convergence due to slow MSTP state transition
In MSTP during a proposal handshake, a port in ALT BLK does not send a BPDU with the agreement flag set.
This cause the port on other end to go through blocking and learning states.
Conditions:
Problem is observed every time when there is change in topology.
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(5) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui34757 |
Title: | Nexus 5k acting as an NTP Client does not sync with an NTP server |
|
Description: | Symptom:
Nexus 5k acting as an NTP Client can't sync with any NTP server(s).
when issuing a "show ntp peer-status" or a "show ntp peers" it does not display any of the servers/peers configured.
Conditions:
Nexus 5500/5000 running 5.2(1)N1(5).
Workaround:
Proactive workaround to prevent from this issue is none.
Reactive workaround to recover this issue is below. However, after reloading system, same issue may happen again.
#conf t
#clock protocol none
#clock protocol ntp
#copy run start
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N2(1), 5.2(1)N1(5) |
|
Known Fixed Releases: | 5.2(1)N1(6) |
|
|
| |
| |
Bug Id: | CSCuv07607 |
Title: | N5k/N6k - No login possible to device when root directory is full |
|
Description: | Symptom:
N5k/N6k switches may not be accessible remotely or locally due to no space available in Root directory.
Authentication is unsuccessful both remotely or locally when this happen, even when issue is not with credentials. Following error message may appear on Syslog server:
%DAEMON-3-SYSTEM_MSG: Unable to create temporary user xxxxxxxx. Error 0x404a000a (16777216)
Conditions:
Issue is seen when debugs are enabled without redirecting to a logfile. Debugs thus are automatically redirected to "startupdebug" file which can grow as much as space available in Root directory.
Debugs are currently seen persistent and they still exist post reload and filling up startupdebug file. Once Root directory runs out of space no more login to box is possible.
- "dir log:" CLI could be used to check for startupdebug file
- show debug, would show active debugs running.
Workaround:
Disable debugs and do not run them to eternity.
Use debug logfile <> to redirect logs to a non-system file. This file is limited to 4MB and is overridden once full.
If you hit these symptoms, please check "show debug" to see if debugs are enabled, if yes, then disable them.
Further Problem Description:
It is possible even with debug logfile <> enabled with debugs running, post reload debugs still persist and now written to startupdebug file.
Traffic forwarded through the switch or even control plane is not impacted. Only login to the switch is not possible.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a), 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus72900 |
Title: | Knob to Disbable ports after loop is detected not working as expected |
|
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
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.2(0)N1(0.114), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCut89123 |
Title: | Kernel panic due to "insmod" process |
|
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:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.2(3a)E2, 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCsy99054 |
Title: | Nexus N5k does not support required password complexity |
|
Description: | Symptom:
Nexus 5000 does not allow any non alpha-numeric character to be used in a password per the documentation:
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/sec_rbac.html#wp1258879
Conditions:
Affects all versions.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.0(1a)N1(1) |
|
Known Fixed Releases: | 4.1(3)N2(1) |
|
|
| |
| |
Bug Id: | CSCtf27651 |
Title: | VSH parsing of SED parameters allows linux cli access |
|
Description: |
Symptom:
Devices running Cisco NX-OS may fail to properly sanitize input passed to certain commands via the command line. An authenticated, local attacker
could leverage this issue to execute arbitrary commands on the underlying operating system.
Conditions:
Devices running affected version of NX-OS.
Workaround:
Restrict access to the management consoles of affected device to trusted users only.
Further Problem Description:
This issue was identified during an internal security audit of the Nexus Operating system.
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
6.8/5.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:C/I:C/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2012-4077 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-4077
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.1(3)N1(1a) |
|
Known Fixed Releases: | 4.2(1)N2(1) |
|
|
| |
| |
Bug Id: | CSCut65095 |
Title: | Nexus may reload due to port-profile hap reset |
|
Description: | Symptom:
Nexus may reload due to port-profile hap reset
Conditions:
Workaround:
Do not use config-sync / switch profile
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(2)N1(0.567), 7.1(2)N1(1a), 7.1(2)ZN(0.27) |
|
|
| |
| |
Bug Id: | CSCui07482 |
Title: | N5k - CE VLAN's active on FabricPath Core Port |
|
Description: | Symptom:
CE VLAN's might appear in forwarding list over FabricPath Core ports (Port-channel only) and would inherit L2 Gateway(L2G) STP features. This could lead to blocking of Edge ports for such VLAN's if a better BPDU is received:-
%STP-2-L2GW_BACKBONE_BLOCK: L2 Gateway Backbone port inconsistency blocking port EthernetX/Y on VLANxxxx
Conditions:
Issue is triggered when when we create a port-channel out of member ports already in fabricpath mode, example:-
interface Ethernet1/3-4
switchport mode fabricpath
channel-group 1 mode active >>>> This automatically creates the PO interface if not already created
Then we end up with CE VLAN's forwarded on Fabricpath ports:-
switch# sh vlan id 400
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
400 TEST active Po1, Eth1/3, Eth1/4, Eth1/20
VLAN Type Vlan-mode
---- ----- ----------
400 enet CE
PO1 (member ports 1/3 & 1/4) is FabricPath enabled port and should not be present for CE VLAN
Workaround:
a) delete the port-channel interface(s) in FabricPath mode which is/are seen with CE VLAN's active against them. Then recreate those PO's again in first place and then adding member ports against it:
- no interface port-channel
- Interface port-channel
Switchport mode fabricpath
- Interface eth
Switchport mode fabricpath
Channel-group mode active
b) A reload of the switch would also clear the problem situation. Issue would reappear if a new Port-channel is created as outlined in conditions section. So the best way to avoid the problem is to create PO interface in fabricpath mode and then add members ports to the channel-group.
Further Problem Description:
Following command will help check presence of L2G STP running for CE VLAN's when in broken state:
switch# sh spanning-tree vlan 400
VLAN0400
Spanning tree enabled protocol rstp
Root ID Priority 4496
Address c84c.75fa.6000 >>>>>>
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 4496 (priority 4096 sys-id-ext 400)
Address c84c.75fa.6000 >>>>>>
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth1/20 Desg BKN*2 128.148 P2p *L2GW_Inc >>>> this might not be observed in every case, only when the port received a BPDU with better bridge-ID from the neighbor.
In normal working the CE VLAN would pick on the System MAC (could be local or vPC based on setup) and not L2G STP reserved MAC.
c84c.75fa.60xx (xx is domain ID in hex, default 00) is the reserved L2G STP MAC and it's presence on CE VLAN indicates broken/incorrect state.
For more information around L2G STP:
https://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/operations/farbric_path/602_n1_1/ops_using_fabricpath.html#wp1053091
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(4) |
|
Known Fixed Releases: | 7.0(7)ZN(0.134), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.178), 7.3(0)N1(0.25), 7.3(0)N1(1), 7.3(0)ZN(0.24) |
|
|
| |
| |
Bug Id: | CSCut19714 |
Title: | N2H traffic can drop on a HIF port-channel when another is down |
|
Description: | Symptom:
Servers are dual homed to FEX 2348UPQ and each FEX is single homed to 5548P which is part of Fabric Path (vPC+).
Bringing down a HIF port-channel on the FEX affects another port-channel, which means N2H traffic through the affected port-channel drops.
Conditions:
FEX 2348UPQ is used in the topology described above.
Bringing down a HIF port-channel on the FEX.
Workaround:
shutdown and no shutdown one of FEX fabric ports which are connected to the affected FEX.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a), 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.776), 7.0(6)N1(0.266), 7.0(6)N1(1), 7.1(1)N1(0.495), 7.1(1)N1(1), 7.1(1)ZN(0.48), 7.2(0)AB(9), 7.2(0)N1(0.157), 7.2(0)N1(0.162), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuq81648 |
Title: | N5K: Po configured as fex-fabric does not work as normal VPC trunk port |
|
Description: | Symptom:
On a Nexus 5K switch if we configure ports as a fex-fabric port-channel, and then configure the prots as regular VPC trunk port the links stop passing traffic.
Conditions:
Sequence of events
a) The physical interface needs to be configured as part of a fex-fabric port channel.
b) Configure the port-channel as a regular VPC trunk interface
Workaround:
The workaround is to use a different port-channel interface ID when configuring the VPC trunk port. For example, if you were using port-channel 2 as a fex-fabric interface, and want to use the same physical ports for creating a regular VPC, use port-channel 10.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(8a), 7.0(3)N1(0.99) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur43974 |
Title: | DFA: VLAN Encapsulation error of fabric ports |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.2(0.1)VB(0.1) |
|
Known Fixed Releases: | 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.2(0)N1(0.12), 7.2(0)N1(1), 7.2(0)ZN(0.16) |
|
|
| |
| |
Bug Id: | CSCum07639 |
Title: | N5k: Incorrect Port-Security violation on A/A FEX HIFs after reload |
|
Description: | Symptom:
Port-security violations on a VPC interface after a reload of the primary VPC switch.
Conditions:
This was observed on Nexus 5500 switch with Active/Active FEX and with port-security configured on the FEX host ports. A known trigger is the VPC primary switch reload.
Workaround:
Remove the port-security configuration from the interface(s).
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.2(1)N1(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus89236 |
Title: | Nexus 5672UP unable to ping other side ip after link flap |
|
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:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv05684 |
Title: | documentation needs correction on removing ipv6 additional information . |
|
Description: | Symptom:
documentation needs correction on removing ipv6 additional information .
Conditions:
documentation needs correction on removing ipv6 additional information .
Workaround:
documentation needs correction on removing ipv6 additional information .
Further Problem Description:
documentation needs correction on removing ipv6 additional information .
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.79) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu85368 |
Title: | Kernel Panic on N5K after loop encountered on Mgmt0 vlan. |
|
Description: | Symptom:
Kernel Panic on N5K after loop encountered on Mgmt0 vlan.
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 166039 usecs after Thu Jun 11 10:06:42 2015
Reason: Kernel Panic
Service:
Version: 7.1(1)N1(1a)
NVRAM log reports;-
%$ VDC-1 %$ 10:06:26 %KERN-0-SYSTEM_MSG: [1154557.002505] BUG: soft lockup - CPU#1 stuck for 11s! [usd_mts_kthread:3402] - kernel
Conditions:
Mgmt interface connected via FEX on same switch.
Mgmt ports in the same vlan (default) as the rest of the ethernet ports.
Increased network traffic (e.g. by introducing loop into N5K)
Workaround:
None - Reloading the unit recovers the N5K.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
:
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论