| |
|
Alert Type: | Updated * |
Bug Id: | CSCut74135 | Title: | Fabricpath mode transit - control packets tagged with internal vlan 4041 |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
On a Nexus 6000/5600 running fabricpath , when fabricpath mode transit is configured, the switch is sending control packets like CDP, LACP, ISIS tagged with internal VLAN ID 4041.
This causes a switch like N7K drop the packet. None of the protocols are able to negotiate and come up
Conditions:
Command fabricpath mode transit is configured.
Workaround:
Disable transit mode and reload the switch.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.269), 7.1(1)N1(0.508), 7.2(0)N1(0.147) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.780), 7.0(6)N1(1), 7.0(7)ZN(0.156), 7.1(1)N1(0.511), 7.1(1)N1(1), 7.1(1)ZN(0.67), 7.1(3)ZN(0.313), 7.2(0)N1(0.167), 7.2(0)N1(0.180), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux92689 | Title: | VMM_TIMEOUT: Service SAP 175 for slot 33 timed out in UPGRADE_READY_SEQ |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
Observed %VMM-2-VMM_TIMEOUT: Service SAP 175 for slot 33 timed out in UPGRADE_READY_SEQ during ISSU
Conditions:
On a scaled vpc setup with 24 fexes, observed that ND-ISSU from 7.1(3)N1(2) to .upg image is consistently failing during upgrading first fex due to vmm timeout in upgrade_ready sequence.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(2)N1(0.599), 7.1(3)N1(1.5) |
|
Known Fixed Releases: * | 7.1(3)N1(1.6), 7.1(3)N1(2), 7.1(3)ZN(0.242), 7.1(3)ZN(0.313), 7.1(4)N1(0.777), 7.1(4)N1(1), 7.2(2)N1(0.407), 7.2(2)N1(1), 7.2(2)ZN(0.106), 7.3(0)IZN(0.13) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz91130 | Title: | Changes in NMI handler for ES image |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Switch hangs and doesnt come out of it and console doesn't respond ... Seen on boxes where PCI devices are generating high correctable error ..
Conditions:
This condition can be seen on switches having issue of high PCI correctable error which feed in as NMI to the system
Workaround:
Dont feed in COrrectable /non-fatal errors to system as NMI and reset the system when FATAL NMI is coming
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 6.0(2)N2(7), 7.0(1)N1(1), 7.0(5)N1(1a), 7.0(7)N1(1), 7.1(1)N1(1), 7.1(2)N1(1), 7.2(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.14), 7.0(7)N1(0.18), 7.0(7)N1(0.19), 7.0(7)N1(0.6), 7.0(7)N1(0.9), 7.0(7)N1(1a), 7.1(3)ZN(0.313), 7.1(3)ZN(0.321), 7.1(4)N1(0.854), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva31928 | Title: | N5K/6K: PIM SSM over VPC does not work for L3 orphan ports |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
In Nexus 5600,6000 running 7.3.0 configured for VPC and PIM SSM, L3 orphan ports do not receive multicast traffic if multicast source is behind a VPC and traffic gets hashed to the other VPC peer.
Conditions:
PIM SSM is configured in VPC topologies
Workaround:
Use PIM ASM.
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.3(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv44148 | Title: | Ports status "down (SFP not inserted)" although SFP present |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Port on a Nexus 6000 show as "down (SFP not inserted)".
Conditions:
Seen on Nexus 6001 running 7.0(2)N1(1).
Doing a reload doesn't solve the issue.
Workaround:
A possible workaround is to use the "debug hardware internal bigsur port ethernet eth1/27 force_qsfp_insert" command. This command is not saved across a reload however.
A second workaround to get the ports up is to remove all power cables, and insert them back again.
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.0(2)N1(1), 7.0(6)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.328), 7.1(3)ZN(0.329), 7.1(4)N1(0.859), 7.1(4)N1(0.863), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu21817 | Title: | High convergence time for multicat/broadcast trf during vPC Primary ISSU |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Seeing convergence delay of around 20 Sec , on FTAG-1 reload on scaled setup (4000 VLANs/ 5000 Multicast routes)
Conditions:
Scaled setup :
1) multiple FP core ports / nodes
2) 4000 FP VLANs
3) 5000 multicast routes
Workaround:
Config recommendations:
1. BFD on Fabricpath enabled interfaces ? Better convergence for Unicast
feature bfd
fabricpath domain default >>> This enabled for all fabricpath interfaces
Bfd
feature bfd
Interface >>>> for specific fabricpath interfaces
fabricpath isis bfd
2. IS-IS parameters for better re-convergence
>>> On Leaf
fabricpath domain default
spf-interval 400 50 50
lsp-gen-interval 100 50 50
>>> On Spine
fabricpath domain default
spf-interval 100 50 50
lsp-gen-interval 100 50 50
3. Remove unsed vlans
Further Problem Description:
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: * | 7.1(2)N1(0.573), 7.2(0)N1(0.186), 7.2(1)N1(0.286) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj24129 | Title: | DHCP offers with unicast bootp flag not relayed. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:When Nexus 6000 switch is configured to be DHCP relay agent, if the switch receives DHCP offers with unicast bootp flag, the packet is not relayed to the client.
Conditions:Seen when DHCP client/server uses unicast bootp flag and in fabricpath set up. For the problem to be triggered, the DHCP offer with unicast flag has to ingress on CE or FP port and have DHCP clients on FP core ports.
Workaround:Configure DHCP clients/server to use broadcast bootp flag.
More Info:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(1) |
|
Known Fixed Releases: * | 6.0(2)N2(1), 6.0(2)N2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw60905 | Title: | KOkomo158(FP): DHCP DISCOVERs in same vlan do not cause MAC learn in FWM |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Multiple DISCOVERs in same vlan do not co-exist.
Conditions:
After the first DISCOVER causes auto-config, subsequent DISCOVERs do not cause MAC learn in FWM.
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.158) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.163), 7.1(3)ZN(0.313), 7.1(4)N1(0.717), 7.1(4)N1(1), 7.2(2)N1(0.372), 7.2(2)N1(1), 7.2(2)ZN(0.55), 7.3(0)IZN(0.13), 7.3(0)N1(0.237), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut64996 | Title: | Nexus5548 _Ethernet ports is lost in running-config after reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus5548 _Ethernet ports is lost in running-config after reload
Conditions:
I can't see Ethe rport on Nexus5548's running-config after power on or reload.
Workaround:
1. downgrade NX-OS version to 5.x
2. upgrade NX-OS version to 7.1(O)N1(1b) from 5.x.
reload is not workaround.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.157), 7.1(3)ZN(0.313), 7.1(4)N1(0.712), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo28747 | Title: | N5K/6K: FWM core during ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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.
Further Problem Description:
Point of crash - During pss restore - fwm pss: ip multicast sg entry exists.
This bug gets triggered due to duplicate multicast entries in PSS during first ISSU to 7.x release.
Origin of issue - Iluka. The issue was introduced in 7.0(0)N1(1)
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.
Scenari
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.1(0)N1(1), 7.1(1)N1(1), 7.2(0)N1(0.2), 7.2(0)N1(0.231) |
|
Known Fixed Releases: * | 7.0(7)N1(0.69), 7.0(7)N1(1), 7.0(7)ZN(0.147), 7.1(2)N1(0.570), 7.1(2)N1(1), 7.1(2)ZN(0.30), 7.1(3)ZN(0.313), 7.2(1)N1(1), 7.2(1)ZN(0.15), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy65138 | Title: | After ISSU from 7.1(0)N1(1b) to 7.1(3)N1(1), unused HIF will not come up |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Previously unused 10GB HIFs on a 2248PQ will not come online after an ISSU from 7.1(0)N1(1b) to 7.1(3)N1(1).
Conditions:
2248PQ connected to N6K
N6K is upgraded via ISSU from 7.1(0)N1(1b) to 7.1(3)N1(1)
New 10GB HIF trying to be brought online on the FEX
Workaround:
Reload the FEX
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(3)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.269), 7.1(3)ZN(0.313), 7.1(4)N1(0.803), 7.1(4)N1(1), 7.3(1)N1(0.352), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus18209 | Title: | VLAN translation after Non-disruptive ISSU to 7.1(0)N1() image |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 17-JUN-2016 |
|
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.1(3)ZN(0.313), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw33676 | Title: | fwm core at fwm_fwim_disassociate_pif_from_pc_int -kk 131 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Fwm assert failure !pc_lif->runtime_data.vif_id_allocated . This is seen when the scale configs are applied simultaneously on both the switches in VPC.
Conditions:
Seen in the scale test bed with 900 port-channels and 500 SVI's and also having 2lvpc configs. the crash occurs during the bring down of portchannels.
Workaround:
Applying Configs one switch at a time will not create this crash.
Further Problem Description:
The pd_lif->container_p is having the NUll value for the 2lvpc portchannel.
because of this we are skipping the certain routins and getting captured as vif_id_allocated. container_p is used for vlan xlate related values.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.131) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.289), 7.1(3)ZN(0.313), 7.1(4)N1(0.823), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux40274 | Title: | Multicast traffic dropped due to cell usage stuck for ingress buffer |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Multicast traffic discarded on a Nexus 6000 switch.
Unicast traffic is not affected.
Conditions:
Input discard counter is incrementing on the port connected to the multicast source.
Checking the instant cell usage for the ingress buffer shows the same cell count every time.
Get the ASIC number:
show hardware internal bigsur port ethernet | inc "instance index"
Check the cell count:
show hardware internal buffer info pkt-stats asic-num
Multicast traffic is reaching the destinations , but when the buffer is full the packets are getting discarded .
Workaround:
Move the link connecting the multicast source to another port.
OR
Reload the Nexus 6000 switch.
If interface is pure L3 and PIM neighbours are formed , then issue is not seen , packet are not getting stuck in the buffers .
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(3)N1(1), 7.2(1)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.268), 7.1(3)ZN(0.313), 7.1(4)N1(0.802), 7.1(4)N1(1), 7.2(2)N1(0.418), 7.2(2)N1(1), 7.2(2)ZN(0.126) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur30631 | Title: | Nexus 6000: FWM crash with not enough core files saved |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 6000 switch running 6.0(2)N2(3) might crash in FWM process.
Conditions:
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: * | 5.2(1)N1(8.157), 5.2(1)N1(9), 6.0(2)A5(1.37), 6.0(2)A5(2), 6.0(2)A6(1.105), 6.0(2)A6(2), 6.0(2)N2(5.114), 6.0(2)N2(6), 6.0(2)U5(1.37), 6.0(2)U5(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux14987 | Title: | Nexus 5k/6k crash with "lacp hap reset" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Specific symptoms are unknown.
Conditions:
"lacp" feature must be enabled.
Workaround:
Disable "lacp".
Further Problem Description:
N/A
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.136), 7.1(3)ZN(0.313), 7.1(4)N1(0.701), 7.1(4)N1(1), 7.2(2)N1(0.355), 7.2(2)N1(1), 7.2(2)ZN(0.39), 7.3(0)IZN(0.13), 7.3(0)N1(0.237), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut55443 | Title: | FWM mac trace buffer memory corruption |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
FWM crash and switch reloads.
Conditions:
No specific trigger; Mostly happens with PVLAN configuration.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(4)N1(0.10) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(1)N1(0.511), 7.1(1)N1(1), 7.1(1)ZN(0.67), 7.1(3)ZN(0.313), 7.2(0)N1(0.180), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut08643 | Title: | N5K CoPP does not match router ISIS packets |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1a), 7.1(0)N1(0.349), 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.559), 7.1(2)N1(1), 7.1(2)ZN(0.18), 7.1(3)ZN(0.313), 7.2(0)AB(9), 7.2(0)N1(0.157), 7.2(0)N1(1), 7.2(0)VZN(0.34) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur41721 | Title: | DHCP relay is broken over L3 sub-int port-channel |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
DHCP relay is broken when configured under a L3 port-channel sub-interface.
This works when using a SVI.
Conditions:
Observed on a Nexus 6000 running 6.0(2)N2(4) and 6.0(2)N2(5).
Workaround:
None. Use the SVI instead.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(5) |
|
Known Fixed Releases: * | 7.1(1)N1(0.449), 7.1(1)N1(1), 7.1(1)ZN(0.4), 7.1(3)ZN(0.313), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy79978 | Title: | N5672 ptp state stuck in "Uncalibrated" State |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
PTP state stuck in "Uncalibrated" and corrections are not happening.
Conditions:
this problem will be seen on nexus n56 series switches when ND ISSSU is preformed from any version before 7.1.0 to later versions.
Workaround:
reboot will solve the issue
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.228), 7.1(3)ZN(0.313), 7.1(4)N1(0.767), 7.1(4)N1(1), 7.2(2)N1(0.403), 7.2(2)N1(1), 7.2(2)ZN(0.99), 7.3(1)N1(0.318), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux68595 | Title: | FWM crashes while executing "show platform load-balance forwarding-path" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
switch crashes after executing the command 'show platform load-balance forwarding-path interface port-channel "
N6K-957# sho cores
Module Instance Process-name PID Date(Year-Month-Day Time)
------ -------- --------------- -------- -------------------------
1 1 fwm 3719 2011-05-26 02:20:53
Conditions:
Execute "no hardware multicast hw-hash" under the port-channel
Workaround:
Don't execute "show platform load-balance forwarding-path interface port-channel " after removing hardware multicast hw-hash
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(7)N1(1), 7.2(1)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.313), 7.2(2)N1(0.393), 7.2(2)N1(1), 7.2(2)ZN(0.75) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur09539 | Title: | Series:Unknown MDS Chassis for N72 and N128 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
when call home message is sent, the message content does not contain correct product series for N72 and N128 chassis
Conditions:
none
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.349) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.299), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.373), 7.1(0)N1(1), 7.1(0)OTT(0.41) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw61635 | Title: | vpc crash at fu_fsm_engine_post_event_processing on 48 AA fex bringup |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
vpc core
Conditions:
copying bootflash file to running-config with 600+po
Workaround:
issue is fixed
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.150) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.158), 7.1(3)ZN(0.313), 7.1(4)N1(0.713), 7.1(4)N1(1), 7.2(2)N1(0.407), 7.2(2)N1(1), 7.2(2)ZN(0.104), 7.3(0)IZN(0.7), 7.3(0)N1(0.171), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut35476 | Title: | Bigsur FAULTY slot 0 asic 3, bigsur_stm_dma_monitor_timer_hdlr |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a Nexus 6000/5600, an ASIC might get declared faulty and following log messages can be seen.
%USER-2-SYSTEM_MSG: Bigsur FAULTY slot 0 asic 3, bigsur_stm_dma_monitor_timer_hdlr - bigsurusd %BIGSURUSD-3-BIGSUR_SYSLOG_ERROR: EDMA update channel faulty on slot 0 asic 3
Several ports on the ASIC will be impacted due to this channel being stuck.
Conditions:
Seen on N6000/5600 during layer 2 instabilities such as L2 bridging loop.
Workaround:
If seen on a LEM, reload LEM. If seen on fixed switch, reload switch.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.134) |
|
Known Fixed Releases: * | 6.0(2)N2(6.135), 6.0(2)N2(7), 7.0(6)N1(0.267), 7.0(6)N1(1), 7.1(1)N1(0.493), 7.1(1)N1(1), 7.1(1)ZN(0.46), 7.1(3)ZN(0.313), 7.2(0)N1(0.162), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq36021 | Title: | cdp send - recv messages to/from fex should not block |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
cdp may cause a crash and disconnect fex devices connected to a Nexus N5K or N6K switch while cdp tries to
get configuration information from the fex.
Conditions:
This is seen in a massive setup with many fex devices and at the time a network event which causes other processes to be very busy.
Workaround:
make sure no network event, like routing loop ect are occuring.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: * | 7.1(0)N1(0.302), 7.1(0)N1(1), 7.1(0)ZN(0.391), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun38423 | Title: | Nexus 6000: Packets discarded on ingress |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:In a Nexus 600x switch, all packets received on interface can be dropped. The drops will show up as input discards in the output of show interface ethernet x/y or show queuing interface ethernet x/y
Conditions:It is a rare occurrence which can happens when interface comes up and traffic is already arriving
Workaround:Reload switch to recover
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(1)N1(0.99) |
|
Known Fixed Releases: * | 6.0(2)N2(4.70), 6.0(2)N2(5), 7.0(0)N1(0.103), 7.0(0)N1(1), 7.0(1)ZN(0.239), 7.0(2)N1(0.160), 7.0(2)N1(1), 7.0(3)N1(0.10), 7.0(3)N1(1), 7.1(0)N1(0.1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz86879 | Title: | Config/Unconfig Speed Inconsistency at NIF PO,make it down & FEX Offline |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Speed config change on devices connected to HIF port do not trigger speed re-negotiation on HIF port.
HIF port does not re-negotiate speed until port is shut/no shut.
Secondary vpc link goes into suspended state until secondary HIF port is shut/no shut.
Conditions:
-HIF ports are in speed auto state
-Change speed config on vpc connected link to trigger vpc speed inconsistency. Secondary vpc link goes into suspended state.
-Then change speed back to match with it's peer. Speed change will not be picked up by the secondary vpc link, it stays in suspended state until HIF port is shu/no shut
Workaround:
shut/no shut on HIF port
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(4)N1(0.826) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.300), 7.1(3)ZN(0.313), 7.1(4)N1(0.834), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu30807 | Title: | FWM hap reset @ fwm_fwim_delete_lif while poweroff the module. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
FWM Crash
Conditions:
During powering off GEM module
Workaround:
No workaround
Further Problem Description:
FWM is trying to get the bigsur_asic_version during the port cleanup but the crash was due to the fact that the module was already cleaned up
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.195) |
|
Known Fixed Releases: * | 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.1(3)ZN(0.313), 7.3(0)N1(0.80), 7.3(0)N1(1), 7.3(0)ZN(0.78) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur02975 | Title: | Nexus56xx/6k switches may take ~25 sec to respond to some show CLI's |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 17-JUN-2016 |
|
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.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(0)ZN(0.91), 7.3(0)N1(0.3), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq61301 | Title: | FEX FCOE FCNS FC4-TYPE:FEATURE incomplete, empty. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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.
|
|
Last Modified: | 17-JUN-2016 |
|
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), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu96337 | Title: | N5672UP NFM crash after config change |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a scaled setup, when the netflow feature is enabled on a large number of VLANs and interfaces, there were issues seen that either the Switch reloads or there is drop in netflow export packets. Example of scaled config on a switch can be : netflow feature enabled for approx. 1500 vlans those are allowed for approx. 400 port channels.
Conditions:
Before these version[7.2(1)N1(1),7.1(3)N1(1),7.0(7)N1(1)], for the above setup mentioned in the Symptoms when interfaces are moved from classic Ethernet to fabric path, the switch reloads.
Another condition is that when there is too much traffic, the NFM export queue will be filled to the max threshold (approx. 26000 packets) that will result in purging the whole queue in one go. This results in drop of export packets. To check the NFM export packet queue, the cli is ::
Workaround:
There is no workaround , Customer needs to upgrade to release with fix [7.2(1)N1(1),7.1(3)N1(1),7.0(7)N1(1)]. For the NFM export packets getting dropped, it is intermittent state and the system recovered itself from this state by purging the whole queue.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.291), 7.0(7)N1(1), 7.0(7)ZN(0.186), 7.1(3)N1(0.626), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.33), 7.2(1)N1(0.274), 7.2(1)N1(1), 7.2(1)ZN(0.38) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur50810 | Title: | vpc_simultaneous_reload failed due to missng flogi in npv switch |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
In FCoE scale test scenario, some VFCs don't come up after simultaneous reload of both VPC peers.
Conditions:
VFCs don't come up because the eth port / PO they are bound to are in VLAN ErrDisable state.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.379) |
|
Known Fixed Releases: * | 7.0(2)FIP(0.6), 7.1(0)N1(0.419), 7.1(0)N1(1), 7.1(0)ZN(0.492), 7.1(1)N1(0.34), 7.1(1)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(0)VZN(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy83222 | Title: | N5696+N5696-M12Q with sub-interf;Snmppolling Cause MTS Buff leak-pfstats |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus 5696 with N5696-M12Q Ethernet Modules running sub interfaces, On 7.0(6)N1.1 code.
Conditions:
Polling via SNMP MIBs
1.3.6.1.2.1.31.1.1.1.10
1.3.6.1.2.1.31.1.1.1.6
1.3.6.1.2.1.31.1.1.1.7
1.3.6.1.2.1.2.2.1
Workaround:
Disable snmp on switch , this will slowly reduce the MTS buffer, but takes hours. To clear whole MTS buffer quick rather than waiting after disabling SNMP, Reload the box.
Command to disable SNMP:
No snmp-server protocol enable
Further Problem Description:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(6)N1(1), 7.2(0)N1(0.144) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.281), 7.1(3)ZN(0.313), 7.1(4)N1(0.816), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq05505 | Title: | Slowness in bringing vlan up on a vpc setup |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Slow bringup in svi interface after auto-config is applied.
Conditions:
When a new VLAN and vn-segment is added during auto-config in vPC setup. For example, the delay happens when a VRF /segment is not available on the leaf where a VM host is moved to.
Workaround:
None. VLAN will be in suspended state for about 20 - 30 seconds. It will resume operational automatically after vlan consistency check failure is cleared by the system.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(3)N1(0.76) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.763), 7.0(6)N1(1), 7.1(0)N1(0.279), 7.1(0)N1(1), 7.1(0)ZN(0.376), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur13534 | Title: | ptplc reset while copy ptp config followed by poweroff & no poweroff mod |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ptplc process crash
Conditions:
issue is specific to UP LEM(N6004X-M20UP). If ptp is configured on UP LEM interfaces and reload(or module power off/power on) is performed.
Workaround:
before triggering reload(or module power off/power on), remove ptp config and apply config back once device is UP.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.339) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.250), 7.1(3)ZN(0.313), 7.2(2)N1(0.407), 7.2(2)N1(1), 7.2(2)ZN(0.112), 7.3(1)N1(0.332), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq46228 | Title: | FWM hap reset at fwm_ds_trace_add() |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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.
|
|
Last Modified: | 17-JUN-2016 |
|
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.1(3)ZN(0.313), 7.2(0)N1(0.2), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu00391 | Title: | N5K/6K: BCAST flag missing for FTAG 2 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1), 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(1)N1(1a), 7.1(1)ZN(0.120), 7.1(2)N1(0.541), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(1)N1(0.251), 7.2(1)N1(1), 7.2(1)ZN(0.16) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq59436 | Title: | IPQOSMGR-4-QOSMGR_PPF_WARNING: PPF library warning: DDB Error: 0x4117004 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The following error appears on the console at boot up stage.
?IPQOSMGR-4-QOSMGR_PPF_WARNING: PPF library warning: DDB Error: 0x41170040?
Conditions:
Error message displayed on boot up of n5500/ n6000
Workaround:
No workaround available
Further Problem Description:
This issue doesn't have an impact on the functionality.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(4)N1(0.148), 7.2(0)N1(0.134) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.124), 7.1(2)N1(0.544), 7.1(2)N1(1), 7.1(2)ZN(0.3), 7.1(3)ZN(0.313), 7.2(0)N1(0.166), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.169) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut05530 | Title: | IPLUS_464_VXLAN_SCALE_Testbed: FWM core after flapping NIF ports |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
FWM Core.
Conditions:
After flapping NIF port in scale topology.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
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.1(2)N1(1), 7.1(3)ZN(0.313), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut84067 | Title: | FWM core hit in the JANJUC 163 image after moving into maintenance mode |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:FWM process Crash After moving into maintenance mode. Core file generated.
Conditions:- Switch is toggled between maintenance mode and no maintenance mode
- Cmd "system mode maintenance" & "no system mode maintenance"
- Observed only in the JANJUC 163 image.
Workaround:- No Work around available
- Observed only once and not reproducible
More Info:- when the system is moved to the maintenance mode all the interfaces are brought down
- After a few seconds crash is observed in the fwm module.
- From the core decode it shows there is a access to the null pointer in the acl update part.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.163) |
|
Known Fixed Releases: * | 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.1(3)ZN(0.313), 7.3(0)N1(0.80), 7.3(0)N1(1), 7.3(0)ZN(0.78) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu97262 | Title: | Lot of unwanted packets seen on debug dhcp all |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
DHCP Snooping might modify destination MAC address in unicast reply from DHCP Server by changing unicast MAC address to broadcast MAC address.
Conditions:
The issue was seen on N5K-C5672UP device performing L2 switching for the traffic when DHCP Snooping enabled.
Workaround:
Disable DHCP Snooping on the device.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(2)N1(0.555), 7.2(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.70), 7.0(7)N1(1), 7.0(7)ZN(0.149), 7.1(2)N1(0.569), 7.1(2)N1(1), 7.1(2)ZN(0.29), 7.1(3)ZN(0.313), 7.2(1)N1(0.244), 7.2(1)N1(1), 7.2(1)ZN(0.10) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo79794 | Title: | wrong met ptr programming on l3 link to spine shut in vici bari setup |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
seen when running vpc switchover script
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: * | 7.0(1)N1(0.72), 7.1(0)N1(0.161) |
|
Known Fixed Releases: * | 7.1(0)N1(0.207), 7.1(0)N1(1), 7.1(0)ZN(0.312), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus39651 | Title: | N6000/N5600: CRC errors on random 40 Gig port after reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Random 40 gig interfaces may see CRC errors after the module or switch is reloaded.
Conditions:
Issue seen on Nexus 6000/5600 40G ports.
Affects both 6.x and 7.x release.
Workaround:
Shut/no shut of the interface fixes the issue. This bug is resolved in NX-OS 6.0(2)N2(7), 7.0(6)N1(1) and 7.1(1)N1(1). Note the NX-OS needs to be upgraded on both the transmitting and receiving side for the bug to be cleared.
Further Problem Description:
Note CRC errors could occur for other reasons too such as bad cabling, stomping etc. Signature of this defect.
1)On the switch seeing the CRC errors, the errors are counted as RX_PKT_CRC_NOT_STOMPED
Spine-2# sh int ethernet 1/1 | inc CRC
0 runts 0 giants 445226948 CRC 0 no buffer
Spine-2# show hardware internal bigsur port ethernet 1/1 counters rx | inc CRC
RX_PKT_CRC_NOT_STOMPED | 445226948 | 445226948 | 4641
RX_PKT_CRC_STOMPED | 0 | 0 | 0
Spine-2#
On the other side of the link, the frames are not leaving corrupted.
2)If it is due to this bug, a shut/no shut of the interface will clear the problem.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: * | 6.0(2)N2(6.130), 6.0(2)N2(7), 7.0(6)N1(1), 7.1(1)N1(0.477), 7.1(1)N1(1), 7.1(1)ZN(0.30), 7.1(3)ZN(0.313), 7.2(0)N1(0.114), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus28101 | Title: | N5K/6K: Inband TACACS traffic matched against exception-class in CoPP |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 17-JUN-2016 |
|
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.1(3)ZN(0.313), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux23707 | Title: | FWM hap reset with uplink-FO cfg on Maywood HIFs connctd to UCS VIC1225T |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
If we enable uplink-failover option on vNICs created in UCS VIC1225T, and configure corresponding veths bound to FEX HIFs on N6K VPC switches, then fwm hap reset happens once the veths come up.
Conditions:
1. Create Veths on FEX HIFs
2. Bind the first physical interface to the veth
3. For uplink failover configuration the second interface is bound to the veth, l
4. No shut the veth interface, when the veth comes up, FWM hap reset happens.
Workaround:
No workaround available
Further Problem Description:
As of now, the issue is known to be seen with FEX HIFs of specific FEXs which use tiburon asic i.e N2348UPQ, N2348TQ, N2332TQ & N2348TQ-E, connected to any UCS server with VIC adapter card. When issue is hit, FWM hap reset is seen on both VPC switches.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.208) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.163), 7.1(3)ZN(0.313), 7.1(4)N1(0.717), 7.1(4)N1(1), 7.2(2)N1(0.376), 7.2(2)N1(1), 7.2(2)ZN(0.59), 7.3(0)N1(0.255), 7.3(0)N1(1), 7.3(0)ZN(0.231) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux22458 | Title: | Multicast traffic drop after fabric link shut on primary vpc switch |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Multicast traffic drop after fabric link shut on primary vpc switch
Conditions:
After ISSU, fabric link shut is performed.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(3)N1(0.684) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.167), 7.1(3)ZN(0.313), 7.1(4)N1(0.721), 7.1(4)N1(1), 7.2(2)N1(0.391), 7.2(2)N1(1), 7.2(2)ZN(0.73) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus31100 | Title: | N56K/6K: After upgrade to 7.1(0)N1(1) VPCs in down state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After a disruptive upgrade of a Nexus 5600/6000 to NX-OS 7.1(0)N1(1), vPCs will fail to come up on the newly upgraded switch. VPCs will be in a down state due to Global compat check failed
esc-5672-right# sh vpc brief
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 572
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : failed
Per-vlan consistency status : success
Configuration inconsistency reason: invalid argument to function call
Type-2 consistency status : success
vPC role : primary, operational secondary
Number of vPCs configured : 3
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ --------------------------------------------------
1 Po572 up 1-10
vPC status
----------------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
------ ----------- ------ ----------- -------------------------- -----------
119 Po119 down* failed Global compat check failed -
129 Po129 down* failed Global compat check failed -
148 Po148 down* failed Global compat check failed -
Conditions:
Seen after a disruptive NX-OS upgrade to 7.1(0)N1(1) of a Nexus 5600/6000 with vPCs configured. This issue is seen in a upgrade scenario of switches in vPC domain where one switch is running 7.1(0)N1(1) and the other switch is yet to be upgraded. This bug is seen after a disruptive NX-OS upgrade of Nexus 5600/6000 to NX-OS 7.1(0)N1(1). This bug is NOT seen in Nexus 5548/5596 series switches.
Workaround:
Upgrade NX-OS to 7.1(0)N1(1a)
Further Problem Description:
This bug is seen due to a new VPC Type-1 consistency check added as part of Vlan Translation feature in NX-OS 7.1(0)N1(1). Since the other Nexus switch in the VPC domain is still running older code which does not support this feature, VPC Type-1 check fails leading to this problem.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.1(1)N1(0.78) |
|
Known Fixed Releases: * | 7.1(0)N1(0.434), 7.1(0)N1(1a), 7.1(0)ZN(0.523), 7.1(1)N1(0.60), 7.1(1)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur16747 | Title: | satctrl cored after write-erase& applying config with 'FEX-QoS-offload' |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After write erase, reload and applying the config with 'FEX-QoS-offload' satctrl core's and Fex goes offline
Conditions:
Write erase, reload and apply the config with 'FEX-QoS-offload' satctrl core's and Fex goes offline
Workaround:
Reload the switch
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.349), 7.2(0)N1(0.100) |
|
Known Fixed Releases: * | 7.0(6)N1(1), 7.1(1)N1(0.486), 7.1(1)N1(1), 7.1(1)ZN(0.38), 7.1(3)ZN(0.313), 7.2(0)AB(9), 7.2(0)N1(0.134), 7.2(0)N1(0.137), 7.2(0)N1(1), 7.2(0)VZN(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq48578 | Title: | Nexus5600/6000: Spico firmware crash after reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Intermittently some interfaces do not come up after reload with the latest SERDES SPICO FW. This is due to the SPICO crashing which prevents the link init from succeeding. The crash is caused when the page swapping required for link training is somehow interrupted and doesn't complete successfully.
Conditions:
This issue can occur during the booting or reload of Nexus 5600/6000 switches. May also be seen during normal runtime. This is seen for 40G ports.
Workaround:
A reload of the switch or if affected port is on an expansion module or LEM, a soft reset could recover the port.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(4)N1(0.138) |
|
Known Fixed Releases: * | 7.0(4)N1(1), 7.1(0)N1(0.312), 7.1(0)N1(1), 7.1(0)ZN(0.398), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux35561 | Title: | L3 Norcal 48 fex scale: FWM hap reset upon module poweroff |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
in a scale setup of 32 fex , issue is seen while powering off the module to which all the fexes are connected.
Conditions:
powerof module with 32 fex setup
Workaround:
1. First, shut down NIF port-channels configured for Fexes in the module being powered-off
2. Wait for Fexes to go to offline state
3. Run `poweroff module` and `no poweroff module`
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.220) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.276), 7.1(3)ZN(0.313), 7.1(4)N1(0.810), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq62914 | Title: | N6K: Config sync failed for 'storm-control' under FEX interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A nexus 6000 series switches VPC pair may fail to commit configuration changes with config-sync after a reload.
Peer information:
----------------
IP-address: x.x.x.x
Sync-status: Not yet merged
Merge Flags: pending_merge:1 rcv_merge:1 pending_validate:0
Status: Verify Failure
Error(s):
Validation Failed: Config validation failed as found changes on both sides. rcvd_rev: 4, expected_rev: 0
interface Ethernet166/1/45
no cdp enable
interface Ethernet166/1/45
storm-control broadcast level 0.50
Conditions:
Nexus 6000 VPC pair with switch-profiles having configured the command below under a FEX interface:
-"storm-control broadcast level "
Workaround:
Manually re-enter the config on the Nexus 6000 where config missing and commit
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.549), 7.0(4)N1(0.156), 7.0(4)N1(1), 7.1(0)N1(0.319), 7.1(0)N1(1), 7.1(0)ZN(0.404), 7.1(3)ZN(0.313), 7.2(0)VZN(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur49982 | Title: | BBC: FEX takes more than 6 mins to come online in AA mode |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
FEX takes more than 6 mins to come online in AA mode
Conditions:
When we do fex reload in AA setup. In standalone no issues.
Workaround:
no
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.389), 7.1(0)N1(0.406) |
|
Known Fixed Releases: * | 7.1(0)ZN(0.554), 7.1(1)N1(0.446), 7.1(1)N1(1), 7.1(3)ZN(0.313), 7.2(0)AB(2), 7.2(0)N1(1), 7.2(0)VZN(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv75457 | Title: | fwm hap reset is seen while applying scaled config |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
fwm hap reset observed while bringing up l3 lif logical bring up
Conditions:
observed fwm crash only if /mnt/pss/rsvd_vlan_start value is touched which decides the monster bd value for the system, by default monster bd value is 4046, here due to /mnt/pss/rsvd_vlan_start is touched with very low no and monster bd value went to 89 which matched vlan created for subinterface which causes this issue. We wont face this problem if /mnt/pss/rsvd_vlan is not touched.
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(7)N1(0.78) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.258), 7.1(3)ZN(0.313), 7.1(4)N1(0.793), 7.1(4)N1(1), 7.2(2)N1(0.410), 7.2(2)N1(1), 7.2(2)ZN(0.117), 7.3(1)N1(0.337), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw75381 | Title: | Masking of Root Control Register for NMI hang issue |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 5600 series switch may experience hangs or reboots during a storm of NMI (non-maskable hardware interrupts) to the main CPU. An interrupt is a message sent between hardware components in the system, and "non-maskable" refers to the fact that the receiving side normally can't ignore the message. In the context of this bug, the NMI messages are originating from the chassis PCIe bus.
There are three means of identifying this bug:
1) If the switch is running NX-OS 6.0(2)N2(5) and later or 7.0(3)N1(1) and later, it will be capable of raising a syslog event when excessive interrupts are being generated on the PCIe bus. Example:
%USER-0-SYSTEM_MSG: 2032: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
2) During the NMI storm to the CPU, it is known to often cause errata to be written to the "uC reset code" field within the reload records. This in turn can cause a false message to be logged indicating a "microcontroller brownout" occurred when one did not. Example:
SWITCH# show logging onboard internal reset-reason.
Mon Jan 1 00:00:00 2015: Card Uptime Record
----------------------------------------------
Uptime: 0, 0 days 0 hour(s) 0 minute(s) 0 second(s)
Reset Reason: Unknown (0)
Reset Reason SW: Unknown (0)
Reset Reason (HW): uC reset code: 0x4800
Host Requested Reset: reload
Microcontroller Detected Platform Reset <=====
3) This is the most reliable method to identify the bug: Run the following command several times back to back, waiting about a minute in-between. This will tell you if NMI events are occurring in the background:
show system internal file /proc/interrupts | incl NMI
Example:
SWITCH# show system internal file /proc/interrupts | incl NMI
NMI: 57000 0 0 0 0 0 0 0 Non-maskable interrupts
SWITCH# show system internal file /proc/interrupts | incl NMI
NMI: 58000 0 0 0 0 0 0 0 Non-maskable interrupts
SWITCH# show system internal file /proc/interrupts | incl NMI
NMI: 59000 0 0 0 0 0 0 0 Non-maskable interrupts
Conditions:
Workaround:
This issue is caused by non-essential ports on the PCIe bus transmitting data. This has been fixed in later NX-OS releases. If an upgrade cannot be performed immediately, please contact TAC to load a debugging plugin. This will grant access to the Linux shell where the ports can be temporarily blocked via the CLI. Note that this workaround does not survive a reload, and the NX-OS upgrade is suggested as a long-term fix.
Further Problem Description:
Prior bugs, CSCus68610 and CSCuv40217 were an incomplete fix for this issue.
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(7), 7.0(4)N1(1), 7.0(7)N1(1), 7.1(1)N1(1), 7.1(2)N1(1), 7.2(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.308), 7.0(7)ZN(0.266), 7.0(8)N1(1), 7.1(3)N1(0.665), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.74), 7.2(2)N1(0.358), 7.2(2)N1(1), 7.2(2)ZN(0.42) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux11037 | Title: | LACP L3 port-channel remains suspended between spine-leaf |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:In vinci/evpn setup, if the members port of the port-channel interface are MTLITE then programming xlate entries to h/w is skipped.
Conditions: In vinci/evpn setup, initially bring up the port-channel with L2 config,
will make all the members are part of MTLITE and then configure 'no switchport'
on the port-channel interface, will make port-channel interface to L3 but
all members are remain as MTLITE. If the member are MTLITE then programming of
xlate entries to h/w is skipped.Due to that LACPDU's were dropped and Po goes
to suspended state.
Workaround:Create explicit Port-channel first then configure the member ports, eventually L3 Port-channel comes up and functional.
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.191) |
|
Known Fixed Releases: * | 7.3(0)IZN(0.13), 7.3(0)N1(0.222), 7.3(0)N1(1), 7.3(0)ZN(0.199), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw09982 | Title: | Crash on N5k after Dell server /w N2K FEX modules inserted is powered on |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A HAP reset causes a system reload after the FEX process crashes:
Reason: Reset triggered due to HA policy of Reset
System version: 7.0(5)N1(1)
Service: fex hap reset
Conditions:
The issue was first seen when a Dell server with FEX modules first powered on. There is two Nexus 5ks that were pre-configured for 6 FEX modules (3 from the FEX modules inserted in one DELL server and 3 from another). In all there are 6 FEX modules attached. At around the same time, both DELL servers were turned on. As the FEX modules came online, both Nexus 5ks crashed.
Workaround:
None Known
Further Problem Description:
Here is information on the DELL server and FEX modules:
DELL Server - PowerEdge M1000e
FEX Modules inserted in the Dell Server: N2K-B22DELL-P-FI
The exact model of DELL server and N2k blade likely does not matter. This information was just what was first observed triggering a crash.
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.266), 7.0(8)N1(0.317), 7.0(8)N1(1), 7.1(3)N1(4), 7.1(3)ZN(0.152), 7.1(3)ZN(0.313), 7.1(4)N1(0.707), 7.1(4)N1(1), 7.3(0)N1(0.143), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw66815 | Title: | Nexus 5k/6k may reload with "fex hap reset" when FEX is not supported. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Device reloads with "fex hap reset" after "show fex" or "show fex # transceiver".
Conditions:
FEX is not supported in used NX-OS version.
Workaround:
Upgrade to NX-OS which supports this FEX.
Further Problem Description:
N/A
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.272), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.100), 7.0(3)IDM3(0), 7.0(3)IDM3(0.6), 7.3(0)IZN(0.7), 7.3(0)N1(0.169), 7.3(0)N1(1), 7.3(0)ZN(0.157) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw10906 | Title: | N5K/N6K vpc ports missing from FTAG tree |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ports are missing on FTAG tree causing broadcast/mulitcast/ARP/ETC.. packets to get dropped.
Conditions:
a) one of the vPC peer is permanently down
b) after one peer goes down this switch has only one FP link connected , and if that goes down too then FTAG tree is deleted and reinited.
Workaround:
none
Further Problem Description:
NA
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(3), 6.0(2)N2(7) |
|
Known Fixed Releases: * | 7.1(3)N1(0.639), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.47), 7.2(2)N1(0.363), 7.2(2)N1(1), 7.2(2)ZN(0.46), 7.3(0)N1(0.135), 7.3(0)N1(1), 7.3(0)ZN(0.124) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw51800 | Title: | unable to delete param-list from config file |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When using auto-config, the param-list of a profile are not removed when a profile is un-applied.
Conditions:
This happens after "copy r s" and reload reload with param-list / applied configs present in startup config.
Workaround:
Use no param-list xyz cross-check command to force remove the param-list if it is not actually being used.
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.150) |
|
Known Fixed Releases: * | 7.0(3)I3(0.276), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.100), 7.0(3)IDM3(0), 7.0(3)IDM3(0.6), 7.1(3)N1(2.13), 7.1(3)N1(4), 7.1(3)ZN(0.131), 7.1(4)N1(0.696) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy02812 | Title: | ifmgr hap reset: show system internal im info module "non existing slot" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ifmgr hap reset when running CLI:
show system internal im info module "non existing slot"
Conditions:
show system internal im info module CLI is run
Workaround:
do not use "show system internal im info module x" with any non existing, non initialized module number
Further Problem Description:
ifmgr hap reste is seen when running the CLI:
show system internal im info module "non existing slot"
Issue is seen for some slot#s like 99, 59, 39, etc..
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.268) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.242), 7.1(3)ZN(0.313), 7.1(4)N1(0.777), 7.1(4)N1(1), 7.2(2)N1(0.407), 7.2(2)N1(1), 7.2(2)ZN(0.106), 7.3(0)N1(0.278), 7.3(0)N1(1), 7.3(0)ZN(0.256) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux27565 | Title: | Crash seen in eth_port-channel on BL node during scale |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
eth_port_channel crash is seen on a border leaf node upon reload
Conditions:
This scale setup has around 1000 sub-interfaces and 500 VRFs in the config.
Workaround:
No workaround exists.
Further Problem Description:
The config for the 500 vrfs is not saved [ no copy r s] but it is instantiated using node recovery when the BL boots up
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.216) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.110), 7.1(3)ZN(0.313), 7.1(4)N1(0.689), 7.1(4)N1(1), 7.2(2)N1(0.337), 7.2(2)N1(1), 7.2(2)ZN(0.20), 7.3(0)IZN(0.13), 7.3(0)N1(0.220), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw75779 | Title: | [Haf] VFC interface are not coming up on module 2 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VFC interface are not coming up on module 2 of Hafnium Switch
Conditions:
VFC interface are not coming up on module 2 of Hafnium Switch
Workaround:
None
Further Problem Description:
VFC interface are not coming up on module 2 of Hafnium Switch
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.169) |
|
Known Fixed Releases: * | 7.3(0)IZN(0.7), 7.3(0)N1(0.180), 7.3(0)N1(1), 7.3(0)ZN(0.162), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw17076 | Title: | ipfib hap reset on an access Nexus 5548P in a Layer3 Scale topology |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ipfib process crash
Conditions:
issue is seen on nexus 5000 platform during PBR adjacency delete
Workaround:
none.
Further Problem Description:
Crash is seen while printing the debug trace. As part of PBR adjacency delete, adjacency gets destroyed(if reference count is 0) and for debug print same adjacency pointer(which is already freed/destroyed).
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.113) |
|
Known Fixed Releases: * | 7.1(3)N1(0.632), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.40), 7.2(1)N1(0.309), 7.2(1)N1(1), 7.2(1)ZN(0.72), 7.3(0)N1(1), 7.3(0)ZN(0.121), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux83653 | Title: | FWM hap reset after upgrade to 7.0(7)N1(1) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 6000 switch can crash in FWM process after a disruptive upgrade to NX-OS 7.0(7)N1(1)
Conditions:
Switch is upgraded disruptively to NX-OS 7.0(7)N1(1)
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.237), 7.1(3)ZN(0.313), 7.1(4)N1(0.773), 7.1(4)N1(1), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu37102 | Title: | N5K kernel Panic on AIPC driver causing crash |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | A Nexus 5K/6K could reload 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:
Software fix is currently available in NX-OS 7.1(2)N1(1).
A debug plugin based workaround also exists. Please contact TAC to obtain the workaround.
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(7), 7.1(1)N1(1), 7.2(0)N1(0.97), 7.3(0)N1(0.104) |
|
Known Fixed Releases: * | 7.0(6)N1(1.4), 7.0(6)N1(2s), 7.0(7)N1(0.65), 7.0(7)N1(1), 7.0(7)ZN(0.141), 7.1(2)N1(0.575), 7.1(2)N1(1), 7.1(2)ZN(0.36), 7.1(3)ZN(0.313), 7.2(1)N1(0.246) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw59277 | Title: | FEX 2348 A-A: Packets send to wrong FEX HIF interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Packets are being forwarded to wrong port in FEX A-A setup. This issue can be seen when FEX is
connected to any parent switch like Nexus 5000/6000 or Nexus 7000 or Nexus 9000.
Conditions:
2348/2332 FEX's in A-A Mode
Workaround:
Either of the following workaround should help mitigate the issue.
- Reload the impacted FEX.
- When the host is dual-homed both FEX should be reloaded.
- If FEXes are dual homed, then change them to single homed.
- If this is an EVPC setup and servers are in VPC to the fex, then shut down one interface link
going to one of the fexes. Ie make the Server standalone to the FEX.
More Info:None.
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.1(2)N1(1), 7.1(3)N1(0.647), 7.1(4)N1(0.722), 7.3(0)D1(0.138), 7.3(0)N1(0.208), 7.3(0)N1(0.245) |
|
Known Fixed Releases: * | 7.0(2)FIP(0.201), 7.0(2)FIP(0.205), 7.0(2)FIP(0.206), 7.0(2)FIP(0.207), 7.0(2)FIP(0.208), 7.1(3)N1(2.7), 7.1(3)N1(4), 7.1(3)ZN(0.196), 7.1(3)ZN(0.313), 7.1(4)N1(0.740) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz86143 | Title: | Deadlock in NXOS in 7.0.7 and prior images |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Switch hangs and doesnt come out of it and console doesn't respond ... Seen on boxes where PCI devices are generating high correctable error ..
Conditions:
This condition can be seen on switches having issue of high PCI correctable error which feed in as NMI to the system
Workaround:
Dont feed in COrrectable /non-fatal errors to system as NMI
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(7), 7.0(1)N1(1), 7.0(5)N1(1a), 7.0(7)N1(1), 7.1(1)N1(1), 7.1(2)N1(1), 7.2(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.3), 7.0(7)N1(1a), 7.1(3)ZN(0.313), 7.1(4)N1(1), 7.3(1)N1(0.154), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz79130 | Title: * | ethpm misprogramming |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
CE trunk interface on Leaf switch receives traffic in vlan which is not allowed and forwards it into a fabric
Conditions:
not known
Workaround:
not known
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 7.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur78132 | Title: | N2K - Input Align-Err on FEX Host Interfaces |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Input Align-Err increases on FEX HIF ports which is not-connected.
This is a cosmetic issue.
NEXUS# show int e101/1/1-32 counters errors
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth101/1/1 0 0 0 0 0 0
Eth101/1/2 0 0 0 0 0 0
Eth101/1/3 4 2 0 6 0 0 <--- ###
Eth101/1/4 0 0 0 0 0 0
Conditions:
Using 2300 series FEX
Port was up at 1000 full and has now gone down due to remote fault now in notconnect state
or
interface is hardcoded for speed 1000 and is in a notconnect state
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: * | 7.0(3)I3(1), 7.1(3)N1(0.674), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.86), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZN(0.12), 7.3(0)IZN(0.7), 7.3(0)N1(0.160) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj27098 | Title: | N6K: Packet drops with ECC errors |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
In a Nexus 6000 switch, packet loss is seen when parity errors are seen.
Conditions:
Parity errors are seen in port ASIC SRAM leading to packet drops/loss
Workaround:
Contact TAC to identify the problem and workaround.
Further Problem Description:
|
|
Last Modified: | 06-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(1), 6.0(2)N2(2) |
|
Known Fixed Releases: | 6.0(2)N2(2.46), 6.0(2)N2(2.47), 6.0(2)N2(2.48), 6.0(2)N2(2.49), 6.0(2)N2(3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy67291 | Title: | HIF ports flap when secondary peer is replaced in vPC+ enviroment |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | In a vPC+ environment when we simulate secondary peer replacement, all HIF interfaces for dual-home FEX flap on primary switch.
Symptom:
In an vPC+ environment with dual-home FEX, when simulating secondary peer replacement, all interfaces on FEX flap on primary switch.
HIF interfaces do not flap when secondary peer is reloaded or when peer-link is flapping.
Conditions:
+isolate connections on secondary peer
+write erase the config and reload the switch
+reconfigure the switch and reconnect it in the vPC+
+system default switchport shutdown command is configured on the peers
Workaround:
Configured " no system default switchport shutdown".
Further Problem Description:
|
|
Last Modified: | 07-JUN-2016 |
|
Known Affected Releases: | 7.0(2)N1(1), 7.0(7)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy71942 | Title: | Absolute time-out causes PPM's background VSH sessions to end |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When line vty's absolute time-out is set, it causes PPM's background VSH sessions to end. This leaves PPM with stale VSH handles and an attempt to write a VSH command fails. The next attempt to write command
Conditions:
When line vty; absolute-timeout is set to a non zero value. After the timeout period ends, the first attempt to configure config-profile or port-profile aware commands to fail. The consecutive attempts succeed until the next time-out.
Workaround:
Remove the absolute-timeout configuration from under line vty.
If the PPM background sessions have already died before the the absolute-timeout config is removed. Then next attempt to write VSH command would fail, this would cause PPM to respawn a background session which will be launched without the absolute time-out config and that session to would remain alive indefinitely.
PPM holds four background session to handle parallel requests. If there are four parallel attempts to write configs after the absolute-timeout config is removed, all four would fail at their first attempt, but all consecutive attempts will work.
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 7.1(3)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(2.13), 7.1(3)N1(2.14), 7.1(3)N1(4), 7.1(3)ZN(0.222), 7.1(4)N1(0.762), 7.1(4)N1(1), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva09099 | Title: | Nexus5672:host lost access for LUN on storage |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Host lost connectivity to LUNs on storage through Nexus5672.
Storage is connected through FC port.
This issue seems to happen after link down/up of FC port which storage is connected.
Conditions:
Nexus5672
NXOS7.3(0)N1(1) and 7.2(1)N1(1)
Storage is connected to fc port on Nexus5672
Workaround:
one of following recover the issue
- reboot Nexus5672
- shutdown fc port storage is connected
and purge fcid allocation cache with "purge fcdomain fcid vsan XXX"
no shutdown fc port storage is connected
Further Problem Description:
|
|
Last Modified: | 15-JUN-2016 |
|
Known Affected Releases: | 7.2(1)N1(1), 7.3(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz22317 | Title: | Fabricpath VPC+ multicast traffic is sending with wrong FTAG |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Multicast traffic drop with RPF error on SPINE
Conditions:
Leaf switch sends multicast data on a interface ( say that is part of FTAG-1) , on spine switch that interface is not part of FTAG-1, and eventually SPINE drops the packet.
Workaround:
Bounce interface (shut/no shut) on which affected multicast traffic is being received.
Further Problem Description:
VPC+ switch 1 is active for FTAG 2, but sends packets with FTAG 1 towards FP SPINE root for FTAG 1. SPINE switch doesn't have this interface in its multidestination tree and eventually drops the traffic by RPF. This can be confirmed by ELAM on SPINE and by PACL on both LEAFs.
M2RIB state:
5500-1# show sys internal m2rib ftag
========================================================================
Ftag|Topo| Flags | State |Pending: | Errors
| | | |inputs:events|
========================================================================
1| 0| MCAST|UCAST| M2RIB_FTAG_SEQ_END| 0: 0| 0
2| 0| MCAST|ACTIVE| M2RIB_FTAG_SEQ_END| 0: 0| 0
5500-2# show sys internal m2rib ftag
========================================================================
Ftag|Topo| Flags | State |Pending: | Errors
| | | |inputs:events|
========================================================================
1| 0| MCAST|ACTIVE|UCAST| M2RIB_FTAG_SEQ_END| 0: 0| 0
2| 0| MCAST| M2RIB_FTAG_SEQ_END| 0: 0| 0
According to isis database, there is following affinity:
FTAG 1 was assigned active for switch 2
FTAG 2 was assigned active for switch 1
If "show platform fwm info l2mp ftag" command is checked per ASIC there could be seen that both switches are active for correct FTAG-s for each ASIC. But, there could be seen that the affected interface which sends traffic with wrong FTAG was added as part of FTAG 1 and then immideately deleted. This won't be seen on non-affected interfaces.
5500-1# show platform fwm info l2mp ftag 1 hw
L2MP FTAG
--------------------------------------------------------------
ftag[0x97dcec4] id: 1 (0x1)
Topology ID: 0 (0x0)
Ftag flags: UCAST MCAST INACTIVE
Is stale: FALSE
Operation: Ftag intf add (3) Topo-ID: 0 (0x0) Ftag-flag: 0x17
Stale: FALSE Alternate: 0 Intf: 0x1a01a000 (Eth1/1)
at Mon Dec 7 09:40:28 2015
Operation: Ftag intf add (3) Topo-ID: 0 (0x0) Ftag-flag: 0x17
Stale: FALSE Alternate: 0 Intf: 0x1a01b000 (Eth1/2)
at Mon Dec 7 09:40:28 2015
Operation: Ftag intf delete (4) Topo-ID: 0 (0x0) Ftag-flag: 0x17
Stale: FALSE Alternate: 0 Intf: 0x1a01a000 (Eth1/1)
at Mon Dec 7 09:40:28 2015
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq60111 | Title: | Incorrect Type 1 vPC consistency for "vPC card type" in Enhanced vPC |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show vpc consistency-parameters interface port-channel
Name Type Local Value Peer Value
------------- ---- ---------------------- -----------------------
vPC card type 1 FEX Empty -> Peer1 output
vPC card type 1 Empty FEX -> Peer2 output
OR
vPC card type 1 Empty Empty -> Peer1 output
vPC card type 1 Empty Empty -> Peer2 output
Conditions:
While configuring enhanced vPC on Nexus 6000 for first time or when recent reload has performed on both peers. We may see "vPC card type" Value mismatch on vpc peers.
- Expected output is
Name Type Local Value Peer Value
------------- ---- ---------------------- -----------------------
vPC card type 1 FEX FEX -> Peer1 output
vPC card type 1 FEX FEX -> Peer2 output
Workaround:
- Shut on FEX up-link port-channels on both vPC peers FIRST and then no-shut on both sides.
Note:- Fex interfaces will go offline when uplinks are disabled on both vpc peers
Further Problem Description:
This behavior does not affect funcationality of FEX or Host connected to HIF interfaces.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(5) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.242), 7.1(3)ZN(0.313), 7.1(4)N1(0.777), 7.1(4)N1(1), 7.2(2)N1(0.407), 7.2(2)N1(1), 7.2(2)ZN(0.104), 7.3(1)N1(0.308), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut13914 | Title: | N6k: fwm hap reset |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Chassis may go down due to FWM process hap reset:
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At usecs after
Reason: Reset triggered due to HA policy of Reset
Service: fwm hap reset
Version: 7.0(5)N1(1)
Conditions:
Was observed after applying multiple-interface configuration (copy/paste). Still under investigation
Workaround:
N/A, since FWM hap reset causes one time reload.
Further Problem Description:
N/A
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.70), 7.0(7)N1(1), 7.0(7)ZN(0.150), 7.1(2)N1(0.562), 7.1(2)N1(1), 7.1(2)ZN(0.22), 7.1(3)ZN(0.313), 7.2(1)N1(0.242), 7.2(1)N1(1), 7.2(1)ZN(0.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw38972 | Title: | Fabricpath ECMP not working after ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Fabircpath ECMP not working
Conditions:
ISSU
Workaround:
change the fabricpath load-balance by "fabricpath load-balance unicast hash_polynomial CRC8c" -- with any Hash Polynomial, and save the config.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.276), 7.3(0.15) |
|
Known Fixed Releases: * | 7.1(3)N1(0.646), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.54), 7.2(1)N1(1), 7.2(1)ZN(0.89), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup74458 | Title: | few seconds of packet loss on vpc secondary link bringup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Few seconds of packet loss seen on VPC link bringup. Drops would correspond with PIF drop counter on fex uplink port
N6K-2(config-if)# show platform fwm info pif ethernet 1/7/1 | grep drop
Eth1/7/1 pd: tx stats: bytes 204948156412 frames 2328371667 discard 0 drop 0
Eth1/7/1 pd: rx stats: bytes 177822996614 frames 2388580485 discard 0 drop 1173850 <---HERE
Conditions:
VPC is being restored on a Nexus 5K/6K and traffic re-hashes to the newly brought up VPC. The delay is due to VLAN programming on the VPC trunk.
Workaround:
Reduce the number of VLANs on the VPC trunk by manually clearing not needed VLANs.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(3), 7.0(2)N1(1) |
|
Known Fixed Releases: * | 6.0(2)N2(5.95), 6.0(2)N2(6), 7.0(1)ZN(0.710), 7.0(6)N1(0.214), 7.0(6)N1(1), 7.1(0)EVN(0.18), 7.1(0)N1(0.356), 7.1(0)N1(1), 7.1(0)ZN(0.432), 7.1(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut42246 | Title: | ACL used for ERSPAN filter not removed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Access-list is configured and used for filter in ERSPAN source session whose status is up.
When trying to remove filter access-group and access-list, access-list is not removed from configuration.
Conditions:
Trying to remove access-list after attach it to filter for ERSPAN source session which is already up.
Workaround:
None. This problem still exists even after removing ERSPAN source session.
Access-list can be removed after reloading switch.
Further Problem Description:
Impact of this issue
Scenario 1: Filter is not required and the ACL needed to be removed .
- Entries (ACE) in the ACL will be removed but ACL will not be removed .
Scenario 2: Filter is needed but with a different set of ACEs .
- ACL can be modified to remove entries which are not required and add entries which are required. No impact in this scenario, provided same ACL name is used.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.124), 7.1(2)N1(0.544), 7.1(2)N1(1), 7.1(2)ZN(0.3), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.11), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup62266 | Title: | [Iplus] MCT flap -ETHPORT-5-IF_SEQ_ERROR while flapping MCT port-channel |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
VDC error messages seen
Conditions:
Flapping MCT port-channel interface
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.216) |
|
Known Fixed Releases: * | 7.1(0)ZN(0.346), 7.1(3)ZN(0.313), 7.2(0)VZN(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv95106 | Title: | After FEX ISSU interfaces error disabled due Dot1q-tunnel misconfig |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Ports configured with dot1q-tunnel will go to error disabled state with reason as dot1q-tunnel misconfiguration
Conditions:
The problem is seen when the port configured with dot1q-tunnel flaps after ISSU
Workaround:
shut/no-shut of the port
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.619), 7.1(3)N1(1), 7.1(3)ZN(0.25), 7.1(3)ZN(0.313), 7.2(1)N1(0.317), 7.2(1)N1(1), 7.2(1)ZN(0.79), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun98175 | Title: | N6K nfp process crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N6K crash on nfp process:
2014 Mar 25 14:46:36 cscsw035 %$ VDC-1 %$ SYSMGR-2-SERVICE_CRASHED Service "nfp" (PID 3732) hasn't caught signal 6 (core will be saved).
2014 Mar 25 14:46:36 cscsw035 %$ VDC-1 %$ SYSMGR-2-HAP_FAILURE_SUP_RESET System reset due to service "nfp" in vdc 1 has had a hap failure
Conditions:
the crash was seen after "ip flow monitor IPv4-monitor input sampler one-for-one"
configured on Eth1/1 - 4
Workaround:
- Reduce the sampling rate - preferably make it 1 in 65536
- Reduce the flow time out
- Keep the total number of netflow interfaces less - maybe equivalent of 10x40G ports (i.e. 40x10G/400x1G)
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(1)ZN(0.9), 7.0(2)N1(1), 7.0(3)N1(1) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.724), 7.0(6)N1(0.227), 7.0(6)N1(1), 7.1(0)N1(0.163), 7.1(0)N1(1), 7.1(0)ZN(0.277), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj88779 | Title: | SXP connection not established b/w n5k and n7k |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
iluka sxp default password not able to setup connection.
Conditions:
using default password for sxp connection with 5k
Workaround:
password none works fine
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N3(0.272) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.129), 7.1(0)N1(0.289), 7.1(0)N1(1), 7.1(0)ZN(0.382), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw83670 | Title: | N5k/6k - AFM Errors - unknown policy - Port error disabled |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
FEX host ports may be error disabled due to AFM process failing:
%AFM-3-AFM_VERIFY_FAIL: Access control policy modification on interface <> failed
%ETHPORT-3-IF_DOWN_ERROR_DISABLED: Interface <> is down (Error disabled. Reason:unknown policy)
Conditions:
Seen with QOS policy applied on FEX host interfaces. Exact cause is not yet known however could be related to link flapping of Network interfaces (NIF) for FEX's
Workaround:
none. Reload is required to get the port working again.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1), 7.1(2)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.674), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.86), 7.2(2)N1(0.354), 7.2(2)N1(1), 7.2(2)ZN(0.38) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux47933 | Title: | FEX2348 EVPC: HIF PO seconds of traffic drops after NIF failure |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Traffic drop for up to 10-20 seconds for dual-homed FEX host ports when FEX fabric interfaces to one N5k switch are disconnected or that N5k switch is reloaded
Conditions:
FEX 2348UPQ Active/Active with enhanced VPC (port-channels on FEX Host ports)
Workaround:
Configure standalone FEX host ports (remove the enhanced VPC port-channel)
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(3)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.157), 7.1(3)ZN(0.313), 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(1)N1(0.360), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo97783 | Title: | Nexus 6000: 3-4 Packet loss during power off LEM operation/switch reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
During LEM power off operation in a Nexus 6000/5600, 3-4 seconds re-convergence time can be seen
Conditions:
Seen during LEM power off operation or reload of the switch.
Workaround:
Shutdown the interfaces on the switch before powering off the LEM or reload.
Further Problem Description:
This problem is seen due to laser not cut on all interfaces at the same time.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(3.17), 7.1(3)N1(4), 7.1(3)ZN(0.258), 7.1(3)ZN(0.313), 7.1(4)N1(0.793), 7.1(4)N1(1), 7.2(2)N1(0.412), 7.2(2)N1(1), 7.2(2)ZN(0.119), 7.3(1)N1(0.308) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj22176 | Title: | traffic loss on vPC trunk with 1K vlans after the reload of vPC+ primary |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On a Nexus 5000 vPC+ pair, reloading the primary vPC switch causes up to 4-5 seconds of traffic loss during the vPC reconvergence.
Conditions:
Nexus 5000 vPC+ pair is part of a FabricPath domain with 1000 FabricPath vlans configured in the vlan database and 1000 vlans permitted on the vPC trunk allowed vlan list.
Workaround:
Reducing the number of allowed vlan list on the vPC trunk reduces the traffic loss time.
Further Problem Description:
Problem:
MCECM will reinit all vpc's on secondary after reload because the previous_comp_check is failure. This reinit is causing some traffic loss because the remote end may have already started to pump in the traffic when the port are up for the first time.
Fix:
Since MCECM will reinit all vpc's on secondary when they are brought up for the first time after reload, we should fail the first bringup in the bundle_member_bringup sequence before the port is tx & rx enabled if there is a reinit pending. This fix only works for LACP po
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1)N1(5), 6.0(2)N1(2a) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.705), 7.0(1)ZN(0.715), 7.0(1)ZN(0.719), 7.0(6)N1(0.210), 7.0(6)N1(0.218), 7.0(6)N1(0.221), 7.0(6)N1(1), 7.1(0)EVN(0.18), 7.1(0)N1(0.344), 7.1(0)N1(0.358) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut36623 | Title: | crash in fwm with signal 6 fwmpd_delete_int_vlan_to_vni_mapping () |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Crash is seen while pulling down vlans and adding new vlans.
Conditions:
Vinci has to be enabled and auto-config has to be disabled, using the commane "platform fabric dot1q disable" command.
Workaround:
NA
Further Problem Description:
NA
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.127) |
|
Known Fixed Releases: * | 7.1(2)N1(0.543), 7.1(2)N1(1), 7.1(2)ZN(0.2), 7.1(3)ZN(0.313), 7.2(0)N1(0.181), 7.2(0)N1(1), 7.2(0)ZN(0.183), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus22741 | Title: | DRAP process crash after FP domain restart |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Nexus 5000/6000 switch can have a process reset in DRAP process leading to switch reboot.
6001-T-A# show system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 385216 usecs after Wed Dec 17 20:47:57 2014
Reason: Reset triggered due to HA policy of Reset
Service: drap hap reset
Version: 7.1(0)N1(1)
2) At 978499 usecs after Wed Dec 17 20:33:57 2014
Reason: Reset triggered due to HA policy of Reset
Service: drap hap reset
Version: 7.1(0)N1(1)
3) At 846739 usecs after Wed Dec 17 20:19:07 2014
Reason: Reset triggered due to HA policy of Reset
Service: drap hap reset
Version: 7.1(0)N1(1)
4) At 896371 usecs after Wed Dec 17 19:51:14 2014
Reason: Disruptive upgrade
Service:
Version: 7.0(5)N1(1a)
Conditions:
The Nexus 5000/6000 is in Fabricpath and/or VPC+ topology. This is seen after fabric path domain is restarted using command restart fabric path domain
Workaround:
Do not issue the command restart fabric path domain
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.722), 7.0(6)N1(0.224), 7.0(6)N1(1), 7.1(1)N1(0.468), 7.1(1)N1(1), 7.1(1)ZN(0.20), 7.1(3)ZN(0.313), 7.2(0)AB(9), 7.2(0)N1(0.133), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup69347 | Title: | Traffic loss when bringing up pre-existing vPC member port |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When bringing up the ethernet link of a pre-existing vPC port-channel towards
the vPC primary device while the peer-link is down, traffic arriving on this
port will be dropped.
Conditions:
This issue occurs when the following sequence occurs for a vPC connected
device:
1) The link to the vPC primary is shutdown/unplugged.
2) The peer-link is shutdown/unplugged
3) The link to the vPC primary comes back up.
Workaround:
Unplugging and re-plugging the link tot he vPC primary clears the issue.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(2), 6.0(2)N2(3), 7.0(2)N1(1) |
|
Known Fixed Releases: * | 6.0(2)N2(5.82), 6.0(2)N2(6), 7.0(1)ZN(0.462), 7.1(0)FGI(0.6), 7.1(0)N1(0.257), 7.1(0)N1(1), 7.1(0)ZN(0.354), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy00525 | Title: | fwm hap reset @in fwm_port_vlan_xlate_handle_logical_portup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Fex going in offline/online sequence. Sometimes it crashes -fwm hap reset
Conditions:
Scaled vlan translation CLIs configured on tiburon based fex NIF port-channel.
Add/remove vlan translation commands
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.268) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.287), 7.1(3)ZN(0.313), 7.1(4)N1(0.821), 7.1(4)N1(1), 7.2(2)N1(0.434), 7.2(2)N1(1), 7.2(2)ZN(0.142), 7.3(1)N1(0.364), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv35326 | Title: | N6k :: ICMPv6 related to neighbor discovery punted to the CPU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In Nexus5K/6K ICMPv6 packets related to neighbor discovery are punted to the CPU even if there is no SVI configured in vlan where packets are present.
Conditions:
Nx-OS version 7.0(0)N1(1) and newer - still to be confirmed
Workaround:
If this is causing drops in copp-system-class-arp, ARP policer can be increased.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.659), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.67), 7.2(2)N1(0.389), 7.2(2)N1(1), 7.2(2)ZN(0.71) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq72020 | Title: | Forwarding ASIC Diag Error not forcing links to go down completely |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In Nexus 6000/5600, when ports go into hardware failure state, other side does not see a link down event.
Conditions:
Ports go into hardware failure state
Workaround:
Shut down interfaces on the other side.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.297), 7.1(3)ZN(0.299), 7.1(3)ZN(0.313), 7.1(4)N1(0.831), 7.1(4)N1(0.833), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu22403 | Title: | N5K/6K Cosmetic Message: Mac registration with L2FM failed for mac... |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a Nexus 5K/6K running NX-OS 7.0(6)N1(1), following messages can be seen
5596A# show logg logfile | inc L2FM
2015 May 6 13:04:55 5596A %ADJMGR-3-MAC_REG_FAILED: adjmgr [3568] Mac registration with L2FM failed for mac 0022.55e9.b53f, iod Vlan15, phy iod: Ethernet115/1/38
2015 May 6 13:07:21 5596A %ADJMGR-3-MAC_REG_FAILED: adjmgr [3568] Mac registration with L2FM failed for mac 0000.0c07.ac0f, iod Vlan15, phy iod: Vlan15
2015 May 6 13:10:04 5596A %ADJMGR-3-MAC_REG_FAILED: adjmgr [3568] Mac registration with L2FM failed for mac 002a.6a1f.2341, iod Vlan15, phy iod: Ethernet130/1/48
2015 May 6 13:11:43 5596A %ADJMGR-3-MAC_REG_FAILED: adjmgr [3568] Mac registration with L2FM failed for mac 547f.ee7e.1441, iod Vlan15, phy iod: Vlan15
5596A#
Conditions:
Seen when the switch sees ARP request packets.
Workaround:
These messages are cosmetic. To suppress them configure 'logging level adjmgr 2'.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.272), 7.1(0)N1(0.401), 7.2(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.291), 7.0(7)N1(1), 7.0(7)ZN(0.186), 7.1(3)N1(0.612), 7.1(3)N1(1), 7.1(3)ZN(0.17), 7.1(3)ZN(0.313), 7.2(2)N1(0.357), 7.2(2)N1(1), 7.2(2)ZN(0.41) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq72386 | Title: | N5k/6k: Static MAC entries deleted upon STP CBL update |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Statically configured RMACs on a vPC port-channel are not in the mac address table
Conditions:
vPC interface bounced and some VLANs are blocked on vPC port-channel by STP.
Workaround:
re-configure static MAC.
Example:
no mac address-table static 002A.xxxx.xxxx vlan 10 interface port-channel[PC_ID]
mac address-table static 002A.xxxx.xxxx vlan 10 interface port-channel[PC_ID]
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: * | 6.0(2)A5(1.37), 6.0(2)A5(2), 6.0(2)A6(1.105), 6.0(2)A6(2), 6.0(2)U5(1.37), 6.0(2)U5(2), 6.0(2)U6(0.105), 6.0(2)U6(1), 7.0(1)ZN(0.689), 7.0(6)N1(0.199) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup57924 | Title: | ip_xlate UIT vPC: clear fabric database host requires shut/noshut |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
None
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)ZN(0.328) |
|
Known Fixed Releases: * | 7.1(0)N1(0.1), 7.1(0)N1(0.234), 7.1(0)N1(1), 7.1(0)ZN(0.331), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut03537 | Title: | QinQ - Double-tag for native/untagged vlan traffic |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Untagged traffic received on dot1q-tunnel enable access port on FEX is getting tagged twice.
Conditions:
Access port on FEX is configured in dot1q-tunnel mode. This problem is not seen on dot1q-tunnel ports on parent N56K/6K
Workaround:
Use ports on parent switch or upgrade NX-OS to a fixed version.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1), 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.0(6)N1(0.267), 7.0(6)N1(1), 7.1(1)N1(0.497), 7.1(1)N1(1), 7.1(1)ZN(0.51), 7.1(3)ZN(0.313), 7.2(0)N1(0.162), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo99149 | Title: | NXOS Kernel Panic - Process fport_svr |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N5k/N6k may observe Kernel Panic running FC in process "fport_svr" (flogi)
Conditions:
Switches are running FC services and there are VFC flaps happening due to which kernel is always buzy
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(3), 6.0(2)N3(0.232), 7.0(1)N1(1) |
|
Known Fixed Releases: * | 6.0(2)N2(5.75), 6.0(2)N2(6), 7.0(1)ZN(0.464), 7.0(3)N1(0.125), 7.0(3)N1(1), 7.1(0)FGI(0.6), 7.1(0)N1(0.275), 7.1(0)N1(1), 7.1(0)ZN(0.372), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq54187 | Title: | VPC auto-recovery reverts to default delay value after switch reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When any of the N6k switches in the VPC pair gets reloaded in its running config after booting up the 'auto-recovery' delay timer appears as set to its default delay value of 240 secs.
Conditions:
Nexus 6k switches configured in VPC pair. 'auto-recovery reload-delay' configured with non -default delay value.
Workaround:
Manually re-configure delay value to the previously set non-default value after the switch reload.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.540), 7.0(4)N1(0.153), 7.0(4)N1(1), 7.1(0)N1(0.311), 7.1(0)N1(1), 7.1(0)ZN(0.397), 7.1(3)ZN(0.313), 7.3(0)N1(0.3), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux95740 | Title: | port-channel member interface with vpc orphan-port suspend configured |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"vpc orphan-port suspend" can be configured on port-channel member interfaces.
Conditions:
"vpc orphan-port suspend" is configured first on the physical interfaces (not yet bundled in a port-channel), then the interfaces are bundled in a port-channel without any error.
Workaround:
Don't configure "vpc orphan-port suspend" on the physical interfaces that will be bundled later in a port-channel as this is not supported at the moment and the configuration lines will be removed upon NX-OS upgrade.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(2)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.193), 7.1(3)ZN(0.227), 7.1(3)ZN(0.313), 7.1(4)N1(0.737), 7.1(4)N1(0.766), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq25291 | Title: | REOP on N6K: CSCtk37170: CDP IPv4 address is reported incorrectly |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In the show cdp neighbors detail command output the Interface address(es) field is populated incorrectly, and neighboring devices will see a different IP address from the one configured on the interface.
Conditions:
Impacts L3 port-channel interfaces.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.18), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo34512 | Title: | fwm hap reset with traffic running over the weekend |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Nexus 5000 or Nexus 6000 switch may unexpectedly reset with the following reset reason:
fwm hap reset
Conditions:
No specific conditions are known yet
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(5), 7.0(2)N1(0.166) |
|
Known Fixed Releases: * | 6.0(2)N2(6.128), 6.0(2)N2(7), 7.0(1)ZN(0.747), 7.0(6)N1(0.245), 7.0(6)N1(1), 7.1(1)N1(0.460), 7.1(1)N1(1), 7.1(1)ZN(0.13), 7.1(3)ZN(0.313), 7.2(0)AB(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq27905 | Title: | clear copp stats also clears qos statistics |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Current implementation of clear copp statistics on Nexus 5K/6K also issues clear qos statistics. This bug is filed to decouple the two.
Conditions:
Command clear copp statistics is issued.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(3)N1(0.1) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.521), 7.0(4)N1(0.144), 7.0(4)N1(1), 7.1(0)N1(0.1), 7.1(0)N1(0.290), 7.1(0)N1(1), 7.1(0)ZN(0.382), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy36538 | Title: | N6K: AA-FEX HIF Suspension on Parent Replacement with FEX Pre-Provision |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When a vPC peer is being replaced and there are dual-homed FEX modules, the FEX Host Interfaces (HIFs) will be suspended on the operational primary due to Type 1 Inconsistencies in the HIF configuration unless the FEX has been pre-provisioned. If the HIFs were suspended because FEX pre-provisioning was not in place, than subsequent attempts will see the same suspension even with FEX pre-provisioning configured.
Conditions:
Initial replacement attempt was made without FEX pre-provisioning resulting in a suspension.
Workaround:
Shut/no shut the affected ports once the FEX is up on both vPC peers and the configuration is consistent.
Further Problem Description:
Refer to enhancement CSCuy38910 for Graceful Consistency Check support on dual-homed FEX ports which would eliminate the FEX pre-provisioning requirement.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.272), 7.1(3)ZN(0.313), 7.1(4)N1(0.806), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut55084 | Title: | N5K/6K Need to make LACP suspend individual default for base ports |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Enhancement request to make LACP suspend individual default on base ports of N5K/6K
Conditions:
Workaround:
Manually configure LACP suspend individual on port-channel interfaces.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.1(3)ZN(0.313), 7.2(1)N1(0.252), 7.2(1)N1(1), 7.2(1)ZN(0.17), 7.3(0)N1(0.141), 7.3(0)N1(1), 7.3(0)ZN(0.129) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus89890 | Title: | Link state will not change after ISSU to 7.0 from 6.0(2) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After a non-disruptive ISSU upgrade from 6.0 to any 7.0(x)N1(1) release, the N6K will not recognize link state changes. If you remove/add an SFP, it will show as the previous state regardless.
Example:
-----------
Eth1/2 show link DOWN before ISSU. Add SFP/SFP+Active connection and 'no shut' still show as down
Conditions:
Seen in a Nexus 6000 switch which went through non-disruptive ISSU upgrade from 6.0 to any 7.0(x)N1(1) release or 7.1(1)N1(1) release.
Workaround:
-If already ISSU, following workarounds can be used
1)For 10G Interfaces, toggle speed to 1000 and then back to 10G using following command
Example;
configure terminal
interface ethernet 1/2
speed 1000
no speed 1000
2)For 40G interfaces, power off and power on the module in question
Example:
configure terminal
poweroff module 2
no poweroff module 2
3) port-channels. i.e. to a fex
1. Copy conf to without
channl-group command
2. Configure 'speed 1000'
3. Configure 'no speed'
4. Configure 'channel-group '
s in the example hereafter fex-fabic interface configuration would be
copied from Eth1/3 to Eth1/36 without 'channel-group 150 and then apply
steps 2-4 above.
interfhernet1/36
description fex 150
switchport mode fex-fabric
fex associate 150
lgging event port link-status
logging event port trunk-status
channel-goup 150
one could also try to simply copy the configuration and then change the speed
on the port-channel itself back and forth.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(5), 7.0(5)N1(1a), 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.67), 7.0(7)N1(1), 7.0(7)ZN(0.144), 7.1(2)N1(0.573), 7.1(2)N1(1), 7.1(2)ZN(0.34), 7.1(3)ZN(0.313), 7.2(1)N1(0.244), 7.2(1)N1(1), 7.2(1)ZN(0.10) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur11378 | Title: | fwm hap reset with %FWM-2-FWM_ASSERT_FAILURE |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On Nexus 5500 series, Service "fwm" hap reset with %FWM-2-FWM_ASSERT_FAILURE
Conditions:
FWM Crash happens when following sequence of events happen:
1. non-disruptive ISSU performed in VPC pair with all interfaces shut.
2. After ISSU, enable any of core interfaces.
3. Disable the core interface which was enabled in step[2]. Crash will be hit at [3].
Workaround:
Do not shut all interfaces before initiating ISSU.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.768), 7.0(6)N1(0.260), 7.0(6)N1(1), 7.1(0)N1(0.1), 7.1(0)N1(0.374), 7.1(0)N1(1), 7.1(0)ZN(0.448), 7.1(3)ZN(0.313), 7.2(0)N1(0.2), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux13186 | Title: | 2232TM/2332TQ link flap with certain Intel 10BaseT NICs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:2232TM/2332TQ link flap with certain Intel 10BaseT NICs
After the link flap the link might negotiate to 1Gbit
Conditions:
Workaround:Increase link debounce timer
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(2)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.682), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu14960 | Title: | Static MAC configuration only allows +-1000 characters |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Configuration of a static MAC address with a long list of interfaces is cut off after approx. 1000 characters.
Conditions:
This is seen when configuring a long command for a static MAC which lists a lot of interfaces.
Workaround:
There is no known workaround at this time.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.7), 7.1(1)N1(0.8) |
|
Known Fixed Releases: * | 7.1(3)N1(0.619), 7.1(3)N1(1), 7.1(3)ZN(0.26), 7.1(3)ZN(0.313), 7.3(0)ZN(0.68) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur13337 | Title: | N5K/6K: LLDP MIB not being responded to in NX-OS 7.0 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a Nexus 5500/5600/6000 series switches running NX-OS 7.0 releases, the switch does not respond to LLDP MIB.
Conditions:
Switch is being polled for LLDP MIBs
Workaround:
None. This issue is not seen in NX-OS 6.0(2)N2(x) release. If hardware/configuration are supported in 6.0(2)N2(x) release, it can be used as a workaround.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(0)EVN(0.18), 7.1(1)ZN(0.116), 7.1(2)N1(0.537), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(0)ZN(0.112), 7.2(0)ZN(0.35) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus16410 | Title: | Sometime N6K export as a TCP Src/Dst port is zero. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Sometime N6K export as a TCP Src/Dst port is zero.
Conditions:
- This issue is occurred In bridged netflow on VLAN.
- TCP flow is exported as TCP Src/Dst port is zero.
- UDP flow is exported correctly.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.718), 7.0(6)N1(0.220), 7.0(6)N1(1), 7.1(1)N1(0.509), 7.1(1)N1(1), 7.1(1)ZN(0.65), 7.1(3)ZN(0.313), 7.2(0)N1(0.180), 7.2(0)N1(1), 7.2(0)VZN(0.34) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup65417 | Title: | LLDP Port Description Value Incorrect |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LLDP packets sent by the N6K use "port id" in the description field. It is expected for the description field in the LLDP packets to match the description configured on the port the LLDP packets are sent out of
Conditions:
None
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: * | 7.1(0)N1(0.310), 7.1(0)N1(1), 7.1(0)ZN(0.396), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut55133 | Title: | N5672: cant't save config after configuring vlan mapping more than 200 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
when we configure vlan mapping more than 200 vlan , we can't save config . and error output .
Nexus5672 %SYSMGR-3-CFGWRITE_SRVFAILED: Service "vlan_mgr"failed to store its configuration (error-id 0x40480005).
Nexus5672 %SYSMGR-2-CFGWRITE_ABORTED: Configuration copy aborted.
Nexus5672 %SYSMGR-3-CFGWRITE_FAILED: Configuration copy failed (error-id 0x401E0000).
Conditions:
when configure vlan mapping more than 200.
Workaround:
once copy to flash and then copy runconfig to startconfig
copy run bootflash:running-config
copy bootflash:running-config startup-config
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.1(2)N1(0.556), 7.1(2)N1(1), 7.1(2)ZN(0.15), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.17), 7.2(1)N1(1), 7.3(0)N1(1), 8.3(0)CV(0.199), 8.3(0)KMS(0.20) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy81174 | Title: | N5K/6K: Abort install if running version of BIOS is empty |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If N5K/6K BIOS is corrupted and running version blank, install operation proceeds but fails to boot up after an upgrade.
esc-6004EF# install all kickstart bootflash:n6000-uk9-kickstart.7.1.3.N1.3.bin system bootflash:n6000-uk9.7.1.3.N1.3.bin
Images will be upgraded according to following table:
Module Image Running-Version New-Version Upg-Required
------ ---------------- ---------------------- ---------------------- ------------
0 system 7.1(1)N1(1) 7.1(3)N1(3) yes
0 kickstart 7.1(1)N1(1) 7.1(3)N1(3) yes
0 bios v2.9.0(12/10/2014) yes < 0 power-seq v5.0 v5.0 no
0 fabric-power-seq v3.0 v3.0 no
1 power-seq v2.0 v2.0 no
2 power-seq v4.4 v4.8 yes
2 century-fpga v16.0 v16.0 no
7 power-seq v2.0 v2.0 no
0 microcontroller v1.1.0.4 v1.1.0.4 no
Do you want to continue with the installation (y/n)? [n] n
esc-6004EF#
Conditions:
Usually seen when upgrading from 7.1(1)N1(1) where there is a bug CSCut86026 due to which /var/tmp is full.
Workaround:
Do not proceed with upgrades or reload on such systems which has BIOS corrupted. Contact Cisco TAC to manually update the BIOS.
Further Problem Description:
Running version of BIOS is corrupt. This can usually happen when system directory /var/tmp is full and install command is issued to a version which has newer BIOS. The install commands aborts with following error.
On success of micro-controller upgrade, SWITCH OFF THE POWER to the system and then, power it up.
[# ] 0% -- FAIL. Return code 0x4071001F (BIOS file size mismatch).
CAUTION: The BIOS/loader/bootrom of above module may be in corrupted state. Please try programming it again and DO NOT reboot without programming it successfully, otherwise you have to manually take out the flash from the card and program it in a BIOS programming station.
Install has failed. Return code 0x40930015 (Pre-upgrade of a module failed).
Please identify the cause of the failure, and try 'install all' again.
esc-6004EF#
But on subsequent install commands goes through and the system does not boot up due to corrupt BIOS
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1), 7.1(3)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.269), 7.1(3)ZN(0.313), 7.1(4)N1(0.803), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo58150 | Title: | N6k: QinQ capability not enabled after non-disruptive ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
QinQ configuration is not allowed on Nexus 6000 running 7.0 release (switchport mode dot1q-tunnel) although the feature was introduced in this release.
Conditions:
This is observed after a non-disruptive ISSU upgrade from 6.0(2) to 7.0 release. It is not triggered if the ISSU is disruptive.
Workaround:
Reload the switch after the upgrade to 7.0
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.1(3)ZN(0.313), 7.2(1)N1(0.262), 7.2(1)N1(1), 7.2(1)ZN(0.26), 7.3(0)BZN(0.41), 7.3(0)N1(0.66), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu69510 | Title: | N5K/N6K snmp 64 bit counters for svi interface dont work |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
User is unable to retrieve snmp 64 bit counters for a svi, interface vlan, on nexus 5000 and nexus 6000.
32 bit counters work fine, 64 bit counters are always reported as 0
Conditions:
snmp polling if-mib oid's for 64 bit counters for a svi interface.
The same oid works fine for a physical 10 gig/s ethernet interface.
Workaround:
use 32 bit counters.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.110), 7.1(2)N1(0.548), 7.1(2)N1(1), 7.1(2)ZN(0.7), 7.1(3)ZN(0.313), 7.2(1)N1(0.241), 7.2(1)N1(1), 7.2(1)ZN(0.7), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw25404 | Title: | IplusMr3 631: Fwm hap reset while doing ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Fwm hap reset while doing ND-issue
Conditions:
Veth interface in the config will create this crash while performing ISSU
Workaround:
No Workaround .
Further Problem Description:
For veth interface the lif_if can be zero . So while performing the ISSU during the restore of the dot1q tunnel mode for port we are accessing the content of lif_if. which created the crash. so we are validating the lif_if before accessing the lif_if content.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(3)N1(0.631) |
|
Known Fixed Releases: * | 7.1(3)N1(0.647), 7.1(3)N1(1), 7.1(3)ZN(0.313), 7.1(3)ZN(0.55) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul00229 | Title: | N6K - PIM Registers Misclassified as PIM Hellos by COPP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The default COPP policy on a Nexus 6K acting as a multicast RP will incorrectly
classify all incoming PIM register packets as PIM hello packets.
Conditions:
If a high rate of registers is received, PIM hellos will be dropped causing all PIM neighbors to be lost because The default COPP policy on a Nexus 6K acting as a multicast RP will incorrectly
classify all incoming PIM register packets as PIM hello packets
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(2) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.551), 7.1(2)N1(1), 7.1(2)ZN(0.10), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.3), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur36713 | Title: | "in-163" entry for SVI MAC missing in HW-STM table in FWM |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ARP replies (and possibly other traffic going to CPU) are not received by CPU on N6K, resulting in INCOMPLETE entries. SPAN/ELAM capture confirms the switch is receiving the ARP reply, but Ethanalyzer does not show it.
Conditions:
Normally there should be two entries, one called "in-0" and one called "in-163", pointing to the SUP ("sup-eth2") for the SVI MAC (same MAC for all SVIs) in the output of show platform fwm info hw-stm. When hitting this issue the "in-163" entry will be missing.
Normal situation:
---snip---
N6K# show platform fwm info hw-stm | inc sup
in-163 002a.6a22.1941 sup-eth2 1:12607:0 4:0:1 2.c.dd.0.0.2 (e:0)
in-0 002a.6a22.1941 sup-eth2 3:0:4092 0:0:1 2.c.dd.0.0.2 (e:0)
---snip---
Broken state as reported in this defect:
---snip---
N6K# show platform fwm info hw-stm | inc sup
in-0 002a.6a22.1941 sup-eth2 3:0:4092 0:0:1 2.c.dd.0.0.2 (e:0)
---snip---
Workaround:
A reload of the switch is required to fix this issue.
Until a reload can be done configuring a static ARP entry on the switch can serve as workaround.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(2), 7.0(3)N1(1), 7.0(4)N1(1), 7.0(5)N1(1), 7.0(5)N1(1a) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.126), 7.1(3)ZN(0.305), 7.1(3)ZN(0.313), 7.1(4)N1(0.837), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus28695 | Title: | WCCP - ACL Remark breaks TCAM redirection entry |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
WCCP redirects all traffic instead of redirecting specified traffic via ACL. Observed with Nexus 5600/6000 switches.
Conditions:
ACL using Remark entry.
Workaround:
Do not use ACL remark. TCAM redirection happens normally.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(4)N1(0.168) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(2)N1(0.543), 7.1(2)N1(1), 7.1(2)ZN(0.2), 7.1(3)ZN(0.313), 7.2(0)N1(1), 7.2(1)N1(0.16), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut53085 | Title: | mmap error for port-channel services |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show port-channel internal event-history all
mmap: Cannot allocate memory
show port-channel internal event-history errors
mmap: Cannot allocate memory
nexus# show tech-support details >bootflash:techfile1
mmap: Cannot allocate memory
#tac-pac bootflash:///showtech
mmap: Cannot allocate memory
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: * | 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.1(3)ZN(0.313), 7.2(1)N1(0.240), 7.2(1)N1(1), 7.2(1)ZN(0.6), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut42878 | Title: | Ethpm Hap Reset on Nexus 6k/5k |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ethpm hap reset
Conditions:
Usually occurs after VLAN config changes
Workaround:
Unknown
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(1)ZN(0.120), 7.1(2)N1(0.541), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)AB(9), 7.2(0)N1(0.155), 7.2(0)N1(1), 7.2(0)ZN(0.158) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur71049 | Title: | STM thrshold not updated correctly - show platform fwm info stm-stats |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
STM thrshold counter is not updated correctly in the output of "show platform fwm info stm-stats"
Conditions:
None
Workaround:
A switch reloaded reflects the outputs correctly.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: * | 7.1(2)N1(0.544), 7.1(2)N1(1), 7.1(2)ZN(0.3), 7.1(3)ZN(0.313), 7.2(0)N1(0.60), 7.2(0)N1(1), 7.2(0)ZN(0.112), 7.2(0)ZN(0.82), 7.3(0)N1(0.3), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo68435 | Title: | On N6k programming of updated Fabricpath FWD entries to hardware delayed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On N6k devices when Fabricpath topology is updated, programming of the updated forwarding entries to hardware is being delayed by 30-60 seconds. As a result some traffic flows might experience drops during that time. The issue recovers by itself after the period of 30-60 seconds.
Executing "show platform info pif all | inc drop", "clear mac address-table dynamic" or "show running-config" commands during the issue on the N6k device with staled Fabricpath forwarding entries in hardware recovers the setup from the issue immediately.
Conditions:
The issue might be seen on N6k Fabricpath spine devices on Fabricpath topology change event. This is seen in case there is N5k VPC+ setup connected to the N6k Fabricpath setup, and the VPC peer-link on the N5k VPC+ setup becomes disabled. The traffic which was previously sent by N6k FP switch towards N5k Secondary VPC+ switch should be shifted to the N5k Primary VPC+ switch, but this transition is delayed by 30-60 seconds.
The problem is seen when there are active VPC orphan ports on the N5k Secondary VPC+ switch. If the orphan port is manually disabled by "shutdown" command, or "vpc orphan-port suspend" command is used - the issue disappears.
Workaround:
Avoid having VPC orphan ports on the VPC+ setup.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(3), 7.0(1)N1(1), 7.1(0)N1(0.197) |
|
Known Fixed Releases: * | 7.0(1)ZN(0.572), 7.0(4)N1(0.162), 7.1(0)N1(0.1), 7.1(0)N1(0.322), 7.1(0)N1(1), 7.1(0)ZN(0.406), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut52535 | Title: | vlan mapping under vPC port cause link up delay |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When vlan translation is configured under vPC port , vPC port link up delay from physical interface link up.
The delay depends on number of vlan mapping upder the vPC port.
Conditions:
Nexus5672
NXOS:7.1(0)N1(1b)
Workaround:
decrease number of vlan mapping upder vPC port.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.213), 7.1(3)ZN(0.313), 7.1(4)N1(0.755), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva16260 | Title: | NXAPI : Show file <> md5sum | json not working |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Show file md5sum | json does not return proper output
Conditions:
CLI Run
Workaround:
None
Further Problem Description:
Please see description
|
|
Last Modified: | 21-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux51705 | Title: | interface counters stucked in 0 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
RX and TX interface bytes counters are stucked in 0.
Ethernet1/1 is up
RX
49741910854 unicast packets 560907 multicast packets 1682 broadcast packets
49742473435 input packets 0 bytes <<<<<<<<<
TX
58849010426 unicast packets 1027488 multicast packets 3991633 broadcast packets
58854029539 output packets 0 bytes <<<<<<<<<
Conditions:
After manual interface flap counters of interface being abnormally high and not increasing anymore:
SWITCH# sh int e1/1 counters detailed
Ethernet1/1
Rx Packets: 18446744003658477104 <<<<
Rx Bytes: 18446688262119259735 <<<<
Tx Bytes: 18446661760268377751 <<<<
SWITCH# sh int Eth 1/1 | i bytes
18446744003658477104 input packets 18446688262119259735 bytes
1967789870 jumbo packets 0 storm suppression bytes
5997769666 output packets 18446661760268377751 bytes
SNMP counters also affected and are not incrementing once counters have reached 2^64 (=1,844x10^19)
[15:23 > snmpwalk
.1.3.6.1.2.1.2.2.1.10.436666368 = Counter32: 4294967295
.1.3.6.1.2.1.2.2.1.16.436666368 = Counter32: 4294967295
After 5 min :
[15:29 > snmpwalk
.1.3.6.1.2.1.2.2.1.10.436666368 = Counter32: 4294967295
.1.3.6.1.2.1.2.2.1.16.436666368 = Counter32: 4294967295
Later, clear counters issued for the interfaces. Counters reseted the values but they are now stucked to 0 despite all the traffic flowing through the interface.
Workaround:
N\A
Further Problem Description:
|
|
Last Modified: | 23-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.434), 7.1(0)N1(1), 7.1(2)N1(1) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.274), 7.0(8)N1(0.332), 7.0(8)N1(1), 7.1(3)N1(4), 7.1(3)ZN(0.165), 7.1(3)ZN(0.313), 7.1(4)N1(0.719), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux49563 | Title: | msg format correction in fwm |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
msg format correction in fwm component.
Conditions:
Some syslog msgs format strings were not properly converted
Workaround:
none.
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.218) |
|
Known Fixed Releases: * | 7.3(0)N1(0.236), 7.3(0)N1(1), 7.3(0)ZN(0.213), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux62958 | Title: | FC -FEX conversion of fex ports to fc, fabric mode to 40G or add syslog |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Observe traffic issues when fabric mode is kept at default and fex ports are running at 16G.
Conditions:
In case of fc-fex connected to legacy platforms and on conversion of fex ports to fc.
Workaround:
None
Further Problem Description:
Fabric-mode of 10G is not sufficient in case of fc-fex connected to legacy platforms and on conversion of fex ports to FC.
We'll print a warning message when the ports of FEX are converted to FC.
Sample Output:
switch# show fabric-mode
Fabric Mode: 10G
switch(config)# fex 100
switch(config-fex)# port 1-24 type fc
Warning: Change fabric-mode to 40G and reload switch as well as FEX to make port type change effective. Commands:
fabric-mode 40g
copy running-config startup-config
reload all
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.245) |
|
Known Fixed Releases: * | 7.3(0)IZN(0.13), 7.3(0)N1(0.248), 7.3(0)N1(1), 7.3(0)ZN(0.224), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw83023 | Title: | %STP-2-VLAN_PORT_LIMIT_EXCEEDED on ISSU even when spanning-tree disabled |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When upgrading software by In-Service Software Upgrade(ISSU), following error messages are shown,
although vlan-port instances are not exceeded before upgrade since spanning-tree for all vlans are disabled.
xxxx indicates current vlan-port, yyyy indicates system limit number.
%STP-2-VLAN_PORT_LIMIT_EXCEEDED: The number of vlan-port instances (xxxx) exceeded [Rapid-PVST mode] recommended limit of yyyy
Conditions:
Nexus 5672 series running with 7.0(5)N1(1) and vPC is configured.
Configuring trunk ports and total of allowed vlan exceeds the limit, and all spanning-tree for these vlans are disabled.
Upgrading software from 7.0(5)N1(1) to 7.1(1)N1(1) by ISSU.
Also observed upgrading software from 7.1(1)N1(1) to 7.2(1)N1(1) by ISSU.
Workaround:
Upgrading software by disruptive upgrade.
Further Problem Description:
This issue is under investigation.
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.276), 7.0(8)N1(1), 7.1(3)ZN(0.313), 7.1(4)N1(0.718), 7.1(4)N1(1), 7.2(2)N1(0.361), 7.2(2)N1(1), 7.2(2)ZN(0.45), 7.3(0)IZN(0.13), 7.3(0)N1(0.195) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw92582 | Title: | Add syslog to notify L3 interface with sub-interface limit exhausted |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
User is allowed to configure more than 59 (N55xx) and 1019 (N56xx) L3 interfaces with at least 1 sub-interface.
Traffic to/from L3 sub-interface may be dropped or not work as expected since this exceeds the limit the switch can handle.
Symptoms might include all traffic/ping to or from a sub-interface may be dropped 100%.
Conditions:
Switch has over 59 (N55xx) and 1019 (N56xx) L3 interfaces with at least one subinterface
L3 interface without sub-interface is not included into this limit
Workaround:
Use 59 (N55xx)/1019 (N56xx) or less L3 interfaces with sub-interface.. This is a limitation. The bug is filed to notify the user when the limit for L3 interface with sub interface is reached.
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.319), 7.1(4)N1(0.852), 7.1(4)N1(1), 7.3(1)N1(0.383), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz94239 | Title: | %VPC-6-LOG_LIBSVI_SVI_MCEC_TYPE2_FAILED should be warning or error level |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Not seeing the following syslog message when there is a configuration mismatch regarding SVIs between vPC peers:
---snip---
%VPC-6-LOG_LIBSVI_SVI_MCEC_TYPE2_FAILED: interface-Vlan Type 2 configuration for VPC is not compatible
---snip---
Conditions:
Running NX-OS with default logging levels enabled.
Workaround:
Increase logging levels for "vpc" feature and the desired logging destination, e.g.:
---snip---
conf t
logging level vpc 6
logging logfile messages 6
end
---snip---
Then when the message is seen the following command can be used to see for which SVI(s) NX-OS detected a Type 2 inconsistency:
---snip---
show vpc consistency-parameters global | inc vlan|Value
---snip---
Further Problem Description:
As there can be severe impact by this kind of mis-configuration (including packet loss across the setup) level 6 ("notification") is not appropriate for this type of error, but should be level 3 ("error") or at least level 4 ("warning").
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(8)N1(1), 7.3(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.305), 7.1(3)ZN(0.313), 7.1(4)N1(0.837), 7.1(4)N1(1), 7.2(2)N1(0.445), 7.2(2)N1(1), 7.2(2)ZN(0.153), 7.3(1)N1(0.372), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq88206 | Title: | Increase FCF MAC Allocation for Nexus 6004 Platform to 48 |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Currently the FCF MAC allocation for port-channel on the Nexus 6004 is limited to 16. resulting in an FCoE port-channel not coming up.
Conditions:
AT&T reached this 16 limit resulting in an FCoE port-channel not coming up
Workaround:
No
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: * | 7.1(0)EVN(0.18), 7.1(0)N1(0.357), 7.1(0)N1(1), 7.1(0)ZN(0.433), 7.1(1)N1(1), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.1(3)ZN(0.313), 7.2(0)N1(0.2), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut87698 | Title: | Nexus: Option 82 circuit-id same for all host when using relay |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When a nexus switch acts as a relay agent, configured to insert option-82, the circuit-id is same for all host even when they are connected to different ports.
This behavior is different when using dhcp snooping. VLAN, module and port information is added in this case
Conditions:
Nexus switch acting as a relay agent, configured to insert option-82
Workaround:
Further Problem Description:
This bug is filed as an enhancement request
"ip dhcp relay sub-option circuit-id customized " will be available to make the behavior identical when using dhcp snooping and dhcp relay to insert option-82
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.0(3)I3(0.239), 7.0(3)I3(1), 7.3(0)BZN(0.47), 7.3(0)N1(0.105), 7.3(0)N1(1), 7.3(0)ZN(0.98), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo91856 | Title: | Single source commits to N6K for SNMP compilation issues |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
N6K compilation was failing.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)ZN(0.269) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.179), 7.1(0)D1(0.180), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)N1(0.226), 7.1(0)N1(0.227), 7.1(0)N1(0.228), 7.1(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy28938 | Title: | One Server sending continous RX pause can cause Buffer lock |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
RX Pause being sent from server causing buffer stuck condition for control-plane packets
Conditions:
RX Pause Floods
Workaround:
Disable flow control
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.1), 7.0(6)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.291), 7.1(3)ZN(0.313), 7.1(3)ZN(0.324), 7.1(4)N1(0.825), 7.1(4)N1(0.857), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu67165 | Title: | pss runtime oifl not showing correct info |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
pss runtime oifl not showing correct info vi command "show platform fwm info pss runtime_oifl".
Conditions:
while running show command.
Workaround:
none.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0) |
|
Known Fixed Releases: * | 7.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.1(3)ZN(0.313), 7.2(2)N1(0.388), 7.2(2)N1(1), 7.2(2)ZN(0.70), 7.3(0)N1(1), 7.3(0)ZN(0.79) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv39838 | Title: | CLI to dump all SGs in a system |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
None. This is an enhancement to introduce new CLI.
Conditions:
while running commands. show-tech.
Workaround:
none.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0) |
|
Known Fixed Releases: * | 7.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.1(3)ZN(0.313), 7.2(2)N1(0.390), 7.2(2)N1(1), 7.2(2)ZN(0.72), 7.3(0)N1(0.75), 7.3(0)N1(1), 7.3(0)ZN(0.73) |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论