| |
|
Alert Type: | New |
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: | 03-NOV-2015 |
|
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.3(0)N1(0.80), 7.3(0)N1(1), 7.3(0)ZN(0.78) |
|
|
| |
| |
|
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: | 20-NOV-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | 7.1(3)N1(0.674), 7.1(3)N1(1), 7.1(3)ZN(0.86), 7.2(2)ZN(0.12), 7.3(0)IZN(0.7), 7.3(0)N1(0.160), 7.3(0)N1(1), 7.3(0)ZN(0.148) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw95767 | Title: | KK144:FWM Crashed while executing "show tech-support fwm" in scale setup |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:Fwm crash while Executing "show tech-support fwm" in the scale test bed
Conditions:
scale test bed with portchannels having more than 3k vlan configured.
Workaround:
No workaround
More Info:Buffer overrun happens while trying to print the lif/pif of the switch in the "show plaform fwm info lif all verbose" which is part of "show tech-support fwm"
the buffer allocation is hardcoded to 48512bytes in the code. and we are crossing that allocation and creating buffer overrun situation . while freeing the buffer back the mem track tool captures this and asserts the fwm process.
|
|
Last Modified: | 21-NOV-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.204), 7.3(0)ZN(0.144) |
|
Known Fixed Releases: * | 7.3(0)N1(0.215), 7.3(0)N1(1), 7.3(0)ZN(0.192) |
|
|
| |
| |
|
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: | 20-NOV-2015 |
|
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.3(0)N1(0.80), 7.3(0)N1(1), 7.3(0)ZN(0.78) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv87644 | Title: | N2348TQ - 10G Auto-negotiation issues |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Servers may fail to auto-negotiate at 10G link speed and fall back to 1Gbps for N2348TQ HIF's. Results may differ with every shut/no shut or reload. Same server may next time negotiate to 10G in next attempt.
Conditions:
N2348TQ with speed set to auto negotiate. So far noticed with Servers x10sdv-tln4f however may not be limited to. Further analysis ongoing.
Workaround:
Moving servers to 2232T FEX's doesn't see this problem.
Hardcode speed to 10G may be one option.
Further Problem Description:
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 7.1(2)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.676), 7.1(3)N1(1), 7.1(3)ZN(0.88) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut49092 | Title: | [comm:ethpm] WARNING: possible memory leak is detected on pers queue |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Switch will be throwing continuous errors about ethpm leak as
"2015 Mar 20 23:45:06 SPINE11 %$ VDC-1 %$ Mar 20 23:45:06 %KERN-2-SYSTEM_MSG: [29216.124753] [sap 175][pid 3942][comm:ethpm] WARNING: possible memory leak is detected on pers queue (len=3122,bytes=32760206) - kernel"
Conditions:
Issue is seen after a write erase, reload,copy bootflash:config to running config.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-NOV-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.258) |
|
Known Fixed Releases: * | 7.3(0)N1(0.208), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux12166 | Title: | Nexus5600/6000: isis_fabricpath hap reset on Spine |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
Spine(Nexus 5696) crashed and cored.
Spine-4# sh system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 572380 usecs after Wed Nov 11 17:16:59 2015
Reason: Reset triggered due to HA policy of Reset
Service: __inst_001__isis_fabricpath hap reset
Version: 7.1(3)N1(1)
Conditions:
Upon upgrading interface from 10G to 40 G, the Spine(Nexus 5696) crashed and cored.
Workaround:
none. System rebooted
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 7.1(3)N1(0.677) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur26244 | Title: | Nexus 6000/5600 packet drops with no drop traffic |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Slow FC or FCOE Performance with Nexus N6004, N5696Q, or N56128P.
Selective Retransmission Request (SRR) may be logged on host or storage.
Drops on the egress on a Nexus 5600/6000, for a no-drop class of traffic.
Note: TAC will confirm packet loss
Conditions:
Running 10g OR 40g fabric mode AND using Nexus N6004, N5696Q, or N56128P platform.
This is seen with 10G fabric mode when traffic flow is high for a single class of traffic, and multiple ingress ports send data to the same egress port
Workaround:
Contact TAC for a workaround.
Since it is a register change, recommend only experienced folks do these register changes.
Further Problem Description:
Issue is not seen with Nexus 5000/5500. After upgrading to fixed release a reload is required to fully resolve this issue.
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.272), 7.1(0)N1(0.368) |
|
Known Fixed Releases: | 7.0(6)N1(0.276), 7.0(7)N1(1), 7.0(7)ZN(0.113), 7.0(7)ZN(0.156), 7.1(0)N1(0.388), 7.1(0)N1(1), 7.1(0)ZN(0.462), 7.2(0)N1(1), 7.2(0)ZN(0.91) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw83505 | Title: | kk-150 : fwm hap reset while bringup the 2248PQ fex |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:FWM crash during FEX bringup on N6K switches
Conditions:FWM crashed during fabric port channel bringup on N6K Switches, which is not consistently reproducible.
Workaround:No Workaround, switch recovers properly after crash.
More Info:Issue in fwmpd_rsrc_program_MIDXT API for reserved multicast index, issue fixed in kokomo, fix need to checked in other branches as well.
|
|
Last Modified: | 30-NOV-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.150) |
|
Known Fixed Releases: | 7.3(0)N1(0.224), 7.3(0)N1(1) |
|
|
| |
| |
|
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: | 20-NOV-2015 |
|
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.3(0)ZN(0.68) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu79246 | Title: | FWM ISSU:MTS BUFFER Leaks seen after ND ISSU from IPMR1->JJ226 in5548P |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
MTS buffer leaks observed after doing ND-ISSU
FWM ISSU ST SCAN recepient SAP(
Conditions: ND-ISSU from IPMR1->JJ226
Workaround:No workaround
More Info:after ISSU, during the restore of the PSS. we found the leaks are observed in fwmpd_restore_mac_table_from_hw while doing fwmpd_recv_issu_scan_addresses.
The MTS receive call will move the buffers from receive_Q to persistance_Q or non-persistance_Q based on the options. here the buffer is moved to the non-persistance_Q.
after processing the MTS message payload we need to call mts_drop api to free the buffers. Then only the buffer will move out of non-persistance_Q. but in our case we are not calling the
Mts drop api. This make the buffers to stay in the non-peristance_Q and not released back. after doing the mts drop the buffers are released back to the non-persistance_Q.
This leak will be observed only in ND-ISSU scenarios. the mts messaged are sent from carmel_usd (in case of n5k) and bigsur_usd
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.226) |
|
Known Fixed Releases: | 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.3(0)N1(0.99), 7.3(0)N1(1), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv91507 | Title: | Migrating Fex from N7K to N6K/N5K may result in the FEX failing to boot |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
A FEX which is attached to an N7K running 6.2(12) or 7.2(0)D1(1) may fail to boot when moved to a Nexus 6K or Nexus 5K:
08/21/2015 00:51:59.593386: Module register received
08/21/2015 00:51:59.594388: Image Version Mismatch
08/21/2015 00:51:59.595438: Registration response sent
08/21/2015 00:51:59.595794: Requesting satellite to download image
08/21/2015 00:53:52.981356: Image preload failed.
08/21/2015 00:54:00.132452: Deleting route to FEX
08/21/2015 00:54:00.141675: Module disconnected
08/21/2015 00:54:00.143718: Module Offline
08/21/2015 00:54:00.152157: Deleting route to FEX
08/21/2015 00:54:00.159062: Module disconnected
08/21/2015 00:54:00.161167: Offlining Module
Conditions:
Issue has been observed on 2248TP-E FEX conencted to F3 line card on N7K.
Workaround:
On 5K/6K running 7.2, the issue can be corrected by unplugging and plugging the cable back in at the FEX uplink.
Further Problem Description:
Migrating Fex from N7K to N6K/N5K may result in the FEX failing to boot
|
|
Last Modified: | 17-NOV-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)N1(0.208), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj45220 | Title: | T2: Maximum mac address limit hit at 131,072 mac addresses |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
N3132 is only able to hold 131,072 mac addresses while the documentation states it can hold 288,000 mac addresses.
Conditions:
N3132 is only able to hold 131,072 mac addresses while the documentation states it can hold 288,000 mac addresses.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 03-NOV-2015 |
|
Known Affected Releases: | 6.0(2)ZK(99.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux19472 | Title: | POAP script fails for 7.0.6.N1.1 |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
If box boots from the version 7.0.6.N1.1
The box starts the poap mode, starts and finishs the dhcp phase OK, downloads the poap script OK, starts the script execution and finishs the script quickly WITH SUCCESS, but it doesn't install the images and configurations.
We need to update the right POAP script in the CCO as well
Conditions:
script that starts with #!/usr/bin/expect -f
Workaround:
none
Further Problem Description:
Python script was fixed using the defect#CSCuu95173
New script will be posted in the CCO.
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux03956 | Title: | ARP Reply for VIP is dropped in hardware on egress path |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
ARP requests that come into the HSRP VIP via private-vlans, and get forwarded over the vPC peer-link end up getting dropped in the 6K platform instead of being sent out.
The ARP reply for the HSRP VIP can be seen being generated by the CPU, but does not egress the box.
Conditions:
This problem has only been seen in vPC+ topologies that have ARP requests coming in via a CE vPC port-channel that is trunking private VLANs.
Workaround:
Move the HSRP Active switch to the FTAG1 root. To check if the switch is active for FTAG 1 use the following command:
Nexus# show platform fwm info l2mp ftag 1 | inc flags
Ftag flags: UCAST MCAST ACTIVE
If the switch shows "INACTIVE" ensure it is HSRP Standby for all PVLANs.
Further Problem Description:
The ARP Request comes in via isolated VLAN for the HSRP VIP on a vPC. The ARP Request is forwarded via FP to the HSRP Active. The active sends the ARP Reply, there is a lookup miss, and the reply is then flooded but it is flooded in hardware in the wrong FTAG.
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 7.0(3)N1(1), 7.0(7)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut49415 | Title: | Logging Levels are lost after first reload post Non-Disruptive ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
User modified logging levels will be lost after reload (manual or otherwise) post a successful ND-ISSU.
Conditions:
Reload the switch after a successful ND ISSU.
Workaround:
Issuing "copy r s" manually after successful ND-ISSU and before reload will make sure the user modified logging levels are retained post reload.
Further Problem Description:
This is happening as during the ND-ISSU process the logging levels are set to default and restored back at the end. After restoring, the logging levels are part of running config and still not copied to the start-up config.
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.631), 7.1(3)N1(1), 7.1(3)ZN(0.38), 7.2(2)N1(1), 7.3(0)N1(0.118), 7.3(0)N1(1), 7.3(0)ZN(0.109) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug84860 | Title: | N6K/N56K sends wrong FCF-MAC causing N4K server adapter ports to go down |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
For any configured vFC interfaces using "bind mac-address" the N6K/N56K uses the interface FCF for FIP negotiation and for FLOGI.
When the CNA sends a PLOGI to the name server, the N6K/N56k sends PLOGI_ACC using the VSAN global FCF MAC address as a source which breaks the FCoE virtual link.
As a result the CNA ignores this reply since it is not coming from the correct virtual link mac address and the FC4 feature type is missing in the FCNS database.
Conditions:
All conditions below must be met to hit the bug.
- This can apply to the following platforms: N600X, N56XX
- NX-OS 7.x
- vFC is configured to bind by MAC address
Workaround:
Bind the vFC by the interface instead of the MAC address.
Further Problem Description:
The CNA does not register its name server information:
Switch# show fcns database
VSAN 60:
--------------------------------------------------------------------------
FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE
--------------------------------------------------------------------------
0x8d0000 N 10:00:00:00:a5:50:f3:55 scsi-fcp:target
0xcd0000 N 10:00:00:00:a5:50:f3:58 << missing fc4 data type
Total number of entries = 2
VSAN 61:
--------------------------------------------------------------------------
FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE
--------------------------------------------------------------------------
0x590000 N 10:00:00:00:13:13:00:00 scsi-fcp:target
0x590020 N 10:00:00:00:13:13:00:01 scsi-fcp:target
0x590100 N 10:00:00:00:13:13:00:07 scsi-fcp:target
0x590120 N 10:00:00:00:13:13:00:08 scsi-fcp:target
0x590140 N 10:00:00:00:13:13:00:09 scsi-fcp:target
0xed0000 N 10:00:00:61:16:16:00:00 << missing fc4 data type
0xed0020 N 10:00:00:61:16:16:00:01 scsi-fcp:target
0xed0040 N 10:00:00:61:16:16:00:02 scsi-fcp:target
0xed0060 N 10:00:00:61:16:16:00:03 scsi-fcp:target
|
|
Last Modified: | 21-NOV-2015 |
|
Known Affected Releases: | 7.0(5)N1(1), 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.3(0)N1(0.215), 7.3(0)N1(1), 7.3(0)ZN(0.192) |
|
|
| |
:
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论