| |
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) |
|
|
| |
没有评论:
发表评论