| |
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: | 01-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N1(1) |
|
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: | 01-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)ZN(0.113), 7.1(2)N1(0.534), 7.2(0)N1(0.183), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.185), 7.3(0)N1(0.25), 7.3(0)N1(1), 7.3(0)ZN(0.24) |
|
|
| |
| |
Bug Id: | 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: | 01-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N2(2a) |
|
Known Fixed Releases: | 5.2(1)N1(5), 6.0(2)N2(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: | 01-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N2(2a) |
|
Known Fixed Releases: | 5.1(3)N2(1) |
|
|
| |
| |
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: | 01-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N2(1) |
|
Known Fixed Releases: | 5.1(3)N2(1) |
|
|
| |
| |
Bug Id: | CSCtr70847 |
Title: | DHCP packet drop "udp_input: Mismatch in mbuf len (46) and IP len (32)" |
|
Description: | Symptom:
When DHCP relay feature is configured we can see the following message and a DHCP packet is dropped:
N5k-2# 2011 Jun 16 01:51:56 N5k-2 %NETSTACK-2-MISMATCH_LEN:
netstack [4617] udp_input: Mismatch in mbuf len (46) and IP len (32)
Conditions:
Nexus 5548 with L3 daughter board running 5.0(3)N1(1c).
Workaround:
No known workaround.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N1(1c) |
|
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: | 01-JUL-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: | CSCut39249 |
Title: | n5k vpc - only local multicast source hashing to DR gets registered |
|
Description: | Symptom:
a nexus 5500 with VPC running 7.0(5)N1(1) will only register traffic that hashes to the DR switch. traffic that hashes to the other switch will generate a S,G but will not be registered with the RP>
Conditions:
must be running VPC and acting as First hop router
Workaround:
no workaround at this time
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtx66087 |
Title: | CDP crashes when receiving malformed packet |
|
Description: | Symptoms:
Cisco Nexus 1000, 3000, 4000, 5000, and 7000 switches as well as Cisco Unified Computing System Fabric Interconnect devices may restart after receiving malformed Cisco Discovery Protocol (CDP) Packets. An adjacent attacker, with the ability to submit malformed CDP traffic to an affected device could cause a denial of service condition while the device reloads or fails over to a redundant Supervisor card if so equipped.
Conditions:
Cisco Nexus Switches running an affected version of NX-OS.
Cisco Unified Computing System, Fabric Interconnect devices running an affected version of UCS Software.
Workaround:
Disable CDP on the affecte device, the CDP protocol is enabled by default.
NX-OS:
no cdp enable
UCS:
Add the 'disable cdp' command to all Network Control Policies
Further Problem Description:
This issue was identified through internal hardening efforts on the NX-OS platform.
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-1322 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: | 01-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N2(2) |
|
Known Fixed Releases: | 5.1(3)N2(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: | 01-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N1(1a) |
|
Known Fixed Releases: | 5.0(3)N2(1) |
|
|
| |
| |
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: | 01-JUL-2015 |
|
Known Affected Releases: | 9.4(1)N1(6.8) |
|
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: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(1b) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 01-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N1(0.357) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc19558 |
Title: | RADIUS insufficient attribute length check |
|
Description: | Symptom:
Cisco NXOS contains a vulnerability in the RADIUS authentication code.
Conditions:
Malformed packets are returned from a RADIUS authentication server.
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-2012-6377 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
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(1) |
|
Known Fixed Releases: | 6.0(2)N2(4.63), 6.0(2)N2(5) |
|
|
| |
| |
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: | 01-JUL-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: | CSCuc54112 |
Title: | DHCP broadcast packets flood/loop with FP enabled |
|
Description: | Symptom:
DHCP Broadcast packets might be looped in a FP network with "ip dhcp snooping" enabled. This will cause a flood of DHCP packets within the network . Due to this packet would be sent to CPU so spike might be observed. Also COPP violations might be observed
Conditions:
DHCP snooping enabled globally on FP leaf/edge .
Workaround:
Disable ip dhcp snooping
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: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(1) |
|
Known Fixed Releases: | 5.2(1)N1(6), 6.0(2)N2(1) |
|
|
| |
| |
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: | 01-JUL-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: | CSCto23248 |
Title: | DHCP offer pkts doesnt get fwded to vpc peer if dst ip is peer's SVI ip |
|
Description: | Symptom:
dhcp relay will drop dhcp reply frames.
Conditions:
When arp entry for peer-gateway doesn't exist, DHCP offer packets destined to peer-gateway's SVI will get dropped by the switch
Workaround:
1) have a static arp entry for peer gateway's SVI IP.
2) ping SVI IP to get dynamic arp resolution for the IP.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N2(0.150) |
|
Known Fixed Releases: | 5.0(3)N2(1) |
|
|
| |
| |
Bug Id: | CSCuv08345 |
Title: | Cisco Nexus 5000 Vulnerability cmd injection via DHCP offer options |
|
Description: | Symptom:
Command injection via DHCP offer options used with PowerOn Auto Provisioning (POAP)
Conditions:
NX-OS Switch would have to be in a state where POAP is initiated, and if
an attacker can either:
A) Inject their own DHCP server and respond to the POAP DHCP request with
crafted DHCP options.
B) Compromise an existing DHCP server, and craft the specific DHCP
options.
Then during the POAP process, when the crafted DHCP options are processed
arbitrary commands on the system could be executed in the context of root
user.
Note this issue only occurs during the POAP DHCP boot process.
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.8:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:H/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C
CVE ID CVE-2015-0658 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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 7.3(0.2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus80042 |
Title: | EMC-ENTRANCE:FWM core during ISSU. |
|
Description: | Symptom:
FWM core during ISSU
Conditions:
ISSU from 7.0(5)N1(1a) to 7.1(0)N1(1a)
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut92605 |
Title: | "port-profile hap reset" after switch-profile commit |
|
Description: | Symptom:
Switch crashes with a signal 6:
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 428034 usecs after Thu Apr 2 11:53:45 2015
Reason: Reset triggered due to HA policy of Reset
Service: port-profile hap reset
Version: 7.1(0)N1(1a)
2) At 536528 usecs after Thu Feb 26 22:52:10 2015
Reason: Disruptive upgrade
Service:
Version: 6.0(2)N2(5)
`show processes log details`
Service: port-profile
Description: Port Profile Manager
Executable: /isan/bin/ppm
Started at Thu Feb 26 22:55:08 2015 (260301 us)
Stopped at Thu Apr 2 11:53:31 2015 (168566 us)
Uptime: 34 days 12 hours 58 minutes 23 seconds
Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
Last heartbeat 15.43 secs ago
RLIMIT_AS: 1369308160
System image name: n5000-uk9.7.1.0.N1.1a.bin
System image version: 7.1(0)N1(1a) S0
PID: 3453
Exit code: signal 6 (core dumped)
cgroup: 184:devices,memory,cpuacct,cpu:/1
Threads: 3460 3459 3458 3457
CWD: /var/sysmgr/work
RLIMIT_AS: 1369308160
Virtual Memory:
CODE 08048000 - 08A30440
DATA 08A31440 - 08A3EF80
BRK 09474000 - 095AB000
STACK 7FB96EF0
TOTAL 389940 KB
after a config sync commit is issued.
Thu Apr 2 11:52:48 2015:type=update:id=vsh.7381:user=admin:cmd=NTP: commit initiated
Thu Apr 2 11:52:50 2015:type=update:id=vsh.7381 (sp-commit):user=admin:cmd=configure sync ; ntp commit (SUCCESS)
Thu Apr 2 11:52:50 2015:type=stop:id=vsh.7381:user=admin:cmd=
Thu Apr 2 11:52:50 2015:type=update:id=172.16.1.240@pts/0:user=nuh:cmd=configure sync ; switch-profile N5K ; commit (FAILURE)
Conditions:
It appears one of the config changes done "no switchport trunk allowed vlan.." has triggered the crash and there is no memory depletion.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.109), 7.1(1)N1(0.3), 7.1(1)N1(1a), 7.1(2)N1(0.568), 7.1(2)ZN(0.28), 7.2(1)N1(0.239), 7.2(1)N1(1), 7.2(1)ZN(0.5) |
|
|
| |
| |
Bug Id: | CSCuc37274 |
Title: | Device crashes at ARP service crash @arp_adj_timer_callback |
|
Description: | Symptom:
Device crashes on Arp service on vPC Secondary Switch.
Conditions:
Arp enabled on device.
Workaround:
There is no known workaround at this time
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N2(2) |
|
Known Fixed Releases: | 5.1(3)N1 |
|
|
| |
| |
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: | 06-JUL-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: | 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: | 07-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N2(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui12905 |
Title: | Nexus 5K Switch Crashes While Zoning Through DCNM |
|
Description: | Symptom:
Nexus 5k switch crashes during zone reconfiguration:
ZONE-2-ZS_MERGE_FAILED VSAN X Zone merge failure, isolating interface fcx/x reason: Zoning object mismatch:[reason:0]
ZONE-2-ZS_MERGE_FAILED VSAN X Zone merge failure, isolating interface fcx/x reason: Zoneset name mismatch:[reason:0]
SYSMGR-2-SERVICE_CRASHED Service "zone" (PID XXXXhasn't caught signal 11 (core will be saved).
Conditions:
Zones being reconfigured in DCNM.
Workaround:
None known.
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N1(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu85368 |
Title: | Kernel Panic on N5K after loop encountered on Mgmt0 vlan. |
|
Description: | Symptom:
Kernel Panic on N5K after loop encountered on Mgmt0 vlan.
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 166039 usecs after Thu Jun 11 10:06:42 2015
Reason: Kernel Panic
Service:
Version: 7.1(1)N1(1a)
NVRAM log reports;-
%$ VDC-1 %$ 10:06:26 %KERN-0-SYSTEM_MSG: [1154557.002505] BUG: soft lockup - CPU#1 stuck for 11s! [usd_mts_kthread:3402] - kernel
Conditions:
Mgmt interface connected via FEX on same switch.
Mgmt ports in the same vlan (default) as the rest of the ethernet ports.
Increased network traffic (e.g. by introducing loop into N5K)
Workaround:
None - Reloading the unit recovers the N5K.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtn99355 |
Title: | N5k: crash in port-profile |
|
Description: | Symptom:
Nexus 5xxx switch will crash in the PID "port-profile"
Conditions:
This bug is due to a slow memory leak caused by scripts/users collecting
show run output.
Workaround:
Stop scripts from collecting show run. This memory can be monitored with
command show system internal port-profile mem-stats det | inc ppm_cmd_t.
If PPM_MEM_ppm_cmd_t is close to 250MB Max, the switch is at risk and
can be reloaded in a controlled maintenance window.
Further Description
Use the command "show core" to validate/verify existence of core file. Copy
core file out and open TAC case.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 5.0(2)N2(1) |
|
Known Fixed Releases: | 5.0(3)N2(1), 9.9(0)BS(0.13) |
|
|
| |
| |
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: | Other |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.174) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj85007 |
Title: | vPC+: After Reload FEX MAC is not Synced Resulting in Traffic Black-Hole |
|
Description: | Symptom:
MAC address entries may not be synced or experience delay to be synced to the peer switch which causes traffic to be black-holed until the entries are synced.
Conditions:
This can occur for both spine and leaf switches in a FabricPath deployment running vPC+ NIF or HIF interfaces:
- For Nexus 5500/6000 (when switch is reloaded)
- For Nexus 7000 (when switch is resuming from reload)
Workaround:
For the Nexus 7000 running a release prior to 6.2(8), contact TAC for an EEM script to prevent this issue. Fabric-path link-up delay is enabled by default 6.2(8) and later on the Nexus 7000.
For the Nexus 5500/6000, increase the link-up delay from the default of 10 seconds:
fabricpath timers linkup-delay 60 (should be increased based on time it takes for all FEX to come online)
Further Problem Description:
In an environment running 6.2(x) on the Nexus 7000, 7.0(x) on the Nexus 5500/6000, and later on all FabricPath devices, it is recommended in addition to modifying the link-up timers, to configure IS-IS overload bit on start-up:
fabricpath domain default
set-overload-bit on-startup 300 (should be increased based on time it takes for all FEX to come online)
This will prevent the device from being used for transit FabricPath traffic until the timer expires.
CSCud25862 is for a similar issue relating to unknown unicast flooding being black-holed.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 6.0(2) |
|
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: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 7.1(1)N1(0.494) |
|
Known Fixed Releases: | 7.1(2)N1(0.563), 7.1(2)ZN(0.23), 7.3(0)N1(0.30), 7.3(0)N1(1), 7.3(0)ZN(0.33) |
|
|
| |
| |
Bug Id: | CSCus75696 |
Title: | N5K N55-M4Q GEM module port1 and port2 stay down after reboot |
|
Description: | Symptom:
N5K N55-M4Q GEM module port1 and port2 connected on 2 N5K's back to back show "not connected" after reboot, also ports will go into "LinkFlapErrdisable" if manually flapped 3 times.
Conditions:
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.126), 7.1(2)N1(0.561), 7.1(2)ZN(0.21), 7.2(1)N1(0.236), 7.2(1)N1(1), 7.2(1)ZN(0.2) |
|
|
| |
| |
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: | 09-JUL-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: | CSCun54561 |
Title: | Zone hap reset |
|
Description: | --
Symptom:
Cisco Nexus5548 reset due to Zone Hap reset running version 6.0(2)N2(2)
The behavior occurs while activating a zoneset with atleast 2 zones associated with it.
Conditions:
Running version 6.0(2)N2(2).
This bug was seen while trying to activate a zoneset with atleast 2 zones associated with it.
Workaround:
None
Further Problem Description:
--
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(2), 7.0(1)N1(1) |
|
Known Fixed Releases: | 6.0(2)N2(4.64), 6.0(2)N2(5), 7.0(1)ZN(0.502), 7.0(4)N1(0.135), 7.0(4)N1(1), 7.1(0)N1(0.289), 7.1(0)N1(1), 7.1(0)ZN(0.382) |
|
|
| |
| |
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: | 09-JUL-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(4)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)ZN(0.105), 7.1(2)N1(0.527), 7.2(1)N1(0.246), 7.2(1)N1(1), 7.2(1)ZN(0.12) |
|
|
| |
| |
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: | Other |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCts72469 |
Title: | FEX Power Supply showing absent |
|
Description: | Symptom:
Power Supply #2 of an Active-Active FEX is showing absent when displaying on
Nexus 5k CLI. Power Supply is installed but not recognized by nexus 5K CLI.
Conditions:
Usually seen on vPC secondary switch after the switches have been ISSU
upgraded(non-disruptive upgrade).
Workaround:
There is no operational impact due to this bug and this is more of a display
issue. Reload of FEX in question using reload fex command will clear
this display issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N2(1) |
|
Known Fixed Releases: | 5.0(3)N2(2a), 5.1(3)N1(1) |
|
|
| |
| |
Bug Id: | CSCub46846 |
Title: | N5K Physical Replacement caused fex link flapping with pre-provision |
|
Description: | Symptom:
Active/Active FEX interfaces connected to vPC pair of Nexus 5000 switches can flap during Nexus 5000 replacement even with FEX
pre-provisioned.
Conditions:
Seen during Nexus 5000 switch replacement.
Workaround:
None. This issue is resolved in NX-OS 5.2(1)N1(2)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N2(1a) |
|
Known Fixed Releases: | 5.2(1)N1(2) |
|
|
| |
| |
Bug Id: | CSCun33975 |
Title: | 'ppm' process crashes soon after upgrading N5K |
|
Description: | Symptom:
After upgrading a N5K to a 7.x release, the 'ppm' process may crash soon after the box comes online.
Conditions:
Upgrade is done. The process fails due to memory exhaustion.
Port-security configuration in port profiles applied to port-channels seems to cause this issue. See More-info for sample config.
Workaround:
Upgrade to 6.0(2)N2(4) before upgrading to 7.0 releases
Further Problem Description:
port-profile type port-channel portChanDefaults
switchport port-security violation shutdown
switchport port-security aging type inactivity
switchport port-security aging time 15
state enabled
interface port-channel116
inherit port-profile portChanDefaults
description DM2 etherchannel
switchport access vlan 300
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUL-2015 |
|
Known Affected Releases: | 7.0(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(2)N1(0.567), 7.1(2)ZN(0.27), 7.2(1)N1(0.242), 7.2(1)N1(1), 7.2(1)ZN(0.8) |
|
|
| |
| |
Bug Id: | CSCut65095 |
Title: | Nexus may reload due to port-profile hap reset |
|
Description: | Symptom:
Nexus may reload due to port-profile hap reset
Conditions:
Workaround:
Do not use config-sync / switch profile
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(2)N1(0.567), 7.1(2)ZN(0.27), 7.2(1)N1(0.241), 7.2(1)N1(1), 7.2(1)ZN(0.7) |
|
|
| |
| |
Bug Id: | CSCus39830 |
Title: | After disruptive ISSU 7.1(0)N1(1) to 7.1(0)N1(1a) primary vpc hapreset |
|
Description: | Symptom:
After ISSU (disruptive or non-disruptive) from 7.1(0)N1(1) to 7.1(0)N1(1a) vpc primary is crashing with vpc hap reset
Conditions:
Both primary and secondary should be in 7.1(0)N1(1) image.ISSU done
on primary to 7.1(0)N1(1a) , while secondary is still in ISSU 7.1(0)N1(1) CCO image.
Workaround:
Issue should not be seen when both vpc primary and secondary are upgraded
simultaneously.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.435) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCty68548 |
Title: | NIV:veth number is conflicting on secondary switch after veth deletion |
|
Description: | Symptom:
Vethernet Interface goes into an error disabled state when being brought up
An error similar to the following is also seen in the logs although the FEX may not be dual homed:
"%VIM-5-VETH_NUMBER_CONFILCT: Interface VethernetNNN is down because the veth number is different from the veth on primary switch"
Conditions:
Deleting Veth interfaces
Workaround:
Reboot the switch
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(0.87) |
|
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: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.0(0)N1(1), 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.0(2)N1(0.4), 7.0(2)N1(1a), 7.0(7)N1(0.69), 7.0(7)N1(1), 7.0(7)ZN(0.147), 7.1(2)N1(0.576), 7.1(2)N1(1a), 7.1(2)ZN(0.37), 7.2(1)N1(0.246), 7.2(1)N1(1) |
|
|
| |
| |
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: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-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: | CSCuu98583 |
Title: | TACACS asserted in 'move_old_entries_from_local_cache' switch reloads |
|
Description: | Configuring maximum tacacs groups and servers in each group results in switch reload . This will ideally not be done
Symptom:
Upon maximum groups and maximum servers per group configured. In which case there is a crash upon change in configuration
Conditions:
Configure maximum Tacacs groups and maximum servers in all those groups
Workaround:
No workarounds available. Partial fix for cache was already available in baseline, This fix updated the canonical name size that was in-correct.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.2(1)N1(0.26) |
|
Known Fixed Releases: | 7.0(7)ZN(0.131), 7.1(2)N1(0.567), 7.1(2)ZN(0.27), 7.2(1)N1(0.235), 7.2(1)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu23296 |
Title: | securityd process is not intializing signalling flags |
|
Description: | Failure to boot system due to sigaction flag not set for security daemon when Address Space Layout Randomization (ASLR) enabled
Symptom:
Failure to boot system dur to security daemon reload when ASLR is enabled
Conditions:
sigaction not set correctly. Hence when ASLR is enabled there will be failure to boot.
Applicable only when ASLR is enabled
Workaround:
None: Needs to be recompiled with sigaction flag initilize
But note: When ASLR is enabled this update would already be part of it.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.272), 7.2(0)N1(0.124) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)ZN(0.113), 7.1(2)N1(0.534), 7.2(1)N1(0.10), 7.2(1)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu94699 |
Title: | Nexus 5596 upgrade from 5.2.1.N1.6 to 7.1.1.N1.1 cause FEX config loss |
|
Description: | Symptom:
upgrade Nexus 5596 from 5.2.1.N1.6 to 7.1.1.N1.1 cause FEX config loss
Conditions:
the pair of 5596 was not upgraded at the same time. So There was a version mismatch of the FEXs.
Workaround:
configure lost FEX commands back
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus89236 |
Title: | Nexus 5672UP unable to ping other side ip after link flap |
|
Description: | Symptom:
When Nexus 5672UP connected to any catalyst switch using 1gig link, it is unable to ping opposite side ip after link flap.The link will be shown up but unable to ping.Nexus will be able to see opposite side as cdp neighbor but opposite side will not.
Conditions:
1. This problem is only seen on unified port of Nexus 5696UP
2. This problem is seen with 1Gig link only with "no negotiate auto" command configured
Workaround:
Remove the command "no negotiate auto" and re-apply it.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
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: | 14-JUL-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: | CSCum12980 |
Title: | N5k: VTP/VLAN config lost after disruptive ISSU |
|
Description: | Symptom:
The VTP and VLAN configuration are lost after a disruptive upgrade.
Conditions:
Nexus 5000 switch running as VTP server and undergoing a disruptive upgrade from 5.0(3) to 6.0(2).
This is not observed when upgrading from releases later than 5.0(3).
Workaround:
Backup VTP configuration, disable VTP feature prior to the disruptive upgrade. Re-enable the feature and re-apply the VTP configuration after the ugprade.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N2(2) |
|
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: | 14-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N2(1), 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul87437 |
Title: | BPDUGuard not Activated on Disallowed Edge Trunk VLANs |
|
Description: | Symptom:
BPDUs from a remote device do not activate BPDUGuard on an edge trunk port.
Conditions:
- Remote device misconfigured as an access port
- VLAN on access port is not in the allowed VLAN list of the edge trunk
Workaround:
Configure both sides of the link correctly as either trunks or access interfaces.
Further Problem Description:
This bug has been filed for documentation purposes.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv05684 |
Title: | documentation needs correction on removing ipv6 additional information . |
|
Description: | Symptom:
documentation needs correction on removing ipv6 additional information .
Conditions:
documentation needs correction on removing ipv6 additional information .
Workaround:
documentation needs correction on removing ipv6 additional information .
Further Problem Description:
documentation needs correction on removing ipv6 additional information .
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.79) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv24577 |
Title: | [Kernel_64bit] Disruptive ISSU Failed |
|
Description: | Symptom:
Switch got stuck in the load prompt with disruptive ISSU
Conditions:
Disruptive ISSU
Workaround:
No
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.30) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv22199 |
Title: | [kernel_64bit]Fex not coming online with 64bit image |
|
Description: | Symptom:
Fex not coming up with the 64 bit image
Conditions:
Kernel change to 64 bit.
Workaround:
No
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.30) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq80334 |
Title: | N5k:Upgrade from 5.2(1)N1(4) to 5.2(1)N1(6) causes ucast ARP to drop |
|
Description: | Symptom:
N5k:Upgrade from 5.2(1)N1(4) to 5.2(1)N1(6) causes ucast ARP to drop
Conditions:
ISSU from 5.2(1)N1(4) to 5.2(1)N1(6) in Fabripath environment
Workaround:
Upgrade to 6.0 version where the problem is not seen
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(4), 5.2(1)N1(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 16-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu66185 |
Title: | ptplc crash in pss related function in ASLR image |
|
Description: | Symptom:
ptplc process crash
Conditions:
Crash seen only with ASLR image
Workaround:
None
Further Problem Description:
Process crash observed while performing PSS restore functionality(stack overflow because of the wrong size passed for memcpy)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.8) |
|
Known Fixed Releases: | 7.0(7)ZN(0.126), 7.1(2)N1(0.551), 7.1(2)ZN(0.10), 7.2(1)N1(0.28), 7.2(1)N1(1), 7.3(0)N1(0.28), 7.3(0)N1(1), 7.3(0)ZN(0.29) |
|
|
| |
| |
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.
More Info:
If a switch running affected release is upgraded to a fixed release using non-disruptive ISSU, this bug gets carried over. A switch reload/power-cycle is required.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-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: | CSCub68739 |
Title: | bind mac-address config in vfc interface is lost after switch reload |
|
Description: | Symptom:
bind mac config lost on most vfcs
Conditions:
On Switch reload
On Nexus 5000
Workaround:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N1(0.319) |
|
Known Fixed Releases: | 5.2(1)N1(3), 6.0(2)A1(1), 6.0(2)N1(2), 6.0(2)N2(1), 6.0(2)U1(1) |
|
|
| |
| |
Bug Id: | CSCue24258 |
Title: | Nexus 5000 returns 0 when SNMP Manager tries to get "ifOutErrors" MIB |
|
Description: | Symptom:
Nexus 5000 always return zero value when we try to get "ifOutErrors" MIB.
Conditions:
Whenever receiving the request for "ifOutErrors".
Workaround:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N1(1a), 5.2(1)N1(1a) |
|
Known Fixed Releases: | 5.2(1)N1(4) |
|
|
| |
| |
Bug Id: | CSCuu32997 |
Title: | Roll Back Failed while applying removed breakout interface config |
|
Description: | Symptom:
Verification of rollback fails.
Conditions:
Checkpoint includes configuration pertaining to port-channels and interfaces configured as members of those port-channels. Post checkpoint, running configuration is modified to remove the members from port-channels.
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.195) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv22408 |
Title: | [kernel_64bit]VSH core@gat_fcp_cli_main |
|
Description: | Symptom:
VSH core
Conditions:
While executing tac-pac command
Workaround:
No
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.30) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 16-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.1) |
|
Known Fixed Releases: | 5.2(1)N1(8.169), 5.2(1)N1(9), 6.0(2)N2(6.143), 6.0(2)N2(7), 7.0(7)ZN(0.108), 7.1(1)ZN(0.109), 7.1(2)N1(0.531), 7.2(1)N1(0.4), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu27835 |
Title: | Enable secret hashes improperly calculated |
|
Description: | Symptom:
A part of the MD5 hash calculated for 'enable secret' command is not correctly seeded. This could lead to a part of the MD5 secret hash to be guessable.
Conditions:
This affects Cisco NX-OS releases 7.0(6)N1(1), 7.1(1)N1(1) and 7.2(0)N1(1).
Workaround:
Do not use 'enable secret'.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.272) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)ZN(0.110), 7.1(2)N1(0.532), 7.2(1)N1(0.4), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuv27318 |
Title: | IGMP packets are sourced from Anycast SWID instead of emulated switch id |
|
Description: | Symptom:
IGMP packets are not flooded along FTAG
Conditions:
HSRP Anycast is configured on ingress switch for the vlan in question
Workaround:
Remove HSRP Anycast
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus78102 |
Title: | N6K crashed due to "kernel panic" @ stale pointer |
|
Description: | Symptom:
N6K running with 6.0.2.N2.3 can get crash due to kernel panic,
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 254246 usecs after Sun Jan 25 11:48:59 2015
Reason: Kernel Panic <<<<<
Service:
Version: 6.0(2)N2(3)
Conditions:
None
Workaround:
None
Further Problem Description:
Kernel panic. Oops in mmap_region()
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N3(2) |
|
Known Fixed Releases: | 5.2(1)N1(8.154), 5.2(1)N1(9), 6.0(2)N2(6.123), 6.0(2)N2(7), 7.0(6)N1(1), 7.1(1)N1(0.490), 7.1(1)N1(1), 7.1(1)ZN(0.43), 7.2(0)N1(0.134), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu13486 |
Title: | Traffic issue in some vrf on setup with 100 vrf |
|
Description: | Symptom:asm multicast issue for some vrf in scaled setup
Conditions:when asm traffic started for 100 vrfs each with 50 s,g
Workaround:do not start for so many at the same time
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.186) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui34757 |
Title: | Nexus 5k acting as an NTP Client does not sync with an NTP server |
|
Description: | Symptom:
Nexus 5k acting as an NTP Client can't sync with any NTP server(s).
when issuing a "show ntp peer-status" or a "show ntp peers" it does not display any of the servers/peers configured.
Conditions:
Nexus 5500/5000 running 5.2(1)N1(5).
Workaround:
Proactive workaround to prevent from this issue is none.
Reactive workaround to recover this issue is below. However, after reloading system, same issue may happen again.
#conf t
#clock protocol none
#clock protocol ntp
#copy run start
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N2(1), 5.2(1)N1(5) |
|
Known Fixed Releases: | 5.2(1)N1(6) |
|
|
| |
| |
Bug Id: | CSCuu33047 |
Title: | Roll back failed while applying allowed vlan command to a interface |
|
Description: | Symptom:
Rollback operation fails.
Conditions:
Checkpointed configuration includes port-channel interfaces and other interfaces configured as members of these port-channel interfaces. Modification to remove member interfaces from port-channel interfaces.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.195) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 17-JUL-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: | 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:
During the Carmel log display, Current log pointer got exceeded over End log pointer by one thread and at the same time another thread accessed current pointer for log wrapping scenario and tried memory set on left over memory. For memory set operation size is determined using End pointer subtracting Current pointer. This operation generated the negative size value for memset call, resulting memory crash. Due to this Carmel got Core.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(6) |
|
Known Fixed Releases: | 7.0(7)N1(0.65), 7.0(7)N1(1), 7.0(7)ZN(0.141), 7.1(2)N1(0.565), 7.1(2)ZN(0.25), 7.2(1)N1(0.245), 7.2(1)N1(1), 7.2(1)ZN(0.11) |
|
|
| |
| |
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: | 17-JUL-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(2)N1(1), 7.0(4)N1(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.697), 7.0(6)N1(0.206), 7.0(6)N1(1), 7.1(0)N1(0.1), 7.1(0)N1(0.372), 7.1(0)N1(1), 7.1(0)ZN(0.446), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.2(0)N1(0.2) |
|
|
| |
| |
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: | 18-JUL-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: | 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: | 20-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N2(1a), 6.0(2)N2(4) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(2)N1(0.548), 7.1(2)ZD(0.5), 7.1(2)ZN(0.7), 7.2(0)BA(0.12), 7.2(0)D1(0.467), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCut37784 |
Title: | [iluka MR5]FEX: Satmgr Module time out during the ISSU upgrade |
|
Description: | Symptom:
Straight through Fex took long time to come up after ISSU upgrade
Conditions:
Disruptive issu between illuka MR5 image.
Workaround:
no
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.6) |
|
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: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.178) |
|
Known Fixed Releases: | 7.2(1)N1(0.257), 7.2(1)N1(1), 7.2(1)ZN(0.21) |
|
|
| |
| |
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: | 20-JUL-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: | CSCul15987 |
Title: | FEX modules disconnected during file copy to bootflash |
|
Description: | Symptom:
Some FEX modules got disconnected from the parent Nexus 5000 switch during an external file copy to disk.
When this happens, the VTY session and the file transfer progress hangs as well.
Conditions:
This was observed under the following conditions:
- Nexus 5020 switch with multiple FEX modules connected to it.
- /var/sysmgr internal directory is at high usage. This can be checked using command:
# show system internal flash
- The file transfer was made via the mgmt0 interface.
Workaround:
Contact Cisco TAC for assistance in reducing the usage of the /var/sysmgr directory.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(5) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq19925 |
Title: | VM-FEX Support on N5K |
|
Description: | Symptom:
When using VM-FEX with UCS C-Series chassis and Nexus 5500 parent switches we will see the logical vNIC connection to the VMs drop off and are unable to come back online, resulting in a connectivity outage for the affected hosts
Conditions:
Setup of N5K & UCS C-Series using VM-FEX
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 21-JUL-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: | 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: | 21-JUL-2015 |
|
Known Affected Releases: | 5.0(3)N2(2b), 5.2(1)N1(3), 6.0(2)N2(2) |
|
Known Fixed Releases: | 5.2(1)N1(7.132), 5.2(1)N1(8), 6.0(2)N2(5.85), 6.0(2)N2(6), 7.0(1)ZN(0.716), 7.0(6)N1(0.219), 7.0(6)N1(1), 7.1(0)N1(0.309), 7.1(0)N1(1), 7.1(0)ZN(0.395) |
|
|
| |
| |
Bug Id: | CSCum74697 |
Title: | Revise documentation for san port channel limit |
|
Description: | Symptom:
The following error is displayed in a Nexus 5000 switches' syslog:
"%FWM-1-FCFIB_HW_PC_LIMIT: Failed to create san-port-channel [#], hardware limit of 4 would be exceeded"
Conditions:
This error occurs when creating more than 4 san-port-channels on a Nexus 5000.
Workaround:
N/A
Further Problem Description:
The Nexus 5000 switching platform allows a maximum of 4 simultaneously active san-port-channels.
The switch will allow the creation a fifth or more san-port-channel interfaces.
Any additional san-port-channels that are admin enabled beyond the limit will remain in a down state.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv22468 |
Title: | Not able to enable Port-track feature |
|
Description: | Symptom:
Not able to install Feature port-track, observing library failure.
Conditions:
Feature Port-track
Workaround:
No
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.30) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu03271 |
Title: | Module/FEX gets into failure state with the NF Errors |
|
Description: | Symptom:
The messages 'nfp: ACL abort fails' or 'nfp: ACL commit fails' appears on the console multiple times. This could be followed by fex modules going offline
Conditions:
ISSU of n6000 with netflow feature enabled from 7.2(0)N1(1) to a higher release version can cause this issue.
Reload of a 7.2(0)N1(1) n6000 with netflow feature enabled also can cause this issue very rarely.
Workaround:
To avoid the issue, please remove netflow feature and configure it again once the ISSU or reload is done.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.170) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 22-JUL-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: | 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-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N2(1b) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(2)N1(0.543), 7.1(2)ZN(0.2), 7.2(1)N1(0.243), 7.2(1)N1(1), 7.2(1)ZN(0.9) |
|
|
| |
| |
Bug Id: | CSCuv22429 |
Title: | FWM core@ fwmpd_asic_dyn_det_entry_cleanup |
|
Description: | Symptom:
switch reloaded with fwm core after excuting "platform fabric database dot1q disable"
Conditions:
execute this command in config mode "platform fabric database dot1q disable"
Workaround:
no
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.30) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv22243 |
Title: | [kernel_64bit]snmp core@snmp_handle_mgmt_set_reques+handle_snmp_cli_msg |
|
Description: | Symptom:
SNMP process crash continuously
Conditions:
Enable the snmp traps for core Notify.
Workaround:
No
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.30) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue80077 |
Title: | FEX: Port flap request from SAP: MTS_SAP_SATMGR |
|
Description: | Symptom:
FEX Fabric Links flap.
Conditions:
This caveat is seen in a condition where spanning tree instabilities caused flood of CFSoE packets. This in turn caused congestion at control plane and thereby resulting in Satellite Discovery Protocol packets to drop and hence causing FEX interfaces to flap.
If there are no instabilities in Spanning tree and/or CFSoE packets are not flooded at control plane and if the FEX flaps are still happening, then it is not related to this caveat. Please investigate the cause of control plane congestion and FEX interface flaps separately.
Workaround:
Links seem to recover on their own.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N1(1a) |
|
Known Fixed Releases: | 5.2(1)N1(7.119), 5.2(1)N1(8), 7.0(7)ZN(0.130), 7.2(1)N1(0.262), 7.2(1)N1(1), 7.2(1)ZN(0.26) |
|
|
| |
| |
Bug Id: | CSCuv39333 |
Title: | ipqosmgr crashes |
|
Description: | Symptom:
ipqosmgr crashes due to wrong interface startup-config reading
customer used a FEX2232 to replace FEX2248, but they didn't remove FEX2232's configuration before he unplugged 2232.
#3 qosmgr_get_pfc_stats (if_index=0x1f940b40, rx_stats_p=0xbfac55a0,
tx_stats_p=0xbfac559c)<<<<<<<<<<<<<<<<<<<<<<
after we decode core file, it indicates that 0x1f940b40 has issue, but customer is using FEX2232, there is no port 46 here.
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu14439 |
Title: | Connectivity problem with solarflare NIC after server reload |
|
Description: | Symptom:
Connectivity problem with solarflare NIC SFN5122F-R64 following server reload.
Despite interface up, switch doesn't see traffic from the serer. Server doesn't receive anything from the switch (including broadcasting) .
Ethernet1/45 is up
RX
0 unicast packets 0 multicast packets 0 broadcast packets
0 input packets 0 bytes
TX
0 unicast packets 10613 multicast packets 0 broadcast packets
10613 output packets 1152256 bytes
Conditions:
Server coming with solarflare NIC SFN5122F-R64 NIC
Workaround:
Shut / no shut
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
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: | 23-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj84269 |
Title: | Nexus 5000 switch reloaded due to gatosusd hap reset |
|
Description: | Symptom:
A Nexus 5000 switch reloads after gatosusd process crashes.
`show system reset-reason`
Reason: Reset triggered due to HA policy of Reset
Service: gatosusd hap reset
Conditions:
Following log messages can be seen in the syslog file:
- KERN 2 SYSTEM_MSG usd process 3372, uuid 657 (0x291) failed to send heartbeat - kernel *
- SYSMGR 2 SERVICE_CRASHED Service "gatosusd" (PID 3372) hasn''t caught signal 6 (core will be saved). *
- SYSMGR 2 HAP_FAILURE_SUP_RESET System reset due to service "gatosusd" in vdc 1 has had a hap failure *
And the following messages can be seen in the output of `show processes log details` command:
- Invalid Desc Fetch Index detected on Channel 0, asic 4
- ERR: Disabling STM update DMA channel on gatos 4 due to error
Workaround:
No known workarounds at the moment.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(3.50) |
|
Known Fixed Releases: | 5.2(1)N1(6.95), 5.2(1)N1(7), 7.0(1)ZN(0.689), 7.0(6)N1(0.198), 7.0(6)N1(1), 7.1(1)N1(0.463), 7.1(1)N1(1), 7.1(1)ZN(0.16), 7.2(0)AB(9), 7.2(0)N1(0.133) |
|
|
| |
| |
Bug Id: | 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: | 23-JUL-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: | CSCup05323 |
Title: | Fwm core while executing fabric port flap |
|
Description: | Symptom:
fwm service crash. Following errors are seen during a crash:
SYSMGR-2-SERVICE_CRASHED: Service "fwm" (PID 3756) hasn't caught signal 11 (core will be saved).
vpc-vl1# sh system reset-reason
System reset reason would be similar to this:
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
Reason: Reset triggered due to HA policy of Reset
Service: fwm hap resetConditions:
Conditions:
This is observed during frequent fabric port flaps
Workaround:
Possible workaround is to stop the fabric port flaps.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.174), 7.1(0)N1(0.186) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 23-JUL-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: | CSCuv34288 |
Title: | Evaluation of n5k-all for OpenSSL July 2015 vulnerability |
|
Description: | Symptom:Cisco Nexus 5000 and 6000 Series Switches, and Nexus 2000 Series FEX include a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) ID:
CVE-2015-1793
Conditions:Exposure is not configuration dependent.
Workaround:Not available.
More Info:Cisco NXOS 7.2(1)N1(1) release is VULNERABLE.
Cisco NXOS 7.1(x), 7.0(x), 6.x and 5.x releases are NOT VULNERABLE.
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.4
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:POC/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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc00994 |
Title: | N5548UP: FC Ports in "out of service" can't be reverted or configured |
|
Description: | Symptom:FC ports can not be released from out-of-service state.
Configuring 'no out-of-service' to make the port available or any other commands put on that interface take a very long time to finish and eventually fail. The fail can be told by looking at config or `show accounting log`.
Mon Sep 3 14:41:45 2012:type=update:id=console0:user=admin:cmd=configure terminal ; interface fc1/31 ; out-of-service (SUCCESS)
Mon Sep 3 14:43:52 2012:type=update:id=console0:user=admin:cmd=configure terminal ; interface fc1/31 ; no out-of-service (FAILURE)
And interface stay in out of service state.
Conditions:This issue happens on the FC port which is once in an out-of-service state.
Workaround:We have three ways to get the port out of the state is :
- initialize the switch
Retrieve the switch config, hand-edit the config to remove the out-of-service command. "write erase" the switch and retrieve the hand-edited config onto switch and then reload.
- version up to fixed release
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(1a) |
|
Known Fixed Releases: | 6.0(2)N1(1) |
|
|
| |
| |
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: | 24-JUL-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: | 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: | 24-JUL-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: | CSCuo69417 |
Title: | Nexus 6000/5600: Link degraded messages seen been port and fabric ASIC |
|
Description: | Symptom:
In a Nexus 6000/5600 series switches, link degraded messages such as following can be seen between port ASIC and fabric ASIC.
USER-2-SYSTEM_MSG: A fabric link on module 3 has degraded, some packets may be corrupted - bigsurusd
USER-2-SYSTEM_MSG: A fabric link on module 3 has degraded, some packets may be corrupted - bigsurusd
USER-2-SYSTEM_MSG: A fabric link on module 3 has degraded, some packets may be corrupted - bigsurusd
Conditions:
Seen during normal production. Fabric link can be degraded for other hardware related issues which this bug does
not address. The root cause for this software issue is incorrect Fabric init issue.
Workaround:
A power cycle of LEM or switch might recover if the root cause is software fabric init issue
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 7.0(3)N1(0.47) |
|
Known Fixed Releases: | 7.0(1)ZN(0.474), 7.0(4)N1(0.126), 7.0(4)N1(1), 7.1(0)N1(0.254), 7.1(0)N1(0.256), 7.1(0)N1(1), 7.1(0)ZN(0.351), 7.1(0)ZN(0.353) |
|
|
| |
| |
Bug Id: | CSCui41293 |
Title: | Active/Active not working for vHBA's and Adapter-FEX on 5K's |
|
Description: | Symptom:
When using Adapter-FEX with a VIC 1225 connected to 5K's, NIV mode works as Active/Active, but we need to have unique vEth's on the 5K's for each vNIC and each vHBA.
I don't see this clearly documented in the config guide for Adapter-FEX. We should add a special note which states that each unique channel number needs a unique vEth on the 5K.
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/adapter-fex/513_n1_1/b_Configuring_Cisco_Nexus_5000_Series_Adapter-FEX_rel_5_1_3_N1.pdf
Conditions:
When using Adapter-FEX
Workaround:
We should add a special note which states that each unique channel number needs a unique vEth on the 5K.
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/adapter-fex/513_n1_1/b_Configuring_Cisco_Nexus_5000_Series_Adapter-FEX_rel_5_1_3_N1.pdf
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N1(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCug29190 |
Title: | 'ethpc' hap reset tied to SFP diagnostics |
|
Description: | Symptom:'ethpc' process crash due to HAP reset. Specifically the process fails to respond to heartbeats and so the system restarts the process to recover it.
Conditions:Process is running diagnostics on SFPs. This happens routinely by default. I don't believe it can be disabled.
Workaround:None.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-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: | 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: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(6), 7.0(6)N1(0.272), 7.1(1)N1(1), 7.1(2)N1(0.562), 7.1(2)N1(0.566), 7.2(0)N1(0.219), 7.2(1)N1(0.243) |
|
Known Fixed Releases: | 7.0(7)N1(0.68), 7.0(7)N1(1), 7.0(7)ZN(0.145), 7.1(2)N1(0.575), 7.1(2)ZN(0.36), 7.2(1)N1(0.252), 7.2(1)N1(1), 7.2(1)ZN(0.17) |
|
|
| |
| |
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. The soft lockup may happen at different process, as the issue is triggered at the interrupt level.
Workaround:
None at this time.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N1(2), 6.0(2)N2(2), 7.1(0)N1(0.129) |
|
Known Fixed Releases: | 5.2(1)N1(7.106), 5.2(1)N1(8), 6.0(2)N2(4.63), 6.0(2)N2(5), 7.0(3)N1(0.30), 7.0(3)N1(1), 7.1(0)N1(0.138), 7.1(0)N1(1), 7.1(0)ZN(0.256) |
|
|
| |
| |
Bug Id: | CSCuq71362 |
Title: | Kernel panic in snmpd |
|
Description: | Symptom:
A kernel panic results in a system reload:
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 245977 usecs after Sat Aug 23 16:48:41 2014
Reason: Kernel Panic
Service:
Version: 6.0(2)N1(1)
Conditions:
This is a corner case in NX-OS kernel-level memory management. Memory corruption may occur if the switch is polled via SNMP under specific timing conditions, and this will result in a crash.
Workaround:
Do not poll the switch via SNMP.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N1(1), 6.0(2)N2(5) |
|
Known Fixed Releases: | 6.0(2)N2(5.103), 6.0(2)N2(6) |
|
|
| |
| |
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: | 25-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N2(1) |
|
Known Fixed Releases: | 5.1(3)N2(1b) |
|
|
| |
| |
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-JUL-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: | CSCuu23398 |
Title: | [SPAN]: "Service not responding" err on shut/unshut of ssn with more src |
|
Description: | Symptom:
Span session with more than 32+ source interface will throw "Service not responding" error
upon doing shut/no shut of the moitor session
Conditions:
"Service not responding " error messages are seen upon doing "shut"/"no shut" of the span session having
32+ source interfaces
Workaround:
Workaround is to wait until the session comes up, even after the "Service not responding" error is thrown
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.192) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut64996 |
Title: | Nexus5548 _Ethernet ports is lost in running-config after reload |
|
Description: | Symptom:
Nexus5548 _Ethernet ports is lost in running-config after reload
Conditions:
I can't see Ethe rport on Nexus5548's running-config after power on or reload.
Workaround:
1. downgrade NX-OS version to 5.x
2. upgrade NX-OS version to 7.1(O)N1(1b) from 5.x.
reload is not workaround.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtn26264 |
Title: | FEX N2148 unexpected reboot due to kernel panic : Cause (SRR1=0x201030) |
|
Description: | Symptom:
FEX 2148 experiences unexpected reboot.
Conditions:
Issue only affects 2148 FEXs.
Workaround:
None
Details:
This is not a hardware issue and the fix is to do a software upgrade. Either of
the cases below can prove you are running into this bug.
Case 1:
Attach to the affected fex by using the command "attach fex 1XX". Get the
output of "show logging onboard stack-trace" and see Sig 7 or Signal 7 in the
output. The exception to this is that if you see "L2 data cache parity error"
as the "Cause" then you are running into the bug CSCtr04473.
`show logging onboard stack-trace`
------------------ LOG 01 -------------------
Logging time: Thu Jan 13 02:22:43 2011
1294881763:202538000 process swapper (0), jiffies 0x22df79d
Other Info: Machine check in kernel mode (sig 7)
Cause (SRR1=0x201030): Transfer error ack signal
Case 2:
Only TAC can confirm this case for you. Debug the FEX core file and see the
signal 7 or sig 7 at the top of the stack trace. It can be any process and does
not have to be the redwood process as shown in this example.
Core was generated by `/isan/bin/redwood -NONE'.
Program terminated with signal 7, Bus error.
#0 0x0fc2c7f4 in ?? ()
(gdb) set height 0
(gdb) up 8
#8 0x0ffd249c in ?? ()
(gdb) thread apply all bt full
Thread 1 (process 880):
#0 0x0fc2c7f4 in ?? ()
No symbol table info available.
#1 0x0fc2de94 in ?? ()
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 4.2(1)N2(1) |
|
Known Fixed Releases: | 5.0(3)N2(1) |
|
|
| |
| |
Bug Id: | CSCuo59839 |
Title: | N5k 6.0(2) CarmelUSD Kernel Panic |
|
Description: | Symptom:
Nexus 5500 crash due to kernel panic
Conditions:
This was observed on Nexus 5500 switch running 6.0(2)N2(2). Other releases may also be affected
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut89123 |
Title: | Kernel panic due to "insmod" process |
|
Description: | Symptom:
The N5K might crash due to kernel panic running process "insmod".
The "show logging onboard stack-trace" output doesn't contain any call traces, but Last Kernel Messages from the some output contains following error message:
<1>BUG: unable to handle kernel NULL pointer dereference at 00000000
There are no core files or process logs.
Conditions:
normal
Workaround:
unknown at this point
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 5.2(3a)E2, 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 28-JUL-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: | CSCuv50424 |
Title: | N5k crash on 'reload fex' |
|
Description: | Symptom:
N5k crash on 'reload fex'
Conditions:
observed with N2K-C2232TM-E-10GE
Workaround:
unknown
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu59941 |
Title: | FC ports error disabled with non-Cisco SFPs after upgrade to 6.x/7.x |
|
Description: | Symptom:
FC ports with non-Cisco SFPs are error disabled after a NX-OS upgrade from 5.x to 6.x/7.x
Conditions:
Occurs after upgrade from NX-OS 5.x to 6.x/7.x when using SFPs that are not Cisco branded.
Workaround:
Use Cisco FC transceivers
Further Problem Description:
This is how the interface appears:
show interface brief
-------------------------------------------------------------------------------
Interface Vsan Admin Admin Status SFP Oper Oper Port
Mode Trunk Mode Speed Channel
Mode (Gbps)
-------------------------------------------------------------------------------
...snip
fc2/16 100 auto on errDisabled -- -- --
And:
show interface fc2/16
fc2/16 is down (Error disabled - SFP vendor not supported)
Hardware is Fibre Channel, SFP is Unknown(0)
...snip
The following messages are seen:
%KERN-3-SYSTEM_MSG: [5018764.606338] jiffies: 501846460, XCVR slot 1 port(lo-hi) 15-15: GBIC/SFP checksum error - kernel
%PORT-5-IF_DOWN_FCOT_VENDOR_NOT_SUPPORTED: %$VSAN 100%$ Interface fc2/16 is down (Error disabled - FCOT vendor not supported)
%KERN-3-SYSTEM_MSG: [5018765.646427] jiffies: 501846564, XCVR slot 1 port(lo-hi) 15-15: GBIC/SFP checksum error - kernel
%KERN-3-SYSTEM_MSG: [5018765.646455] jiffies: 501846564, XCVR slot 1 port(lo-hi) 15-15: Failed reading information from transceiver - kernel
Resolution Summary:
To be determined once resolved.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(1), 6.0(2)N2(7), 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.116), 7.1(2)N1(0.553), 7.1(2)ZN(0.12), 7.2(1)N1(0.25), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuv37294 |
Title: | 2248: Packets getting Blackholed in the HIF VPC port-channel |
|
Description: | Symptom:
Packets will get black holed in the HIF VPC Port-channel
Conditions:
1) FEX 2248
2) 55xx based Platforms
3) Running 7.0(6)N1(1)
Workaround:
1) Keep one single HIF port in the HIF port-channel.
2) If there are more ports in port-channel, Change the hashing by shutting down ports on HIF side.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo79180 |
Title: | copy run start fails: Service "flogi" failed to store its configuration |
|
Description: | Symptom:
A "copy run start" can fail with the following message:
2014 May 10 00:01:23 N5548UP SYSMGR-3-CFGWRITE_SRVTIMEOUT Service "flogi" failed to store its configuration in the timeout period
2014 May 10 00:01:23 N5548UP SYSMGR-2-CFGWRITE_ABORTED Configuration copy aborted.
2014 May 10 00:01:26 N5548UP SYSMGR-3-CFGWRITE_FAILED Configuration copy failed (error-id 0x401E0045).
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq68153 |
Title: | Fexes go offline when removing the detectable vlan cmd |
|
Description: | Symptom:
FEXes going offline was seen on scaled setup, under various conditions, including removing the mobility domain detectable vlan range config, or simple switch reboot. This failure does not seem to be related to the
mobility domain feature, but rather an infrastructure issue, as it was seen even without mobility domain
feature configured.
Conditions:
Scaled setup with 16+ FEXes.
Workaround:
FEXes can come back up after going offline for a while
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.315) |
|
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: | 29-JUL-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.7), 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus72900 |
Title: | Knob to Disbable ports after loop is detected not working as expected |
|
Description: | Symptom:When STM loop is detected:
MCT link goes down
Both the links goes down
Conditions:When "mac address-table loop-detect port-down" is enabled & STM loops are detected
Workaround:None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-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: | 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: | 29-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N1(1) |
|
Known Fixed Releases: | 5.1(3)N2(1a), 5.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: | 29-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(3), 7.2(0)N1(0.192) |
|
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: | 29-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 29-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(4) |
|
Known Fixed Releases: | 7.0(7)ZN(0.134), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.178), 7.3(0)N1(0.25), 7.3(0)N1(1), 7.3(0)ZN(0.24) |
|
|
| |
| |
Bug Id: | CSCui06208 |
Title: | FEX 2232TM-E 10G link flap |
|
Description: | Symptom:
Link from the server flaps on the FEX 2232TM-E-10G with an error:
ETHPORT-3-IF_DOWN_LINK_FAILURE Interface Ethernet100/1/1 is down (Link failure)
Conditions:
On FEX 2232TM-E-10G port is statically configured with speed 10Gbps or speed auto and 10Gbps was negotiated
Workaround:
Configure links with speed 1Gbps
More Info:
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N1(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 30-JUL-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: | CSCus68610 |
Title: | Nexus 5672/56128 - Silent reset with uC reset code: 0x4800 or 0x400b |
|
Description: | Symptom:
A Nexus 5672 or Nexus 56128 may reset with unknown reason
From the "show logging onboard internal reset-reason",
Reset Reason (HW): uC reset code: 0x4800 <<<<
OR
Reset Reason (HW): uC reset code: 0x400b
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:
Correctable errors seen on the internal PCIE bus.
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: | 30-JUL-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)N1(0.513), 7.1(1)N1(1), 7.1(1)ZN(0.69), 7.2(0)N1(0.167), 7.2(0)N1(0.180), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.170), 7.3(0)N1(0.25) |
|
|
| |
| |
Bug Id: | CSCus17580 |
Title: | eth_port_channel hap reset |
|
Description: | Symptom:
A Nexus 5000 may reload unexpectedly due to a eth_port_channel hap reset.
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1)...
Reason: Reset triggered due to HA policy of Reset
Service: eth_port_channel hap reset
...
Conditions:
The exact conditions for this issue are unknown.
Workaround:
There are no known workarounds at this time.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(5)N1(0.184) |
|
Known Fixed Releases: | 7.0(7)N1(0.282), 7.0(7)N1(1), 7.0(7)ZN(0.159), 7.2(1)N1(0.257), 7.2(1)N1(1), 7.2(1)ZN(0.21) |
|
|
| |
| |
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: | 30-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(7), 6.0(2)N2(4), 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.120), 7.1(2)N1(0.543), 7.1(2)ZN(0.2), 7.2(0)AB(9), 7.2(0)N1(0.147), 7.2(0)N1(1), 7.2(0)ZN(0.151), 7.3(0)N1(0.25), 7.3(0)N1(1) |
|
|
| |
| |
Bug Id: | 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: | 30-JUL-2015 |
|
Known Affected Releases: | 5.0(2)N2(1), 5.1(3)N2(1) |
|
Known Fixed Releases: | 5.0(3)N2(1) |
|
|
| |
| |
Bug Id: | CSCut19714 |
Title: | N2H traffic can drop on a HIF port-channel when another is down |
|
Description: | Symptom:
Servers are dual homed to FEX 2348UPQ and each FEX is single homed to 5548P which is part of Fabric Path (vPC+).
Bringing down a HIF port-channel on the FEX affects another port-channel, which means N2H traffic through the affected port-channel drops.
Conditions:
FEX 2348UPQ is used in the topology described above.
Bringing down a HIF port-channel on the FEX.
Workaround:
shutdown and no shutdown one of FEX fabric ports which are connected to the affected FEX.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a), 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.776), 7.0(6)N1(0.266), 7.0(6)N1(1), 7.1(1)N1(0.495), 7.1(1)N1(1), 7.1(1)ZN(0.48), 7.2(0)AB(9), 7.2(0)N1(0.157), 7.2(0)N1(0.162), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | 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: | 30-JUL-2015 |
|
Known Affected Releases: | 5.2(1)N1(7), 7.0(5)N1(1a) |
|
Known Fixed Releases: | 5.2(1)N1(8.153), 5.2(1)N1(9), 6.0(2)A5(1.37), 6.0(2)A5(2), 6.0(2)A6(1.105), 6.0(2)A6(2), 6.0(2)N2(6.129), 6.0(2)N2(7), 6.0(2)U5(1.37), 6.0(2)U5(2) |
|
|
| |
| |
Bug Id: | CSCuv07607 |
Title: | N5k/N6k - No login possible to device when root directory is full |
|
Description: | Symptom:
N5k/N6k switches may not be accessible remotely or locally due to no space available in Root directory.
Authentication is unsuccessful both remotely or locally when this happen, even when issue is not with credentials. Following error message may appear on Syslog server:
%DAEMON-3-SYSTEM_MSG: Unable to create temporary user xxxxxxxx. Error 0x404a000a (16777216)
Conditions:
Issue is seen when debugs are enabled without redirecting to a logfile. Debugs thus are automatically redirected to "startupdebug" file which can grow as much as space available in Root directory.
Debugs are currently seen persistent and they still exist post reload and filling up startupdebug file. Once Root directory runs out of space no more login to box is possible.
- "dir log:" CLI could be used to check for startupdebug file
- show debug, would show active debugs running.
Workaround:
Disable debugs and do not run them to eternity.
Use debug logfile <> to redirect logs to a non-system file. This file is limited to 4MB and is overridden once full.
If you hit these symptoms, please check "show debug" to see if debugs are enabled, if yes, then disable them.
Further Problem Description:
It is possible even with debug logfile <> enabled with debugs running, post reload debugs still persist and now written to startupdebug file.
Traffic forwarded through the switch or even control plane is not impacted. Only login to the switch is not possible.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a), 7.1(1)N1(1) |
|
Known Fixed Releases: | 7.2(1)N1(0.265), 7.2(1)N1(1), 7.2(1)ZN(0.29) |
|
|
| |
| |
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: | 30-JUL-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: | CSCur91280 |
Title: | N5k mst interop with cat6k: 30 sec convergece after TCN |
|
Description: | Symptom:
+30sec MSTP convergence due to slow MSTP state transition
In MSTP during a proposal handshake, a port in ALT BLK does not send a BPDU with the agreement flag set.
This cause the port on other end to go through blocking and learning states.
Conditions:
Problem is observed every time when there is change in topology.
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(5) |
|
Known Fixed Releases: | |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论