| |
|
Alert Type: | Updated * |
Bug Id: | CSCux24542 | Title: | FCoE FLOGI from NPV switch gets LS_RJT due to solicit not done |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: * | Symptom:FCoE FLOGI from NPV switch gets LS_RJT due to FIP solicitation not done. The LS_RJT contains:
Reason Code: 0x09 - "Unable to perform command"
Reason Explanation: 0x29 - "Insufficient Resources for Login"
Conditions:Occurs when there is an FCoE NPV to NPIV link only.
Workaround:Connect the devices involved into the NPIV switch itself.
More Info:None.
Resolution Summary:
To be determined once resolved.
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 6.0(2)N1(2a), 7.0(7)N1(1) |
|
Known Fixed Releases: | 7.1(3)ZN(0.136), 7.1(4)N1(0.701), 7.1(4)N1(1), 7.2(2)N1(0.355), 7.2(2)N1(1), 7.2(2)ZN(0.39), 7.3(0)IZN(0.13), 7.3(0)N1(0.236), 7.3(0)N1(1), 7.3(0)ZN(0.213) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy44439 | Title: | admin on N5K can execute shell commands using tar |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms:
Cisco Nexus devices running an affected version of Cisco NX-OS software contain a local privilege
escalation vulnerability within the command line interpreter (CLI) that could allow an authenticated,
local attacker to execute arbitrary commands on the underlying operating system with user privileges.
The vulnerability exists due to insufficient input sanitization of parameters passed to the tar command
on the CLI of an affected device. An attacker could leverage this behavior to execute arbitrary commands
on the underlying operating system with the privileges of the user authenticated to the device.
Conditions:
Cisco Nexus devices running an affected version of Cisco NX-OS software.
Workaround:
Not available.
Further Problem Description:
Credit:
Cisco would like to thank Jens Krabbenhoeft for discovering and reporting this vulnerability.
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:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:P/I:P/A:P/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2015-4232 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
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 5.2(1)N1(9.179), 7.1(4)N1(0.742), 7.2(2)N1(0.397), 7.3(1)N1(0.37) |
|
Known Fixed Releases: * | 5.2(1)N1(9.182), 5.2(1)N1(9a), 7.1(3)ZN(0.206), 7.1(4)N1(0.748), 7.1(4)N1(1), 7.2(2)N1(0.402), 7.2(2)N1(1), 7.2(2)ZN(0.84), 7.3(1)N1(0.302), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCut56888 | Title: | PCI erros reporting in 5K/6K products |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 600x switch might hang with no response via console, mgmt0 or inband interfaces. In certain NX-OS error messages such as following are printed prior to switch being impacted.
%USER-0-SYSTEM_MSG: 452: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
%USER-0-SYSTEM_MSG: 453: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
%USER-0-SYSTEM_MSG: 454: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
%USER-0-SYSTEM_MSG: 455: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
Conditions:
Seen in Nexus 600x platforms
Workaround:
A debug plugin based workaround exists. Contact Cisco TAC to obtain the workaround.
Further Problem Description:
The correctable error notfication coming from PCI bus have been blocked to feed into NMI path ...
Have implemented a counter based mechanism to implement this
Two new syslogs are added
? ?Bus:Dev.Func 00:01.1 Vendor 0x8086 Device 0x105 is giving out high correctable Error ..? ?Syslog is given out if the device 0x8086 Device 0x105 at Bus 0, device 1 and function1 is found to have correctable error status for 30 seconds continuously.
? ?Bus:Dev.Func 00:01.1 Vendor 0x8086 Device 0x105 showing Invalid Config ...? ? Syslog is given out if device 0x8086 Device 0x105 at Bus 0, device 1 and function1 is found to have invalid configuration
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.1(1)N1(0.445), 7.2(0)N1(0.226), 7.2(0)N1(0.231) |
|
Known Fixed Releases: | 7.0(7)ZN(0.266), 7.0(8)N1(0.322), 7.0(8)N1(1), 7.1(3)N1(4), 7.1(4)N1(0.718), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy61164 | Title: | fwm core with "no int po102" after seeing "%ETHPORT-2-IF_SEQ_ERROR" |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:In a rare instance when ETHPM misses link up/down events in this case for fex NIF link and goes out of sync. Any subsequent triggers to recover fex fabric-po shut/no-shut, fex reload etc., doesn't recover out of sync state. when there is vpc switchover Fex might show down in both vpc switches. Giving "no int po-" for the fex fabric PO results in this crash.
This is rare occurrence not reproducible in lab again.
Conditions:* when Ethpm queue is full with mts messages (when new modules or fex interfaces come online, unstable network) and miss link up/down events.
* vpc switchover, fex reload or fex nif link sh/no-shut
* removing fex fabric po "no int po-x"
Workaround:* We can prevent this crash, when ethpm misses any link up/down events particularly for fex NIF links, avoid triggers like ISSU, vpc switchover, fex reload etc.,
Allow network to stabilize and ethpm queue to drain and recover out of sync links first before proceeding further on maintenance activity.
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.295) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz27269 | Title: | N5K aclmgr hap reset when saving config |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus 5000 may crash because of read of a memory after it is already freed. It seems to be a corner case and doesn't happen always because of the timing.
Conditions:
The crash seems to occur when saving the config.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.2(1)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.261), 7.1(4)N1(0.795), 7.1(4)N1(1), 7.2(2)N1(0.412), 7.2(2)N1(1), 7.2(2)ZN(0.119), 7.3(1)N1(0.339), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur15901 | Title: | N2K-C2348UPQ FEX does not come up due to "SDP timeout/SFP Mismatch" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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
Seen in a N2K-C2248PQ-10GE FEX connected to a Nexus 7K
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)
|
|
Last Modified: | 26-APR-2016 |
|
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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy44281 | Title: | admin on N5K can break out of vsh-"chroot" using symbolic links |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco Nexus devices running Cisco NX-OS software contain a symbolic link vulnerability that could allow a local,
authenticated attacker to break out of the chroot environment that their Virtual Device Context (VDC) has been
assigned. This could result in the attacker gaining the ability to write files to locations that should be restricted to
the context to which they belong. This could also have an extended impact of allowing the attacker to read data
that should be restricted.
Conditions:
Cisco Nexus devices running an affected version of Cisco NX-OS Software
Workaround:
None.
Further Problem Description:
Credit:
Cisco would like to thank Jens Krabbenhoeft for reporting this vulnerability.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 3.2/2.6:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:P/I:P/A:N/E:F/RL:OF/RC:C&version=2.0
No CVE ID has been assigned to 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
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 5.2(1)N1(9.179), 7.1(4)N1(0.742), 7.2(2)N1(0.397), 7.3(1)N1(0.37) |
|
Known Fixed Releases: * | 5.2(1)N1(9.182), 5.2(1)N1(9a), 7.1(3)ZN(0.205), 7.1(4)N1(0.747), 7.1(4)N1(1), 7.2(2)N1(0.402), 7.2(2)N1(1), 7.2(2)ZN(0.84), 7.3(1)N1(0.302), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud31738 | Title: | After issu upgrade, N5k unable to restore link without FC GEM reload |
|
Status: | Terminated |
|
Severity: | 2 Severe |
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.
Symptom:
On a Nexus 5548 equipped with N55-M8P8FP GEM, FC ports are attached to a peer MDS switch in a port-channel. When the ports are flapped or the MDS is reloaded, link is not coming back. FC ports does not re-initialize
Conditions:
A port-channel between Nexus 5548 with N55-M8P8FP GEM and MDS .
Perform ISSU on Nexus switch and flap ports of the port channel.
Workaround:
Reload the GEM module or reload the switch
Further Problem Description:
After an ISSU upgrade, when the ports in the port-channel are flapped they try to reinitialize. The links are stuck in init stage for a while and end in "Error disabled - port reinit limit reached" state. The bug was reproduced in the specified versions. However, the same has been fixed in the 5.2(1)N1(1) and above releases
|
|
Last Modified: | 05-APR-2016 |
|
Known Affected Releases: | 5.1(3)N2(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui12905 | Title: | Nexus 5K Switch Crashes While Zoning Through DCNM |
|
Status: | Terminated |
|
Severity: | 2 Severe |
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.
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 6.0(2)N1(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup49604 | Title: | Multiple hwclock zombie processes triggered by ntp |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Unexpected reload caused by a memory leak
Conditions:
This has been seen when ntp is configured it was noticed that hwclock processes keeps increasing "show process memory.
and leaves a %NETSTACK-3-NO_MEM: netstack [3816] Failed to allocate private memory for message batch buffer before reload.
Workaround:
Disable ntp
Further Problem Description:
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: * | 5.2(1)N1(9.183), 5.2(1)N1(9a), 7.1(0)N1(1), 7.2(0)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz42053 | Title: | N5K Crash in ethpm Due to Memory Leak in libutils.so.0.0.0 |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 5K may experience a crash in the ethpm process. This crash is cuased by a memory leak within this process. The reset reason will show the following:
Reason: Reset triggered due to HA policy of Reset
System version: 7.0(7)N1(1)
Service: ethpm hap reset
Conditions:
Unknown at this time.
Workaround:
Unknown at this time.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv68967 | Title: * | SNMP Timeout on CISCO-RMON-CONFIG-MIB |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
While running CISCO-RMON-CONFIG-MIB (OID: 1.3.6.1.4.1.9.9.103) on Hafnium (N5672-UP-16G) seeing SNMP timeout issue.
Conditions:
Run snmpwalk -c public -v 2c 10.127.119.62 iso.3.6.1.4.1.9.9.103.1.4 on N5672UP-16G
Issue is hit for walk on oids .1.3.6.1.4.1.9.9.109.1.1.1.1.2, .1.3.6.1.4.1.9.9.109.1.1.1.1.6, .1.3.6.1.4.1.9.9.109.1.1.1.1.7, .1.3.6.1.4.1.9.9.109.1.1.1.1.8, .1.3.6.1.4.1.9.9.109.1.1.1.1.9, .1.3.6.1.4.1.9.9.109.1.1.1.1.12 and .1.3.6.1.4.1.9.9.109.1.1.1.1.13.
on setup 12Q, 24Q, 48Q and 96Q where SUP is on slot 0.
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.169), 7.3(0)N1(0.177), 7.3(0)N1(0.56) |
|
Known Fixed Releases: | 7.1(3)N1(4), 7.1(3)ZN(0.202), 7.1(4)N1(0.745), 7.1(4)N1(1), 7.3(0)D1(0.171), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)IZN(0.13), 7.3(0)N1(0.225), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux63041 | Title: | CLI command 'show debug logfile' allows arbitrary file access |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms:
A vulnerability in CLI diagnostic command interface of the Cisco Nexus 5000 and 6000
Series Switches could allow an authenticated, local attacker to have read access to
files which should be restricted.
The vulnerability is due to lack of proper input validation of the user input parameters
of a diagnostic CLI command. An attacker could exploit this vulnerability by authenticating
to the affected device and issuing crafted diagnostic CLI commands. An exploit could allow
the attacker to to have read access to files which should be restricted.
Conditions:
The user must authenticated to a device running affected 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 4.6/3.8:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:C/I:N/A:N/E:F/RL:OF/RC:C&version=2.0
No CVE ID has been assigned to 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
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 7.0(7)ZN(0.262) |
|
Known Fixed Releases: * | 5.2(1)N1(8.173), 5.2(1)N1(9a), 7.0(7)ZN(0.266), 7.0(8)N1(0.313), 7.0(8)N1(1), 7.1(3)ZN(0.152), 7.1(4)N1(0.707), 7.1(4)N1(1), 7.2(2)N1(0.364), 7.2(2)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud56630 | Title: | not able to unload mib using 'no snmp-server load-mib' command |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In NX-OS release 5.2 or 6.x we are unable to unload the mibs using command no snmp-server load-mib
Conditions:
Trying to remove one of the loaded mibs on the nexus switch. Use command show snmp internal loaded mibs to view the list of loaded mibs.
Workaround:
Stop polling the respective mib from snmp server.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.0(0)N1(0.53), 7.2(1)N1(0.259) |
|
Known Fixed Releases: * | 7.2(1)D1(0.10), 7.2(1)D1(0.44), 7.2(1)D1(1), 7.2(1)N1(0.243), 7.2(1)N1(0.277), 7.2(1)N1(1), 7.2(1)ZD(0.38), 7.2(1)ZD(0.8), 7.2(1)ZN(0.41), 7.2(1)ZN(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo69417 | Title: | Nexus 6000/5600: Link degraded messages seen been port and fabric ASIC |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 29-APR-2016 |
|
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), 7.3(0)ZN(0.190) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux30880 | Title: | Auto-config profile stuck PPM Del Wait ascii-cfg-server rollback request |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Profile stuck in "PPM del wait" in output of show fabric database host.
Conditions:
Concurrent profile changes.
Workaround:
Reload the switch.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.1(2)N1(0.599), 7.1(3)N1(1) |
|
Known Fixed Releases: | 7.1(3)N1(3.17), 7.1(3)N1(4), 7.1(4)N1(0.723), 7.1(4)N1(1), 7.2(2)N1(0.381), 7.2(2)N1(1), 7.3(1)N1(0.12), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt10736 | Title: | Traffic from peer-link dropped after secondary reload and pka reconnect |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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.
|
|
Last Modified: | 27-APR-2016 |
|
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) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz34665 | Title: | Example for Dynamic FCoE contains incorrect ISIS metric value |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
The example in the "Increasing the FabricPath Cost for a vPC+ Peer Link for FCF Leafs" section of the Nexus 5K documentation incorrectly states an ISIS metric value of 16777210, while all other places state the correct value of 16777215.
Conditions:
Looking at the "Increasing the FabricPath Cost for a vPC+ Peer Link for FCF Leafs" section of the Nexus 5K documentation.
Workaround:
Use "fabricpath isis metric 16777215" on the vPC Peer Link (MCT) to separate the two fabrics.
Further Problem Description:
This defect is opened to get documentation corrected.
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul02998 | Title: | Update doc for"hard multicast-port-prune-threshold" |
|
Status: * | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Command hardware multicast-port-prune-threshold explanation needs to be documented.
Conditions:
This command is used in scenarios to alleviate egress multicast congestion caused by microbursts.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 6.0(2)N2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux06999 | Title: | N5K Config-Sync shows "in sync" despite "sh run switch-profile" differs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The 'show switch profile status' is In sync, despite 'show run switch-profiles' is different on the pair of N5Ks.
Inspecting CSM database entries (sh system internal csm info switch-profile cfgd-db cmd-tbbl) will show the missing commands, but the CONFIG-T database ( sh system internal csm info global-db cmd-tbl detail), will not have the respective entries for the missing commands.
(e.g)
# sh system internal csm info switch-profile cfgd-db cmd-tbl | grep prod-nic1
parent_seq_no= 5939, seq_no= 5940, clone_seq_no= 0, cmd= 'description
prod-nic1
# sh system internal csm info global-db cmd-tbl detail | grep prod-nic1
'empty output'
For that reason imports will keep failing.
Conditions:
Normal use of config-sync.
In the field, this was noticed after performing multiple ISSU upgrades and applying the workaround for CSCuw61934. Not clear if the issue was historical, or triggered by ISSUs and the changes carried out.
Workaround:
The only known workaround as of now is to:
1) Delete the switch profile
no switch-profile NAME profile-only local
2) Save the current configuration to a file in the bootflash.
Also save to to an external location, as per best practices.
3) Write erase/reload
4) Reconfigure the switch and recreate the switch-profiles
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.266), 7.1(4)N1(0.800), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd58322 | Title: | n5k: cpmCPUTotal5minRev OID returns out of range value |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: * | $$IGNORE
Symptom:
out of range values obtained with cpmCPUTotal5minRev oid
Conditions:
The acceptable range of values for this cpmCPUTotal5minRev is between 0 - 100. On polling this oid, values higher than 100 could be obtained
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: | 4.1(3)N2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui79701 | Title: | Config Sync / Verify Failed / Lock already taken by another session |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:config-sync might intermittently fail when trying to Verify changes
The switch-profile peer is unable to accept lock request due to "Lock already taken by another session" error.
Conditions:This was seen after upgrading a vPC pair of N5Ks from 5.1(3)N1(1) to 5.2(1)N1(4)
Workaround:At this point since the lock is not correctly released in this checkpoint failure state, the recovery is through reload.
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: | 5.2(1)N1(4) |
|
Known Fixed Releases: | 5.2(1)N1(6), 7.0(0)N1(1), 9.9(0)BS(0.13) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun30488 | Title: | N 55K series switch does not show more than 255 tx credits on fc int |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Nexus 5500 switch is displaying on native fc interfaces the tx b2b credits that are in use wrong under the
following condition.
If the other end has the ability to configure more than 240 credits, 240 is the limit on the N5500 switches series.
The N55K will not display more than 255 b2b credits correct.
Conditions:
I.e. MDS connected to N55K via san-port-channel.
MDS configures 500 rx b2b buffers, these are exchanged with the N55K at flogi time. The N55K however displays those as 244. This does not cause a immediate issue but if you would i.e. configured 256 buffers on the mds switch it would show up as 1 on the N55K.
The N55K can not display, handle, more than 255 buffers for the tx b2b credits per fc interface.
Workaround:
configure the number of b2b credits on the partner device, i.e. mds switch, accordingly.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 5.2(1)N1(7) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.246), 7.1(3)ZN(0.256), 7.1(4)N1(0.781), 7.1(4)N1(0.791), 7.1(4)N1(1), 7.2(2)N1(0.407), 7.2(2)N1(0.409), 7.2(2)N1(1), 7.2(2)ZN(0.108), 7.2(2)ZN(0.116) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu85979 | Title: | Inconsistent value in series tag |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
model number in series tag ... such as 'Nexus 5672UP Chassis '
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)RAS(0.1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.106), 7.3(0)D1(1), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)N1(0.143), 7.3(0)N1(1), 7.3(0)OTT(0.55), 7.3(0)PDB(0.74), 7.3(0)RSP(0.7), 7.3(0)RTG(0.88) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux17060 | Title: | N5K xmlma hap reset |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
`show process log`
Process PID Normal-exit Stack Core Log-create-time
--------------- ------ ----------- ----- ----- ---------------
xmlma 3126 N Y Y Fri Jul 10 05:37:09 2015
Conditions:
Unknown at this time.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: | 5.2(1)N1(6) |
|
Known Fixed Releases: * | 5.2(1)N1(9.186), 5.2(1)N1(9a), 6.0(2)N2(4.3), 6.0(2)N2(5b), 7.1(3)ZN(0.217), 7.1(4)N1(0.759), 7.1(4)N1(1), 7.2(2)N1(0.403), 7.2(2)N1(1), 7.2(2)ZN(0.100) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux95821 | Title: | show tech-support fcoe needs to contain all pertinent FC information |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:Enhance show tech-support fcoe so that it includes all FC pertinent information. This should be similar to the MDS show tech-support details
Conditions:Applicable to the Nexus 5000/5600/6000 switches using FC and/or FCoE.
Workaround:Use individual show tech-support commands. For example:
show tech-support zone
show tech-support fcns
show tech-support fcdomain
show tech-support port
etc...
More Info:None.
Resolution Summary:
show tech-support fcoe will now contain the following commands:
show switchname
show inventory
show interface
show topology
show logging log
show logging nvram
show accounting log
show tech-support snmp
show tech-support ha
show tech-support cli
show tech-support cdp
show tech-support issu
show tech-support clis
show tech-support pltfm-config
show tech-support flogi
show tech-support pfstat
show tech-support cfs
show tech-support fcdomain
show tech-support fcs
show tech-support acl
show tech-support port-channel
show tech-support fc2
show tech-support port
show tech-support fc
show tech-support fcoe_mgr
|
|
Last Modified: | 19-APR-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.243), 7.1(4)N1(0.778), 7.1(4)N1(1), 7.2(2)N1(0.407), 7.2(2)N1(1), 7.2(2)ZN(0.107), 7.3(1)N1(0.325), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu83350 | Title: | Evaluation of nexus-5000-all for OpenSSL June 2015 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
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-1788
CVE-2015-1789
CVE-2015-1790
CVE-2015-1792
This bug has been opened to address the potential impact on this product.
Conditions:
NXOS uses OpenSSL 0.9.8 release and is vulnerable.
The LDAP feature uses Open SSL. To disable the LDAP
SSL Authentication feature. LDAP can be disabled or used without SSL
Authentication.
Workaround:
If using features that use SSL/TLS then no workaround.
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.8/6.4
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:F/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
Please check IMPACT_ASSESSMENT attachment for more details.
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 7.1(2) |
|
Known Fixed Releases: * | 5.2(1)N1(8.173), 5.2(1)N1(9a), 7.0(7)N1(1), 7.0(7)ZN(0.161), 7.1(2)N1(0.582), 7.1(2)N1(1), 7.1(2)ZN(0.46) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy44523 | Title: | Hidden cli commands allow access to arbitrary files |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Cisco devices running NX-OS include hidden commands that could allow an authenticated,
local attacker to view arbitrary files on on the underlying operating system. This could
result in the disclosure of critical system information.
The following Cisco Nexus devices are affected:
Cisco Nexus 1000V Series
Cisco Nexus 3000 Series
Cisco Nexus 5000 Series
Cisco Nexus 6000 Series
Cisco Nexus 7000 Series
Conditions:
Cisco Nexus and MDS switches running an affected version of NX-OS software are affected.
Workaround:
Restrict access to trusted users only.
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 4.6/3.8:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:C/I:N/A:N/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2012-4134 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
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 5.2(1)N1(9.179), 7.1(4)N1(0.742), 7.2(2)N1(0.397), 7.3(1)N1(0.37) |
|
Known Fixed Releases: * | 5.2(1)N1(9.182), 5.2(1)N1(9a), 7.1(3)ZN(0.206), 7.1(4)N1(0.748), 7.1(4)N1(1), 7.2(2)N1(0.402), 7.2(2)N1(1), 7.2(2)ZN(0.84), 7.3(1)N1(0.302), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux86335 | Title: | January 2016 OpenSSH Vulnerabilities |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
This product may include a version of OpenSSH that is affected by the vulnerability identified by one or more of the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2016-0777 and CVE-2016-0778
This bug has been raised to investigate the impact to this product.
Conditions:
Device enabled with SSH client support.
See http://www.openssh.com/txt/release-7.1p2 for more details of the OpenSSH vulnerabilities.
Workaround:
None. Avoid use the SSH client command from the NX-OS device.
Further Problem Description:
Additional details about those vulnerabilities can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 5.1/3.8
http://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:H/Au:N/C:P/I:P/A:P/E:F/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
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 5.2(1)N1(9), 6.0(2)N2(7), 7.0(8)N1(0.324), 7.1(4)N1(0.719), 7.2(2)N1(0.375) |
|
Known Fixed Releases: * | 5.2(1)N1(9.175), 5.2(1)N1(9a), 7.0(8)N1(1), 7.1(3)ZD(0.84), 7.1(3)ZN(0.180), 7.1(4)N1(0.728), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup70139 | Title: | N5K fwm hap reset |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 983601 usecs after Wed Jun 18 14:35:19 2014
Reason: Reset triggered due to HA policy of Reset
Service: fwm hap reset
Version: 5.2(1)N1(3)
%SYSMGR-2-SERVICE_CRASHED: Service "fwm" (PID 3358) hasn't caught signal
11 (core will be saved).
%SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "fwm" in vd
c 1 has had a hap failure
Conditions:
this crash was seen on Nexus5548 running code 5.2(1)N1(3)
Workaround:
there is no workaround
Further Problem Description:
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 5.2(1)N1(3) |
|
Known Fixed Releases: * | 5.2(1)N1(9.178), 5.2(1)N1(9a), 7.0(7)N1(0.66), 7.0(7)N1(1), 7.0(7)ZN(0.142), 7.1(2)N1(0.547), 7.1(2)N1(1), 7.1(2)ZN(0.6), 7.2(1)N1(0.242), 7.2(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw48559 | Title: | Nexus 5K: Change fan detection logic |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In Nexus 55xx switches, fans stop getting detected by the switch even though the fans are present in the system and spinning. if this condition is hit, messages such as following will be printed and the switch will shut down even though the fans are present and spinning.
2015 Mar 19 22:13:44.791 Nexus5548UP %$ VDC-1 %$ %NOHMS-2-NOHMS_ENV_ERR_FAN_DOWN: System minor alarm on fans: One fan missing or failed
2015 Mar 19 22:13:44.792 Nexus5548UP %$ VDC-1 %$ %PFMA-2-PFMA_FAN_REMOVED: Fan module 1 N5548P-FAN removed
2015 Mar 19 22:13:45.015 Nexus5548UP %$ VDC-1 %$ %PFMA-0-SYS_SHUTDOWN_FAN_REMOVAL: System shutdown in 60 seconds due to fan removal
2015 Mar 19 22:13:45.015 Nexus5548UP %$ VDC-1 %$ %NOHMS-2-NOHMS_ENV_ERR_FANS_DOWN: System major alarm on fans: Multiple fans missing or failed
2015 Mar 19 22:13:45.017 Nexus5548UP %$ VDC-1 %$ %PFMA-2-PFMA_FAN_REMOVED: Fan module 2 N5548P-FAN removed
2015 Mar 19 22:13:50.012 Nexus5548UP %$ VDC-1 %$ %PFMA-0-SYS_SHUTDOWN_FAN_REMOVAL: System shutdown in 55 seconds due to fan removal
2015 Mar 19 22:13:55.013 Nexus5548UP %$ VDC-1 %$ %PFMA-0-SYS_SHUTDOWN_FAN_REMOVAL: System shutdown in 50 seconds due to fan removal
Conditions:
Unknown
Workaround:
None
Further Problem Description:
The problem is seen due to system micro-controller not seeing fans even though it records the fan speed RPM. As part of this bug fix, the fan detection logic has been made more robust by also looking at RPM readings.
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 5.2(1)N1(7) |
|
Known Fixed Releases: * | 5.2(1)N1(9.177), 5.2(1)N1(9a), 7.0(7)N1(0.307), 7.0(7)ZN(0.266), 7.0(8)N1(1), 7.1(3)N1(0.656), 7.1(3)N1(1), 7.1(3)ZN(0.64), 7.2(2)N1(0.5), 7.2(2)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua04442 | Title: | Nexus 5000: vFC down does not trigger callhome alert |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a Nexus 5000/5500 switches configured for FCoE, callhome alerts are not seen for vFC down events
after a NX-OS upgrade to 5.1(3)N1(1) or 5.1(3)N2(1).
Conditions:
Workaround:
None
Further Problem Description:
Callhome alert for vFC down relies on severity 2 syslog message %PORT-2-IF_DOWN_ERROR_DISABLED:
%$VSAN x%$ Interface vfc x is down (Error disabled) and this message is missing in NX-OS 5.1
|
|
Last Modified: | 12-APR-2016 |
|
Known Affected Releases: | 5.1(3)N2(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.237), 7.1(4)N1(0.773), 7.1(4)N1(1), 7.2(2)ZN(0.103), 7.3(1)N1(0.321), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub16077 | Title: | FRAME DISCARD message seen after bringing up multi-hop FCoE vfc intf |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Nexus 5000 switch configured to be in NPV mode might print following messages every 20 minutes for
NP mode vFC interfaces.
2012 Aug 2 23:00:17 20-08-5548-B %NPV-5-FRAME_DISCARDED: %$VSAN 200%$ Frame with unexpected FC2 status 0xc received on interface vfc548
2012 Aug 2 23:20:17 20-08-5548-B %NPV-5-FRAME_DISCARDED: %$VSAN 200%$ Frame with unexpected FC2 status 0xc received on interface vfc548
Conditions:
Nexus 5000 switch has NPV mode configured and multi-hop FCoE is configured with NP vFC interfaces.
Workaround:
Messages does not have any impact. Logging level could be changed to warnings with command logg level npv 4
Further Problem Description
f the nexus 5k switch is in npv mode with native FC interfaces configured with upstream NPIV switch and if the same errors occurs for FC interfaces going to upstream NPIV switch the problem is tracked via
CSCtz79193 Frame discard observed in NPV when NP is brought up.
Further Problem Description:
|
|
Last Modified: | 23-APR-2016 |
|
Known Affected Releases: | 6.0(2)N1(0.292) |
|
Known Fixed Releases: * | 6.0(2)A1(1), 6.0(2)U1(1), 7.1(3)ZN(0.258), 7.1(4)N1(0.793), 7.1(4)N1(1), 7.2(2)N1(0.411), 7.2(2)N1(1), 7.2(2)ZN(0.118), 7.3(1)N1(0.338), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui73960 | Title: | N5k: Scrambled logs in logfile based on the timestamp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Log messages in local logfile buffer are not sorted properly based on their timestamp. The "sort" pipe option sorts them better but still not in the fully sorted way.
Conditions:
This was first observed on Nexus 5000 switches running 6.0(2)N1(2) and is seen after changing logging monitor level using command. This issue is present in 6.x and 7.x releases.
Workaround:
Back up current log messages and clear logging buffer using command "clear logging log"
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 5.1(3)N1(1), 6.0(2)N1(2), 6.0(2)N3(0.340), 7.0(5)N1(0.184) |
|
Known Fixed Releases: * | 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)SIB(99.109), 7.2(0)AB(9), 7.2(0)BA(0.12), 7.2(0)CF(0.11), 7.2(0)D1(0.426), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)N1(0.121) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu99943 | Title: | N5k : fwm hap reset |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
fwm process experiences a crash and in turn forces other processes to exit
Conditions:
This has been noticed when the 'show tech details' command is issued
switch# show tech-support details > bootflash:shtechdet.txt
switch# show tech-support details > bootflash:shtechdet.txt
[ 601.600579] Shutdown Ports..
[ 601.634937] writing reset reason 16, fwm hap reset
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: * | 7.3(1)N1(0.341), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty11635 | Title: | Error message after ISSU - FCP_ERRFCP_PORT: gat_fcp_utils_exp_log@30 |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
Below error message might appear after ISSU on Nexus 5000
%KERN-3-SYSTEM_MSG: FCP_ERRFCP_PORT: gat_fcp_utils_exp_log@30,
The frequency of the error message is random
Conditions:
After ISSU on Nexus 5000
Workaround:
None. This bug does not have functional impact
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: * | 5.0(3)N2(2b), 6.0(2)N2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh78381 | Title: | SAN Port-channel reports as going down when a member link fails |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
San-port-channel reports as going down in the logs.
Conditions:
When one of the member links of the san-port-channel fails, the logs indicate that san-port-channel is down.
Workaround:
None at this time.
Further Problem Description:
|
|
Last Modified: | 04-APR-2016 |
|
Known Affected Releases: | 5.0(3)N1(1c), 5.2(1)N1(2) |
|
Known Fixed Releases: | 7.1(3)ZN(0.227), 7.1(4)N1(0.766), 7.1(4)N1(1), 7.2(2)N1(0.403), 7.2(2)N1(1), 7.2(2)ZN(0.96), 7.3(1)N1(0.313), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw96661 | Title: | N5K not able to suppress Sev5 syslog messages related with connected FEX |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Configuring syslog levels and can't suppress syslog message for the following message
%LLDP-FEX102-5-SERVER - adds or removals
(config)# logging level fex ?
config)# logging level lldp ?
<0-7> 0-emerg;1-alert;2-crit;3-err;4-warn;5-notif;6-inform;7-debug
The same issue is observed with the following message:
%LACP-FEX101-5-LACP_SUSPEND_INDIVIDUAL: LACP port Ether
net101/1/2(0x1f640040) of port-channel port-channel1(0x16000000) not receiving a
ny LACP BPDUs suspending (individual) port
It is observed even when the logging level is 1 for all the facilities. Thus it does not depend on the severity level, it is always present.
Conditions:
LLDP hosts go online/offline. LACP link is bounced.
syslog configured
Workaround:
none
More Info:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 5.1(3)N1(1), 5.1(3)N2(1) |
|
Known Fixed Releases: * | 5.2(1)N1(6), 6.0(2)N2(4.59), 6.0(2)N2(5), 7.0(0)N1(0.368), 7.0(0)N1(1), 7.0(0)ZN(0.88), 7.1(0)ZN(0.281), 7.2(0)ZN(0.111), 7.3(1)D1(0.46), 7.3(1)N1(0.329) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz10788 | Title: | N5k transceiver det. show incorrect link length supported for OM3 cable |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Nx5548U with DS-SFP-FC8G-SW reporting incorrect link length supported for OM3 cable in the show int x/x transceiver details. We should see 150 meters but the capture shows 50 meters (which would be correct with OM2).
Link length supported for 50/125mm fiber is 50 m
Link length supported for 62.5/125mm fiber is 20 m
Conditions:
Issue was found with Nexus5000 series, DS-SFP-FC8G-SW and OM3 cable.
Workaround:
Issue is cosmetic, no known workarounds.
Further Problem Description:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(1)N1(0.244), 6.0(2)N1(0.234), 7.1(4)N1(0.9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz29352 | Title: | copp config isn't in show run all |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
show run all doesn't show config about copp
Conditions:
Nexus5672
NXOS7.2(0)N1(1) ,7.3(0)N1(1)
Workaround:
use "show copp status" to check applied copp policy
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.2(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz13727 | Title: | Make syslog EPP-5-EPP_TRUNK_PROTOCOL_STATUS critical |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
This is an enhacement request to change the severity level of the following syslog message from notificaiton
EPP-5-EPP_TRUNK_PROTOCOL_STATUS
to critical
EPP-2-EPP_TRUNK_PROTOCOL_STATUS
Conditions:
Workaround:
Further Problem Description:
Resolution Summary:
To be completed when the enhancement is completed.
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 7.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw02613 | Title: | no shut twice when PP with shut is applied to admin down interface |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When a port-profile with "shutdown" is applied to an already admin down interface, it is required to do "no shut" twice to bring the interface to admin up
Conditions:
This behavior was seen in 7.0(6) and does not apply to 7.2 releases
Workaround:
Remove the "shutdown" from the port-profile or the interface before applying the port-profile
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.266), 7.1(4)N1(0.800), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy80838 | Title: | "errdisable recovery cause security-violation" for N5k/N6k |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
dot1x configured Port can go into sec-violation state.
Conditions:
dot1x configured Port can go into sec-violation state due to different error conditions. one such condition is when we have a single host mode and receive packets with more than one source MAC address.
Workaround:
flap the port through "shut" and "no shut" to recover from error disabled state.
Further Problem Description:
We need to enable support "errdisable recovery cause security-violation" config so that ports which are error-disabled due to sec-violation would auto-recover. This config is available in N7K but missing in N5K/N6K platforms.
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(1)N1(0.308) |
|
Known Fixed Releases: | |
|
|
| |
没有评论:
发表评论