| |
Bug Id: | CSCus16779 |
Title: | FEX vlan translation with multiple HIF PO flaps may stop L2 vlan fwding |
|
Description: | Symptom:
L2 vlan forwarding may stop on one or more VLANs that are included in a FEX HIF PO trunk allowed vlan list, if the FEX is also configured for vlan translation.
Conditions:
The following conditions must hold TRUE:
- VLAN translation mappings enabled on ST/AA FEX fabric interface.
- FEX has HIF PO with trunk allowed vlan list.
- The last vlan in the FEX HIF PO trunk allowed vlan list is not the translated vlan for any of the vlan maps on the FEX fabric interfaces
- FEX HIF Po flaps multiple times.
Workaround:
If a FEX has a FEX HIF PO, ensure that the last vlan specified in the trunk allowed vlan on the FEX HIF PO is associated with a translated vlan in one of the vlan maps configured on the FEX fabric interface.
This maybe achieved by:
1) Reserving a VLAN in the system with the largest vlan id that will be allowed on any of the FEX HIF Pos
2) Adding this VLAN to the FEX HIF Po's trunk allowed vlan list, and
3) Configuring a vlan map on the FEX Fabric interface, that maps an unused original vlan on the FEX to the reserved vlan specified in step 1.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.426) |
|
Known Fixed Releases: | 7.1(1)N1(0.69), 7.1(1)N1(1), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu13462 |
Title: | Port-profile hap resets after enabling fabricpath |
|
Description: | Symptom:
The issue was originally seen in a Nexus 6000 running 6.0(2)N2(6):
[ 352.974066] Shutdown Ports..
[ 353.013281] writing reset reason 16, port-profile hap reset
Aug 14 16:53:20 %LIBSYSMGR-3-SIGTERM_FORCE_EXIT Service "u2rib" (PID 5141) is forced exit.
Aug 14 16:53:20 %LIBSYSMGR-3-SIGTERM_FORCE_EXIT Service "vshd" (PID 3555) is forced exit.
Aug 14 16:53:20 %LIBSYSMGR-3-SIGTERM_FORCE_EXIT Service "urib" (PID 3651) is forced exit.
...
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Unmounting filesystems...
[ 362.939993] Resetting board
(c) Copyright 2012, Cisco Systems.
NC-64 BIOS v.1.6.0, Mon 10/21/2013, 12:26 PMKernel uptime is 0 day(s), 0 hour(s), 2 minute(s), 33 second(s)
Last reset at 397089 usecs after Sun Aug 14 20:34:22 2011
Reason: Reset triggered due to HA policy of Reset
System version: 6.0(2)N2(6)
Service: port-profile hap reset
Conditions:
VLANs converted to fabricpath mode.
Workaround:
N/A
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 02-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo87565 |
Title: | N5k/6k suspends vPC+ legs on primary after replacing the vPC+ peer |
|
Description: | Symptom:
N5k/6k suspends vPC+ legs on Primary switch after replacing the vPC+ secondary peer.
Conditions:
- replace vpc+ peer, and then vpc peer-link become down.
- down reason is "suspended by vpc"
- in "show system internal vpcm info all", existing vpc peers table does not update.
Workaround:
As the vPC+ peers table times out after 20 minutes, wait 20+ minutes before replacing a vPC+ peer.
Further Problem Description:
1)The system-id or the peer is populated in the case of VPC+ from the DRAP protocol.
2)The DRAP gets that information from ISIS. ISIS has that information in its LSDB.
3)On disconnecting secondary1, the primary still has the system-id of the secondary1. The LSP which brought that information will stay on primary till the LSP timeout value. Which is 20 mins.
4)After 20 mins the LSP form secondary1 will get flushed, from the primary's database.
5)Now this removal will also cause DRAP to remove the system-id info for the VPC database.
6)Now connecting secondary 2 will bring in a new LSP into the primary , in form of ISIS LSDB exchange.
7)The system-id is now again populated by DRAP into VPC.
8)There should not be any conflict.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(3), 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu39895 |
Title: | Support for dhcp server & client in a non-default vrf topology |
|
Description: | Symptom:
In the DFA Network When the dhcp server CPNR in the non-default vrf and dhcp client in Non-default VRF Placed in different leaf switches . In such condition dhcp client in the non-default vrf not able to get the ip address form the dhcp server .
Conditions:
This issue seen when DHCP server CPNR & dhcp client are in different leaf switches.
Workaround:
Users can keep the dhcp server in Management VRF .
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.167) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur12427 |
Title: | 5672UP unable to read sensors temperature |
|
Description: | Symptom:
In a Nexus 5672 series switch running NX-OS 7.0(4)N1(1) and 7.0(5)N1(1), fans run at full speed all the time and output of show environment temperature giving an empty output at all
time:
Nexus5672# sh environment temperature
Temperature
-----------------------------------------------------------------
Module Sensor MajorThresh MinorThres CurTemp Status
(Celsius) (Celsius) (Celsius)
-----------------------------------------------------------------
Nexus5672#
Conditions:
Seen in 5672UP running NX-OS 7.0(4)N1(1) and 7.0(5)N1(1). This issue does NOT affect Nexus 55xx,56128 or Nexus 600x platforms.
Workaround:
None. NX-OS 7.1(0)N1(1) and 7.0(5)N1(1a) do have the fix.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 7.0(4)N1(1), 7.0(5)N1(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.679), 7.0(1)ZN(0.740), 7.0(5)N1(1a), 7.0(6)N1(0.2), 7.0(6)N1(0.240), 7.0(6)N1(1), 7.1(0)N1(0.405), 7.1(0)N1(1), 7.1(0)ZN(0.480), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCup45280 |
Title: | kernel panic in ethpm |
|
Description: | Symptom:
Kernel panic crashes in ethpm:
sc1-c08-6k1-1# show system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 359759 usecs after Fri Jun 3 14:52:27 2011
Reason: Kernel Panic
Service:
Version: 7.0(2)N1(1)
sc1-c08-6k1-1# show logging onboard stack-trace
Logging time: Fri Jun 3 14:52:25 2011
1307137945:79999999 process ethpm (3966), jiffies 0x2a17a30
invalid opcode
STACK
CPU 6
Process ethpm (3966)
Stack:
Call Trace:
[<801813fc>]page_remove_rmap+0xc6/0xfc
[<8017a4c3>]unmap_vmas+0x344/0x598 (116)
[<8017e2bb>]exit_mmap+0x68/0xe4 (40)
[<80128062>]mmput+0x33/0x86 (12)
[<8012b7b4>]exit_mm+0xe9/0xf1 (32)
[<8012cceb>]do_exit+0x1dd/0x745 (68)
[<8012d2b6>]do_group_exit+0x63/0x8a (20)
[<801358d1>]get_signal_to_deliver+0x2df/0x2f6 (48)
[<80102c33>]do_notify_resume+0x70/0x779 (220)
[<80103b2e>]work_notifysig+0x13/0x25 (-8112)
Conditions:
Unknown
Workaround:
None at this time
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut49745 |
Title: | Nexus 6001 Silent Reload with I2C Cause Code 0x0100 |
|
Description: | Symptom:
A Nexus 6001 chassis may experience an unexpected reload. The reset-reason will be listed as "Unknown".
The I2C cause code, which should be recorded in 'show logging onboard internal reset-reason' on all released code for the N6K, will be recorded as 0x0100 ("ADM1066 Power Good Triggered Reset").
Reset Reason for this card:
Image Version : 6.0(2)N2(3)
Reset Reason (LCM): Unknown (0) at time Fri Feb 20 13:30:02 2015
Reset Reason (SW): Unknown (0) at time Fri Feb 20 07:32:04 2015
Service (Additional Info):
Reset Reason (HW): uC reset code: 0x0100
ADM1066 Power Good Triggered Reset at time Fri Feb 20 07:32:04 2015
Conditions:
This has thus far been observed on N6K-C6001-64P switches with Platinum power supplies (NXA-PAC-1100W).
This defect is currently under investigation and so an exact trigger or other possible conditions are not currently known.
Workaround:
None known.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(3), 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup76343 |
Title: | Missing XML output for "show feature-set" on N6K |
|
Description: | Symptom:
Show feature output not available in XML format
Conditions:
N/A
Workaround:
Use 'show feature' cli.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 6.0(2)ZK(99.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus29400 |
Title: | FCPC cores and triggers hap reset while allocating response payload |
|
Description: | Symptom:
A Nexus 6000 or 56xx switch running 7.0(3)N1(1) may trigger a hap reset due to an unexpected FCPC crash:
N6K %$ last message repeated 1 time
N6K%$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "fcpc" (PID 4247) hasn't caught signal 6 (core will be saved).
N6K %$ VDC-1 %$ %SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "fcpc" in vdc 1 has had a hap failure
N6K %$ VDC-1 %$ 22 05:35:42 %KERN-0-SYSTEM_MSG: [12049989.661356] Shutdown Ports.. - kernel
N6K %$ VDC-1 %$ 22 05:35:42 %KERN-0-SYSTEM_MSG: [12049989.698850] writing reset reason 16, fcpc hap reset - kernel
Conditions:
FCPC crash can be seen with around 32 physical FC ports in the switch. The leak is less and can take days to crash. Happens only on 56xx nexus switch.
Workaround:
Reload the box to restore the memory to normal
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 7.0(3)N1(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.776), 7.0(6)N1(0.267), 7.0(6)N1(1), 7.1(1)N1(0.495), 7.1(1)N1(1), 7.1(1)ZN(0.48), 7.2(0)N1(0.162), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.164) |
|
|
| |
| |
Bug Id: | CSCuu69079 |
Title: | Memleak Seen in ethpm |
|
Description: | Symptom:
Memleak in ethpm component. Warning messages of memleak appers in syslogs
Conditions:
Box idle with no trigger
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.226) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus66054 |
Title: | vPC designated forwarder does not have OIF programmed |
|
Description: | Symptom:
When tried simply reach steady state, the N6K vPC peers are not programming the designated forwarder OIF
Conditions:
VPC switches. Both the peers have same unicast routing metric back to the source, the vPC Primary is the designated forwarder
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup85771 |
Title: | Nexus 6000 resets SSH intermittently |
|
Description: | Symptom:
A java script is ran to fetch show run interface outputs from a windows machine.
Topology:
Nexus 6001---windows machine
The script establishes a SSH session to collect the outputs. After fetching 3 interface running configurations outputs through the script, the Nexus 6000 switch disconnects the ssh session.
packet capture on the management interfaces shows a RST packet sent from the switch towards the pc to disconnect the SSH session which is buggy.
This script works fine with 6.0(2)N1 code. The issue is seen only on 6.0(2)N2 versions.
Sample working & Non-working output:
Is session connected: true
exit-status: 0
!Command: show running-config interface Ethernet1/1
interface Ethernet1/1
description testing range
switchport mode trunk
switchport trunk allowed vlan 1
spanning-tree port type edge trunk
Non-working:
Is session connected: true
exit-status: -1
Please note that during non-working scenario the script can collect the outputs 3 times, but the 4th try fails because of the RST signal from Nexus 6000 which needs to be investigated.
Please find the attached Java script & outputs under the file name "labrecreate detailed" attached to the bug
Conditions:
seen only on 6.0(2)N2
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | 5.2(1)N1(8.152), 5.2(1)N1(9), 6.0(2)N2(6.129), 6.0(2)N2(7), 7.0(1)ZN(0.683), 7.0(6)N1(0.194), 7.0(6)N1(1), 7.1(0)N1(0.402), 7.1(0)N1(0.404), 7.1(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu24951 |
Title: | ACL Label Applied on Primary SVI Does Not Get Set On Secondary VLAN |
|
Description: | Symptom:
Traffic is not getting dropped by access-list applied to private vlan primary SVI.
Conditions:
Traffic is ingressing the switch on a standard L2 trunk in the secondary vlan and is to be routed, via the primary vlan SVI.
Workaround:
Apply the access-list to the physical ingress interface as a PACL instead of to the SVI as a RACL.
Further Problem Description:
This issue occurs because the ACL label only gets applied to the primary vlan, and not the secondary vlan:
Current running group id counter: 22
Group 21 configuration for asic id 4:
Label Table: [vacl]-[valid:1, size:512, used:65029]
In use labels:
0-4,512-65535
Global Label Table: [used:65029]
In use labels:
0-4,512-65535
Label:4 group:21, logical operators: <===================== Label 4
vlan 1.118: pi vacl_label 4 span_ssn_id 255 <================ Label 4 is programmed on the Primary vlan
vlan 1.118: pi vacl_label 4 span_ssn_id 255
vlan 1.118 pd: int-vlan 19 state table idx 19 vacl_label 4 mbr_bitmap_idx 19, vlan_flags 0x1
vlan 1.119: pi vacl_label 0 span_ssn_id 255 <================ Label 4 is not programmed on the Secondary vlan
vlan 1.119: pi vacl_label 0 span_ssn_id 255
vlan 1.119 pd: int-vlan 18 state table idx 18 vacl_label 0 mbr_bitmap_idx 18,
|
|
Status: | Terminated |
|
Severity: | 1 Catastrophic |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.7) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut95490 |
Title: | JanJuc166 Vinci FE - traffic issue when core links are shut |
|
Description: | Symptom:on a vinci FE set up ,when the links to the spine are shut ,the traffic is not going through mct.
Conditions:
Workaround:
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.174), 7.2(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus28101 |
Title: | N5K/6K: Inband TACACS traffic matched against exception-class in CoPP |
|
Description: | Symptom:
In a Nexus 5600/6000, TACACS/Radius traffic coming in on in band SVI interfaces hits class-exception class in Control plane policers.
Conditions:
TACACS/Radius used for access control and in band SVIs used for management Nexus 5600/6000. If there is violations in exception class, authentication failures can be seen due to this issue.
Workaround:
Use mgmt0 interfaces for managing Nexus 5600/6000 switches.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: | 6.0(2)N2(6.129), 6.0(2)N2(7), 7.0(1)ZN(0.726), 7.0(6)N1(0.227), 7.0(6)N1(1), 7.1(1)N1(0.468), 7.1(1)N1(1), 7.1(1)ZN(0.20), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCun54576 |
Title: | Nexus6000: License grace period is shown after disabling grace period |
|
Description: | Symptom:
N96-OPTICS(config)# sh lic us
Feature Ins Lic Status Expiry Date Comments
Count
--------------------------------------------------------------------------------
ENTERPRISE_PKG No - Unused Grace 116D 17H
FC_FEATURES_PKG No - Unused Grace 119D 9H
--------------------------------------------------------------------------------
Under comments column, grace period is shown even when license is unused.
Conditions:
Always reproducible as per the problem statement
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(0.115) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108) |
|
|
| |
| |
Bug Id: | CSCup87465 |
Title: | Kernel panic in netstack |
|
Description: | Symptom:
Switch may reload due to a kernel panic in netstack
Conditions:
Not known at this stage
Workaround:
Not known at this stage
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut66989 |
Title: | vPC+ connected fex (2348TQ) black holing ingress traffic |
|
Description: | Symptom:
After the reload of one of the two vPC peers, ingress traffic to a vPC+ connected fed (in this instance N2K-C2348TQ-10GE) received from the connected Nexus 5k is not delivered to the target port.
Conditions:
vPC+ connected fex using QSFP-H40G-CU5M.
Workaround:
shutdown the port-channel loosing traffic on the affected Nexus 5k.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.15) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui67441 |
Title: | N6K: sh fcs database vsan <> cause system reload |
|
Description: | Symptom:
Nexus 6000 switch configured for FCoE and large number of FLOGI sessions might reload after typing command show fcs database vsan <>
Conditions:
Large Number of FLOGI Sessions
Workaround:
None:
Further Problem Description:
The reload is due to core dump in FCS process.
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut05530 |
Title: | IPLUS_464_VXLAN_SCALE_Testbed: FWM core after flapping NIF ports |
|
Description: | Symptom:
FWM Core.
Conditions:
After flapping NIF port in scale topology.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 7.1(1)N1(0.464) |
|
Known Fixed Releases: | 7.1(1)ZN(0.116), 7.1(2)N1(0.537), 7.2(0)AB(9), 7.2(0)N1(0.153), 7.2(0)N1(1), 7.2(0)ZN(0.156), 7.3(0)N1(0.25), 7.3(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu00391 |
Title: | N5K/6K: BCAST flag missing for FTAG 2 |
|
Description: | Symptom:
In a Nexus 5K/6K configured for vPC+, broadcast flag will be missing for FTAG 2 on the vPC+ switch which has affinity for FTAG2
5596A# sh platform fwm info l2mp ftag 2 hw
L2MP FTAG
--------------------------------------------------------------
ftag[0x9ed03e4] id: 2 (0x2)
Topology ID: 0 (0x0)
Ftag flags: MCAST ACTIVE <<------Broadcast Flag is missing
Is stale: FALSE
alternate: 0
ftag_ucast_index: 0
ftag_flood_index: 0
ftag_mcast_index: 65
ftag_alt_mcast_index: 80
rpf: (null)
ftag_mask[0xa54f62c]
Conditions:
Seen in switches where both vPC+ pair go VPC Active/Active due to VPC auto-recovery
Workaround:
Reload the switch in question
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)N1(1a), 7.1(1)ZN(0.120), 7.1(2)N1(0.541) |
|
|
| |
| |
Bug Id: | CSCut94663 |
Title: | JJ170: N128 device crashed with FWM cores |
|
Description: | $$IGNORE
Symptom:
FWM process crashes and switch reloads
Conditions:
Issue observed with script run and it happens with PVLAN configuration
Workaround:
No workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.170), 7.2(0)N1(0.182) |
|
Known Fixed Releases: | 7.1(2)N1(0.543), 7.1(2)ZN(0.2), 7.2(0)N1(0.194), 7.2(0)N1(1), 7.2(0)ZN(0.197) |
|
|
| |
| |
Bug Id: | CSCut08643 |
Title: | N5K CoPP does not match router ISIS packets |
|
Description: | Symptom:
Router ISIS packets are not matched by the ISIS copp class and router ISIS packets will be hit by class defualt
Conditions:
none
Workaround:
Cannot add customer class map to N5K CoPP.
Can increase class default rate to allow more packets to the cpu
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a), 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(2)N1(0.559), 7.1(2)N1(1a), 7.1(2)ZN(0.18), 7.2(0)AB(9), 7.2(0)N1(0.157), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.161), 7.3(0)N1(0.25) |
|
|
| |
| |
Bug Id: | CSCuu46633 |
Title: | interface vethernet X enters interface range configuration mode |
|
Description: | Symptom:
When configuring "interface vethernet X", the configuration mode changes to interface range mode when it should change to interface mode.
Conditions:
Nexus5600# sh run | i i "system default switchport"
no system default switchport
Nexus5600#
Nexus5600# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Nexus5600(config)# int vethernet 7777
Nexus5600(config-if-range)# bind ?
^
% Invalid command at '^' marker.
Workaround:
Nexus5600(config)# system default switchport
Nexus5600(config)# no interface vethernet 7777
Nexus5600(config)# int vethernet 7777
Nexus5600(config-if)# bind ?
interface Interface
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut29939 |
Title: | Nexus 6k Kernel Panic with Corrupted CPU Process Name |
|
Description: | Symptom:
Kernel Panic reload, with a corrupted CPU process:
CPU 5
Process ??????]???????????u??????}????????????]??????????& (-2020868097)
Conditions:
Unknown
Workaround:
Unknown
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut60043 |
Title: | N6004 - 40g transceivers have delay for link-up on module boot |
|
Description: | Symptom:
On Nexus 6004 chassis or module reload 40g interfaces can take up to 50 minutes to come online and forward traffic. Seen with QSFP-40G-LR and WSP-Q40GLR4L, though we do not expect it to be limited to just these transceivers
Conditions:
Reloading a chassis or LEM module that contains at least one 40g transceiver in a 6004 chassis
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(2)N1(1), 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu16775 |
Title: | NVE config is missing after doing ISSU from 7.1(1)N(1a) to 7.2 |
|
Description: | Symptom:
VXLAN traffic will get dropped due to missing Network virtualization interface (interface nve) configuration.
Conditions:
Vxlan feature configured on Nexus OS version 7.1.x and upgrading from this version to Nexus OS version 7.2.
Workaround:
Copy the saved running-configuration to switch's running configuration using the command "copy running-config". This will restore the missing configuration related to nve interfaces. Since other parts of configuration already existed prior to the operation of copying save file to running-config, certain warnings will be displayed. These warnings can be ignored.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.191) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun10615 |
Title: | N6k - Software MAC learning of SVI MAC in HW table |
|
Description: | Symptom:
IP/ARP connectivity affected as a result of Dynamic learning of SVI MAC on Nexus 6000 switch. This may lead to black-holing of traffic.
Conditions:
SVI MAC (BIA) is seen coming from the network due to a network loop. Not all type of packets would cause MAC table to updated as Dynamic for a System MAC. So far is seen to be happening with DHCP packets.
Workaround:
Clearing of MAC (clear mac address-table) removes such entry and connectivity is restored. However if a DHCP packet with SMAC as SVI is looped/reflected again we'll have the same condition.
Further Problem Description:
Example, when in problem state:-
sh int vlan x
Hardware is EtherSVI, address is 0000.0000.0001
sh mac address-table address 0000.0000.0001
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link
VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+------------------
* X 0000.0000.0001 dynamic 1800 F F Po10 >>>> learning from network
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(3), 7.0(0)N1(0.527) |
|
Known Fixed Releases: | 6.0(2)N2(5.97), 6.0(2)N2(6), 7.0(0)N1(0.106), 7.0(0)N1(1), 7.0(1)ZN(0.497), 7.0(4)N1(0.133), 7.0(4)N1(1), 7.1(0)ZN(0.224) |
|
|
| |
| |
Bug Id: | CSCur30099 |
Title: | Nexus 6000 : evaluation of SSLv3 POODLE vulnerability |
|
Description: | Symptom:
This product includes a version of SSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-3505
CVE-2014-3506
CVE-2014-3507
CVE-2014-3508
CVE-2014-3510
CVE-2014-3566 (POODLE)
This bug has been opened to address the potential impact on this product.
Conditions:
The POODLE Security issue CVE-2014-3566 exists if we configure LDAP as part of DFA configuration
Something like this
fabric database type network
server protocol ldap ip 10.95.126.166 vrf management
Or
Onep is configured with "transport type tls ..." option
Or
vmtracker configuration
Workaround:
1. Avoid any LDAP configuration
2. For DFA configuration use XMPP "server protocol xmpp .." or "server protocol radius ..." instead of LDAP
3. Do not use onep
Further Problem Description:
A POODLE attack requires a man in the middle attack between the nexus5000/6000 switch (the LDAP client)
and the LDAP server. It would also require a protocol downgrade attack since, by default, nexus5000/6000
uses TLS protocol.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the
time of evaluation are: 2.6/2.5
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.9(0)ZD(0.4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut83532 |
Title: | 5600 vPC Pair loops back unknown unicast packets |
|
Description: | Symptom:
MAC move notifications on switch connected to 5600 vPC pair.
Conditions:
Nexus 5600 in vPC, unknown unicast packets hitting the switch.
Workaround:
We can static the MAC addresses on the connected swtich(es) to avoid looping the frames in the network and losing flows when the flap occurs, but this is not a good option if the MAC moves under a normal network circumstance, e.g. Vmotions in a VMware environment.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.1(1)N1(0.512) |
|
Known Fixed Releases: | 7.1(2)N1(0.543), 7.1(2)ZN(0.2) |
|
|
| |
| |
Bug Id: | CSCut69584 |
Title: | SNMP process crash with DCNM discovery with new SNMP username |
|
Description: | Symptom:
Device sees a snmpd process crash.
Logs might show similar to:
2015 Mar 30 15:14:27.949 ipt-zbl103-m-fb-02 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 8266) hasn't caught signal 11 (core will be saved).
2015 Mar 30 15:14:38.354 ipt-zbl103-m-fb-02 %$ VDC-1 %$ 30 15:14:38 %KERN-0-SYSTEM_MSG: [ 4691.029783] Shutdown Ports.. - kernel
2015 Mar 30 15:14:38.358 ipt-zbl103-m-fb-02 %$ VDC-1 %$ 30 15:14:38 %KERN-0-SYSTEM_MSG: [ 4691.064149] writing reset reason 16, snmpd hap reset - kernel
Conditions:
The issue appears to occur with DCNM discovery with new SNMP username authenticated through tacacs.
This is specific to a situation where the tacacs server is configured to give 2 roles to the username that is used
authenticate on the switches via dcnm.
I.e. tacacs gives the role "network-admin" AND "vdc-admin"
Workaround:
from the tacacs server, remove the role "vdc-admin" only apply the role "network-admin" to the userid, used by dcnm to manage the switches.
Further Problem Description:
Customer Issue:
---------------------
Customer basically implemented a new DCNM server within the same subnet connected to same switch and restore the old LDAP database backup. After this, Customer changed the SNMP username in the switch to a dedicated username. Earlier switch was having default username (admin). This new dedicated SNMP username is through Tacacs. Also the switch login username is same as SNMP username and is also through Tacacs.
So DCNM ssh to Switch with same username as SNMP username.
Crash happened after customer changed the SNMP username in the switch and is keep on crashing.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul77425 |
Title: | Nexus 5600/6000: vPC/vPC+ Constant MAC Flush/Learn at FWM |
|
Description: | Symptom:Packet loss can be observed in VPC/vPC+ environment when destination MAC constantly flush/learn. During this time MAC address at FWM cleared and learned again on the vPC secondary device:
Nexus# show platform fwm info mac MAC_ADDR 5 | inc Oper
Operation: Mac delete (10)
Operation: Mac create (9)
Operation: Peer sent; local down and mct learnt (2)
Operation: Mac delete PVRST flush sent to peer (46)
Operation: Mac delete due to hw/sw mismatch (37)
Operation: Mac delete (10)
Operation: Mac create (9)
Operation: Peer sent; local down and mct learnt (2)
Operation: Mac delete PVRST flush sent to peer (46)
Operation: Mac delete due to hw/sw mismatch (37)
Operation: Mac delete (10)
Operation: Mac create (9)
Operation: Peer sent; local down and mct learnt (2)
Operation: Mac delete PVRST flush sent to peer (46)
Operation: Mac delete due to hw/sw mismatch (37)
Operation: Mac delete (10)
Operation: Mac subjected to HW delete due to convert eror in new learn (54)
Operation: Mac subjected to HW delete due to convert eror in new learn (54)
Operation: Mac create (9)
Operation: Peer sent; local down and mct learnt (2)
Operation: Mac delete PVRST flush sent to peer (46)
Operation: Mac delete due to hw/sw mismatch (37)
Conditions:- MAC-address should be learned from vPC/vPC+
- Destination MAC of the traffic is vPC peer SVI interface
Workaround:Configuring command 'peer-gateway' under vPC domain might help for most cases. If this does not work, configure a static MAC addresses.
More Info:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(2), 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq61301 |
Title: | FEX FCOE FCNS FC4-TYPE:FEATURE incomplete, empty. |
|
Description: | Symptom:
FEX attached FCoE host showing FCNS FC4 is incomplete, empty.
FCoE initiator lose access to Storage
Conditions:
This issue affects both N6K-600x and N56xx
FCOE Host attached to FEX
Workaround:
Connect Host to Base N6K.
or
Reload N6K/N5K to restore connectivity
Further Problem Description:
Resolution Summary:
Please Note: If you hit this issue and upgrade to a fixed release, you will still need to reload the switch in order to resolve the issue permanently.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | 6.0(2)N2(5.98), 6.0(2)N2(6), 7.0(1)ZN(0.699), 7.0(6)N1(0.207), 7.0(6)N1(1), 7.1(0)N1(0.347), 7.1(0)N1(1), 7.1(0)ZN(0.425) |
|
|
| |
| |
Bug Id: | CSCut71208 |
Title: | Unknown unicast packets coming from CE not punted to CPU |
|
Description: | Symptom:
pings towards SVI are not responded
Conditions:
currently unknown
Workaround:
start pinging from the affected chassis.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur89241 |
Title: | N2K-C2348 FEX does not come up due to "SDP timeout/SFP Mismatch" |
|
Description: | Symptom:
A Nexus N2K-C2348TQ-10GE or 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-C2348TQ-10GE or N2K-C2348UPQ-10GE FEX connected to a Nexus 5K/6K. This issue is resolved in NX-OS 7.1(1)N1(1)
Workaround:
Upgrade the parent N5K/6K to NX-OS 7.1(1)N1(1) and power cycle the the FEX few times with fabric connection to the parent in place. If the FEX does not come online contact TAC
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.412) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)N1(1), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu92452 |
Title: | Too many MTS flush generated when connecting VPC+ MST to legacy RPVST |
|
Description: | Symptom:
Too many MTS flush messages generated when connecting VPC+ MST to legacy RPVST, if multiple switches are connected at the same this can lead to instabilities of the VPC+ pair
Conditions:
Connecting VPC+ MST to legacy RPVST switches
Workaround:
Use RPVST on VPC+ instead of MST
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv01812 |
Title: | N6k: port-security err-disables HIF after switch/fex reload |
|
Description: | Symptom:
HIF ports with port-sec show status as "err-disab" (Error disabled).
Following syslog is generated.
ETHPORT-5-IF_SEQ_ERROR: Error ("Address already secured") communicating with MTS_SAP_ETH_PORT_SEC for opcode MTS_OPC_ETHPM_PORT_PRE_CFG
Conditions:
switch reload or FEX reload
port-security configured on HIF ports
Workaround:
Ports must be shut/no shut to clear the error disable state.
Automated workaround:
event manager applet RESET_ERROR_DISABLED_POTRTS
event syslog pattern "Error disabled. Reason:Address already secured"
action 1.0 syslog priority notifications msg CLEARING_ERROR_DISABLED_PORT
action 1.1 cli command enable
action 1.3 cli command "conf t"
action 1.4 cli command "errdisable recovery cause all"
action 1.5 cli command "no errdisable recovery cause all"
action 1.6 cli command "errdisable recovery cause failed-port-state"
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.0(5)N1(1), 7.1(1)N1(1), 7.2(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut56369 |
Title: | ARP Ingress packets dropped due to 'BIG_DROP_SRC_VLAN_MBR' |
|
Description: | Symptom:
ARP Ingress packets dropped due to 'BIG_DROP_SRC_VLAN_MBR'
Conditions:
On a vpc+ setup having Iluka image 7.0(6)N1(1), it is observed that ARP ingress packets are dropped on FEX interface connected to PVLAN host when STP mode is changed from PVST to MST.
Workaround:
No workaround exits, should not change STP mode
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.258) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus18209 |
Title: | VLAN translation after Non-disruptive ISSU to 7.1(0)N1() image |
|
Description: | Symptom:
After a non disruptive ISSU, FEX fabric interfaces continuously flap after VLAN translation is configured on either an ST or AA FEX.
A "show interface" for the FEX fabric interface(s), that continually flap, indicates an (SDP timeout/SFP mismatch).
Conditions:
Non-disruptive ISSU to Iluka Plus release followed by VLAN translation configuration on a FEX fabric interface..
Workaround:
1) After non-disruptive ISSU, shut/no-shut the port on which the vlan translation needs to be configured.
2) Disruptive ISSU or clean reload.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.426), 7.1(0)N1(0.435) |
|
Known Fixed Releases: | 7.1(0)N1(0.438), 7.1(0)N1(1a), 7.1(0)ZN(0.533), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu06261 |
Title: | N6k Vinic-Forwarding: Multicast failing to reciever after leaf reload |
|
Description: | Symptom:
Receiver off leaf failing to receive multicast traffic after leaf reload and after resending igmp joins.
Conditions:
Leaf reload with a multicast receiver hanging off of it.
Workaround:
Preform a shut/no shut on the VRF to which the impacted receiver belongs to.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu37102 |
Title: | N5K kernel Panic on AIPC driver causing crash |
|
Description: | N5696 crash due to a kernel panic
Symptom:
Conditions:
This has been seen on Nexus running 7.1(1)N1(1) and 7.0(6)N1(1)
Workaround:
Not known
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq46228 |
Title: | FWM hap reset at fwm_ds_trace_add() |
|
Description: | Symptom:FWM core happens at fwm_ds_trace_add() routine.
Conditions:If FWM trace buffer size is configured as 300MB,then this problem can occur
Workaround:Configure FWM trace buffer size as 20,40 or 80MB.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.291) |
|
Known Fixed Releases: | 7.1(0)N1(0.1), 7.1(0)N1(0.363), 7.1(0)N1(1), 7.1(0)ZN(0.438), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.2(0)N1(0.2), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCur02975 |
Title: | Nexus56xx/6k switches may take ~25 sec to respond to some show CLI's |
|
Description: | Symptom:
Nexus 56xx/6k switches may see a ~25-30 seconds delay on executing "show running-config" or "show startup-config"
Also seen with "show running-config interface <>" CLI's.
Worse case scenario leads to crash as well on executing above CLI's.
Conditions:
Switches running 7.0.x releases with breakout interface configuration:
interface breakout slot 1 port 49-52 map 10g-4x
During internal and external test above symptoms were only observed with 7.0(4)N1(1) and later releases.
Workaround:
To view running or startup config exclude cdp:
- show running-config exclude cdp
- show startup-config exclude cdp
Do not execute "show running-config interface <>" CLI and use the above two listed. Same with startup-config.
7.1(0)N1(1) and later release currently have the fix and not impacted by this issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.344) |
|
Known Fixed Releases: | 7.0(1)ZN(0.724), 7.0(6)N1(0.227), 7.0(6)N1(1), 7.1(0)N1(1), 7.2(0)N1(1), 7.2(0)ZN(0.91), 7.3(0)N1(0.3), 7.3(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuo28747 |
Title: | N5K/6K: FWM core during ISSU |
|
Description: | Symptom:A Nexus 5K/6K switch may experience FWM crash upon ND-ISSU in NX-OS 7.x.
This crash may be seen when we already have a 7.x image which is upgraded from either 5.x/6.x and are now trying to perform a Non-Disruptive ISSU to any post 7.0(0)N1(1) image.
Conditions:FWM crash may be seen when a double step ISSU is performed on Nexus 5K/6K switches from a 5.x/6.x release to a 7.x and then another ISSU to a subsequent 7.0/7.1/7.2 release. This crash is seen only when multicast traffic/groups is present in the setup. This crash is not applicable to those customers who are running only unicast/broadcast traffic.
Possible upgrade scenarios
Following is a detailed list of scenarios in which this bug may/maynot be seen:
Scenario 1: Customer is currently using 5.x/6.x release and upgrading to 5.x+/6.x+
No issue.
Scenario 2: Customer is currently using 5.x/6.x release and upgrading to 7.0(x)/7.1(x)
The issue will not affect customers topology until and unless they upgrade to 7.0(x)/7.1(x). After the upgrade, Check whether the Switch has the issue from the CLI mentioned below [Section More-Info]. If the issue exists, Refer to Workaround or upgrade options [Section Workaround] mentioned below, based on customers agreement.
Scenario 3: Customer is currently using 5.x/6.x release and upgrading to 7.2(0)N1(1)-
In this case ND-ISSU is not supported. So this issue will not be seen.
But due to a limitation with Disruptive upgrade between 5.x/6.x to 7.2(0)N1(1) (Limitation - A direct upgrade between these images will lead to loss/mismatch of breakout configs), the customer should perform the upgrade by doing a fresh installation of 7.2(0)N1(1) - Write erase and reload freshly with 7.2(0)N1(1) image. Once the switch is up, reconfigure the switch with previous configs.
Scenario 4: Customer is currently using 7.0(2)N1(1) - 7.0(5)N1(1), has already performed Step1 ISSU(from 5.x/6.x to 7.x) and is now upgrading to higher 7.0(x)+/7.1(x)+
Check whether the Switch has the issue from the CLI mentioned below [Section More-Info]. If the issue exists, then ND ISSU will lead to crash. Refer to Workaround or upgrade options [Section Workaround] mentioned below, based on customers agreement.
Scenario 5: Customer is currently using 7.0(2)N1(1) - 7.0(5)N1(1), has already performed Step1 ISSU(from 5.x/6.x to 7.x) and is now upgrading to 7.2(0)N1(1)
In this case ND-ISSU is not supported. So this issue will not be seen.
But due to a limitation with Disruptive upgrade between 5.x/6.x to 7.2(0)N1(1) (A direct upgrade between these images will lead to loss/mismatch of breakout configs), the customer should perform the upgrade by doing a fresh installation of 7.2(0)N1(1) - Write erase and reload freshly with 7.2(0)N1(1) image. Once the switch is up, reconfigure the switch with previous configs.
Scenario 6: Customer is currently using 7.0(6)N1(1) or 7.1(0)N1(1), has already performed Step1 ISSU(from 5.x/6.x to 7.x) and is now upgrading to higher 7.x+:
Check whether the Switch has the issue from the CLI mentioned below [Section More-Info]. If the issue exists, then ND-ISSU will lead to crash. Refer to Workaround or upgrade options[Section Workaround] mentioned below.
Scenario 7: Customer has started from 7.x release and upgrading to 7.x+ (7.1.x +)
The issue will not be seen on the switch, if the customer has been using 7.x from the beginning and was not using 5.x/6.x before.
Workaround:Workaround
CASE1: CE Network Setup
Disable IGMP snooping before the N
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.1(0)N1(1), 7.1(1)N1(1), 7.2(0)N1(0.231) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut16773 |
Title: | vlan_mgr crash on creating or deleting VLAN |
|
Description: | Symptom:
vlan_mgr may crash on a Nexus 5k after vlan removal.
This bug is linked to CSCur39582.
CSCur39582 solves the vlan_mgr to be unresponsive.
In some situations, this might lead to crash ( this is handled under CSCut16773 )
Conditions:
Deleting the vlan.
Workaround:
no workaround avaiable
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.134), 7.2(0.54) |
|
Known Fixed Releases: | 7.0(7)ZN(0.134), 7.2(0)AB(9), 7.2(0)N1(0.136), 7.2(0)N1(1), 7.2(0)VZN(0.7), 7.2(0)ZN(0.141), 7.3(0)N1(0.3), 7.3(0)N1(1) |
|
|
| |
:
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论