| |
|
Alert Type: | Updated * |
Bug Id: | CSCus64364 | Title: | N5K: carmelusd component got cored on O2 switch |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
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.
|
|
Last Modified: | 06-JAN-2016 |
|
Known Affected Releases: * | 5.2(1)N1(6), 7.1(1)N1(1) |
|
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)N1(1), 7.1(2)ZN(0.25), 7.2(1)N1(0.245), 7.2(1)N1(1), 7.2(1)ZN(0.11), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur11599 | Title: | Nexus 5k/6k - Memory leak in pfstat process causing hap reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Polling SVI If-Index to collect packet statistics via SNMP.
Or,
using CLI "show interface [vlan #] counter [detail]"
The above results in memory leak in pfstat process. Once process runs out of its designated memory space, leads to crash/hap reset.
Symptom:
Memory leak in pfstat process results in HAP reset.
Reason: Reset triggered due to HA policy of Reset
Service: pfstat hap reset
Conditions:
Polling SVI If-Index to collect packet statistics via SNMP.
Or,
using CLI "show interface [vlan #] counter [detail]"
The above results in memory leak in pfstat process. Once process runs out of its designated memory space, leads to crash/hap reset.
Switch should be operating in L2 mode (no L3 license) to hit the issue.
Workaround:
Excluding SVI if_indexes from SNMP polling for interface statistics collection. Avoiding running "show interface counter" globally or for SVI.
The ifindex OID is 1.3.6.1.2.1.2.2.1.1. So excluding this OID should prevent the issue (although it has not yet been confirmed).
Further Problem Description:
|
|
Last Modified: | 01-FEB-2016 |
|
Known Affected Releases: | 6.0(2)N2(6), 7.0(3)N1(0.125) |
|
Known Fixed Releases: | 7.0(1)ZN(0.684), 7.0(6)N1(0.194), 7.0(6)N1(1), 7.1(0)EVN(0.18), 7.1(0)N1(0.372), 7.1(0)N1(1), 7.1(0)ZN(0.445), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.2(0)N1(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv32204 | Title: | SNMPd Memory Leak in libport_mgr_common |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Memory held by SNMPd increases over time, eventually resulting in an snmpd hap reset, with memory held under the "libport_mgr_common" process:
show system internal snmp mem-stats detail
Private Mem stats for UUID : Non mtrack users(0) Max types: 304
--------------------------------------------------------------------------------
TYPE NAME ALLOCS BYTES
CURR MAX CURR MAX
88 [r-xp]/isan/plugin/0/isan/lib/libnetsnm 1443 1446 362088 501842
102 [r-xp]/isan/plugin/0/isan/lib/libport_m 372760 372765 186007240 186009916 <<<<<<<<
Conditions:
doing continuous snmpget on entSensorThresholdSeverity [1.3.6.1.4.1.9.9.91.1.2.1.1.2]
Workaround:
Instead use snmpwalk
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 7.1(1)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.7), 7.3(0)N1(0.152), 7.3(0)N1(1), 7.3(0)ZN(0.140) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui34757 | Title: | Nexus 5k acting as an NTP Client does not sync with an NTP server |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 19-JAN-2016 |
|
Known Affected Releases: | 5.1(3)N2(1), 5.2(1)N1(5) |
|
Known Fixed Releases: | 5.2(1)N1(6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv20660 | Title: | NetApp: Response to VLAN Request seen after vfc port was shut |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Response to VLAN Request seen even after vfc port was shut.
Conditions:
Shut the VFC and send VLAN request from the host.
Workaround:
if VFC is not required, then we can delete the VFC instead of just shutting it down.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.3(0)N1(0.208) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.158), 7.1(4)N1(0.713), 7.1(4)N1(1), 7.2(2)N1(0.369), 7.2(2)N1(1), 7.2(2)ZN(0.52), 7.3(0)IZN(0.13), 7.3(0)N1(0.264), 7.3(0)N1(1), 7.3(0)ZN(0.240) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul85203 | Title: | N5K Port in Internal-Fail errDisable : fu ha standby message queued |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
N5k Port connected to N1110X goes to "Internal-Fail errDisable" state if the N1110 Appliance is powered off for HA Testing.
-----
this symptom will also happen when partner device is nexus.
Conditions:
Nexus 5000 ( 5548 )
Ver : 6.0(2)N2(1)
Feature LLDP is turned off
Feature FCoE is turn on
Workaround:
Turn on LLDP
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 6.0(2)N2(1), 7.3(0)N1(0.141) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.157), 7.1(4)N1(0.712), 7.1(4)N1(1), 7.2(2)N1(0.368), 7.2(2)N1(1), 7.2(2)ZN(0.51), 7.3(0)IZN(0.13), 7.3(0)N1(0.242), 7.3(0)N1(0.262), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus89236 | Title: | Nexus 5672UP unable to ping other side ip after link flap |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.2(1)N1(0.319), 7.2(1)N1(1), 7.2(1)ZN(0.81), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy03675 | Title: | Nexus crash in FCS process |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Crash on nexus device due to FCS process
Conditions:
Customer is using fabric channel
Workaround:
Unknown
Further Problem Description:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 7.1(3)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw53377 | Title: | Nexus5672 WCCP process crash |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
WCCP process crash when wccp appliance disconnected and core generated
Conditions:
when wccp appliance disconnected/ reconnected
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.307), 7.0(7)ZN(0.266), 7.0(8)N1(1), 7.1(3)ZN(0.115), 7.1(4)N1(0.689), 7.1(4)N1(1), 7.2(2)N1(0.339), 7.2(2)N1(1), 7.2(2)ZN(0.22), 7.3(0)IZN(0.13) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw48786 | Title: | Kernel crash |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
N6K running 6.0(2)N2(4) crashing due to kernel panic.
Conditions:
Trigger not known.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 14-JAN-2016 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux46009 | Title: | Nexus 802.1x: suffix delimited with @ is not sent in RADIUS request |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Username suffix delimited by '@' is stripped off in RADIUS acces-request.
Conditions:
Dot1x authentication on N5k, username contains domain name.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(2)N1(0.1) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.266), 7.0(8)N1(0.311), 7.0(8)N1(1), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo66649 | Title: | bigsurusd core on adding member port to portchannel |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
add a member port to port channel may trigger a bigsurusd hap reset.
Conditions:
port channel was being configured including force option
Workaround:
try without force option
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 7.0(3)N1(0.47), 7.0(6)N1(0.272) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.156), 7.1(4)N1(0.711), 7.1(4)N1(1), 7.2(2)N1(0.369), 7.2(2)N1(1), 7.2(2)ZN(0.52) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCup76173 | Title: | 240/249 ERROR: Timer expired on replay config cfs hap reset at syscall() |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The Cisco Fabric Services (cfs) process could unexpectedly crash following a port-profile crash due to CSCuv58843:
%SYSMGR-2-SERVICE_CRASHED: Service "port-profile" (PID 3709) hasn't caught signal 11 (core will be saved).
%SYSMGR-2-SERVICE_CRASHED: Service "cfs" (PID 3952) hasn't caught signal 6 (core will be saved).
Conditions:
A port-profile crash occurs after a config-sync switchport trunk config change (as outlined in CSCuv58843). CFS then crashes ~1-2 minutes later.
Workaround:
Avoid the conditions that trigger CSCuv58843.
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.240) |
|
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.356), 7.2(2)N1(1), 7.2(2)ZN(0.40) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw28001 | Title: | Switch reloads while ND ISSU with Lacp failure-maximum downtime exceeded |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ISSU failure on N5672-8G switch during ISSU with error of LACP failure of "maximum downtime exceeded"
The below string will be displayed to the user:-
"Upgrade has failed. Return code 0x40930085 (lacp failure - maximum downtime exceeded)"
Rebooting the switch to recover.
[ 230.307510] Shutdown Ports..
[ 230.342086] writing reset reason 3, ISSU failure: 0x40930085
Conditions:
During ISSU on 5672-8G switch.
Workaround:
None
Further Problem Description:
The LACP failure in this case was happening due to microcontrollers(these microcontrollers are used to access SFPs, only the control(LED status, SPROM data of SFP etc..) not the LOS/Datapath- datapath is controlled by bigsur) getting timedout during ISSU just after kexec of new kernel. These controllers are enumerated as USB devices in the kernel and need to re-probe and sync with the new kernel, some times these devices fail to get initialized and as the timeout for USB operations was 45 secs and in 5672 there are 3 microcontrollers and hence was causing a delay of more than 80 secs which is the maximum downtime for LACP.
The reason for USB devices not responding is not clear and the failure is not consistent and as of now its reproduced more often on 5672UP platform only.
Fix
====================================
There are 2 approaches taken for fixing the issue completely.
1. USB timeout is being reduced from 45 secs to around 2 sec.
2. If any of the device fails to respond, the a list of these devices is maintained in the kernel which will be fetched by the PFMA module during te system image bootup which will perform the reset of the device to bring it to operational state.
These USB devices (microcontrollers used to access SFP) dont impact the datapath of the interface, hence wont have any impact on the interface functionality. This fix is applicable only for 5672-8G
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.131) |
|
Known Fixed Releases: | 7.1(3)N1(1.5), 7.1(3)N1(2), 7.3(0)N1(0.221), 7.3(0)N1(1), 7.3(0)ZN(0.198) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw24211 | Title: | DHCP offer pkt getting dropped post ISSU frm 6.0.2.N2.7 to 7.0.6.N1.1 |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
DHCP Offer Broadcast packet getting dropped post ISSU
Conditions:
ISSU to 7.0 branch from earlier branch
Workaround:
remove and apply ip dhcp relay
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.113) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv68534 | Title: | WCCP crashing in the steady state w/o any user induced trigger |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
WCCP with multiple clients crashing WCCP in nexus
Conditions:
WCCP running with multiple clients crashing if left for long time
Workaround:
No workaround
Further Problem Description:
Due to Wave server not updating the correct receive id, wccp session was flapping.
Here_I_Am packet from 10.10.10.2 w/bad recive_id 0x0. Expected 0x94
FSM states are save for future recovery.
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.97) |
|
Known Fixed Releases: | 7.0(7)N1(0.306), 7.0(8)N1(1), 7.1(3)N1(0.642), 7.1(3)N1(1), 7.1(3)ZN(0.50), 7.2(2)N1(0.356), 7.2(2)N1(1), 7.2(2)ZN(0.40), 7.3(0)N1(0.130), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw51093 | Title: | WCCP redirection should be applied for layer 3 routed packets |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Whenever the client side SVI on the nexus switches is active on the switch 1A the client (Router 1B)'s packets do not get redirected to the wccp recipient.
Conditions:
NEXUS 5600 running on 7.1.1
Workaround:
N/A
Further Problem Description:
WCCP redirection happens incorrectly on layer 2 switched packets whereas it has to be applied only for layer 3 routed packets.
WCCP should be applied for routed packets in HSRP active switch. When packets are received by a standby switch, it shall L2 forward the packets and HSRP active shall apply the WCCP redirection.
While applying wccp redirection, both in active and standby hsrp switch, redirection is applied to all matching packets whether the packet is destined to be L2 switched or routed.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.1(1)N1(0.8) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.266), 7.0(8)N1(0.313), 7.0(8)N1(1), 7.1(3)ZN(0.138), 7.1(4)N1(0.703), 7.1(4)N1(1), 7.2(2)N1(0.357), 7.2(2)N1(1), 7.2(2)ZN(0.41), 7.3(0)IZN(0.13) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux33230 | Title: | "ipqosmgr hap reset" during ISSU 7.1(2)N1(1)->7.1(3)N1(1) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Switch crash:
Reason: Reset triggered due to HA policy of Reset
System version: 7.1(3)N1(1)
Service: ipqosmgr hap reset
Conditions:
ISSU 7.1(2)N1(1)->7.1(3)N1(1)
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.1(3)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(1.3), 7.1(3)N1(2), 7.1(3)ZN(0.157), 7.1(4)N1(0.712), 7.1(4)N1(1), 7.3(0)IZN(0.13), 7.3(0)N1(0.246), 7.3(0)N1(1), 7.3(0)ZN(0.222) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw73332 | Title: | VTPv3 mode changes from client to transparent after PVLAN creation |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VTPv3 mode changes from client to transparent:
2015 Oct 14 17:27:22 Nexus5500 %VTP-2-VTP_MODE_TRANSPARENT_CREATE_SEQ_FAILED: VTP Mode changed to transparent since VTP vlan create/update failed.
Conditions:
VTPv3 Primary Server is configured on Catalyst 4900M switch.
Nexus switches have at least one port with the following configuration:
* switchport mode private-vlan trunk promiscuous
* switchport private-vlan trunk allowed vlan A,B-C,D
* switchport private-vlan mapping trunk X Y-Z
Workaround:
None at the moment.
Further Problem Description:
After the PVLAN is added on the VTPv3 Primary Server, we can see that PVLAN resources are locked on the Nexus 5500 switches until eventually there is a timeout and the VTPv3 mode changes from client to transparent.
Nexus5500# show system internal private-vlan info
System info:
------------
Global LOCKED
Private VLANs
------------
private-vlan 1:1800 vlan-type is "unknown(8)" LOCKED primary=0, otxns=1
state: PVLAN_VLAN_STATE_NORMAL_TO_PRIMARY_VLAN_MGR
associations(0):
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(0)N1(1) |
|
Known Fixed Releases: * | 7.2(2)N1(0.341), 7.2(2)N1(1), 7.2(2)ZN(0.24), 7.3(0)IZN(0.13), 7.3(0)N1(0.219), 7.3(0)N1(1), 7.3(0)ZN(0.196) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux10337 | Title: | N2348TQ tiburon fex devices crash repeatedly |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
N2348TQ fex device resets unexpected.
Conditions:
No additional symptoms are known at this point in time.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1), 7.3(0)N1(0.46), 7.3(0)N1(0.47), 7.3(0)N1(0.50) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.266), 7.0(8)N1(0.313), 7.0(8)N1(1), 7.1(3)ZN(0.128), 7.1(4)N1(0.693), 7.1(4)N1(1), 7.2(2)N1(0.345), 7.2(2)N1(1), 7.2(2)ZN(0.28), 7.3(0)IZN(0.13) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun34005 | Title: | Nexus2k/5k/6k: Continuous memory leak messages seen for ethpm |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Possible memory leak messages for ethpm are observed.
Exemplary logs:
%$ VDC-1 %$ Feb 25 06:32:17 %KERN-2-SYSTEM_MSG: [20640.784304] [sap 175][pid 3969][comm:ethpm] WARNING: possible memory leak is detected on pers queue (len=649,bytes=15825069) - kernel
%$ VDC-1 %$ Feb 25 06:32:27 %KERN-2-SYSTEM_MSG: [20650.122663] [sap 175][pid 3969][comm:ethpm] WARNING: possible memory leak is detected on pers queue (len=647,bytes=15773045) - kernel
Conditions:
This problem was observed on the Nexus 5000 after pasting the configuration with 500+ vlans to the running-config.
Also config replay of these vlans are extremely slow (might take a few hours to complete).
Workaround:
copy the config from a temporary file to startup config and reload the switch for the configs to take effect.
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 7.0(1)N1(0.106), 7.0(6)N1(0.185), 7.1(3)N1(0.647), 7.1(3)N1(0.662), 7.2(0)N1(0.111), 7.2(0)N1(0.180), 7.2(1)N1(0.313) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.155), 7.1(4)N1(0.710), 7.1(4)N1(1), 7.2(2)N1(0.382), 7.2(2)N1(1), 7.2(2)ZN(0.64), 7.3(0)N1(0.221), 7.3(0)N1(1), 7.3(0)ZN(0.198) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy03620 | Title: | NTP is not syncronize with remote server |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
MZ-DC-SW-410A# show ntp peer-status
Total peers : 2
* - selected for sync, + - peer mode(active),
- - peer mode(passive), = - polled in client mode
remote local st poll reach delay
----------------------------------------------------------------------
=10.195.3.1 0.0.0.0 1 16 377 0.00117
=10.199.9.129 0.0.0.0 1 16 377 0.00093
MZ-DC-SW-410A# show ntp statistics peer ipaddr 10.199.9.129
remote host: 10.199.9.129
local interface: Unresolved
time last received: 13s
time until next send: 16s
reachability change: 8421s
packets sent: 96565
packets received: 107096
bad authentication: 0
bogus origin: 0
duplicate: 0
bad dispersion: 0
bad reference time: 0
candidate order: 6
Source interface: 10.197.202.1
MZ-DC-SW-410A#
MZ-DC-SW-410A#
MZ-DC-SW-410A# show ntp statistics peer ipaddr 10.195.3.1
remote host: 10.195.3.1
local interface: Unresolved
time last received: 48s
time until next send: 2s
reachability change: 8440s
packets sent: 96658
packets received: 107174
bad authentication: 0
bogus origin: 0
duplicate: 0
bad dispersion: 0
bad reference time: 0
candidate order: 4
Source interface: 10.197.202.1
Conditions:
Z-DC-SW-410A# 2016 Jan 27 14:40:10.242594 ntp: Sending cmi response with return_code = 0x0
2016 Jan 27 14:40:10.242919 ntp: setting global CMI msg req to NULL
2016 Jan 27 14:41:38.862624 ntp: SYS-MCLOCK-GET-TSPEC(tv_sec=88063574, tv_nsec=257696214)
2016 Jan 27 14:41:38.863151 ntp: Sending Time of day upd to standby
2016 Jan 27 14:43:08.880709 ntp: SYS-MCLOCK-GET-TSPEC(tv_sec=88063664, tv_nsec=275781895)
2016 Jan 27 14:43:08.881239 ntp: Sending Time of day upd to standby
2016 Jan 27 14:47:38.929061 ntp: Sending Time of day upd to standby
2016 Jan 27 14:49:08.944329 ntp: SYS-MCLOCK-GET-TSPEC(tv_sec=88064024, tv_nsec=339401699)
2016 Jan 27 14:49:08.944846 ntp: Sending Time of day upd to standby
MZ-DC-SW-410A# 2016 Jan 27 14:47:38.928538 ntp: SYS-MCLOCK-GET-TSPEC(tv_sec=88063934, tv_nsec=323610039)
2016 Jan 27 14:47:38.929061 ntp: Sending Time of day upd to standby
2016 Jan 27 14:49:08.944329 ntp: SYS-MCLOCK-GET-TSPEC(tv_sec=88064024, tv_nsec=339401699)
2016 Jan 27 14:49:08.944846 ntp: Sending Time of day upd to standby
2016 Jan 27 14:50:38.960177 ntp: SYS-MCLOCK-GET-TSPEC(tv_sec=88064114, tv_nsec=355249620)
2016 Jan 27 14:50:38.960702 ntp: Sending Time of day upd to standby
2016 Jan 27 14:52:08.976150 ntp: SYS-MCLOCK-GET-TSPEC(tv_sec=88064204, tv_nsec=371222489)
2016 Jan 27 14:52:08.976679 ntp: Sending Time of day upd to standby
2016 Jan 27 14:53:38.992665 ntp: SYS-MCLOCK-GET-TSPEC(tv_sec=88064294, tv_nsec=387737888)
2016 Jan 27 14:53:38.993190 ntp: Sending Time of day upd to standby
Workaround:
1 Workaround but not solve the problem.
1. Type "no ntp peer"
2. Reenter complete configuration of "ntp peer use-vrf management"
2 Change the configurantions.
Before:
ntp distribute
ntp server 10.195.3.1 use-vrf management
ntp server 10.199.9.129 prefer use-vrf management
ntp source-interface mgmt0
ntp commit
After:
ntp distribute
ntp server 10.195.3.1
ntp server 10.199.9.129 prefer
ntp source-interface mgmt0
ntp commit
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 4.2(1)N2(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun45981 | Title: | L3 N5K: Inbound and output ICMP frames on different ports |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
ICMP Echo Request and Reply using different Inband ports.
For N5k/N6k this is observed since 7.x releases. While for N6k this may be observed in 6.x releases as well.
Conditions:
Ethanalyzer capture shows ICMP Requests coming from network are seen in Inband-Low Q, while reply is seen in Inband-Hi Q
Workaround:
ICMP flows might now have to be tracked on both Inband ports till this is fixed. There is no impact in respect to handling of traffic.
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 7.0(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)N1(0.287), 7.0(7)N1(1), 7.0(7)ZN(0.166), 7.0(7)ZN(0.167), 7.1(0)AV(0.38), 7.1(0)PDB(0.317), 7.1(0)SIB(99.82), 7.1(2)N1(0.549), 7.1(2)N1(1), 7.1(2)ZD(0.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux56823 | Title: | Wrong default warntime and gracetime on upgrading from 7.2.1 to 7.3.0 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Existing users are assigned warntime of 7 instead of 14 and no default gracetime instead of 3 days.
Conditions:
While upgrading or reloading from 7.2(1) to 7.3(0), the default warntime and default gracetime is set incorrectly for existing users. Default warntime is set to 7 instead of 14 and no gractime instead of 3 days.
Workaround:
Change the default wartime and gracetime manually and update the same for all existing users.
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.238) |
|
Known Fixed Releases: * | 7.3(1)N1(0.15), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus71581 | Title: | need to copy cores from show cores into bootflash by default |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
N5K switch cannot save more than 1 core dump under show cores command. Cores may be lost when reloading.
Conditions:
When device crashes more than once and/or a reload occurs.
Workaround:
no workaround
Further Problem Description:
This defect is to add a 'system core bootflash:' command similar to N3K and enable it by default. This will automatically copy the core to bootflash when crashing so it will not be lost.
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 6.0(2)N2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw31547 | Title: | N5k/N6k stale param-lists in config which user cannot |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Unable to delete stale param-list manually with the no command:
Leaf11(config)# no param-list param_list_name_instance_vni_30000_205
ERROR: Parameter instance being used cannot be deleted
Leaf11(config)# no param-list param_list_name_instance_vni_30004_4
ERROR: Parameter instance being used cannot be deleted
Leaf11(config)# no param-list param_list_name_instance_vn
Conditions:
This error was seen after copy run start and reload of leaf nodes, it is possible that stale \
param-lists remain and cause the issues with future instantiations of vlans.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | 7.1(3)N1(0.671), 7.1(3)N1(1), 7.1(3)ZN(0.83), 7.3(0)IZN(0.7), 7.3(0)N1(0.151), 7.3(0)N1(1), 7.3(0)ZN(0.139) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw83308 | Title: | Need to support leading underscore as username in N5k/N6k |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Can not create a username starting with _ (underscore)
Conditions:
When a username is created starting with _ (underscore) it throws an exrror,
and the user is not created
Workaround:
None
Further Problem Description:
Usernames with leading "_" are being allowed from 7.3 release onwards on Nexus 5k/6k. Any downgrade to previous releases (like 7.2 or 7.1) would lead to such user names getting deleted.
|
|
Last Modified: | 27-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.177) |
|
Known Fixed Releases: | 7.3(0)IZN(0.7), 7.3(0)N1(0.183), 7.3(0)N1(1), 7.3(0)ZN(0.165) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux98910 | Title: | Descriptions on FEX port corrupt when FEX become online |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Descriptions on FEX port corrupt when FEX become online
## When FEX offline
interface Ethernet100/1/1
description % ABCDEFGHIJ %
switchport access vlan 1111
spanning-tree port type edge
## After FEX become online
interface Ethernet100/1/1
description 0X1.F16E4080A2F15P-890BCDEFGHIJ %
switchport access vlan 1111
spanning-tree port type edge
Conditions:
Workaround:
Not using "%" in description
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 7.2(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue33391 | Title: | PF_DEV1: Vinci: Some enhancements in L2/FP switching for Titanium |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
test
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 0.1 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut87111 | Title: | Cisco NX-OS Arbitrary File Read Vulnerability |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Summary
Cisco NX-OS software contains a directory traversal vulnerability within
the command line interface that could allow a local, authenticated
attacker to disclose the contents of arbitrary files on the affected device.
An attacker could leverage the NX-OS ''copy'' command to duplicate
the contents of arbitrary files on the device to a user writable area of the
filesystem. As the new file will be owned by the authenticated user, the
attacker will be able to view the contents.
This vulnerability affects the following platforms which are based on Cisco NX-OS:
Cisco Nexus 7000
Cisco MDS 9000
Cisco Nexus 6000
Cisco Nexus 5500
Cisco Nexus 5000
Cisco Nexus 4000
Cisco Nexus 3500
Cisco Nexus 3000
Cisco Nexus 1000V
Cisco Connected Grid Router 1000 Series
Cisco Unified Computing System Fabric Interconnect 6200
Cisco Unified Computing System Fabric Interconnect 6100
Conditions
Device is running an affected version of Cisco NX-OS software; An authenticated user
with the privileges to run the copy command.
Symptom:
Conditions:
Workaround:
Further Problem Description:
This issue was discovered during internal testing by Cisco.
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-2013-6975 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: | 25-JAN-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.165) |
|
Known Fixed Releases: | 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.540), 7.1(2)N1(1), 7.2(0)N1(0.187), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.189), 7.3(0)N1(0.31), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux95822 | Title: | N5K - Link stuck in notconnect following reload |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
Following a reload of a chassis or shut/no shut using interface range command some ports remain in notconnect state.
Conditions:
reload or shut/no shut via interface range.
Workaround:
shut/no shut the ports stuck in this state.
Further Problem Description:
Thisis issue is due to asic driver sending multiple up/down triggers for multiple interfaces to software driver simultaneously. This results on software driver not processing the events, thus leaving the interface in this state.
|
|
Last Modified: | 23-JAN-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus89196 | Title: | Trunk ports move to BKN state for native vlan |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:Native vlan on trunk links will move into a BKN spanning-tree state on the 5000 side
Conditions:5000 running 7.1(0)N1 code, and BPDUs sent on the trunk for vlans that do not exist on the 5000
Workaround:Prune off vlans on the remote end that are not needed on the 5000
If you are adding a new VLAN to a link between another switch and a N5K, add the VLAN to the N5K side trunk first.
More Info:
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.1(1)N1(0.468), 7.1(1)N1(1), 7.1(1)ZN(0.20), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum73187 | Title: | N5K the Output of "show run track" broken |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:When you configure track-list and tracks on N5K, the Output of "show run track" broken.
This is the cosmetic issue.
Conditions:This issue is seen on NXOS5.2.x or earlier version,
But this issue doesn't happen NXOS6.0(2)N1(1) or later.
Case 1,
1.Create track list
2.Create some tracks
3.Add objects to track list
In this condition, when you configure seventh objects the Output of "show run track" broken.
Case 2,
1.Create some tracks
2.Create track list
3.Add objects to track list
4.Create new tracks (not yet add to track list)
In this condition, if you add less than 8 objects on step 3, the Output of "show run track" is no problem.
But if you add more than 8 objects on step 3, the Output of "show run track" broken.
Workaround:Create track list after all of tracks you need is created.
If you need to create new track, you must clear track configuration and configure again.
More Info:N7K has similar issue.( CSCty02268)
If you reload the device with this issue, the broken objects are bundled with track list.
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 5.2(1)N1(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur20769 | Title: | BBC:sh fex 'fex num' transceiver -shows sfp is present but not supported |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"show fex 1xx transceiver" shows "sfp information is not available"
Conditions:
FEX Type is N2K-C2348TQ-10GE
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 07-JAN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.364), 7.3(0)N1(0.114) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.152), 7.1(4)N1(0.707), 7.1(4)N1(1), 7.3(0)IZN(0.7), 7.3(0)N1(0.152), 7.3(0)N1(1), 7.3(0)ZN(0.140) |
|
|
| |
| |
|
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 fex-fabric port, then no shutdown on that port.
Port-channel on FEX is configured as LACP, however connected device has no LACP capability, which leads port on FEX into Individual(I) state.
Workaround:Use LACP and form port-channel properly on FEX.
This problem does not happen when port-channel on FEX is correctly formed by LACP.
More Info:Problem is identified and fix has been provided by software.
|
|
Last Modified: | 07-JAN-2016 |
|
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.2(2)N1(0.363), 7.2(2)N1(1), 7.2(2)ZN(0.46), 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: | CSCus02686 | Title: | N5K switchport NP mode causes FCoE outage |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
vFCs go into an errdisabled state due to PRTOV Timer Expiry.
Check show logging log' for the following:
%PORT-5-IF_PORT_QUIESCE_FAILED: Interface vfcX port quiesce failed due to failure reason: PRTOV Timer Expiry (0xe1)
Conditions:
N5K with feature NPV enabled
Note: Feature fcoe-npv is not enabled
CNA facing vFC has switchport mode changed from F to NP
Workaround:
Change the CNA facing interface back to switchport mode F<./b>
Save the configuration. copy running-config startup-config
Reload the switch. reload
Further Problem Description:
It is not recommended to configure a vFC in NP mode, unless fcoe-npv is enabled.
Host/CNA facing vFCs should always be in F/TF switchport mode, if fcoe-npv is disabled.
|
|
Last Modified: | 31-JAN-2016 |
|
Known Affected Releases: | 5.2(1)N1(7) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq75453 | Title: | Nexus 50x0 - vPC peer is not reachable between 5.0(3) and 5.2(1)N1(8) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
VPC peer link is down (vPC peer is not reachable over cfs) between 5.0(3) and 5.2(1)N1(8) image.
Conditions:
Pair of Nexus 50x0's in VPC domain. This bug is seen if one switch is running 5.0(3) and the other is running 5.2(1)N1(8) or (8a) or 5.2(1)N1(9)
Workaround:
Do an intermediate upgrade to anything prior to 5.1(3) or earlier 5.2(1).
Further Problem Description:
This bug is applicable only to Nexus 5010/5020 and does not apply to Nexus 55xx
|
|
Last Modified: | 31-JAN-2016 |
|
Known Affected Releases: | 5.2(1)N1(8a) |
|
Known Fixed Releases: * | 5.2(1)N1(10), 5.2(1)N1(8.173) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux40246 | Title: | Nexus5672 WCCP service not responding when new client connected |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
when new client connected to the box, wccp process usage become high for 5 min and
at that time , cpu usage was very high . then wcccp process not responding and we can't check
config or setting of WCCP.
Conditions:
numbers of SVIs are configured
Workaround:
reduce the number of SVIs
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.249) |
|
Known Fixed Releases: * | 7.0(8)N1(1), 7.1(3)ZN(0.132), 7.1(4)N1(0.697), 7.1(4)N1(1), 7.2(2)N1(0.351), 7.2(2)N1(1), 7.2(2)ZN(0.36), 7.3(0)IZN(0.13), 7.3(0)N1(0.243), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux06997 | Title: | inherit port-profile fails due to vpc orphan-port suspend |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Trying to inherit a port-profile on an interface throws the following error:
Nexus5500(config-if)# inherit port-profile PORT-PROFILE-NAME
Message reported by command :: vpc orphan-port suspend
ERROR: Configuration exists for some interfaces
ERROR: Failed to write VSH commands
Conditions:
"vpc orphan-port suspend" configured under the interface in question.
Workaround:
Remove "vpc orphan-port suspend" from the interface, inherit the port-profile and then add "vpc orphan-port suspend" configuration back on the interface.
Further Problem Description:
This issue does not apply when both the port-profile and the interface have "vpc orphan-port suspend" configured, where the error is expected due to mutual exclusion.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.3(0)IZN(0.13), 7.3(0)N1(0.219), 7.3(0)N1(1), 7.3(0)ZN(0.196) |
|
|
| |
| |
|
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: | 30-JAN-2016 |
|
Known Affected Releases: | 5.2(1)N1(7) |
|
Known Fixed Releases: * | 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), 7.3(0)IZN(0.13), 7.3(0)N1(0.195) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv46411 | Title: | HIF ports go down and don't come back up when host reloads |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
10G CU HIF ports go down and don't come back up when connected host gets Reloaded
Conditions:
End Host Getting Reloaded
TESTSWITCH# sh int eth 109/1/21
Ethernet109/1/21 is down (Link not connected)
56XX
6000
Workaround:
Shut/No shut will not work, Removing the cable + SFP would reinitialize and would bring the port back up
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.306), 7.0(7)ZN(0.263), 7.0(8)N1(1), 7.1(3)ZN(0.151), 7.1(4)N1(0.706), 7.1(4)N1(1), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZN(0.4), 7.3(0)IZN(0.13) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux11097 | Title: | N5k / N6k- ssh login-attempts 3 results in no ssh login-attempts |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ssh login-attempts 3 results in no ssh login-attempts in show run security all configuration on N6k / N5k.
N5K-EB5(config)# sh run security all | i ssh
feature ssh
ssh login-attempts 2
ssh key rsa 1024
no ssh key dsa
N5K-EB5(config)# conf ter
N5K-EB5(config)# ssh login-attempts 3
N5K-EB5(config)# sh run security all | i ssh
feature ssh
no ssh login-attempts
ssh key rsa 1024
no ssh key dsa
N5K-EB5(config)#
N5K-EB5(config)# ssh login-attempts 4
N5K-EB5(config)# sh run security all | i ssh
feature ssh
ssh login-attempts 4
ssh key rsa 1024
no ssh key dsa
N5K-EB5(config)#
Conditions:
only ssh login-attempts 3
Workaround:
use ssh login-attempts 1-2 , 4-10
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(1)N1(0.1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.115), 7.1(4)N1(0.689), 7.1(4)N1(1), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZN(0.13), 7.3(0)IZN(0.13), 7.3(0)N1(0.209), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug92414 | Title: | SVI can go down corresponding vlan active on FlexLink only |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
SVI interface can go down when corresponding VLAN is active (forwarded by) on FlexLink only.
Conditions:
This issue can happen only if you have FlexLinks and regular STP ports (trunk/access) which are allowing VLAN X.
When last non-FlexLink port belonging to VLAN X goes down, SVI interfaces goes down as well.
This happens despite on fact that FlexLink is active and VLAN X forwarded by it.
Workaround:
In order to restore SVI state, you will need to shutdown/no shutdown it.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 5.1(3)N2(1), 5.2(1)N1(2) |
|
Known Fixed Releases: * | 7.3(0)D1(0.148), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)IZN(0.13), 7.3(0)N1(0.197), 7.3(0)N1(0.199), 7.3(0)N1(1), 7.3(0)PDB(0.112), 7.3(0)SC(0.14), 7.3(0)ZD(0.165) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw89463 | Title: | MTS buffer leaks for mcecm on the peer device with MCT flap |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Observed MTS buffer leaks on vPC secondary device with MCT flap
Conditions:
On a vPC setup, mts buffer leaks for vPC SAP (450) are seen after flapping MCT on vPC primary repeatedly around 20 times.
Workaround:
No workaround exists.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.177) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.137), 7.1(4)N1(0.702), 7.1(4)N1(1), 7.2(2)N1(0.356), 7.2(2)N1(1), 7.2(2)ZN(0.40), 7.3(0)IZN(0.13), 7.3(0)N1(0.211), 7.3(0)N1(1), 7.3(0)ZN(0.190) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud96475 | Title: | Inconsistent running and startup config on Nexus 5596 |
|
Status: | Terminated |
|
Severity: | 4 Minor |
Description: * | Symptom:
Different order of the way the commands are shown between running and startup config .
Conditions:
None
Workaround:
Attached the file wokaround.txt
Further Problem Description:
Please read the Eng-notes attached
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 5.1(3)N2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux76712 | Title: | FC interface disabled due to 'bit error rate too high' when rate is low |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
A Fibre Channel interface is disabled and has the following status even though the bit error rate of the interface is below the threshold specified in the Fibre Channel standards:
show interface
fcx/y is down (Error disabled - bit error rate too high)
The following type of syslog messages are logged for the interface:
show logging log
%PORT-5-IF_DOWN_BIT_ERR_RT_THRES_EXCEEDED: %$VSAN v%$ Interface fcx/y is down (Error disabled - bit error rate too high)
Conditions:
This issue applies to all FC interfaces on the Nexus 5000 and Nexus 6000 models.
show platform software fcpc event-history errors
Event:E_DEBUG, length:102, at 571407 usecs after Tue Jan 5 05:33:02 2016
[102] CREDITMON_EVENT_ERR_COUNT, if_index 1105000: cur=0x2acfd01e76de prev=0x2acfd01e76dd occurances=3
If the time between occurances=1 to occurances=15 for the interface if_index is greater than 5 minutes, then this bug has been hit.
Workaround:
shut and then no shut the fc interface to recover.
Further Problem Description:
Even though the rate of bit errors on the affected link may not have been at as high as the rate specified in the Fibre Channel standards, there were still bit errors occurring. This causes the interface to be error disabled prematurely. However, persistent bit errors on a link are undesirable and the problem should still be corrected.
To find the fc interface, use the if_index
show system internal fcfwd idxmap interface-to-port | i 1105000
01105000 fc3/6 | 105| 0| 05| 01 | 02 | 05 | 0101| 00 | 00
Resolution Summary:
To be completed when the bug is resolved.
|
|
Last Modified: | 12-JAN-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 21-JAN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1), 7.3(0)N1(0.117) |
|
Known Fixed Releases: * | 7.0(7)N1(0.307), 7.0(7)ZN(0.266), 7.0(8)N1(1), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz94196 | Title: | Need capability to clear QoS statistics per interface. |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Cannot clear QoS statistics per interface.
Conditions:
Workaround:
Clear QoS statistics for the entire switch.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 5.2(1)N1(0.174) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.175), 7.1(4)N1(0.725), 7.1(4)N1(1), 7.3(0)IZN(0.7), 7.3(0)N1(0.157), 7.3(0)N1(1), 7.3(0)ZN(0.145) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux83991 | Title: | hwclock crashes if system time set before Unix epoch |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
The hwclock process may repeatedly crash.
Conditions:
This was seen on a N5K switch where the system clock was set to October 1957, which is prior to the Unix epoch (time "0" or January 1, 1970). It's not know how the system got into that state as it seems to reject all attempts to set the time prior to that value manually.
When the time is corrected, crashes stop
Workaround:
Set system clock to a date/time after Unix epoch.
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 5.2(1)N1(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh12794 | Title: | syslog message when max port-channel binded vFCs of 48 is reached. |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Port-binded vfc interface will not come up.
Conditions:
Over 48 vfc interfaces are configured that are binded (or bound) to a port-channel.
Workaround:
Bind the vfc to the physical ethernet interface.
Further Problem Description:
The max port-channel binded vFCs is 48 for N5K and N6K (except 6001)
# sh platform software fcoe_mgr info pcfcfmac
FCoE port-channel FCF-MAC allocation info
--------------------------------------------
Base MAC : 00:2a:6a:68:xx:xx
MAC Range : 48 <---------- max 48
Allocated : 0
From a 6001
# sh platform software fcoe_mgr info pcfcfmac
FCoE port-channel FCF-MAC allocation info
--------------------------------------------
Base MAC : 00:2a:6a:cd:6d:08
MAC Range : 24 <-------- max is 24 for nexus 6001
Allocated : 0
|
|
Last Modified: | 04-JAN-2016 |
|
Known Affected Releases: * | 5.2(1)N1(4), 7.0(6)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua16886 | Title: | Enh: Add a Note indicating restart needed for port type change. |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Currently Nexus 5548UP and 5596UP switches do not print a warning message indicating users that
the switch/module needs to be restarted for a port type change(Ethernet <->FC) to take effect.
This is an enhancement request so that the switch will have a message indicating so to the user.
Conditions:
Workaround:
Further Problem Description:
Fix is available in all recent versions.
7.0(8)N1(0.xx)
7.3.(0)N1(0.)
7.1(3)N1(1))
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 5.1(3)N2(1) |
|
Known Fixed Releases: * | 7.1(3)N1(1), n5000-uk9.7.0.8.N1.0.323.bin, n6000-uk9.7.3.0.N1.0.265.bin |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux86708 | Title: | ENH: N5K needs commands to rebuild switch-profile DB |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Request for additional commands available from normal CLI to delete and recreate switch-profile DB, based on the existing configurations.
Conditions:
To be used when global-db and cfgd-db don't match with the global and switch-profile configs.
Workaround:
There are no simple procedures to recover from a situation like this.
Further Problem Description:
This is a serviceability enhancement to facilitate the recovery of config-sync issues (without requiring shell access), when DBs and running-configs differ.
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux88771 | Title: | Nexus5k FEX monitoring using CISCO-ENTITY-FRU-CONTROL-MIB |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Need to monitor the status of FEX module on N5K (same as shown using 'show fex' CLI).
Conditions:
FEX module installed on N5k Chassis
Workaround:
Use OID : cefcModuleTable
In the following output you can see there are two FEX, numbered 101 and 102, both of which are online.
ocs5548-2# sh fex
FEX FEX FEX FEX
Number Description State Model Serial
------------------------------------------------------------------------
101 FEX0101 Online N2K-C2232PP-10GE SSI155001QZ
102 FEX0102 Online N2K-C2232PP-10GE SSI15460AT7
When we browse the cefcModuleTable from this MIB we can see the two FEX, numbered 101000022 and 102000022, with an AdminStatus of enabled and an OperStatus of ok.
[sfuller@rhel8 ~]$ snmpwalk ocs5548-2 cefcMIBObjects.2
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleAdminStatus.2 = INTEGER: enabled(1)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleAdminStatus.24 = INTEGER: enabled(1)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleAdminStatus.101000022 = INTEGER: enabled(1)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleAdminStatus.102000022 = INTEGER: enabled(1)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleOperStatus.22 = INTEGER: ok(2)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleOperStatus.24 = INTEGER: ok(2)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleOperStatus.101000022 = INTEGER: ok(2)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleOperStatus.102000022 = INTEGER: ok(2)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleResetReason.22 = INTEGER: 0
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleResetReason.24 = INTEGER: 0
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleResetReason.101000022 = INTEGER: 0
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleResetReason.102000022 = INTEGER: 0
If we then take one of the FEX offline (by shutting the port-channel on the Nexus) I can see the FEX offline from the CLI as expected:
ocs5548-2(config-if)# sh fex
FEX FEX FEX FEX
Number Description State Model Serial
------------------------------------------------------------------------
101 FEX0101 Offline N2K-C2232PP-10GE SSI155001QZ
102 FEX0102 Online N2K-C2232PP-10GE SSI15460AT7
And the entry in the cefcModuleTable has now been removed.
[sfuller@rhel8 ~]$ snmpwalk ocs5548-2 cefcMIBObjects.2
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleAdminStatus.22 = INTEGER: enabled(1)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleAdminStatus.24 = INTEGER: enabled(1)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleAdminStatus.102000022 = INTEGER: enabled(1)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleOperStatus.22 = INTEGER: ok(2)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleOperStatus.24 = INTEGER: ok(2)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleOperStatus.102000022 = INTEGER: ok(2)
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleResetReason.22 = INTEGER: 0
CISCO-ENTITY-FRU-CONTROL-MIB::cefcModuleResetReason.24 = INTEGER: 0
Further Problem Description:
|
|
Last Modified: | 19-JAN-2016 |
|
Known Affected Releases: | 7.1(3)ZN(0.99) |
|
Known Fixed Releases: | |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论