Cisco Blog » The Platform

2015年6月1日星期一

Cisco Notification Alert -Nexus 5000 Series Switch-01-Jun-2015 17:10 GMT

 

 

 

 

 

 

 


Field Notice for Nexus 5000 Series Switches

Title:
Field Notice: FN - 63893 - N55-PAC-1100W PSU Silent Reload Failure
Description:

A particular component failure in N55-PAC-1100W and N55-PAC-1100W-B power supply units (PSUs) can cause the entire N5500 switch to reload.

Date:
21-MAY-2015

Find additional information in Field Notices

Known Bugs - Nexus 5000 Series Switches

Bug Id:
CSCus20646
Title:
N5K crash on CDP process
Description:

Symptom:
N5K crashed without any User activity

Conditions:
Occurs regardless of whether CDP is enabled or disabled.

Workaround:
None

Further Problem Description:

Status:
Fixed
Severity:
2 Severe
Last Modified:
03-MAY-2015
Known Affected Releases:
7.0(5)N1(0.169), 7.0(5)N1(1), 7.0(5)N1(1a)
Known Fixed Releases:
6.1(2)I3(3.113), 6.1(2)I3(4), 7.0(1)ZN(0.774), 7.0(6)N1(0.264), 7.0(6)N1(1), 7.1(1)N1(0.506), 7.1(1)N1(1), 7.1(1)ZN(0.60), 7.2(0)AB(9), 7.2(0)N1(0.137)
Bug Id:
CSCus01406
Title:
Ports part of the secondary private vlan may face connectivity issue
Description:

Symptom:
Some ports part of the secondary isolated vlan may no longer have connectivity with the primary vlan.

Conditions:
Issue seen after upgrad to 6.0(2)N2(5).

Workaround:
Reloading the switch.

Further Problem Description:

Status:
Terminated
Severity:
2 Severe
Last Modified:
04-MAY-2015
Known Affected Releases:
6.0(2)N2(5)
Known Fixed Releases:
Bug Id:
CSCuj26945
Title:
Sensor objects missing entPhysicalTable but exist ciscoEntitySensor
Description:

Symptom:

Nexus 5000/6000/2000 switch can experience a memory leak issue leading to unexpected reload when polling for Transceiver information which is part of ENTITY-SENSOR-MIB.

Conditions:

Nexus 5000/6000/2000 switch enabled for SNMP polling for ENTITY-SENSOR-MIB

Workaround:

Currently SFP Transceiver information is not fully supported in Nexus 5000/6000/2000 switch as part of ENTITY-SENSOR-MIB. With the new release which has the fix, support for polling transceiver information in ENTITY-SENSOR-MIB has been removed. So there will be no issue wrt memory leak being caused due to the polling for SFP information in ENTITY-SENSOR-MIB leading to the unexpected reload. There is no ETA wrt when SFP information will be fully supported in ENTITY-SENSOR-MIB

There is a similar problem seen on nexus 7000 platform. It is tracked by separate CDETS CSCud61263.

Status:
Fixed
Severity:
2 Severe
Last Modified:
04-MAY-2015
Known Affected Releases:
6.0(2)N3(0.225)
Known Fixed Releases:
6.0(2)N2(4.63), 6.0(2)N2(5), 7.0(0)N1(1), 7.0(0)ZN(0.21), 7.0(1)ZN(0.2)
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:
04-MAY-2015
Known Affected Releases:
6.0(2)N2(6)
Known Fixed Releases:
Bug Id:
CSCut39472
Title:
VxLan on 5600 switches may not work with static RP configuration
Description:

Symptom:
VxLan on 5600 may not work with static RP configuration.
NVE peers may not form. Unable to ping hosts over nve overlay.

Conditions:
VxLan VTEP's are configured with static RP

Workaround:
Use auto-rp configuration.

Further Problem Description:

Status:
Open
Severity:
2 Severe
Last Modified:
04-MAY-2015
Known Affected Releases:
7.1(1.23)
Known Fixed Releases:
Bug Id:
CSCto34674
Title:
vPC port-channel towards STP root in blocking state
Description:

Symptom:
In a Nexus 5000/5500 series switch, vPC port-channel towards STP root can go to
STP blocking.

Workaround:
Remove the port-channel using no channel-group, no interface
port-channel x
and reconstruct the port-channel/VPC

This issue is fixed in 5.0(3)N1(1c) and later releases.

Status:
Fixed
Severity:
2 Severe
Last Modified:
05-MAY-2015
Known Affected Releases:
5.0(3)N1(1a), 5.0(3)N1(1b)
Known Fixed Releases:
5.0(3)N1(1c), 5.0(3)N2(1)
Bug Id:
CSCud31738
Title:
After issu upgrade, N5k unable to restore link without FC GEM reload
Description:

Symptoms

Nexus 5K to Nexus 5k or MDS san-port-channel.

The san-port-channel is up and running, after a a ISSU upgrade the san
port-channel does not come up anymore.

On one end we may see the physical FC interface down with following reason:

fc4/15 is down (Error disabled - port reinit limit reached)

The other end is just down and not coming up.

Conditions

Nexus 5K to Nexus 5k or MDS san-port-channel.

Workaround

The workaround is to reload individual GEM modules that have the fc ports
configured on the N5K device. Alternative is to reload the complete N5K. This
issue is not seen if Nexus switch is upgraded disruptively.

Further Problem Description

On the problem switch we can see drops using the following command:

switch# show platform fwm info pif fc x/y | incl drop
fcx/y pd: tx stats: bytes 614284 frames 3733 discard 0 drop 0
fcx/y pd: rx stats: bytes 275440 frames 3527 discard 1 drop 267 <====
fcx/y pd fcoe: tx stats: bytes 614284 frames 3733 discard 0 drop 0
fcx/y pd fcoe: rx stats: bytes 275440 frames 3527 discard 1 drop 267 <===

This FC port can be an individual port or member port of a port channel.



Status:
Open
Severity:
2 Severe
Last Modified:
06-MAY-2015
Known Affected Releases:
5.1(3)N2(1a)
Known Fixed Releases:
Bug Id:
CSCul25239
Title:
N-96: qd hap reset while performing manual swap of 16UPLEM with CR LEM
Description:

Symptom:seeing qd hap reset on Cisco Nexus 6004 switch( N6K-C6004-96Q)
when we do hotswap of the 'Fixed Line-card Expansion Module(LEM) with 16 unified ports' with 'Nexus 6004 Extensible Fixed Chassis Module 12Q 40GE Ethernet/FCoE'.


This is Extra Description
performing hotswap of the Line-card Expansion Module(LEM) is not the recommended way and the issue is not hit in a graceful insertion case(via Online Insertion & Removal(OIR)).
Conditions:software releases which are affected

NXOS release version
6.0(2)N1(2a)
6.0(2)N1(2)
6.0(2)N1(1)
6.0(2)N1(1a)
6.0(2)N2(1)
6.0(2)N2(1b)
6.0(2)N2(6)
6.0(2)N2(5a)

Workaround:There is no workaround








Status:
Fixed
Severity:
2 Severe
Last Modified:
06-MAY-2015
Known Affected Releases:
6.0(2)N3(0.316)
Known Fixed Releases:
6.0(2)N2(6.130), 6.0(2)N2(7), 7.0(1)N1(0.57), 7.0(1)N1(1), 7.0(1)ZN(0.124)
Bug Id:
CSCub38011
Title:
Nexus 5k might boot to bash prompt
Description:

Symptom:
A Nexus 5000/5500 switch which has Fibre Channel(FC) license grace-period expired might boot to
bash
prompt after a reboot/reload/power cycle or a software crash. Following output would be seen on the
console of the switch.

System is coming up ... Please wait ...

System is coming up ... Please wait ...

System is coming up ... Please wait ...

bash-3.2#

Conditions:
Usually seen after a reboot/reload/power cycle or a software crash in a switch which has Fibre
Channel(FC) license grace-period expired.

Workaround:
The switch gets into this state due to process not getting spawned. A write erase and reload
will recover from this state. Contact Cisco TAC if you need assistance.


Status:
Fixed
Severity:
2 Severe
Last Modified:
06-MAY-2015
Known Affected Releases:
5.1(3)N1(1), 6.0(2)N1(0.360)
Known Fixed Releases:
5.1(3)N2(1c), 5.2(1)N1(4), 6.0(2)A1(1), 6.0(2)N1(1), 6.0(2)U1(1)
Bug Id:
CSCug46504
Title:
DHCP Relay does not work when the Bootp flag is set (Broadcast)
Description:

Symptom:
On a Nexus 5000 series switch a dhcp offer might not be forwarded to the client through dhcp relay when the server/client are on different vlans.

Conditions:
For this to happen the broadcast/bootp flag needs to be set in the dhcp discover from the client, which means the server would send a broadcast offer.

Workaround:
None

More Info:

Status:
Fixed
Severity:
2 Severe
Last Modified:
07-MAY-2015
Known Affected Releases:
6.0(2)N1(2)
Known Fixed Releases:
6.0(2)N1(2a), 6.0(2)N2(1)
Bug Id:
CSCuo93689
Title:
Port-profile hap reset after adding new VLANs to port-profile
Description:

Symptom:
After configuring new VLANs and adding them to the trunk allowed range in a port-profile, just after hitting the 'show port-profile' command a message like "System is going to reboot now" is seen and system reloads with the following log messages:

%SYSMGR-2-SERVICE_CRASHED: Service "port-profile" (PID 3627) hasn't caught signal 11 (core will be saved).
%SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "port-profile" in vdc 1 has had a hap failure
%KERN-0-SYSTEM_MSG: [ 2400.621123] Shutdown Ports..
%KERN-0-SYSTEM_MSG: [ 2400.655458] writing reset reason 16, port-profile hap reset

Note: A core dump for port-profile is also generated.

From the output of "show system reset-reason" we can see:

1) At 949507 usecs after Wed May 21 14:41:00 2014
Reason: Reset triggered due to HA policy of Reset
Service: port-profile hap reset
Version: 7.0(1)N1(1)

Conditions:
Seen on a device running 7.0(1)N1(1). The crash can occur after configuring new VLANs and adding them to the trunk allowed range in a port-profile, just after executing the 'show port-profile' command.

Workaround:
N/A

Further Problem Description:

Status:
Fixed
Severity:
2 Severe
Last Modified:
07-MAY-2015
Known Affected Releases:
7.0(1)N1(1)
Known Fixed Releases:
7.0(1)ZN(0.400), 7.0(3)N1(0.93), 7.0(3)N1(1), 7.1(0)FGI(0.6)
Bug Id:
CSCuo15898
Title:
N5K: Unicast packet drops seen on first SSO only with 5.2.1 build
Description:

Symptom:
Only on first sso the issue is seen.

Conditions:
Only on first sso the issue is seen.

Workaround:
1. from second sso onwards the issue is not seen.

OR

2. upgrade the N5K pair to n5000-uk9.7.0.1.N1.1.bin image and issue is not seen there after.

Further Problem Description:
Please refer to big_description attachment.

Status:
Open
Severity:
2 Severe
Last Modified:
07-MAY-2015
Known Affected Releases:
5.2(1)N1(3)
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:
07-MAY-2015
Known Affected Releases:
7.0(0)N1(1), 7.0(1)N1(1)
Known Fixed Releases:
Bug Id:
CSCuo45515
Title:
N5K 5.2 carmelusd crash
Description:

Symptom:
Nexus 5000 crash due to carmelusd hap reset.

Conditions:
This was observed on NX-OS 5.2(1)N1(4). Other releases can be affected as well.

Workaround:

Further Problem Description:
This issue is fixed in 7.0(0)N1(1) and later releases.

Status:
Other
Severity:
2 Severe
Last Modified:
08-MAY-2015
Known Affected Releases:
5.2(1)N1(4)
Known Fixed Releases:
Bug Id:
CSCuo41442
Title:
N5k Disruptive upgrade results in FC interface to load as Ethernet
Description:

Symptom:
After disruptive upgrade all FC interfaces load as Ethernet.
'slot X ; port Y - Y type FC' config is present in running/start-up configuration.

Conditions:
This issue is seen only with N2(1b) not seen with N2(1)
Disruptive upgrade from NX-OS 6.0(2)N2(1b) causes all native FC interfaces to load as Ethernet.
Disruptive downgrade to NX-OS 6.0(2)N2(1b) causes all native FC interfaces to load as Ethernet.

Workaround:
N/A

Further Problem Description:
To recover from this you have to change 'port type' config back to Ethernet then change it back to fc, and perform a switch reload:

Recovery Steps
N5k_Lab(config)# sh run | i slot n 1

slot 1
port 1-48 type fc
slot 2
port 1-16 type fc
slot 3
port 1-16 type fc

N5k_Lab(config)# slot 1 ; port 1-48 type ethernet
Service not responding
N5k_Lab(config-slot)# slot 2 ; port 1-16 type ethernet
N5k_Lab(config-slot)# slot t3 ; port 1-16 type ethernet
N5k_Lab(config-slot)# sh run | i slot n 1

slot 1
port 1-48 type ethernet
slot 2
port 1-16 type ethernet
slot 3
port 1-16 type ethernet

N5k_Lab(config-slot)# slot 1 ; port 1-48 type fc
N5k_Lab(config-slot)# slot 2 ; port 1-16 type fc
N5k_Lab(config-slot)# slot 3 ; port 1-16 type fc
N5k_Lab(config-slot)# sh run | i slot n 1

slot 1
port 1-48 type fc
slot 2
port 1-16 type fc
slot 3
port 1-16 type fc

N5k_Lab(config-slot)# copy run start
N5k_Lab(config-slot)# reload

Status:
Other
Severity:
2 Severe
Last Modified:
08-MAY-2015
Known Affected Releases:
6.0(2)N2(1)
Known Fixed Releases:
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:
08-MAY-2015
Known Affected Releases:
7.1(0)N1(1)
Known Fixed Releases:
Bug Id:
CSCut89123
Title:
Kernel panic due to "insmod" process
Description:

Symptom:
The nexus N5K-C5596UP running 5.2(1)N1(6) can 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:

Workaround:

Further Problem Description:

Status:
Open
Severity:
2 Severe
Last Modified:
11-MAY-2015
Known Affected Releases:
5.2(3a)E2
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:
12-MAY-2015
Known Affected Releases:
5.0(3)N1(1c)
Known Fixed Releases:
5.2(1)N1(4), 6.0(2)N1(2)
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:
12-MAY-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:
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:
12-MAY-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:
CSCuj56227
Title:
IGMP proxy reports may loop on the network
Description:

Symptom:
Proxy leaves and proxy reports looping between peer switches.

Conditions:
Nexus 5000 setup in vPC.

Workaround:
None.

Further Problem Description:
If a switch running affected code is upgraded to a fixed code using non disruptive ISSU, this bug gets carried over to fixed version. A switch reload/power-cycle is required.

Status:
Fixed
Severity:
2 Severe
Last Modified:
14-MAY-2015
Known Affected Releases:
5.2(1)N1(5), 6.0(2)N2(1)
Known Fixed Releases:
5.2(1)N1(6), 6.0(2)N2(3), 6.0(2)U3(0.661), 6.0(2)U3(1), 7.2(0)ZN(0.111)
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:
14-MAY-2015
Known Affected Releases:
7.0(0)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:
15-MAY-2015
Known Affected Releases:
7.1(1)N1(0.494)
Known Fixed Releases:
Bug Id:
CSCuq98902
Title:
First port on N2K-B22HP-P fails on upgrade to 7.0(3)N1(1)
Description:

Symptom:First port on N2K-B22HP-P goes to down state after upgrade of Nexus 5500/5600/6000 parent switch to 7.0(3)N1(1) or 7.0(4)N1(1)
Conditions:N2K-B22HP-P connected to Nexus 5500/5600/6000 parent switch running 7.0(3)N1(1) or 7.0(4)N1(1)
Workaround:None. Upgrade NX-OS to 7.0(5)N1(1) which has the fix
More Info:


Status:
Fixed
Severity:
2 Severe
Last Modified:
15-MAY-2015
Known Affected Releases:
7.0(3)N1(0.1), 7.0(3)N1(0.99)
Known Fixed Releases:
7.0(1)ZN(0.615), 7.0(5)N1(0.173), 7.0(5)N1(1)
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-MAY-2015
Known Affected Releases:
6.0(2)
Known Fixed Releases:
Bug Id:
CSCuq45427
Title:
N5K: Vlan Translation Table gets misprogrammed drop packets
Description:

Symptom:
N5k: Vlan Translation Table gets misprogrammed when we shut the PVLAN HIF port-channel or by reloading the end server.

Conditions:
when your End HIF port on FEX is configured with PVLAN Native vlan and as isolated trunk secondary with Port-channel.

Sample Interface Config:

switchport mode private-vlan trunk secondary
spanning-tree port type edge trunk
switchport private-vlan trunk native vlan 1500
switchport private-vlan trunk allowed vlan 1-3967,4048-4093
switchport private-vlan association trunk 4088 4087

Workaround:
1) Shut / No Shut of the HIF port-channel.
2) Remove the Port-channel Bundle and configure it as standalone ports.
3) Remove the Trunk secondary and re-add it back again on the HIF port-channel.

Further Problem Description:

Status:
Open
Severity:
2 Severe
Last Modified:
18-MAY-2015
Known Affected Releases:
5.2(1)N1(1b)
Known Fixed Releases:
Bug Id:
CSCui47412
Title:
N5596: N5K droppes packets on N2K VPC dual-active with peer-gateway
Description:

Symptom:
- MAC address is learnt on the vPC peer-link intermittently instead of regular vPC link.
- Unicast flooding observed for known MAC addresses on the vPC Operational Secondary switch when MAC address is learnt towards the vPC peer-link.
- Intermittent connectivity issues might be observed as well.

Conditions:
- N5k switch pair running with vPC configuration.
- Trying to reach an unknown destination (no route or no ARP) through the N5k switches.
- vPC peer-gateway feature is enabled.

Workaround:
Disable vPC peer-gateway functionality.

Further Problem Description:

Status:
Other
Severity:
2 Severe
Last Modified:
18-MAY-2015
Known Affected Releases:
5.1(3)N2(1)
Known Fixed Releases:
Bug Id:
CSCut21777
Title:
DHCP Packets flooded to VPC peer with DHCP snooping configuration
Description:

Symptom:
Nexus 56128P in VPC enabled for DHCP snooping would loop the DHCP packets to VPC peer causing mac-flap on down-stream switches and connectivity issue.

Conditions:
1) VPC
2) Peer-switch
3) DHCP Snooping

Workaround:
Disable DHCP snooping

Further Problem Description:

Status:
Fixed
Severity:
2 Severe
Last Modified:
18-MAY-2015
Known Affected Releases:
7.0(1)N1(1), 7.0(4)N1(1)
Known Fixed Releases:
7.1(1)ZN(0.105), 7.1(2)N1(0.527), 7.1(2)N1(1a)
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-MAY-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:
CSCtr37490
Title:
Switch use different bridge ID for STP convergion and BPDU
Description:

Symptom:
Ports should be Altn BLK on the nexus but they are forwarding, that will create a loop.
Ports go to dispute, when there is no physical issue and BPDU are sent and received.
Switch uses differet mac to calculate STP and send BPDUs

Conditions:
Nexus 5000 with an Alternate Blocking port.

Workaround:
Change the STP priority: spanning-tree vlan # priority #

Example:
sw1 Designated forwarding --- alternate block Nexus

If you hit the bug you will see:
sw1 Designated forwarding --- Designated forwarding Nexus

lower the priority on sw1 will workaround the issue.

Solution:

Send BPDU with vpc system mac and calculate bridge ID with physical mac is expected per design.
If vpc peer-switch is configured both will use system MAC.


1.- Short term solution:
STP dispute will block the port to prevent the loop. Rationale being that the vpc topo is "non-blocking" and always select vpc in active links (since vpc provide L2 Multipath).

2.- Need the redundant vpc between to be in "Alternate block" STP state --> Will be the long term fix.

"vpc peer-switch" should be our recommendation.

Status:
Fixed
Severity:
2 Severe
Last Modified:
18-MAY-2015
Known Affected Releases:
5.0(3)N2(1)
Known Fixed Releases:
5.0(3)N2(2)
Bug Id:
CSCur88459
Title:
B22 IBM fex: Temp sensor failures
Description:

Symptom:
Temperature sensor failures reported for a FEX on the switch.
2014 Nov 11 16:50:23 5K %SATCTRL-FEX185-2-SOHMS_ENV_ERROR: FEX-185 Module 1 temperature sensor Outlet-1 failed.
2014 Nov 11 16:50:23 5K %SATCTRL-FEX185-2-SOHMS_ENV_ERROR: FEX-185 Module 1 temperature sensor Inlet-1 failed.
2014 Nov 11 16:50:23 5K %SATCTRL-FEX185-2-SOHMS_ENV_ERROR: FEX-185 Module 1 temperature sensor Inlet-2 failed.
2014 Nov 11 16:50:23 5K %SATCTRL-FEX185-2-SOHMS_ENV_ERROR: FEX-185 Module 1 temperature sensor Die-1 failed
These alarms can be followed with the Fex going offline and never coming back up. In some cases the fex can come back online after sometime.
The duration between the alarms and the fex going offine is not fixed.

Conditions:
Seen on IBM B22 fex only.

Workaround:
None.

Further Problem Description:

Status:
Other
Severity:
2 Severe
Last Modified:
19-MAY-2015
Known Affected Releases:
6.0(2)N2(3), 6.0(2)N2(5)
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

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.

Workaround:
None

Further Problem Description:

Status:
Fixed
Severity:
2 Severe
Last Modified:
19-MAY-2015
Known Affected Releases:
7.2(0.1)VB(0.1)
Known Fixed Releases:
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:
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:
19-MAY-2015
Known Affected Releases:
5.0(3)N2(2b), 5.2(1)N1(3)
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:
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:
19-MAY-2015
Known Affected Releases:
5.2(1)N1(4)
Known Fixed Releases:
7.2(0)N1(1), 7.2(0)ZN(0.178)
Bug Id:
CSCtj94130
Title:
L3 traffic over vPC peer-link is dropped.
Description:

Symptom:

On Nexus 5500 switch running NX-OS 5.0(3) with VPC enabled , Layer 3 unicast
traffic crossing vPC peer-link is getting dropped

Further Problem Description:

On Nexus 5500 switch with Layer 3 module installed and running 5.0(3) , with
VPC enabled, Layer 3 unicast traffic crossing vPC peer-link with
Destination-mac = router-mac (or Virtual router Mac) is getting dropped after
reaching vPC peer. The traffic drop is seen only if we have asymmetric
configuration(such as SVI missing on one switch or SVI admin shut on one
switch) on the Layer 3 SVI interfaces between the two Nexus 5500 VPC peer switches.

With this bug fix, vPC will detect a Type-2 consistency check failure. Having
asymmetric SVI is not supported in any release and the configuration needs to
be made symmetric.

Workaround:

Configure SVI (Layer 3 vlan) symmetrically on both VPC peer switches.

Status:
Fixed
Severity:
2 Severe
Last Modified:
19-MAY-2015
Known Affected Releases:
5.0(3)N1(0.176), 5.0(3)N1(1), 6.0(2)N1(0.352)
Known Fixed Releases:
5.1(3)N1(1)
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:
Open
Severity:
2 Severe
Last Modified:
20-MAY-2015
Known Affected Releases:
7.1(0)N1(1)
Known Fixed Releases:
7.1(1)N1(0.3), 7.1(1)N1(1a)
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:
20-MAY-2015
Known Affected Releases:
5.1(3)N1(1a)
Known Fixed Releases:
5.2(1)N1(7.119), 5.2(1)N1(8)
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:
1 Catastrophic
Last Modified:
20-MAY-2015
Known Affected Releases:
5.2(1)N1(7), 5.2(1)N1(8a)
Known Fixed Releases:
Bug Id:
CSCuo10325
Title:
igmp snooping flooded on stp blocking after stp change
Description:

Symptom:IGMP reports are forwarded to router ports even if the port is in blocking state

Conditions:Can happen if the port was originally in forwarding state and was learnt as a router port. And some change in STP topo causes the router port to go into blocking state. But the port is not removed from IGMP snoopings router port list. So until the router port gets timed out, any report received on this vlan, will be forwarded out of this blocked port as well.

Workaround:Forwarding over blocked ports will stop once the router port gets timed out. If this is not acceptable, then disable IGMP snooping for the problem vlan.

More Info:Note that the fix will not work if upgrading to an image with the fix using ISSU. It will only work if switch is reloaded and booted up with an image that has the fix. If switch is running an image which doesn't have the fix, and is upgraded to an image which has the fix using non-disruptive ISSU, then this fix will not work. If for some reason ISSU is the only way switches can be upgraded, please contact Cisco support to help provide steps which would avoid this IGMP loop issue.

Status:
Fixed
Severity:
2 Severe
Last Modified:
20-MAY-2015
Known Affected Releases:
5.1(3)N2(1a)
Known Fixed Releases:
5.2(1)N1(7.114), 5.2(1)N1(8), 6.0(2)N2(5.94), 6.0(2)N2(6), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(1)ZD(0.254), 7.0(1)ZN(0.511), 7.0(1)ZN(0.523)
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:
20-MAY-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:
CSCun24084
Title:
after ISSU from 6.0(2)N1(2) mac aging time -1 for some vlans
Description:

Symptom:
n5k2# sh mac address-table aging-time
Vlan Aging Time
----- ----------
****SNIP****
999 -1
901 -1
****SNIP****

Conditions:
ISSU from 6.0(2)N1(2):
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 680601 usecs after Wed Feb 19 00:42:32 2014
Reason: Reset due to upgrade
Service:
Version: 6.0(2)N1(2)

Workaround:
reload of the affected switch

or enable eem script to clear mac address table if the unicast mac address table fills up:


event manager applet test
event syslog pattern "FWM-2-STM_LIMIT_REACHED*"
action 1.0 cli clear mac address dynamic

Further Problem Description:

Status:
Terminated
Severity:
2 Severe
Last Modified:
20-MAY-2015
Known Affected Releases:
6.0(2)N2(3)
Known Fixed Releases:
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:
Open
Severity:
2 Severe
Last Modified:
20-MAY-2015
Known Affected Releases:
6.0(2)N2(1)
Known Fixed Releases:
Bug Id:
CSCth42415
Title:
Security issue in OpenSSL
Description:

Summary:
Device may be impacted by the following openssl vulnerabilities:

CVE-2010-0742
CVE-2010-1633

Symptom:

Conditions:

Workaround:
N/A

Further Problem Description:

Status:
Terminated
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
4.0(1a)N2(1)
Known Fixed Releases:
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:
21-MAY-2015
Known Affected Releases:
7.0(6)N1(0.7), 7.1(0)N1(1)
Known Fixed Releases:
Bug Id:
CSCte62753
Title:
Command Injection in admin CLI
Description:

Symptoms:
A vulnerability exists in affected versions of NX-OS which could allow an authenticated local attacker to inject shell commands. A successful exploit
would allow an attacker to gain elevated privileges on the underlying operating system.

Conditions:
Devices running affected versions of NX-OS are vulnerable.

Workaround:
None

Further Problem Description:
This issue was discovered in internal security testing and has been resolved in all current versions of affected software.

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-2011-4235 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
4.0(1a)N2(1), 4.1(3)N2(1a)
Known Fixed Releases:
4.2(1)N1(1)
Bug Id:
CSCta84652
Title:
Misconfigured TACACS+ server crashes the switch
Description:

Symptom:

Switch crashes when receiving malformed TACACS+ packets.

Conditions:

This has been observed on 4.0.1a.N2.1 and previous versions.

Workaround:

None.

Status:
Fixed
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
4.0(1a)N1(0.2), 4.1(3)N1(0.180)
Known Fixed Releases:
4.1(3)N1(1)
Bug Id:
CSCur16747
Title:
satctrl cored after write-erase& applying config with 'FEX-QoS-offload'
Description:

Symptom:
After write erase, reload and applying the config with 'FEX-QoS-offload' satctrl core's and Fex goes offline

Conditions:
Write erase, reload and apply the config with 'FEX-QoS-offload' satctrl core's and Fex goes offline

Workaround:
Reload the switch

Further Problem Description:

Status:
Fixed
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
7.1(0)N1(0.349), 7.2(0)N1(0.100)
Known Fixed Releases:
7.0(6)N1(1), 7.1(1)N1(0.486), 7.1(1)N1(1), 7.1(1)ZN(0.38), 7.2(0)AB(9), 7.2(0)N1(0.134), 7.2(0)N1(0.137), 7.2(0)N1(1), 7.2(0)VZN(0.7), 7.2(0)ZN(0.142)
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:
21-MAY-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:
CSCtk19132
Title:
Nexus reset due to HA policy on multiple CDP process crash
Description:

Symptoms:
A Cisco Nexus 5000 may reset due to a HA policy if the CDP process crashes multiple times

Conditions:
This has been seen when processing a malformed CDP packet

Workaround:
Disable the CDP process

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.1/5:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C

CVE ID CVE-2012-2469 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
1 Catastrophic
Last Modified:
21-MAY-2015
Known Affected Releases:
4.1(3)N2(1a)
Known Fixed Releases:
5.0(2)N2(1)
Bug Id:
CSCut51575
Title:
VPC breaks due to incorrect emulated switch-id after ISSU upgrade
Description:

Symptom:
Emulated switch-id changed to default value(2750) instead of configured one causing network connectivity issue. Software shows the correct switch-id.

Software:
`show vpc`
Legend:
(*) - local vPC is down, forwarding via vPC peer-link

vPC domain id : 150
vPC+ switch id : 2010--------------------------------------------->Correct value
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
vPC fabricpath status : peer is reachable through fabricpath
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : secondary
Number of vPCs configured : 85
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)


`show platform fwm info l2mp myswid`
switch id
-------------------------------------------------------------------
switch id manager
-------------------------------------------------------------------
vpc role: 0
my primary switch id: 1011 (0x3f3)
emu switch id: 2750 (0xabe)--------------------------------???instead of 2010
peer switch id: 1010 (0x3f2)

Conditions:
ISSU upgrade

Workaround:
Remove the switch-id and reconfigure the same.

Conf ter
Vpc domain 150
No fabricpath switch-id 2010
fabricpath switch-id 2010

Further Problem Description:

Status:
Open
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
6.0(2)N2(3)
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:
21-MAY-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:
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:
21-MAY-2015
Known Affected Releases:
7.0(1)N1(1)
Known Fixed Releases:
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)ZN(0.170)
Bug Id:
CSCuq32693
Title:
ISSU causes 'inherit port-profile' CLI to break
Description:

Symptom:ISSU - Non Disruptive from 5.2 to 6.0(2)N2(5) causes CLI 'inhert port-profile' to break. It does not appear to be part of switch profile database and may cause failures to sync up such interfaces.
The same would be observed while upgrading to 7.0(3)N1(1) or later where bug CSCun84134 has been integrated.

Conditions:ISSU - Non Disruptive only. This issue is observed due to fix for bug CSCun84134 not working for Non Disruptive upgrade case properly.

Workaround:Disruptive upgrade does not see this problem. So a forced disruptive upgrade may be performed to avoid hitting this problem.

More Info:


Status:
Fixed
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
6.0(2)N2(5)
Known Fixed Releases:
7.1(0)N1(0.298), 7.1(0)N1(1), 7.1(0)ZN(0.389)
Bug Id:
CSCuq98419
Title:
N5K crash due to kernel panic during ISSU 5.2(1)N1(7)
Description:

Symptom:
Nexus 5K crash due to Kernel panic

Conditions:
This has been seeing on Nexus 5K during ISSU from 5.2(1)N1(4) to 5.2(1)N1(7)

Workaround:
Not known

Further Problem Description:

Status:
Fixed
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
5.2(1)N1(7)
Known Fixed Releases:
5.2(1)N1(8.162), 5.2(1)N1(9), 6.0(2)N2(6.137), 6.0(2)N2(7), 7.0(1)ZN(0.717), 7.0(6)N1(0.219), 7.0(6)N1(1)
Bug Id:
CSCut21098
Title:
N5k switch stuck while upgrading to latest MR5 image
Description:

Symptom:
After ISSU disruptive upgrade N5k switch got stuck. Not able to power on the device

Conditions:
Bios upgrade 3.7.0

Workaround:
No

Further Problem Description:

Status:
Fixed
Severity:
1 Catastrophic
Last Modified:
21-MAY-2015
Known Affected Releases:
7.0(6)N1(0.1)
Known Fixed Releases:
7.0(1)ZN(0.766), 7.0(6)N1(0.259), 7.0(6)N1(1), 7.1(1)N1(0.481), 7.1(1)N1(1), 7.1(1)ZN(0.33), 7.2(0)AB(9), 7.2(0)N1(0.134), 7.2(0)N1(1), 7.2(0)VZN(0.7)
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:
21-MAY-2015
Known Affected Releases:
7.0(5)N1(1)
Known Fixed Releases:
Bug Id:
CSCur08894
Title:
N5k/6k - FP BCAST broken on VPC edge port after root change on VPC+ peer
Description:

Symptom:
ARP Request is no longer flooded outside VPC+ Edge port after Fabricpath topology change.

Conditions:
Powering off the FTAG 1 root which is in the following vpc state: primary, operational secondary

Workaround:
After the reloaded restores the VPC+ edge ports are re-added to the Outgoing Interface List.

Shutdown/ no shutdown of the impacted VPC+ edge ports.

Further Problem Description:

Status:
Fixed
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
7.0(1)N1(1), 7.0(2)N1(1)
Known Fixed Releases:
7.0(1)ZN(0.697), 7.0(6)N1(0.206), 7.0(6)N1(1), 7.1(0)N1(0.1), 7.1(0)N1(0.372), 7.1(0)N1(1), 7.1(0)ZN(0.446), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.2(0)N1(0.2)
Bug Id:
CSCul85203
Title:
N5K Port in Internal-Fail errDisable : fu ha standby message queued
Description:

Symptom:N5k Port connected to N1110X goes to "Internal-Fail errDisable" state if the N1110 Appliance is powered off for HA Testing.

-----
this symptom will also happen when partner device is nexus.


Conditions:Nexus 5000 ( 5548 )
Ver : 6.0(2)N2(1)
Feature LLDP is turned off
Feature FCoE is turn on

Workaround:Turn on LLDP

More Info:


Status:
Open
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
6.0(2)N2(1)
Known Fixed Releases:
Bug Id:
CSCuq27230
Title:
IBM Fex: upgrade cmmuc version to 1.10
Description:

Symptom:
On CMM the bios or cmmuc version will be shown below 1.10 eg 1.09.

Conditions:
Will happen w/ old builds

Workaround(s):
None

Workaround:
None

Further Problem Description:

Status:
Fixed
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
7.1(0)N1(0.272)
Known Fixed Releases:
7.1(0)N1(0.360), 7.1(0)N1(1), 7.1(0)ZN(0.435), 7.1(1)N1(0.37), 7.1(1)N1(1), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.2(0)N1(0.2), 7.2(0)N1(1)
Bug Id:
CSCtx54794
Title:
Specific SNMP GET request causes 'vlan_mgr' to crash on Nexus switches
Description:

Symptoms:
Cisco Nexus 1000v, Nexus 3000, Nexus 5000, and Nexus 7000 devices contain a denial of service vulnerability within the SNMP subsystem. An
authenticated, remote attacker could submit a request to an affected device designed to trigger a null pointer dereference error that results in a crash
and reload of the affected device.

Conditions:
Cisco Nexus 1000v, Nexus 3000, Nexus 5000, and Nexus 7000 devices running an affected version of Cisco NX-OS Software.

Workaround:
None.

Further Problem Description:
None.

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/6.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:N/I:N/A:C/E:F/RL:U/RC:C

CVE ID CVE-2012-4125 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
2 Severe
Last Modified:
21-MAY-2015
Known Affected Releases:
5.0(3)N2(2a)
Known Fixed Releases:
5.1(3)N2(1)
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:
22-MAY-2015
Known Affected Releases:
7.1(1)N1(1)
Known Fixed Releases:
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:
22-MAY-2015
Known Affected Releases:
7.2(0)N1(0.178)
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:
22-MAY-2015
Known Affected Releases:
7.2(0)N1(0.125)
Known Fixed Releases:
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:
22-MAY-2015
Known Affected Releases:
5.1(3)N2(1b)
Known Fixed Releases:
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:
22-MAY-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:
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:
23-MAY-2015
Known Affected Releases:
5.1(3)N1(1)
Known Fixed Releases:
5.1(3)N2(1a), 5.2(1)N1(1)
Bug Id:
CSCue49770
Title:
Modifying config-sync input buffer-db without lock
Description:

Symptom:
CFS lock on one 5k switch in a VPC due to session manager that does not clear

Conditions:
5ks in a VPC running newer 5.2 or 6.0 releases with config sync, a lockout of config-t, config sync and show run

Workaround:
reload the chassis

If the switch is running 6.0 based release, downgrade to 5.2(1)N1(4) or latest 5.2 release to get the fix.

Further Problem Description

There was an older bug for a similar problem

CSCue03528 Session Database / Config Sync / CFS locked on one side without a commit

where few triggers which could have caused the database lock condition are fixed. However there could still be conditions where we can hit the same problem. A final fix for the database lock condition is being implemented via this bug CSCue49770.

The fix for this bug is available in 5.2(1(N1(4) and 6.0(2)N2(3) later releases.

Further Problem Description:

Status:
Fixed
Severity:
2 Severe
Last Modified:
23-MAY-2015
Known Affected Releases:
5.2(1)N1(3)
Known Fixed Releases:
9.9(0)BS(0.13)
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:
23-MAY-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:
CSCut77416
Title:
APRIL 2015 NTPd Vulnerabilities
Description:

Symptom:This product includes a version of ntpd that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:

CVE-2015-1798 and CVE-2015-1799

This bug has been opened to address the potential impact on this product.

Conditions:The configurations that can expose the vulnerability are
ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234
ntp peer 1.2.3.4 key 1

Exposure is configuration dependent

Workaround:Not available
More Info:PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 4.3/3.2

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:P/A:N/E:U/RL:OF/RC:C

The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.

Additional information on Cisco's security vulnerability policy can be found at the following URL:

http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html





Status:
Other
Severity:
2 Severe
Last Modified:
24-MAY-2015
Known Affected Releases:
7.2(0.2)
Known Fixed Releases:
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-MAY-2015
Known Affected Releases:
0.1
Known Fixed Releases:
7.0(0)KM(0.87)
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-MAY-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.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), 7.2(0)BA(0.12)
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:
24-MAY-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:
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:
24-MAY-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.1(1)ZN(0.109), 7.1(2)N1(0.531), 7.1(2)N1(1a), 7.2(1)N1(0.4), 7.2(1)N1(1)
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:
24-MAY-2015
Known Affected Releases:
7.2(0)N1(0.1)
Known Fixed Releases:
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
More Info:

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:
Open
Severity:
2 Severe
Last Modified:
25-MAY-2015
Known Affected Releases:
7.0(0)N1(1)
Known Fixed Releases:
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:
25-MAY-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:
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:
25-MAY-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:
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:
25-MAY-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:
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:
25-MAY-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:
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:
25-MAY-2015
Known Affected Releases:
5.0(2)N2(1), 5.1(3)N2(1)
Known Fixed Releases:
5.0(3)N2(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:
25-MAY-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.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)ZN(0.184)
Bug Id:
CSCty10802
Title:
Cisco Device Manager Command Execution Vulnerability
Description:

Summary
Cisco Device Manager contains a vulnerability that could allow an unauthenticated, remote attacker to execute arbitrary commands on a client host
with the privileges of the user. This vulnerability affects Cisco Device Manager for the Cisco MDS 9000 Family and Cisco Nexus 5000 Series
Switches when it is installed or launched via the Java Network Launch Protocol (JNLP) on a host running Microsoft Windows.

Cisco Device Manager installed or launched from Cisco Prime Data Center Network Manager (DCNM) or Cisco Fabric Manager is not affected. This
vulnerability can only be exploited if the JNLP file is executed on systems running Microsoft Windows. The vulnerability affects the
confidentiality, integrity, and availability of the client host performing the installation or execution of Cisco Device Manager via JNLP file.
There is no impact on the Cisco MDS 9000 Family or Cisco Nexus 5000 Series Switches.

Cisco has released free software updates that address this vulnerability in the Cisco Device Manager for Cisco MDS 9000 Family Switches. Cisco
Nexus 5000 Series Switches have discontinued the support of the Cisco Device Manager installation via JNLP and updates are not available.

Workarounds that mitigate this vulnerability are available. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130424-fmdm

Status:
Terminated
Severity:
2 Severe
Last Modified:
25-MAY-2015
Known Affected Releases:
5.1(3)N1(0.357)
Known Fixed Releases:
Bug Id:
CSCus04851
Title:
N5k/6k -FP BCAST/MCAST broken on VPC edge ports after remote root change
Description:

Symptom:
If there is a root change in FP topology, broadcast/multicast on edge ports of VPC+ Nexus 5K/6K can be affected even though there were no local changes.

Conditions:
FP root change in the core part of the FP network

Workaround:
Shut/no shut the affected edge port on the VPC+ N5K/6K

Further Problem Description:

Status:
Fixed
Severity:
2 Severe
Last Modified:
25-MAY-2015
Known Affected Releases:
7.0(1)N1(1), 7.0(2)N1(1), 7.0(5)N1(1), 7.1(0)N1(1)
Known Fixed Releases:
6.0(2)N2(6.134), 6.0(2)N2(7), 7.0(1)ZN(0.728), 7.0(6)N1(0.228), 7.0(6)N1(0.6), 7.0(6)N1(1), 7.1(1)N1(0.468), 7.1(1)N1(0.78), 7.1(1)N1(1), 7.1(1)ZN(0.20)
Bug Id:
CSCug54317
Title:
N5k: Port-profile crash after configuring trunk allowed vlan <long list>
Description:

<B>Symptom:</B>
Port-profile crash on Nexus 5000 switch after configuring the switchport trunk allowed vlan
command under an interface range with a large vlan list as argument.

<B>Conditions:</B>
- This is seen on 6.0(2)N1(1) release.
- "switchport trunk allowed vlan" command applied under more than interface, and
having a large vlan list

<B>Workaround:</B>
Split the vlan list and apply them using multiple switchport trunk allowed vlan commands

Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via normal
resolution channels.

If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.

Additional information on Cisco's security vulnerability policy can be found at the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
2 Severe
Last Modified:
25-MAY-2015
Known Affected Releases:
5.2(1)N1(3), 5.2(1)N1(6), 6.0(2)N1(1), 6.0(2)N1(2), 6.0(2)N1(2a)
Known Fixed Releases:
5.2(1)N1(7.100), 5.2(1)N1(8), 6.0(2)N2(1)
Bug Id:
CSCtu10594
Title:
CDP with long address crashes process
Description:

Summary

Cisco Nexus, Cisco Unified Computing Systemn (UCS), Cisco MDS 9000 Series Multilayer Switches, and Cisco 1000 Series Connected Grid Routers
(CGR) are all based on the Cisco NX-OS operating system. These products are affected by one or more of the following vulnerabilities:

* Multiple Cisco Discovery Protocol Vulnerabilities in Cisco NX-OS-Based Products
* Cisco NX-OS Software SNMP and License Manager Buffer Overflow Vulnerability
* Cisco NX-OS Software SNMP Buffer Overflow Vulnerability
* Cisco NX-OS Software Jumbo Packet Denial of Service Vulnerability

Cisco has released free software updates that address these vulnerabilities.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130424-nxosmulti

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/6.4:
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:OF/RC:C

CVE ID CVE-2013-1181 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
5.0(3)N2(2)
Known Fixed Releases:
5.1(3)N1(1)
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:
26-MAY-2015
Known Affected Releases:
4.0(1a)N1(0.1)
Known Fixed Releases:
4.0(1a)N1(1)
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:
26-MAY-2015
Known Affected Releases:
7.2(0)N1(0.192)
Known Fixed Releases:
Bug Id:
CSCta72709
Title:
Disabling IGMP snooping causes flood to all FEX port with trunk on FEX
Description:

Symptom:

On Cisco Nexus 5000 Series switches with a Cisco Nexus 2000 Series Fabric Extenders (FEX) installed,
unregistered IP multicast packets on one VLAN are forwarded to other VLANs where IGMP snooping is disabled.

Conditions:

1. The Cisco Nexus 5000 Series has a Nexus 2000 FEX installed.

2. There are multiple VLANs configured on the Nexus 2000 FEX.

3. IGMP snooping is disabled on the VLAN where the traffic is forwarded to.

Affects the following Nexus Products with the Cisco Nexus 2000 FEX installed:
* Cisco Nexus 5548P Switch prior to integration of Cisco Bug ID CSCtk03738.
* Cisco Nexus 5020 Switch for all versions. Currently no plan to address in 5020 platforms.
* Cisco Nexus 5010 Switch for all versions. Currently no plan to address in 5010 platforms.

Workaround:

Serveral potential workarounds exist for this vulnerability:

* Static IGMP entries

Enable IGMP snooping, then use static IGMP entries to add multicast receiver to the switch MAC table if
the host is unable to send IGMP group membership report.

* Single VLAN per FEX

Ensuring that trunking is disabled for the FEX uplink port and have a single VLAN assigned to the FEX.

* Upgrade end host applications

Upgrade host application to support IGMP protocol so it can automatically send IGMP join/leave report
without static configuration on the switch.

PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS
scores as of the time of evaluation are 3.3/3.1:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C

CVE ID CVE-2011-0397 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Terminated
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
4.1(3)N1(0.185)
Known Fixed Releases:
Bug Id:
CSCtu10550
Title:
CDP missing number of addresses check
Description:

Summary

Cisco Nexus, Cisco Unified Computing Systemn (UCS), Cisco MDS 9000 Series Multilayer Switches, and Cisco 1000 Series Connected Grid Routers
(CGR) are all based on the Cisco NX-OS operating system. These products are affected by one or more of the following vulnerabilities:

* Multiple Cisco Discovery Protocol Vulnerabilities in Cisco NX-OS-Based Products
* Cisco NX-OS Software SNMP and License Manager Buffer Overflow Vulnerability
* Cisco NX-OS Software SNMP Buffer Overflow Vulnerability
* Cisco NX-OS Software Jumbo Packet Denial of Service Vulnerability

Cisco has released free software updates that address these vulnerabilities.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130424-nxosmulti

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/6.4:
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:OF/RC:C

CVE ID CVE-2013-1181 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
5.0(3)N2(2)
Known Fixed Releases:
5.1(3)N1(1)
Bug Id:
CSCto09813
Title:
N5k: Remark in a ACL before a deny leaks traffic
Description:

Summary
A vulnerability exists in Cisco Nexus 5000 and 3000 Series Switches that may allow traffic to bypass deny statements in access control lists
(ACLs) that are configured on the device.

Cisco has released free software updates that address this vulnerability.

A workaround is available to mitigate this vulnerability.

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110907-nexus.shtml

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 5/4.1:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:N/A:N/E:F/RL:OF/RC:C

CVE ID CVE-2011-2581 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
5.0(3)N1(1a)
Known Fixed Releases:
5.0(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:
26-MAY-2015
Known Affected Releases:
4.1(3)N1(1a)
Known Fixed Releases:
4.2(1)N2(1)
Bug Id:
CSCte90364
Title:
File System Access
Description:

Symptoms:
A vulnerability exists in NX-OS which allows an authenticated, local attacker to read or write arbitrary files in volatile storage. A successful exploit could
allow the attacker to gain unauthorized access to sensitive files on the device, or to overwrite arbitrary files in volatile storage.

Conditions:
Devices running affected versions of NX-OS are vulnerable.

Workaround:
None

Further Problem Description:
This issue was discovered in internal security testing and has been resolved in all current versions of affected software.

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
5.2/4.3:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:C/I:P/A:N/E:F/RL:OF/RC:C

CVE ID CVE-2011-4490 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
4.1(3)N2(1a)
Known Fixed Releases:
Bug Id:
CSCtf27780
Title:
VSH parsing of pipe 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-4076 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-4076

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:
26-MAY-2015
Known Affected Releases:
4.0(1a)N2(1)
Known Fixed Releases:
4.2(1)N2(1)
Bug Id:
CSCtr58428
Title:
Command Injection vulnerability with the | section command
Description:

Symptom:
Cisco Nexus OS contains a vulnerability that could allow an authenticated,
local attacker to execute arbitrary commands on a targeted device. The
vulnerability is due to improper sanitization of user-supplied values to
command line interface commands.

An authenticated, local attacker could exploit the vulnerability by issuing
commands that contain malicious options on the device command line interface.
If successful, the attacker could gain elevated privileges on the targeted device.

Conditions:Injection can be done via either the less or the section sub command. Full
details below:

----------------------------------------------------------------------
NX-OS - "less" sub-command - Command injection / sanitization issues.
----------------------------------------------------------------------

Affected Products:
==================

The following products are affected by this vulnerability:

+-----------------------------------------------------------------+
| Affected Product | Cisco Bug | First Fixed |
| | ID | Release |
|-----------------------------------+------------+----------------|
| Cisco Nexus 7000 Series Switches | CSCtf40008 | 4.2(6) |
| | | 5.1(1) |
|-----------------------------------+------------+----------------|
| Cisco Nexus 5000 Series Switches | CSCtf40008 | 4.2(1)N2(1) |
|-----------------------------------+------------+----------------|
| Cisco Nexus 2000 Series Switches | CSCtf40008 | 4.1(1)N2(1) |
|-----------------------------------+------------+----------------|
| Cisco Nexus 1000V Series Switches | CSCtf40008 | 4.2(1)SV1(5.1) |
|-----------------------------------+------------+----------------|
| Cisco MDS 9000 Software | CSCtf40008 | 4.2(6) |
| | | 5.1(1) |
|-----------------------------------+------------+----------------|
| Cisco Unified Computing System | CSCtg18363 | 1.3(1c) |
| | | 1.4(1i) |
+-----------------------------------------------------------------+

The following are not affecfed by the "less" sub-command - command injection
vulnerability.

* Cisco Nexus 3000 Series Switches
* Cisco Nexus 4000 Series Switches

-------------------------------------------------------------------------
NX-OS - "section" sub-command - Command injection / sanitization issues.
-------------------------------------------------------------------------

Affected Products:
==================

The following products are affected by this vulnerability:

+--------------------------------------------------------------+
| Affected Product | Cisco Bug | First Fixed |
| | ID | Release |
|-----------------------------------+------------+-------------|
| Cisco Nexus 7000 Series Switches | CSCtr44645 | 5.2(1) |
|-----------------------------------+------------+-------------|
| Cisco Nexus 5000 Series Switches | CSCtr44645 | 5.1(3)N1(1) |
|-----------------------------------+------------+-------------|
| Cisco Nexus 3000 Series Switches | CSCts10188

Status:
Other
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
5.0(3)N1(1)
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:
26-MAY-2015
Known Affected Releases:
7.2(0)N1(0.144)
Known Fixed Releases:
Bug Id:
CSCtj62291
Title:
Nexus 5000: switch reloaded upon [show vlan]
Description:

Symptom:

When an authenticated user issues the 'show vlan' command on the cli, the Nexus
5000 may crash and reload.


Conditions:

This issue may occur when more than 1000 VLANs and Virtual Ethernet Ports
(VETH) have been configured on a device running affected software.

Workaround:

None.


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 4.6/4.0:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:N/I:N/A:C/E:H/RL:O/RC:C

CVE ID CVE-2011-0370 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at
the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
4.2(1)N2(1)
Known Fixed Releases:
4.0(4)SV1(3c), 4.2(1)N2(1b), 4.2(7.96)S0, 5.0(2)N1(1), 5.0(5)S9, 5.0(6.7)S0, 5.1(1.57)S0
Bug Id:
CSCsv08325
Title:
TCP connections may get stuck in any state after ESTAB indefinitely
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:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
4.0(1a)N1(0.1), 4.0(1a)N2(0.1)
Known Fixed Releases:
4.0(1a)N2(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:
26-MAY-2015
Known Affected Releases:
4.0(0)N1(0.55)
Known Fixed Releases:
4.0(0)N1(2a)
Bug Id:
CSCug26811
Title:
Kernel Panic, process hap reset caused by excessive traffic on mgmt port
Description:

Symptom:
Cisco Nexus 5000/5500 series chassis may reload due to Kernel panic a process crash. The messages similar to the following may indicate that the
device has been affected by this issue.

sh system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 756622 usecs after Tue Feb 26 13:56:55 2013
Reason: Reset triggered due to HA policy of Reset
Service: ethpc hap reset
Version: 5.2(1)N1(3)
2) At 654893 usecs after Tue Feb 26 13:45:28 2013
Reason: Reset triggered due to HA policy of Reset
Service: fwm hap reset
Version: 5.2(1)N1(3)
3) At 193086 usecs after Tue Feb 26 13:01:33 2013
Reason: Kernel Panic
Service:
Version: 5.2(1)N1(3)
4) At 679325 usecs after Thu May 28 11:19:45 2009
Reason: Reset due to upgrade
Service:
Version: 5.2(1)N1(2a)

Conditions:
Cisco Nexus 5000/5500 series devices running a version of NX-OS software prior to 5.2(1)N1(6) or 6.0(2)N2(2) are affected.

The issue occurs when excessive traffic is destined to the Out of Band management interface (mgm0).

Workaround:
Management interfaces can be configured with RACL's that allow access from the Network Management Station only.

Affected devices that are connected to FEX via the management port, can disable 'cfs ipv4 distribute' and reload the switch. This will disable multi-cast
on the port and may help mitigate some situations that can cause this issue to occur.

More Info:
The issue is known to have been triggered by Spanning Tree Protocol loops that occur on upstream switches. STP traffic in excess of 200mb/second
may be required for the issue to appear.

Status:
Fixed
Severity:
1 Catastrophic
Last Modified:
26-MAY-2015
Known Affected Releases:
5.2(1)N1(3)
Known Fixed Releases:
5.2(1)N1(6), 6.0(2)N2(2), 7.0(0)N1(1)
Bug Id:
CSCtu10605
Title:
CDP with long protocol crashes process
Description:

Summary

Cisco Nexus, Cisco Unified Computing Systemn (UCS), Cisco MDS 9000 Series Multilayer Switches, and Cisco 1000 Series Connected Grid Routers
(CGR) are all based on the Cisco NX-OS operating system. These products are affected by one or more of the following vulnerabilities:

* Multiple Cisco Discovery Protocol Vulnerabilities in Cisco NX-OS-Based Products
* Cisco NX-OS Software SNMP and License Manager Buffer Overflow Vulnerability
* Cisco NX-OS Software SNMP Buffer Overflow Vulnerability
* Cisco NX-OS Software Jumbo Packet Denial of Service Vulnerability

Cisco has released free software updates that address these vulnerabilities.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130424-nxosmulti

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/6.4:
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:OF/RC:C

CVE ID CVE-2013-1181 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
5.0(3)N2(2)
Known Fixed Releases:
5.1(3)N1(1)
Bug Id:
CSCtf81847
Title:
OpenSSL Record of death Issue
Description:

Symptom:
The device may be affected by an OpenSSL vulnerability.

This vulnerability is tracked as CVE-2010-0740

In TLS connections, certain incorrectly formatted records can cause an OpenSSL
client or server to crash due to a read attempt at NULL.

Conditions:
Device configured with any feature that uses SSL.

Workaround:
Not available

Further Problem Description:

Status:
Terminated
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
4.0(1a)N2(1)
Known Fixed Releases:
Bug Id:
CSCtr10164
Title:
N5K - ospfv2 memory leak when receiving specific malformed packets
Description:

Symptoms:
OSPF process leaks memory when receiving specially-crafted packet

Conditions:
This issue may occur when the switch processes a malformed packet.

Workaround:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2011-2539 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
5.0(3)N2(1)
Known Fixed Releases:
5.0(3)N2(2)
Bug Id:
CSCtx54790
Title:
Specific SNMP GET request causes 'pfm' service to crash on Nexus 5K
Description:

Symptoms:
Cisco Nexus 5000 devices contain a denial of service vulnerability within the SNMP subsystem. This vulnerability could allow an authenticated,
remote attacker to crash the device by submitting a malformed SNMP request to a specific MIB.

Conditions:
Cisco Nexus 5000 devices running an affected version of Cisco NX-OS Software.

Workaround:
None.

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
6.8/6.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:N/I:N/A:C/E:F/RL:U/RC:C

CVE ID CVE-2012-4124 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
5.0(3)N2(2a)
Known Fixed Releases:
5.2(1)N1(5), 6.0(2)N2(1)
Bug Id:
CSCte87709
Title:
CDP with the long hostname crashes Nexus 5k
Description:

Symptom:
The mgmt port is connected to other switch with CDP enabled. When N5k receives the first CDP packet, it crashes. When N5k comes back up and
receives another CDP packet, it crashes again. It happens repeatedly.

Conditions:
It happens when the remote switches or routers with CDP enabled has the extraordinary LONG hostname.

Workaround:
Disable CDP under the interface of the remote device where the mgmt port is connected to.

Further Problem Description:
None.

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.1/6.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2011-0360 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
4.1(3)N2(1a)
Known Fixed Releases:
4.2(1)N1(1)
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-MAY-2015
Known Affected Releases:
6.0(2)N2(3), 7.2(0)N1(0.192)
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:
26-MAY-2015
Known Affected Releases:
5.1(3)N2(1), 7.1(1)N1(1)
Known Fixed Releases:
Bug Id:
CSCts56672
Title:
Read-only user can create and overwrite files
Description:



Symptom:

Cisco Nexus devices contain an input validation vulnerability. This issue could allow a local, authenticated attacker to create or overwrite arbitrary files
on the device. This issue affects all user account types including Read-Only users.

This issue affects Nexus 7000 series and Nexus 5000 series devices.



Conditions:

Devices running an affected version of NX-OS Software.



Workaround:

Restrict access to trusted users only.



Further Problem Description:

This issue was identified during an internal security audit of Cisco Nexus devices.

PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are
4.6/3.8:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:N/I:C/A:N/E:F/RL:OF/RC:C

CVE ID CVE-2012-4122 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-4122

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:
26-MAY-2015
Known Affected Releases:
5.0(3)N2(1)
Known Fixed Releases:
5.1(3)N2(1)
Bug Id:
CSCtu10555
Title:
CDP with long sysobj crashes process
Description:

Summary

Cisco Nexus, Cisco Unified Computing Systemn (UCS), Cisco MDS 9000 Series Multilayer Switches, and Cisco 1000 Series Connected Grid Routers
(CGR) are all based on the Cisco NX-OS operating system. These products are affected by one or more of the following vulnerabilities:

* Multiple Cisco Discovery Protocol Vulnerabilities in Cisco NX-OS-Based Products
* Cisco NX-OS Software SNMP and License Manager Buffer Overflow Vulnerability
* Cisco NX-OS Software SNMP Buffer Overflow Vulnerability
* Cisco NX-OS Software Jumbo Packet Denial of Service Vulnerability

Cisco has released free software updates that address these vulnerabilities.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130424-nxosmulti

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/6.4:
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:OF/RC:C

CVE ID CVE-2013-1181 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
5.0(3)N2(2)
Known Fixed Releases:
Bug Id:
CSCts46521
Title:
crash in igmp process @ igmp_snoop_orib_fill_source_update
Description:

Symptom:

Cisco Nexus 5000 switches may experience a device reload after receiving certain IGMP packets. Successful exploitation may cause a reload of the
affected device. Repeated exploitation could result in a sustained denial of service (DoS) condition.

Conditions:
Cisco Nexus 5000 configured with IGMP snooping. An attacker needs to be Layer 2 adjacent in order to trigger this vulnerability.

Workaround:
IGMP can be disabled as a workaround if not needed.

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.1/5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C

CVE ID CVE-2012-1357 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
5.0(3)N2(1)
Known Fixed Releases:
5.1(3)N1(1), 7.2(0)ZN(0.111)
Bug Id:
CSCts35605
Title:
Security Issue in Apache
Description:

Summary
A denial of service vulnerability has been found in the way the multiple overlapping ranges are handled by the Apache HTTPD server. Multiple Cisco products could be affected by this vulnerability.

Mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Intelligence companion document for this Advisory: http://tools.cisco.com/security/center/viewAMBAlert.x?alertId=24024

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110830-apache.shtml.

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.8:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:H/RL:U/RC:C

CVE ID CVE-2011-3192 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Status:
Terminated
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
9.4(1)N1(6.8)
Known Fixed Releases:
Bug Id:
CSCts10593
Title:
N5k kernel panic caused by jumbo packet hitting the mgmt interface
Description:

Summary

Cisco Nexus, Cisco Unified Computing System (UCS), Cisco MDS 9000 Series Multilayer Switches, and Cisco 1000 Series Connected Grid Routers (CGR) are all based on the Cisco NX-OS operating system. These products are affected by one or more of the following vulnerabilities:

* Multiple Cisco Discovery Protocol Vulnerabilities in Cisco NX-OS-Based Products
* Cisco NX-OS Software SNMP and License Manager Buffer Overflow Vulnerability
* Cisco NX-OS Software SNMP Buffer Overflow Vulnerability
* Cisco NX-OS Software Jumbo Packet Denial of Service Vulnerability

Cisco has released free software updates that address these vulnerabilities.

This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130424-nxosmulti

Status:
Fixed
Severity:
2 Severe
Last Modified:
26-MAY-2015
Known Affected Releases:
5.0(3)N2(1)
Known Fixed Releases:
5.0(3)N2(2)
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:
26-MAY-2015
Known Affected Releases:
4.0(1a)N1(1)
Known Fixed Releases:
4.1(3)N2(1)
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:
26-MAY-2015
Known Affected Releases:
7.2(0)N1(0.134)
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:
26-MAY-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.1(2)N1(1a)
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:
26-MAY-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:
CSCut86729
Title:
vPC Multicast optimization doesn't work after disable/enable the CLI
Description:

Symptom:
Multicast traffic flows through the MCT link (vpc peer-link) even though VPC Multicast optimization is enabled using CLI "no ip igmp snooping mrouter vpc peer-link".

Conditions:
VPC Multicast optimization is enabled using CLI -
"no ip igmp snooping mrouter vpc peer-link"

Workaround:
If vPc multicast optimization is required such that multicast traffic doesn't traverse MCT link and if this issue is observed in the network, enabling the command by configuring "ip igmp snooping mrouter vpc peer-link" and disabling the command after some time by using "no ip igmp snooping mrouter vpc peer-link" will work.

Further Problem Description:
Enabling Multicast optimisation through CLI doesn't take effect in a scale setup. No issue is seen if we do not enable VPC Multicast optimization. It is disabled by default.

Status:
Open
Severity:
2 Severe
Last Modified:
27-MAY-2015
Known Affected Releases:
7.2(0)N1(0.163)
Known Fixed Releases:
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:
27-MAY-2015
Known Affected Releases:
7.0(5)N1(1)
Known Fixed Releases:
7.1(1)ZN(0.113), 7.1(2)N1(0.534), 7.1(2)N1(1a), 7.2(0)N1(0.183), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.185)
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:
27-MAY-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:
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:
27-MAY-2015
Known Affected Releases:
5.2(1)N1(4), 5.2(1)N1(6)
Known Fixed Releases:
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:
27-MAY-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:
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:
27-MAY-2015
Known Affected Releases:
5.1(3)N2(1a), 6.0(2)N2(4)
Known Fixed Releases:
7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.2(0)BA(0.12), 7.2(0)D1(0.467), 7.2(0)N1(0.160), 7.2(0)N1(1), 7.2(0)PDB(0.401), 7.2(0)VZD(0.26), 7.2(0)VZN(0.34), 7.2(0)ZD(0.146)
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:
27-MAY-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:
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:
27-MAY-2015
Known Affected Releases:
7.0(5)N1(1)
Known Fixed Releases:
7.1(1)ZN(0.99), 7.1(2)N1(0.523), 7.1(2)N1(1a), 7.2(0)N1(0.191), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.193)
Bug Id:
CSCul30680
Title:
N5k restart due to monitor process crash when a VLAN is added/removed
Description:

Symptom:
A Nexus 5000 Series switch may reload unexpectedly due to a crash in the 'monitor' service. Last reset reason will be recorded as 'monitor hap reset'.

2014 May 10 10:06:35.637 N5K %$ VDC-1 %$ SYSMGR-2-SERVICE_CRASHED Service "monitor" (PID 3717) hasn't caught signal 11 (core will be saved).
2014 May 10 10:06:35.643 N5K %$ VDC-1 %$ SYSMGR-2-HAP_FAILURE_SUP_RESET System reset due to service "monitor" in vdc 1 has had a hap failure
2014 May 10 10:06:43.815 N5K %$ VDC-1 %$ 10 10:06:43 KERN-0-SYSTEM_MSG Shutdown Ports.. - kernel
2014 May 10 10:06:43.849 N5K %$ VDC-1 %$ 10 10:06:43 KERN-0-SYSTEM_MSG writing reset reason 16, monitor hap reset - kernel



Last reset at 798270 usecs after Sat May 10 10:06:43 2014

Reason: Reset triggered due to HA policy of Reset
System version: 5.2(1)N1(6)
Service: monitor hap reset

Conditions:
At least one SPAN session must be configured.

The crash is more likely to occur with a configuration containing a large number of non-consecutive VLANs.

A potential trigger for this crash is the addition or removal of a VLAN. However, it has also been seen to occur with no specific trigger.

Workaround:
Disable SPAN on the switch.

Further Problem Description:

Status:
Fixed
Severity:
1 Catastrophic
Last Modified:
27-MAY-2015
Known Affected Releases:
5.2(1)N1(4)
Known Fixed Releases:
5.2(1)N1(6.94), 5.2(1)N1(7), 6.0(2)N2(5.84), 6.0(2)N2(6), 7.0(1)ZN(0.340)
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:
27-MAY-2015
Known Affected Releases:
5.2(1)N1(8a), 7.0(3)N1(0.99)
Known Fixed Releases:
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:
28-MAY-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:
CSCuu50142
Title:
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:
Open
Severity:
2 Severe
Last Modified:
28-MAY-2015
Known Affected Releases:
7.0(3)N1(0.28), 7.2(1)N1(0.5)
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:
28-MAY-2015
Known Affected Releases:
7.2(0)N1(0.174)
Known Fixed Releases:
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:
28-MAY-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:
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:
28-MAY-2015
Known Affected Releases:
7.2(0)N1(0.144)
Known Fixed Releases:
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:
Open
Severity:
2 Severe
Last Modified:
28-MAY-2015
Known Affected Releases:
7.0(5)N1(1)
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:
28-MAY-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:
CSCuq13396
Title:
Nexus 5500 ethpc hap reset - SYSMGR_DEATH_REASON_FAILURE_HEARTBEAT
Description:

Symptom:
N5k undergoes ETHPC hap reset/crash running 6.0(2)N2(3) and later releases.
Reason: Reset triggered due to HA policy of Reset
Service: ethpc hap reset

Conditions:
Exactly not known, however collection of DOM statistics via CLI "show interface transceiver [detail]" may result in such a crash. Though crashes have been observed in instances where such CLI was not issued.

Workaround:
None so far.

Further Problem Description:
In addition to the 6.x releases, this ethpc crash has also been seen in 7.0(2)N1(1).

The defensive fix was added already as part of 7.0(3)N1(1) so this issue should not be seen with this release

Status:
Fixed
Severity:
2 Severe
Last Modified:
28-MAY-2015
Known Affected Releases:
6.0(2)N2(3)
Known Fixed Releases:
6.0(2)A6(0.74), 6.0(2)A6(1), 6.0(2)N2(5.98), 6.0(2)N2(6), 6.0(2)U6(0.74), 6.0(2)U6(1)
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:
29-MAY-2015
Known Affected Releases:
5.2(1)N1(6)
Known Fixed Releases:
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:
29-MAY-2015
Known Affected Releases:
5.1(3)N1(1)
Known Fixed Releases:
Bug Id:
CSCus80303
Title:
ethpc hap reset - SYSMGR_DEATH_REASON_FAILURE_HEARTBEAT
Description:

Symptom:
N5k undergoes ETHPC hap reset/crash running 6.0(2)N2(6)
Reason: Reset triggered due to HA policy of Reset
Service: ethpc hap reset

Conditions:
Exactly not known, however collection of DOM statistics via CLI "show interface transceiver [detail]" may result in such a crash.

Workaround:
none

Further Problem Description:

Status:
Open
Severity:
2 Severe
Last Modified:
29-MAY-2015
Known Affected Releases:
6.0(2)N2(6)
Known Fixed Releases:
Bug Id:
CSCug49968
Title:
Nexus 5K/6K: Memory leak in LACP process leading up to switch reset
Description:

Symptom:LACP process crashes. This ends up causing a HAP Reset that reloads the system.

Conditions:Memory leak on the VPC peer everytime a portchannel member goes down on local switch.

Based on the Total memory being held in the output of the 'show processes log detail' output, the LACP process appears to have leaked until the RLIMIT was reached:

Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
Last heartbeat 6.32 secs ago
RLIMIT_AS: 122024320 <--------- Max memory in bytes the LACP can hold before it crashes.

Virtual Memory:

CODE 08048000 - 08165A14
DATA 08166A14 - 08168068
BRK 082B7000 - 0BF2D000
STACK BFC47E40
TOTAL 119120 KB <----------- Total memory consumed.

Workaround:None

More Info:Memory leak can be tracked with following command.

Nexus5548# show lacp internal mem-stats detail | inc libutils
97 [r-xp]/isan/plugin/0/isan/lib/libutils. 273645 273645 7114650 7114650

If utilization is above 20M for libutils, a switch can be considered at risk for LACP hap reset.

Status:
Fixed
Severity:
2 Severe
Last Modified:
29-MAY-2015
Known Affected Releases:
5.2(1)N1(5), 5.2(1)N1(6), 5.2(1)N1(7), 6.0(2)N2(0.88)
Known Fixed Releases:
5.2(1)N1(8), 6.0(2)N2(1), 6.0(2)N2(3), 7.0(0)N1(1)
Bug Id:
CSCut21440
Title:
B22 IBM fex: CMM IP flap messages
Description:

Symptom:
CMM module displays IP flap messages randomly-
Text: IO Module 01- I/O module 1 IP address was changed to 192.168.3.165
by the I/O module.
Text: IO Module 01- I/O module 1 IP address was changed to 192.168.3.166
by the I/O module.

Module 1 and 2 are fex modules and the the IPs they are referencing are
n5k mgmt0 IP.

Conditions:
Issue seen on IBM bladechassis that has b22 fexes

Workaround:
Please engage TAC for further debugging

Further Problem Description:

Status:
Terminated
Severity:
2 Severe
Last Modified:
29-MAY-2015
Known Affected Releases:
6.0(2)N2(3), 6.0(2)N2(5)
Known Fixed Releases:
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:
Open
Severity:
2 Severe
Last Modified:
29-MAY-2015
Known Affected Releases:
6.0(2)N2(2)
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-MAY-2015
Known Affected Releases:
7.0(6)N1(0.272), 7.1(1)N1(1)
Known Fixed Releases:
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-MAY-2015
Known Affected Releases:
7.0(2)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:
29-MAY-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:
CSCuq00161
Title:
Verizon CoPP: Nexus 5600 Support for CB-QOS MIB
Description:

Symptom:
Verizon operational standard requires CB-QOS MIB (or equivalent visibility) before allowing the device to be deployed.

Conditions:

Workaround:

Further Problem Description:
Committed changes to support phase 1 of CB QoS MIB, as listed in the FS. Second phase support in later release

Status:
Fixed
Severity:
2 Severe
Last Modified:
29-MAY-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.1(0)AV(0.38), 7.1(0)ES(0.7), 7.1(0)SIB(99.92), 7.1(1)N1(0.454), 7.1(1)N1(0.455), 7.1(1)N1(0.50), 7.1(1)N1(0.51), 7.1(1)N1(0.52)
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:
Open
Severity:
2 Severe
Last Modified:
29-MAY-2015
Known Affected Releases:
7.0(3)N1(0.28), 7.2(1)N1(0.5)
Known Fixed Releases:
7.1(1)ZN(0.114), 7.1(2)N1(0.535), 7.1(2)N1(1a), 7.2(1)N1(0.11), 7.2(1)N1(1)
Bug Id:
CSCuj36520
Title:
Nexus: reload due to PIM process crash
Description:

Symptom:
A Nexus device may reload. Last reload reason is seen as "pim hap reset":

N6K# show system reset-reason

----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 62610 usecs after Mon Dec 9 16:35:07 2013
Reason: Reset triggered due to HA policy of Reset
Service: pim hap reset
Version: 6.0(2)N2(2)

Conditions:
PIM is configured. The crash occurs when a particular timing condition is encountered during the processing of PIM Join and Prune messages.

Workaround:
None known at this time.

Further Problem Description:
This defect tracks this issue on the Nexus 5000 and 6000 only. The issue can also affect the N7K and platform-independent (PI) code. The fix for this issue in the N7K/PI case is tracked in CSCun27512.

Status:
Fixed
Severity:
2 Severe
Last Modified:
29-MAY-2015
Known Affected Releases:
6.0(2)N2(3)
Known Fixed Releases:
5.2(1)N1(7.103), 5.2(1)N1(8), 6.0(2)A4(0.813), 6.0(2)A4(0.825), 6.0(2)A4(1), 6.0(2)N2(3.57), 6.0(2)N2(4), 6.0(2)U4(0.813), 6.0(2)U4(0.825), 6.0(2)U4(1)
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:
29-MAY-2015
Known Affected Releases:
5.1(3)N2(1)
Known Fixed Releases:
5.1(3)N2(1b)
Bug Id:
CSCuu59941
Title:
FC ports error disabled with non-Cisco SFPs after ISSU to 7.0(5)N1(1)
Description:

Symptom:
FC ports with non-Cisco SFPs are error disabled after ISSU from 5.2 to 7.0(5)N1(1) .

Conditions:
Occurs after upgrade via ISSU to 7.0(5)N1(1) when using SFPs that are not Cisco branded.

Workaround:
No workaround at 7.0(5)N1(1) . service unsupported-transceiver command does not allow these ports to function.
Downgrade back to original version of NX-OS.

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:
Open
Severity:
2 Severe
Last Modified:
30-MAY-2015
Known Affected Releases:
7.0(5)N1(1)
Known Fixed Releases:
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:
30-MAY-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:
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:
31-MAY-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:
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:
31-MAY-2015
Known Affected Releases:
5.2(1)N1(7), 6.0(2)N2(4), 7.0(5)N1(1)
Known Fixed Releases:
7.2(0)AB(9), 7.2(0)N1(0.147), 7.2(0)N1(1), 7.2(0)ZN(0.151)
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:
31-MAY-2015
Known Affected Releases:
6.0(2)N2(5)
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:
31-MAY-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:
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:
31-MAY-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:
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:
31-MAY-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)

Find additional information in Bug Search index.

 

2013 Cisco and/or its affiliates. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks

 

没有评论:

发表评论