| |
|
Alert Type: | Updated * |
Bug Id: | CSCur47731 | Title: * | CSCur59789 5596UP / Crash, Reload after setting a FC Port shut/no shut |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
After bringing up a FC interface - Nexus5k cored and reloaded
Conditions:
Flap the FC port, Either switch will crash or relead.
Workaround:
no
Further Problem Description:
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | 7.0(1)ZN(0.706), 7.0(2)FIP(0.6), 7.0(6)N1(0.211), 7.0(6)N1(1), 7.1(0)N1(0.419), 7.1(0)N1(1), 7.1(0)ZN(0.492), 7.1(1)N1(0.34), 7.1(1)N1(1), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw09598 | Title: | ETHANALYZER FIP only collecting frames from Customer Side. |
|
Status: | Open |
|
Severity: * | 2 Severe |
Description: | Symptom:
Ethanalyzer FIP only capturing inbound frames.
Conditions:
ethanalyzer capturing FIP frames.
Workaround:
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 7.2(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur30094 | Title: | Nexus 5000 : evaluation of SSLv3 POODLE vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
This product includes a version of SSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-3505
CVE-2014-3506
CVE-2014-3507
CVE-2014-3508
CVE-2014-3510
CVE-2014-3566 (POODLE)
This bug has been opened to address the potential impact on this product.
Conditions:
The POODLE Security issue CVE-2014-3566 exists if we configure LDAP as part of DFA configuration
Something like this
fabric database type network
server protocol ldap ip 10.95.126.166 vrf management
Or
Onep is configured with "transport type tls ..." option
Or
vmtracker configuration
Workaround:
1. Avoid any "fabric database" configuration with keyword "enable-ssl".
For example:
fabric database type network
server protocol ldap ip 172.29.21.2 enable-ssl
2. Make sure the 'secure LDAP' option is unchecked when defining POAP template on DCNM.
3. Do not use onep
Further Problem Description:
A POODLE attack requires a man in the middle attack between the nexus5000/6000 switch (the LDAP client)
and the LDAP server. It would also require a protocol downgrade attack since, by default, nexus5000/6000
uses TLS protocol.
Current schedule for the fix :
- 7.1(1)N1(1) March or early April 2015 (was postponed from Feb 2015)
- 7.2 release April 2015
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the
time of evaluation are: 2.6/2.5
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 23-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N3(0.91), 7.0(4)N1(1), 7.1(0)ZN(91.34), 7.2(0)N1(0.76), 7.2(0)N1(0.82), 7.2(0)N1(0.85), 7.2(0)N1(0.88), 7.2(0)VX(0.9), 7.2(0.1)PR(0.1), 7.9(0)ZD(0.4) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.0(0)KMS(0.11), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.1(1)N1(0.482), 7.1(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu27835 | Title: | Enable secret hashes improperly calculated |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 03-SEP-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.1(2)N1(1), 7.2(0)N1(1), 7.2(1)N1(0.4), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu33047 | Title: | Roll back failed while applying allowed vlan command to a interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Rollback operation fails.
Conditions:
Checkpointed configuration includes port-channel interfaces and other interfaces configured as members of these port-channel interfaces. Modification to remove member interfaces from port-channel interfaces.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.195), 7.2(0)N1(0.226) |
|
Known Fixed Releases: * | 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.2(1)N1(0.258), 7.2(1)N1(1), 7.2(1)ZN(0.22) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCud72942 | Title: | mcast drop for one of hif ports after multiple parallel fex reloads |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptoms:
When all the fex's are reloaded at the same time, layer 2 multicast traffic may not recover on one of the HIF ports.
Conditions:
Reload of many fex's (atleast 5) all at the same time. If few fex's are reloaded at the same time, this issue may not be seen.
These conditions does not necessarily mean that the issue would happen all the time. In internal tests, it is seen once in 30 iterations.
Workaround:
shut/no-shut of the affected HIF port. Traffic would recover.
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N1(0.365) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus17580 | Title: | eth_port_channel hap reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 5000 may reload unexpectedly due to a eth_port_channel hap reset.
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1)...
Reason: Reset triggered due to HA policy of Reset
Service: eth_port_channel hap reset
...
Conditions:
The exact conditions for this issue are unknown.
Workaround:
There are no known workarounds at this time.
Further Problem Description:
|
|
Last Modified: | 04-SEP-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.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.2(1)N1(0.257), 7.2(1)N1(1), 7.2(1)ZN(0.21) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw19708 | Title: | Nexus 5000 crashes when removing VM tracker config from the interfaces |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Switch crash with "vmtracker hap reset"
Conditions:
Removing VM tracker config from the range of interfaces
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 7.1(2)N1(0.599) |
|
Known Fixed Releases: * | 7.1(3)N1(0.633), 7.1(3)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw17076 | Title: | ipfib hap reset on an access Nexus 5548P in a Layer3 Scale topology |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ipfib process crash
Conditions:
issue is seen on nexus 5000 platform during PBR adjacency delete
Workaround:
none.
Further Problem Description:
Crash is seen while printing the debug trace. As part of PBR adjacency delete, adjacency gets destroyed(if reference count is 0) and for debug print same adjacency pointer(which is already freed/destroyed).
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.113) |
|
Known Fixed Releases: * | 7.1(3)N1(0.632), 7.1(3)N1(1), 7.1(3)ZN(0.40), 7.2(1)N1(0.309), 7.2(1)N1(1), 7.2(1)ZN(0.72), 7.3(0)N1(1), 7.3(0)ZN(0.121) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv74117 | Title: | HIF port suspended by VPC after upgrade to 7.0(6)N1(1) |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
HIF port suspended by VPC after upgrade from 6.0(2)N2(6) to 7.0(6)N1(1)
Conditions:
N5596 in VPC and FEX 2232 dual connected to N5K
The HIF port was previously configured as EVPC
Then EVPC configuration was removed
Now upgrade was performed from 6.0(2)N2(6) to 7.0(6)N1(1)
After upgrade one of the N5K was rebooted
Workaround:
Configure the interfaces back in port-channel and then deleting the port-channel to bring the physical interface up
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv50424 | Title: | N5k crash on 'reload fex' |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
N5k crash on 'reload fex'
Conditions:
observed with N2K-C2232TM-E-10GE
Workaround:
unknown
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo45515 | Title: | N5K 5.2 carmelusd crash |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: * | Symptom:
Nexus 5000 crash due to carmelusd hap reset.
Conditions:
This was observed on NX-OS 5.2(1)N1(4). Other releases can be affected as well.
The issue occurs when we do DOM read for the SFP.
Potential trigger's scenarios that could lead to this problem:
1. When we do multiple "show interface transceiver details"
2. Multiple scripts running concurrently for "show interface transceiver details"
3. Pull/Insert transceivers while running "show interface transceiver details"
4. Pull/insert GEMs while running "show interface transceiver details"
5. Use broken transceivers to force failures on DOM retreivals if possible
Workaround:
Further Problem Description:
This issue is fixed in 7.0(0)N1(1) and later releases.
|
|
Last Modified: | 13-SEP-2015 |
|
Known Affected Releases: | 5.2(1)N1(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu07598 | Title: | Nexus 5548P/N55-M16P : After Upgrade Interface Down & Unrecoverable |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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 6000/5600
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
Prior to upgrading the switch to a fixed NX-OS version, remove the EEM script from the running configuration.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 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.190), 7.2(0)N1(0.219), 7.2(0)N1(1), 7.2(1)N1(0.243), 7.3(0)N1(0.68) |
|
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)N1(1), 7.1(2)ZN(0.36), 7.2(1)N1(0.252), 7.2(1)N1(1), 7.2(1)ZN(0.17), 7.3(0)BZN(0.41) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq94445 | Title: | ISSU failed: maximum downtime exceeded (0x4093003B) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
ISSU fails with the reason code 0x4093003B (maximum downtime exceeded)
Conditions:
Carmel ASIC based systems (i.e. 55xx series), with FCOE enabled and with a scaled setup: interface scale and qos policies.
Upgrade in this specific case is from 7.1(0)N1(1) to 7.1(0u)N1(1u).
Workaround:
None.
Further Problem Description:
Same problem seen in ISSU upgrade from 6.0(2)N2(5) > 7.0(5)N1(1a) > 7.1(0)N1(1a)
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 80169 usecs after Thu Mar 12 10:17:39 2015
Reason: Reset Requested due to Fatal System Error
Service: ISSU failure: 0x4093003B
Version: 7.1(0)N1(1a)
2) At 331870 usecs after Thu Mar 12 10:15:23 2015
Reason: Reset due to upgrade
Service:
Version: 7.0(5)N1(1a)
3) At 785798 usecs after Thu Mar 12 09:53:19 2015
Reason: Reset due to upgrade
Service:
Version: 6.0(2)N2(5)
`show logging nvram`
2015 Mar 12 10:17:39 FS01PPGHDL %$ VDC-1 %$ %SYSMGR-2-ISSU_FAILED: The ISSU has failed: maximum downtime exceeded (error-id 0x4093003B)
2015 Mar 12 10:17:39 FS01PPGHDL %$ VDC-1 %$ Mar 12 10:17:39 %KERN-0-SYSTEM_MSG: [ 134.045810] Shutdown Ports.. - kernel
2015 Mar 12 10:17:39 FS01PPGHDL %$ VDC-1 %$ Mar 12 10:17:39 %KERN-0-SYSTEM_MSG: [ 134.080176] writing reset reason 3, ISSU failure: 0x4093003B - kernel
2015 Mar 12 10:17:39 FS01PPGHDL %$ VDC-1 %$ Mar 12 10:17:39 %KERN-0-SYSTEM_MSG: [ 134.080178] - kernel
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 7.0(0)N1(1.1), 7.1(0)N1(0.335), 7.1(0)N1(0.342), 7.2(0)N1(0.116), 7.2(0)N1(0.180), 7.3(0)N1(0.113) |
|
Known Fixed Releases: | 7.3(0)D1(0.106), 7.3(0)N1(0.143), 7.3(0)N1(1), 7.3(0)ZD(0.120), 7.3(0)ZN(0.131) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut45896 | Title: | Nexus 5k/6k - MARCH 2015 OpenSSL Vulnerabilities |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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
|
|
Last Modified: | 03-SEP-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.1(2)N1(1), 7.2(0)N1(1), 7.2(1)N1(0.4) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCut68109 | Title: | 48q: bigsurusd hap reset @bigsur_serdes_control () |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Switch crash with "port-profile hap reset"
Conditions:
Error in reading JTAG
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.1(1)N1(0.499) |
|
Known Fixed Releases: | 7.0(7)N1(0.299), 7.0(7)N1(1), 7.0(7)ZN(0.203), 7.1(2)N1(0.551), 7.1(2)N1(1), 7.1(2)ZN(0.10), 7.2(1)N1(0.242), 7.2(1)N1(1), 7.2(1)ZN(0.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu03271 | Title: | Module/FEX gets into failure state with the NF Errors |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The messages 'nfp: ACL abort fails' or 'nfp: ACL commit fails' appears on the console multiple times. This could be followed by fex modules going offline
Conditions:
ISSU of n6000 with netflow feature enabled from 7.2(0)N1(1) to a higher release version can cause this issue.
Reload of a 7.2(0)N1(1) n6000 with netflow feature enabled also can cause this issue very rarely.
Workaround:
To avoid the issue, please remove netflow feature and configure it again once the ISSU or reload is done.
Further Problem Description:
|
|
Last Modified: | 08-SEP-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.170) |
|
Known Fixed Releases: * | 7.1(3)N1(0.626), 7.1(3)N1(1), 7.1(3)ZN(0.33), 7.2(1)N1(0.282), 7.2(1)N1(1), 7.2(1)ZN(0.46) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus84485 | Title: | Status LED AMBER after upgrading to 7.1(0)N1(1) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Status LED is On(Amber) after upgarding 7.1(0)N1(1) or later releases.
Note that staus LED was On(Green) when running prior releases(such as 7.0(3)N1(1)).
Conditions:
Upgrading software to 7.1(0)N1(1) or later releases.
No configuration change has been made on upgrading software.
Workaround:
None.
Further Problem Description:
This defect is under investigation.
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(1), 7.2(1)N1(0.268), 7.2(1)N1(1), 7.2(1)ZN(0.32) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu01961 | Title: | show run takes long time with large amount of vlans/vsans |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show run takes long time with large amount of vlans/vsans
Conditions:
large amount of vlans and defined vlan names
Also seen in setup with large number of vsans
Workaround:
Instead of having different configurations in different vlans, users can club different vlans to convert them to vlan ranges having same configurations under them. With that the delay will get reduced significantly.
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.634), 7.1(3)N1(1), 7.1(3)ZN(0.42), 7.3(0)N1(0.135), 7.3(0)N1(1), 7.3(0)ZN(0.124) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq17271 | Title: | After ISSU, only FEX hifs that are up show up in "sh fex <id> detail" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Only FEX hifs that are up show up in "sh fex detail".
Conditions:
Issue is related to ISSU non disruptive. In this particular case, ISSU failed with the line card upgrade sequence failure and after that another ISSU non disruptive was performed on the switch. Second ISSU was performed on the inconsistent state that resulted in this error. After the first ISSU failure, the customer should have reloaded the switch as the switch state was not consistent and might have resulted in the topology changes as well.
Workaround:
Reload (in maintenance window) all the FEX devices attached with the switch should solve the problem. Another step the user might have taken is to reload(in maintenance window) the switch after the ISSU failure to come out from the inconsistent state.
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 5.2(1)N1(6), 5.2(1)N1(7) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur15707 | Title: | N5k: Vlans learned via vtp not created |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
VLANs learned via VTP may not be added to the VLAN database
Conditions:
Nexus 5500 switch running as VTP client
Workaround:
Workaround 1: Reload
Workaround 2: Disable/reenable the vtp feature and reapply the VTP configuration. Deleting the reserved vlans 1002-1005 may be needed before changing the VTP mode to client.
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua78843 | Title: | SFP validation issue with switchport mode fex-fabric |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
In a Nexus 5000/5500, adding configuration switchport mode fex-fabric to an interface
which has speed 1000 configured, removes the speed configuration causing a user to
believe the interface is configured for default 10G. Adding a 10Gig optics causes SFP Validation failed
status.
5596-A.cisco.com# sh run int ethernet 1/17
!Command: show running-config interface Ethernet1/17
!Time: Mon Jul 2 09:39:22 2012
version 5.2(1)N1(1)
interface Ethernet1/17
switchport mode fex-fabric
5596-A.cisco.com# sh int ethernet 1/17 brief
--------------------------------------------------------------------------------
Ethernet VLAN Type Mode Status Reason Speed Port
Interface Ch #
--------------------------------------------------------------------------------
Eth1/17 1 eth fabric down SFP validation failed 1000(D) -- <<<----
5596-A.cisco.com# sh int ethernet 1/17
Ethernet1/17 is down (SFP validation failed)
Conditions:
Adding switchport mode fex-fabric to an interface which has speed 1000 configured.
Workaround:
Remove switchport mode fex-fabric and do a no speed 1000
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 5.1(3)N2(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw27142 | Title: | Need CLI to clear snmp counters for Nexus switches |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
In Device Manager GUI for a Nexus switch, summary error counters are not cleared when corresponding interface counters are cleared via CLI.
Conditions:
Interface counters for FC interfaces are showing up in Summary window of Device Manager and can't be cleared in any way.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 5.2(1)N1(9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut13992 | Title: | Interop issue with third-party : link stays down after shut/no shut |
|
Status: * | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Interface may fail to come up after shut/no shut
Conditions:
Interface is connected to third-party device.
Has been seen with SFP-1000BASE-SX.
Workaround:
Un-plug/plug the fibre restores connectivity
Further Problem Description:
|
|
Last Modified: | 14-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun79907 | Title: | MAC flap seen in fabricpath domain with ERSPAN |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
MAC flaps seen in fabricpath network coming from same switch ID
L2FM-4-L2FM_MAC_MOVE Mac XXXX.XXXX.XXXX in vlan XX has moved from 312.0.1 to 312.0.0
The switch ID is same - in the above message it is 312 and the LID flaps between 0 and 1
The MAC belongs to the switch itself - some interface VLAN
Conditions:
ERSPAN running on the device whose MAC is flapping
Workaround:
None
Further Problem Description:
This causes no functional impact to traffic or ERSPAN
This issue is no longer seen in 7.0.x code train
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut75399 | Title: | update rdecode.sh to support n3k/5k |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Some nexus platforms lack the tooling necessary to decode tracebacks.
Conditions:
This was seen for nexus 3k, 5k, and 6k.
Workaround:
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: | 7.1(2)N1(0.544), 7.1(2)N1(1), 7.1(2)ZD(0.3), 7.1(2)ZN(0.3), 7.2(1)D1(0.1), 7.2(1)PIB(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv22468 | Title: | Not able to enable Port-track feature |
|
Status: * | Other |
|
Severity: * | 3 Moderate |
Description: | Symptom:
Not able to install Feature port-track, observing library failure.
Conditions:
Feature Port-track
Workaround:
No
Further Problem Description:
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.30) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu25462 | Title: | UDLD NOT to be enabled on the port previously configured fex-fabric |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
UDLD can't be enabled to the access port which previously configured fex-fabric port.
Conditions:
Configure fex-fabric first and then enable UDLD feature
Workaround:
Once disable UDLD feature, then enable UDLD feature again
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.3(0)BZN(0.41), 7.3(0)N1(0.76), 7.3(0)N1(1), 7.3(0)ZN(0.74) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu73687 | Title: | N5k AAA process crash during during accounting |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
AAA feature ON and leave setup for 3-4 days.
when accounting logs reaches threshold and is being archived due to a corner case issue aaa process reloads of the switch.
Conditions:
System kept idle with accounting enabled for 3-4 days and the accounting logs size reaches threshold and in parallel there is some show accounting logs done, this issue can happen.
Workaround:
There are no specific workarounds as this is not 100% re-producible .
Some options: User can try to clear accounting logs in case it has reached a threshold set.
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.0(3)N1(0.28), 7.1(2)N1(0.528), 7.2(1)N1(0.5) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.115), 7.1(2)N1(0.551), 7.1(2)N1(1), 7.1(2)ZN(0.10), 7.2(0)N1(1), 7.2(1)N1(0.23), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut19721 | Title: | logging source-interface loopback does not work for ipv6 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Configuring "logging source-interface loopback" for ipv6 loopback interface does not work. You would see the following error:
N6K-3(config)# logging source-interface loopback 60
Configuring logging source-interface will open UDP/syslog socket(514).
Configuration Failed, no IP address associated with the loopback interface
interface loopback60
description IPV6 Management Loopback
ipv6 address 2001:558:2a0::3/128
Conditions:
ipv6 address is configured on the loopback
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.0(2)N1(1), 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.548), 7.1(2)N1(1), 7.1(2)ZN(0.7), 7.2(0)N1(1), 7.2(1)N1(0.21), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu70037 | Title: | "Tacacs Daemon" crashed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
TACACS Crashed and Core is generated.
Process restarted state full and started accepting the request.
restart count not reached the max restart to do hap reset.
Conditions:
When a very long command as shown in the logs is executed, this issue is seen. The length of the command causes the buffers in TACACS (which are of length 255) to overflow and hence the issue is seen.
Workaround:
No Work around.
We can avoid using longer commands.
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.110), 7.1(2)N1(0.550), 7.1(2)N1(1), 7.1(2)ZN(0.9), 7.2(0)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus52683 | Title: | Port-channel on FEX down when fex-fabric up |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Port-channel interface configured on FEX down when connecting fex-fabric port.
Conditions:
FEX is connected to 2 Nexus 5000 series via vPC(Daul-home).
shutdown the one of vPC port. Then no shutdown on that port.
Workaround:
None.
Further Problem Description:
This defect is under investigation.
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: * | 7.1(3)N1(0.621), 7.1(3)N1(1), 7.1(3)ZN(0.28), 7.3(0)BZN(0.41), 7.3(0)N1(0.75), 7.3(0)N1(1), 7.3(0)ZN(0.73) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu46021 | Title: | security_clear_vty from library libsecuritycli.so exited due to Signal11 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
VSH crash
Conditions:
1. when "cli clear line" is executed as part of Tcl script , which is associated with the scheduler job
2. For repro (or) for more info,
refer the attachment "e_mail_attachment"
Workaround:
Do not run "cli clear line" from schedular
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.357) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.108), 7.1(1)ZN(0.115), 7.1(2)N1(0.536), 7.1(2)N1(1), 7.2(0)N1(1), 7.2(1)N1(0.13), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCus01129 | Title: | Iplus : vpc status shows "DOWN" in the fex uplink port PoCH output |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
vpc status shows "DOWN" in the fex uplink port PoCH output
Conditions:
vpc status shows DOWN in the fex uplink port PoCH output. The vpc status is shown as UP for "show vpc (fex PoCH no)" No traffic impact but is a regression issue.
Workaround:
no
Further Problem Description:
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.418), 7.1(1)N1(0.47) |
|
Known Fixed Releases: | 7.1(1)N1(0.448), 7.1(1)N1(0.76), 7.1(1)N1(1), 7.1(1)ZN(0.2), 7.2(0)N1(0.78), 7.2(0)N1(1), 7.2(0)ZN(0.112), 7.2(0)ZN(0.96), 7.3(0)N1(0.3), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCty77380 | Title: | Logging log timestamps incorrect |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: |
Symptom:Log time stamps are out of sequence.
Conditions:So far these only appear to be FEX messages and we have only been able to reproduce a difference of 5-10 seconds. Customer has seen a 1 hour+ difference
Workaround:None
More Info:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 5.1(3)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf16457 | Title: | Norcal:Applying policy maps is failing with %RPM-2-PPF_SES_VERIFY after |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Issue happens if PBR policies are applied on a SUB interface as soon as the sub-interface is created.
We can encounter this error.
"% Could not apply PBR route-map - L3 interface is not created completely - cannot get vlan resource"
Conditions:
We can hit this issue if we copy asci config to running. [If asci cfg has the commands to create the sub-interface and apply PBR policy on it]
Workaround:
Remove and add PBR policies again.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(0.48) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw40965 | Title: | Expected global command response in nexus platform |
|
Status: | Open |
|
Severity: * | 3 Moderate |
Description: * | $$IGNORE
Symptom:
Expected global command response in nexus platform
Conditions:
Nexus platform should respond the global command "show lldp interface"
Workaround:
Non nexus platform responding the global command response "show lldp interface" response"
Similar that expecting nexus platform.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 7.1(1.97) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq16049 | Title: | fwm process crash with heartbeat failure |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
2014 Jul 21 13:36:46 N5K$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "fwm" (PID 3401) hasn't caught signal 6 (core will be saved).
2014 Jul 21 13:36:46N5K$ VDC-1 %$ %SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "fwm" in vdc 1 has had a hap failure
2014 Jul 21 13:36:57 N5K$ VDC-1 %$ Jul 21 13:36:57 %KERN-0-SYSTEM_MSG: Shutdown Ports.. - kernel
2014 Jul 21 13:36:57 N5K$ VDC-1 %$ Jul 21 13:36:57 %KERN-0-SYSTEM_MSG: writing reset reason 16, fwm hap reset - kernel
Conditions:
the fwm process crash was seen on N5K switch running code 5.2(1)N1(6) and 7.0(5)N1(1).
Workaround:
Further Problem Description:
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: * | 5.2(1)N1(6), 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(7)N1(0.280), 7.0(7)N1(0.282), 7.0(7)N1(1), 7.0(7)ZN(0.157), 7.0(7)ZN(0.159) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo46284 | Title: * | N55xxUP showing SFP uC: Module 1: v0.0.0.0 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
SFP uC: version shown as v0.0.0.0
Conditions:
After upgrading the Nexus 55XXUP, the version will show as v1.0.0.0, but upon bringing the FEXes online, we see that the SFP uC version changes to v0.0.0.0
- This issue is also seen in environments without the FEX or if the switch was connected to FEX anytime in the past.
Workaround:
Two potential workarounds exist:
- Reload the device.
- Run the 'install all' command again to install the v1.0.0.0 uC version and issue a 'reload power-cycle'
Further Problem Description:
If the two switches are in VPC, because of this issue, the switch undergoing upgrade will fail to get upgrade to the new code during the first time. Also because of this failure during install process, vpc role switchover does not happen gracefully and hence vpc secondary suspend its port channels as peer link goes down and thus both vpc switches will shut down the port channels causing an outage, until another upgrade is performed on the concerned switch during which time the switch should upgrade successfully.
|
|
Last Modified: | 26-SEP-2015 |
|
Known Affected Releases: | 5.2(1)N1(5) |
|
Known Fixed Releases: | 7.0(7)N1(1), 7.0(7)ZN(0.124), 7.1(2)N1(0.558), 7.1(2)N1(1), 7.1(2)ZN(0.17), 7.2(1)N1(0.243), 7.2(1)N1(1), 7.2(1)ZN(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw28430 | Title: | Disabling password strength-check does not take effect |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On a Nexus 5000/5500/5600/6000, disabling password strength-check may still cause weak passwords to be rejected.
Conditions:
This is seen after configuring 'no password strength-check'.
Workaround:
Use strong passwords.
Alternatively, copy pasting the encrypted password directly from a different device also is accepted.
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.1(1)N1(1), 7.2(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.640), 7.1(3)N1(0.645), 7.1(3)N1(1), 7.1(3)ZN(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv29358 | Title: | Interface counters on a Nexus 2348 may be erroneous |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
HIF interfaces on a Nexus 2348 may report incorrect counters.
Conditions:
This has been observed with a Nexus 2348.
Workaround:
No known workarounds at this time.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 7.1(1)N1(1), 7.3(0)N1(0.117) |
|
Known Fixed Releases: * | 7.1(3)N1(0.646), 7.1(3)N1(1), 7.1(3)ZN(0.54), 7.2(1)N1(0.318), 7.2(1)N1(1), 7.2(1)ZN(0.80), 7.3(0)N1(1), 7.3(0)ZN(0.121) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCts79415 | Title: | sh int sta mod 4 |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | -Symptom:Unable to execute 'show int module 4'
Conditions:NXOS 5.1.3N1.1
Workaround:"Show interface eth4/1-16 status"
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 5.1(3)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCug28099 | Title: | Enh: Knob to Disbable ports after loop is detected on N5k. |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The Current behavior when loop
(FWM-2-STM_LOOP_DETECT: Loops detected in the network among ports and vlan >vlan_id> - Disabling dynamic learn notifications for 180 seconds)
is detected , is after 120 seconds of loop detection , we would rapid age out all the MAC and then relearn them rather than aging the whole mac address table . Due to this behavior we would not learn the new mac for 120 sec but still if the loops is consistently present it can cause significant impact to network as we would rapid age mac from all vlan.
Conditions:
MAC Flap
Workaround:
none
Further Problem Description:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/sw/layer2/7x/b_5600_Layer2_Config_7x/b_6k_Layer2_Config_7x_chapter_01010.html#task_78C359C5D24F457EB1EE1DA2DCCEE718
For 55XX and 56XX above command was introduced you can configure the action of bringing down the port instead of disabling dynamic learn.
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 5.2(1)N1(3), 6.0(2)N1(2) |
|
Known Fixed Releases: | 6.0(2)N2(1), 7.2(0)ZN(0.111), 7.2(0)ZN(0.93) |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论