| |
|
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: | 28-JAN-2016 |
|
Known Affected Releases: | 7.1(3)N1(1.5) |
|
Known Fixed Releases: * | 7.1(3)N1(1.6), 7.1(3)N1(2), 7.3(0)N1(0.272), 7.3(0)N1(1), 7.3(0)ZN(0.249) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux40515 | Title: | fwm core seen in VINCI N6K |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:Switch got reload due to FWM process crash
Conditions:In VINCI N6K setup, the fwm process crash was seen after issuing trigger triggerDisableEnableFabricpathWithTftp
Workaround:
NA
More Info:
|
|
Last Modified: | 04-JAN-2016 |
|
Known Affected Releases: | 7.1(3)ZN(0.116) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 21-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.208) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.163), 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: | CSCuw93085 | Title: | After shutting down an i/f , it takes long time to get to shut state |
|
Status: | Open |
|
Severity: * | 2 Severe |
Description: | Symptom:The reason is the port-channel is in adminCfgChange state for that much time.
Conditions:In vPC setup scale setup, It is seen that on shutdown of port-channel interface, there is a traffic drop for around 8-10 seconds. After it is completely down , the routes are removed from the adjacent routers... after which the traffic converges.
Workaround:None
|
|
Last Modified: | 31-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.177) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur37987 | Title: | nx-os crash in "show system internal im info module "non existing slot " |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Reason: Reset triggered due to HA policy of Reset
Service: ifmgr hap reset
Conditions:
Executing the command "sh system internal im event-history module" or "show system internal im info module x"
Workaround:
do not use "show system internal im info module x" with any non existing, non initialized module number
Further Problem Description:
none
|
|
Last Modified: | 31-JAN-2016 |
|
Known Affected Releases: | 7.0(4)N1(1), 7.1(3)N1(0.647) |
|
Known Fixed Releases: * | 7.0(3)I3(0.292), 7.0(3)I3(1), 7.1(3)ZN(0.138), 7.1(4)N1(0.703), 7.1(4)N1(1), 7.2(2)N1(0.357), 7.2(2)N1(1), 7.2(2)ZN(0.41), 7.3(0)IZN(0.13), 7.3(0)N1(0.201) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux32552 | Title: * | N5K/6K ascii-cfg hap reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Switch reloads due to crash of process ascii-cfg.
Conditions:
When a checkpoint of the configuration is taken, under rare conditions, this issue can happen.
Workaround:
Further Problem Description:
|
|
Last Modified: | 31-JAN-2016 |
|
Known Affected Releases: * | 7.0(7)N1(1), 7.3(0)N1(0.208) |
|
Known Fixed Releases: | 7.1(3)ZN(0.156), 7.1(4)N1(0.711), 7.1(4)N1(1), 7.2(2)N1(0.367), 7.2(2)N1(1), 7.2(2)ZN(0.50), 7.3(1)N1(0.12), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut60043 | Title: | N5K/6K - 40G transceivers have delay for link-up on module boot/reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On Nexus 6004 chassis or module reload 40g interfaces can take up to 50 minutes to come online and forward traffic.
Conditions:
Reloading a chassis or LEM module that contains at least one 40g transceiver in a 6004 chassis
Workaround:
None. The interfaces do come up after a while
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.0(2)N1(1), 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.175), 7.1(4)N1(0.725), 7.1(4)N1(1), 7.3(0)BZN(0.47), 7.3(0)N1(0.102), 7.3(0)N1(1), 7.3(0)ZN(0.95) |
|
|
| |
| |
|
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: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.216) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.110), 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), 7.3(0)ZN(0.197) |
|
|
| |
| |
|
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: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.158) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.163), 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), 7.3(0)ZN(0.214) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw95767 | Title: | KK144:FWM Crashed while executing "show tech-support fwm" in scale setup |
|
Status: | Fixed |
|
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
Further Problem Description:
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: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.204), 7.3(0)ZN(0.144) |
|
Known Fixed Releases: * | 7.3(0)IZN(0.13), 7.3(0)N1(0.215), 7.3(0)N1(1), 7.3(0)ZN(0.192) |
|
|
| |
| |
|
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: | 30-JAN-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.1(3)ZN(0.131), 7.1(4)N1(0.696), 7.1(4)N1(1), 7.2(2)N1(0.379), 7.2(2)N1(1), 7.2(2)ZN(0.62), 7.3(0)IZN(0.13), 7.3(0)N1(0.234) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux03218 | Title: | Kernel reload during ISSU/ISSD from KK-191 bin to upg image |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ISSU failure while ISSU with the following error:-
Saving mts state.
[###############[ 1480.449005] writing reset reason 88,
#####] 100% -- SUCCESS
Reloading the kernel to proceed with the upgrade.
All telnet and ssh connections will now be temporarily terminated.
[ 1484.883321] Starting new kernel
[ 1484.920850] Calling kexec callback
[ 1484.930002] Moving to new kernel
[ 1484.930002] Calling into reboot_code_buffer code
??[ 7.776667] RAMDISK: incomplete write (-28 != 51) 134217728
[ 7.843203] crc error
[ 8.044987] EXT2-fs error (device ram0): ext2_check_page: bad entry in director
y #1492: : rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_le
n=0
[ 8.220824] EXT2-fs error (device ram0): ext2_check_page: bad entry in director
y #373: : rec_len is smaller than minimal - offset=1024, inode=0, rec_len=0, name_
len=0
[ 8.398679] EXT2-fs error (device ram0): ext2_check_page: bad entry in director
y #1899: : rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_le
n=0
[ 8.574519] KGDB: Waiting for remote debugger
[ 8.581876] wdt_log_buf: No logging buffer available, use local buffer
[ 8.581876] platform_type=3, hwclock time: 09:40:51, 08/09/2001
[ 8.581876]
0997350050:619999998 process swapper (1), jiffies 0xffff8e2e
[ 8.581876] invalid opcode
Conditions:
ISSU
Workaround:
None
Further Problem Description:
While doing KEXEC for the new kernel , the root file system if for some reason gets corrupted, then the unzipping of the File system would be an invalid rootfs , thus INIT task will not get started and generates a Kernel Panic.
In NC72UP-8G , IO use the SEGMENT received from NBI headers in kickstart image and it seems the calculation of RFS segment was done wrongly due to which, the RFS was getting corrupted.
So now NBI script will hard coded to an appropriate correct value.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.191) |
|
Known Fixed Releases: * | 7.1(3)N1(1.4), 7.1(3)N1(2), 7.1(3)ZN(0.136), 7.1(4)N1(0.701), 7.1(4)N1(1), 7.2(2)N1(0.356), 7.2(2)N1(1), 7.2(2)ZN(0.40), 7.3(0)IZN(0.13), 7.3(0)N1(0.215) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv88346 | Title: | EVPN: FWM crash at fwm_mtlite_enable_dynamic_vlan_detection |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
System crash while apply config when modules were coming up.
Conditions:
After system bringup and applying the breakout config, modules were powered off and powered on and simultaneously configs were applied.
Workaround:
Let the system come up fully. After that only apply the config.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.94) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.160), 7.1(4)N1(0.715), 7.1(4)N1(1), 7.3(0)IZN(0.13), 7.3(0)N1(0.236), 7.3(0)N1(1), 7.3(0)ZN(0.212) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue99559 | Title: | N5K/6K: FWM hap reset during ISSU upgrade |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus 5K/6K can crash in FWM process during a non disruptive ISSU
Conditions:
Seen during non disruptive ISSU upgrade
Workaround:
None
Further Problem Description:
The crash is due to stale entries in PSS which could have occurred in the past. Trigger for this is VLAN deletion/addition and execution of 'no feature-set fabricpath" and re-adding it in older code.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.307), 7.0(7)ZN(0.266), 7.0(8)N1(1), 7.1(3)ZN(0.133), 7.1(4)N1(0.698), 7.1(4)N1(1), 7.2(2)N1(0.355), 7.2(2)N1(1), 7.2(2)ZN(0.39), 7.3(0)IZN(0.13) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | 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: | 30-JAN-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.258) |
|
Known Fixed Releases: * | 7.2(2)N1(0.360), 7.2(2)N1(1), 7.2(2)ZN(0.44), 7.3(0)IZN(0.13), 7.3(0)N1(0.208), 7.3(0)N1(1), 7.3(0)ZN(0.188) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux85832 | Title: | pvlan traffic blackholed after GIR on n5k fabricpath leaf |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic Loss .
Conditions:
When GIR is done on fabric path leaf
Workaround:
vpc shutdown to be used.
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 7.3(0.215) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur72846 | Title: | Multi mobility domain and FCOE coexistance does not work |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
FCoE VFC doesn't come up, when Multi Mobility Domain feature is enabled.
Conditions:
The issue happens in following sequence:
1. FCoE VLAN is created first.
2. Then, "system fabric global-mobility-domain detectable-vlans " is configured with FCoE VLAN in detectable vlan range.
Workaround:
There are 2 workarounds:
1. Ensure that FCoE VLAN is created *after* "system fabric global-mobility-domain detectable-vlans" is configured.
2. If the issue is already hit due to the execution of sequence mentioned in "conditions" section, then delete and re-add FCoE VLAN to recover from the issue.
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.401), 7.1(2)N1(0.575) |
|
Known Fixed Releases: | 7.1(3)ZN(0.159), 7.1(4)N1(0.714), 7.1(4)N1(1), 7.2(2)N1(0.364), 7.2(2)N1(1), 7.2(2)ZN(0.47), 7.3(0)N1(0.118), 7.3(0)N1(1), 7.3(0)ZN(0.109) |
|
|
| |
| |
|
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-JAN-2016 |
|
Known Affected Releases: | 6.0(2)N2(7), 7.1(1)N1(1), 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.2(1)N1(0.246), 7.2(1)N1(1) |
|
|
| |
| |
|
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 5600/6000
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:Applies only when all of the following are true:
1. Running 10g OR 40g fabric mode
2. Nexus 5600/6000 platform
3. Running NX-OS version 7.0(6)N1(1) or prior.
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.
More Info:Issue is not seen with Nexus 5000/5500. After upgrading to fixed release a reload is required to fully resolve this issue.
Resolution Summary:
A change was made to set no-drop pool buffer allocation to the maximum value.
The fix is available in 7.0(7)N1(1), 7.1(0)N1(1), 7.2(0)N1(1) and all later releases.
|
|
Last Modified: | 25-JAN-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.272), 7.1(0)N1(0.368) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.156), 7.1(0)N1(1), 7.2(0)N1(1), 7.2(0)ZN(0.91) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux60138 | Title: * | PPM core during auto-configure |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
port-profile cored during a scale bld-dci auto-config.
Conditions:
Seen once. No specific condition.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 22-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.238) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup10367 | Title: | N6K/N5K Crashed @MRIB |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
nexus switch might crash unexpectedly with mrib hap reset
2010 Nov 3 09:49:40 AOB-5k-1 %$ VDC-1 %$ %VDC_MGR-2-VDC_ONLINE: vdc 1 has come online
2015 Dec 10 18:08:35 AOB-5k-1 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "mrib" (PID 3496) hasn't caught signal 11 (core will be saved).
2015 Dec 10 18:08:35 AOB-5k-1 %$ VDC-1 %$ %SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "mrib" in vdc 1 has had a hap failure
Conditions:
normal operation
Workaround:
there is no workaround. issue not seen in new code
Further Problem Description:
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.266), 7.0(8)N1(0.314), 7.0(8)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux95418 | Title: | 2348TQ: N2H traffic is dropped due to sending it to the wrong port |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
In enhanced vPC environment, traffic from a parent switch to a server via FEX could be dropped. The traffic could be sent out from the wrong HIF port on the FEX.
Conditions:
Still unknown. Reload a parent switch, HIF flapping or vPC peer-link flapping might trigger the problem.
Workaround:
The problem is not self recovered. By executing shut and no shut FEX HIF, it is restored.
Further Problem Description:
This defect is still under investigation.
|
|
Last Modified: | 01-FEB-2016 |
|
Known Affected Releases: | 7.1(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu92452 | Title: | Too many MTS flush generated when connecting VPC+ MST to legacy RPVST |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Too many MTS flush messages generated when connecting VPC+ MST to legacy RPVST, if multiple switches are connected at the same this can lead to instabilities of the VPC+ pair
Conditions:
Connecting VPC+ MST to legacy RPVST switches
Workaround:
Use RPVST on VPC+ instead of MST
Further Problem Description:
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.266), 7.0(8)N1(0.321), 7.0(8)N1(1), 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.3(0)BZN(0.47), 7.3(0)N1(0.95), 7.3(0)N1(1), 7.3(0)ZN(0.89) |
|
|
| |
| |
|
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: | 21-JAN-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.272), 7.0(3)I3(1), 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: | New |
Bug Id: | CSCux91530 | Title: | Hitting "Fowarding ASIC Failure" after ISSU from KK268 bin to upg |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
module is not coming up. showing as hardware failure
Conditions:
performing upgrade from bin to upg
Workaround:
reload the switch
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.268) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux80611 | Title: | Vlan to vni mapping incorrect on the border leaf VPC system |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
%FWM-2-VLAN_VNI_MAPPING_INCORRECT: VLAN to VNI mapping is incorrect syslog is seen.
Conditions:
1. Applicable at EDGE or Border Leaf when feature nv overlay and nv overlay evpn is enabled:
2. VNI is associated under nve interface for a vlan, routed interfaces or sub interfaces are present in the system.
3. routed interface or sub interface is deleted prior to vni is removed under nve interface or respective vlan (mapped with vni) is deleted.
Workaround:
None.
Further Problem Description:
Routed interfaces and sub interfaces uses a L3 vdc VLAN internally in the range of 4-4094 and if this vlan is getting used as core VLAN with L3 VNI under NVE interface then deleting the sub interfaces deletes L3 vdc VLAN mappings.
Now if a core VLAN-VNI is also removed, which is same as L3 vdc VLAN picked up randomly for routed or sub interfaces then VLAN residual states might present in the switch even after deleting the VLAN.
Using the same VLAN but different VNI mapping may cause the VLAN_VNI_MAPPING_INCORRECT and forwarding might not work.
Even after this fix.
Please ensure to shut the routed and sub interfaces before changing the core VLAN range.
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.254) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux54950 | Title: | Traffic drop with 'hardware profile fast-port-channel-bringup'& hif flap |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Seen traffic drops for north to south trafic (eth port to hif port channel) on submitter setup when HIF port channel has single port and "hardware profile fast-port-channel-bringup" feature is enabled.
Conditions:
hardware fast-port-channel-bringup feature is enabled and HIF port channel has single member port.
Workaround:
no hardware fast-port-channel-bringup, pc flap brings up the traffic.
Further Problem Description:
Seen traffic drops for north to south trafic (eth port to hif port channel) on submitter setup when HIF port channel has single port and "hardware profile fast-port-channel-bringup" feature is enabled. Found interface counters are incremented more than as expected. no hardware fast-port-channel-bringup, pc flap brings up the traffic.
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.220) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq81648 | Title: | N5K: Po configured as fex-fabric does not work as normal VPC trunk port |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a Nexus 5K switch if we configure ports as a fex-fabric port-channel, and then configure the prots as regular VPC trunk port the links stop passing traffic.
Conditions:
Sequence of events
a) The physical interface needs to be configured as part of a fex-fabric port channel.
b) Configure the port-channel as a regular VPC trunk interface
Workaround:
The workaround is to use a different port-channel interface ID when configuring the VPC trunk port. For example, if you were using port-channel 2 as a fex-fabric interface, and want to use the same physical ports for creating a regular VPC, use port-channel 10.
Further Problem Description:
|
|
Last Modified: | 11-JAN-2016 |
|
Known Affected Releases: | 5.2(1)N1(8a), 7.0(3)N1(0.99) |
|
Known Fixed Releases: * | 7.1(3)N1(0.647), 7.1(3)N1(1), 7.1(3)ZN(0.55), 7.2(2)N1(0.357), 7.2(2)N1(1), 7.2(2)ZN(0.41), 7.3(1)N1(0.4), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw28452 | Title: | Dot1q Port shudown (with 4k vlans) time increased to 9sec in kokomo |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Dot1q Port shudown (with 4k vlans) time increased to 9sec
Conditions:
Workaround:
no workaround
Further Problem Description:
STP is taking ~3.5 sconds to respond to LOGICAL BRINGUP message
FWM is taking around ~3.5 Seconds.
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: * | 7.3(0)N1(0.100), 7.3(0)N1(0.80) |
|
Known Fixed Releases: | 7.3(0)N1(0.243), 7.3(0)N1(1), 7.3(0)ZN(0.220) |
|
|
| |
| |
|
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: | 13-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.150) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.158), 7.1(4)N1(0.713), 7.1(4)N1(1), 7.3(0)IZN(0.7), 7.3(0)N1(0.171), 7.3(0)N1(1), 7.3(0)ZN(0.158) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw15815 | Title: | FLD_REQ(TO): Validation fail after device wr + reload (vtp pwd is ON) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VLANS/MST configs are not getting updated properly on N6k and getting FLD_REQ(TO): Validation fail(MD5 mismatch) message
Conditions:
VTP v3 is configured on the topology mentioned in Description with VTP password enabled.
Workaround:
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.104) |
|
Known Fixed Releases: | 7.3(0)IZN(0.7), 7.3(0)N1(0.167), 7.3(0)N1(1), 7.3(0)ZN(0.155) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux88309 | Title: | KK260:maint mode runn is added to "show runn int <name>" cmd output |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"show runn mmode" command output is getting added with ""show running-config interface " command output
Conditions:
maintenance mode profile should be configured.
Workaround:
need to remove maintenance mode profile
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.260) |
|
Known Fixed Releases: * | 7.3(0)IZN(0.13), 7.3(0)N1(0.269), 7.3(0)N1(1), 7.3(0)ZN(0.246) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux30836 | Title: | NIV: Static Veth deletion taking long time on VPC primary switch |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
When static veths are deleted on VPC primary switch, it takes a long time for the veths to actually get deleted. The corresponding veths on secondary switch get deleted instantly.
Conditions:
Static veth deletion on VPC switches
Workaround:
NA
Further Problem Description:
When we shut and delete the veth interfaces on VPC primary switch, it takes a significant amount of time for the interfaces to get deleted:
First, the veth shut CLI takes about 70-90 secs to get executed:
48q-npv(config-if-range)# no interface vethernet 1-2
^[[A^[[B ^
<Invalid range at '^' marker.
48q-npv(config-if-range)# sh run interface vethernet 1-2
48q-npv(config-if-range)#
But veths are still not deleted. They get struck in this state for atleast 3-5 mins:
48q-npv(config-if-range)# sh interface virtual status
Interface VIF-index Bound If Chan Vlan Status Mode Vntag
-------------------------------------------------------------------------
Veth1 VIF-16 Eth101/1/9 1 1 Deleting Unknown 2
Veth1 VIF-21 Eth102/1/9 1 1 Init Unknown 2
Veth2 VIF-20 Eth102/1/9 2 1 Init Unknown 3
Veth2 VIF-19 Eth101/1/9 2 1 Deleting Unknown 3
|
|
Last Modified: | 05-JAN-2016 |
|
Known Affected Releases: | 7.1(2)N1(1), 7.3(0)N1(0.177), 7.3(0)N1(0.208) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux64958 | Title: | Documentation-Netflow missing BGP ASN and next hop IP detail |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Documentation update is required to mention the restriction software imposes currently for Netflow collection of BGP ASN and next hop IP details.
Enhancement CSCuw66497 is currently pending for development for FIB to assist Netflow collection.
Conditions:
Netflow collection of BGP ASN and next hop IP details.
Workaround:
None. This is a documentation bug to outline the restrictions on config guides and release notes.
Further Problem Description:
|
|
Last Modified: | 04-JAN-2016 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.1(1)N1(1), 7.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux77664 | Title: | Qos counters not working for Acl based classification |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
class-map with a match acl upon the show policy-map interface
Service-policy (qos) input: pmap_in
policy statistics status: enabled
Class-map (qos): class_in (match-all)
0 packets
Match: access-group qos_in
set qos-group 4
set dscp af11
Class-map (qos): class-default (match-any)
0 packets
Match: any
set qos-group 0
Conditions:
Class-map with an ACL as a criteria
Workaround:
"show ip access-list " shows the counters for ACL
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.245) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 30-JAN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 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), 7.3(0)N1(1), 7.3(0)ZN(0.178) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv91507 | Title: | Migrating Fex from N7K to N6K/N5K may result in the FEX failing to boot |
|
Status: | Fixed |
|
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: | 30-JAN-2016 |
|
Known Affected Releases: | 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)IZN(0.13), 7.3(0)N1(0.208), 7.3(0)N1(1), 7.3(0)ZN(0.188) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus42592 | Title: | Potential Buffer Overflow in Nexus 6k Bios |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
This product includes a version of third-party software that is affected by the vulnerabilities identified by the following Common Vulnerability
and Exposures (CVE) IDs:
CVE-2014-8271
Cisco has analyzed these vulnerabilities and concluded that the product is not impacted
Conditions:
Not applicable
Workaround:
Not applicable
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 3.5/3.3:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:M/Au:S/C:N/I:N/A:P/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2014-8271 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.2(0.1)PR(0.1) |
|
Known Fixed Releases: * | 7.3(0)IZN(0.7), 7.3(0)N1(0.180), 7.3(0)N1(0.210), 7.3(0)N1(1), 7.3(0)ZN(0.162), 7.3(0)ZN(0.190) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu21983 | Title: | mts leak between Mcecm SAP and CFS after mct flap followed by reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
observed MTS leak between Mcecm SAP and CFS services.
Conditions:
These MTS leaks are observed after mct flap on primary followed by reload.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.186) |
|
Known Fixed Releases: | 7.1(3)ZN(0.157), 7.1(4)N1(0.712), 7.1(4)N1(1), 7.3(0)IZN(0.7), 7.3(0)N1(0.150), 7.3(0)N1(1), 7.3(0)ZN(0.138) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw99897 | Title: | kokomo_190 : PC member links are suspended by vPC |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
There are scenarios where command doesn't get rejected when explicit configuration of VPC id for HIF Port-channel when the FEX is in Active-Active mode.
Conditions:
FEX is in AA mode.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.190) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux25186 | Title: | [KK_208]: vPC-Mgr SAP timed out on unconfiguring MCT on vPC Primary |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
2015 Nov 17 15:10:10 Classical-Ethernet-Layer-3-Nexus-56128P--Pod--Left--vPC-Primary %ETH_PORT_CHANNEL-3-ALL_DROP_TIMEOUT: Some component(s) (sap:unknown) timed out on dropping
notif:MTS_OPC_IM_IF_REMOVED (for:port-channel999); Please collect
Conditions:
Issue is triggered on a vPC setup with HSRP scale
Workaround:
returns after few minutes with no functional impact.
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.150), 7.3(0)N1(0.208), 7.3(0)N1(0.213) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 30-JAN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1), 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.157), 7.1(4)N1(0.712), 7.1(4)N1(1), 7.2(2)N1(0.368), 7.2(2)N1(1), 7.2(2)ZN(0.51), 7.3(0)IZN(0.13), 7.3(0)N1(0.215), 7.3(0)N1(1), 7.3(0)ZN(0.192) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv87316 | Title: | "show interfaces" takes 6-7 min to complete |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
'show interface' CLI output takes longer time.
Conditions:
This issue is seen on L2 scale testbed with 24 fexs. There are 1780 interfaces.
Workaround:
None.
Further Problem Description:
This seems to be the expected performance for a command like 'show interface' to fetch the data for so many interfaces. I have verified that there is NO high CPU utilization and NO MTS queue buildup while running this command for 1800 interfaces. 'Show interface' fetches the required information to be displayed from the various components / modules involved. And fetching the such bulk information for large number of interfaces would take time. In case of 'show interface status' , we are fetching only single attribute - the status of the interface and hence it is faster.
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.0(3)N1(0.93) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw09193 | Title: | %CDP-4-NATIVE_VLAN_MISMATCH message not logged on N5600 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
%CDP-4-NATIVE_VLAN_MISMATCH message not logged on N5600 when it happens
Conditions:
Native vlan mismatch
Workaround:
N/A
Further Problem Description:
%CDP-4-NATIVE_VLAN_MISMATCH message not logged on N5600 when it happens
|
|
Last Modified: | 19-JAN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.1(4)N1(0.718), 7.1(4)N1(1), 7.3(0)N1(1), 7.3(0)ZN(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu62888 | Title: | N5K/N6K ISIS Neighbor with network type p2p adjacency not coming up |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On a nexus 5000/6000 series switch, ISIS Neighbor with network type p2p is not coming up with routers running IOS-XR
Conditions:
None
Workaround:
None
Further Problem Description:
None
|
|
Last Modified: | 18-JAN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.163), 7.1(4)N1(0.717), 7.1(4)N1(1), 7.3(0)BZN(0.47), 7.3(0)ZN(0.103) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux59653 | Title: | fwm core is observed while Disable/enable lacp with TFTP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
FWM process crash
Conditions:
Disable/enable lacp with TFTP on N6K switch running images 7.3.0.ZN.0.218.
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 18-JAN-2016 |
|
Known Affected Releases: | 7.3(0)ZN(0.218) |
|
Known Fixed Releases: * | 7.3(0)N1(0.264), 7.3(0)N1(1), 7.3(0)ZN(0.240) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv96234 | Title: | match datalink mac destination-address use field id 57 for ingress flow |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"match datalink mac destination-address" use PostDestinationMacAddress for ingress flow
Conditions:
- configure flow record for ingress source/destination mac.
- nx-os use field id 56 (sourceMacAddress) for source mac
- nx-os use field id 57 (PostDestinationMacAddress) for destination mac.
- nx-os shoud use field id 80 (destinationMacAddress).
http://www.cisco.com/c/en/us/td/docs/routers/access/ISRG2/AVC/api/guide/AVC_Metric_Definition_Guide/avc_app_exported_fields.html
Workaround:
none
Further Problem Description:
This behavior seen on N7K.
- 7.2(1)D1(1)
- 6.2(12)
|
|
Last Modified: | 14-JAN-2016 |
|
Known Affected Releases: | 7.0(3)N1(1), 7.2(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.159), 7.1(4)N1(0.714), 7.1(4)N1(1), 7.2(2)N1(0.346), 7.2(2)N1(1), 7.2(2)ZN(0.29), 7.3(0)N1(0.140), 7.3(0)N1(1), 7.3(0)ZN(0.128) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux71610 | Title: | Multiple VPC sections are seen after maintenance-mode is configured |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
DCNM is not discovering the interfaces due to multiple sections of the vpc domain
Conditions:
router ospf 100
isolate
router ospfv3 100
isolate
fabricpath domain default
isolate
vpc domain 100 <<<< this section is seen in "show runn | sec vpc"
shutdown
N6K_P1#
Workaround:
remove the "vpc domain " configuration from maintenance-mode
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.245) |
|
Known Fixed Releases: * | 7.3(0)IZN(0.13), 7.3(0)N1(0.259), 7.3(0)N1(1), 7.3(0)ZN(0.235) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux41730 | Title: | NXOS changes wrt BIOS change for CSCuw58510 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Nexus 600x switch might hang with no response via console, mgmt0 or inband interfaces. In certain NX-OS error messages such as following are printed prior to switch being impacted.
%USER-0-SYSTEM_MSG: 452: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
%USER-0-SYSTEM_MSG: 453: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
%USER-0-SYSTEM_MSG: 454: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
%USER-0-SYSTEM_MSG: 455: PCIe critical FAILURE DETECTED, contact Cisco TAC - pfm
Conditions:
Seen in Nexus 600x platforms
Workaround:
A debug plugin based workaround exists. Contact Cisco TAC to obtain the workaround.
Further Problem Description:
We are updating BIOS as the final solution for this
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(0)N1(1) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.266), 7.0(8)N1(0.313), 7.0(8)N1(1), 7.1(3)ZN(0.157), 7.1(4)N1(0.712), 7.1(4)N1(1), 7.3(0)IZN(0.13), 7.3(0)N1(0.247), 7.3(0)N1(0.252), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc36397 | Title: | vPC role switchover doesn't happen when vPC role is operational primary |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Changing the role-priority and flapping the peer-link does not change the roles of the vPC peers.
Conditions:
This happens when one of the switch has its role as "Operational primary" due to an earlier reload of the primary switch.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 12-JAN-2016 |
|
Known Affected Releases: | 4.1(3)N2(0.80), 4.1(3)N2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 11-JAN-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.2(2)N1(0.357), 7.2(2)N1(1), 7.2(2)ZN(0.41), 7.3(1)N1(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur11793 | Title: | Host entries for member-links not cleaned up once portchannel is up |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
The port channel member links are shown as data-snooping ports.
However, the baseline behaviour is such that For packets coming in on the PC, the Port-channel should be the only the data snooping port displayed and not its member links.
The issue is that the member links of Port-channel are also reported as associated ports.
Conditions:
This occurs during switch reload, when the member ports come up before the port-channel is applied.
Workaround:
No Workaround
More Info:
|
|
Last Modified: | 11-JAN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.349) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
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-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.150) |
|
Known Fixed Releases: * | 7.3(0)IZN(0.13), 7.3(0)N1(0.224), 7.3(0)N1(1), 7.3(0)ZN(0.201) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut07639 | Title: | N56: BIG_DROP_HIT_DROP_PORT_MAP_IDX increased when AA-FEX |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
PING to dest from host in the below topology fails when PING to N5672-1 from host is being done as well.
Conditions:
Topology:
[dest]
| vPC
[N5672-1]=====[N5672-2]
\ /
[N2248TP]
|
[host]
This issue was seen only when both traffic from FEX goes through vPC peer-link.
This issue was seen only on N5600 platform not on N5500 platform.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 08-JAN-2016 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut92989 | Title: | EVPC+ peer drops FTAG2 traffic while other VPC peer initializes the FEX |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Layer 2 multicast that traverses the FabriPath domain and belongs to FTAG2 MDT is black holed while the FEX is initialized.
Layer 2 multicast coming in from VPC+ port-channels connected to OTV Edge is also impacted, since some multicast flows are hashed by upstream N7K towards the secondary VPC+ N6K which is initializing the FEX.
Conditions:
Peer-Link restore or VPC+ peer restore after power off.
Workaround:
A simple combination of EEM and Python scripts was developed by AS Solutions Architect and SVS engineer that automatically detects when the peer-link port-channel is up and admin shuts all of the FEX VPC POs if the peer is VPC secondary. The FEXs can the be manually brought up by the network operations engineer one by one.
1.) EEM Script
event manager applet FEX_SHUT
event syslog pattern "%ETH_PORT_CHANNEL-5-PORT_UP: port-channel10:"
action 1.0 cli conf t
action 1.1 cli source vpcfailshut_final.py
action 1.2 syslog priority notifications msg FEX Ports Shut Down Post Peer-Link Recovery. Require Manual Enablement
2.) Python Script
#!/usr/bin/env python
import sys
import ConfigParser
import cisco
import time
# time is there to try for 100 seconds in the case of switch reload
for attempt in range(10):
shVpc = cli("show vpc")
shVpcLines = shVpc.splitlines()
stateList = shVpcLines[11].split()
vpcState = stateList[3:]
# If the VPC is secondary, shut the specific interface
if (vpcState == ["secondary"] or vpcState == ['primary,', 'operational', 'secondary']):
print("shutdown fp interface")
cli("conf t ; int po101-122 ; shut")
cli("conf t ; int po150-151 ; shut")
time.sleep(80)
cli("conf t ; int po101 ; no shut")
time.sleep(60)
cli("conf t ; int po102 ; no shut")
time.sleep(60)
cli("conf t ; int po103 ; no shut")
time.sleep(60)
cli("conf t ; int po104 ; no shut")
time.sleep(60)
cli("conf t ; int po105 ; no shut")
time.sleep(60)
cli("conf t ; int po106 ; no shut")
time.sleep(60)
cli("conf t ; int po107 ; no shut")
time.sleep(60)
cli("conf t ; int po108 ; no shut")
time.sleep(60)
cli("conf t ; int po109 ; no shut")
time.sleep(60)
cli("conf t ; int po110 ; no shut")
time.sleep(60)
cli("conf t ; int po111 ; no shut")
time.sleep(60)
cli("conf t ; int po112 ; no shut")
time.sleep(60)
cli("conf t ; int po113 ; no shut")
time.sleep(60)
cli("conf t ; int po114 ; no shut")
time.sleep(60)
cli("conf t ; int po115 ; no shut")
time.sleep(60)
cli("conf t ; int po116 ; no shut")
time.sleep(60)
cli("conf t ; int po117 ; no shut")
time.sleep(60)
cli("conf t ; int po118 ; no shut")
time.sleep(60)
cli("conf t ; int po119 ; no shut")
time.sleep(60)
cli("conf
|
|
Last Modified: | 07-JAN-2016 |
|
Known Affected Releases: | 7.2(360)NX(0.5) |
|
Known Fixed Releases: * | 7.1(3)N1(0.659), 7.1(3)N1(1), 7.1(3)ZN(0.67), 7.2(2)N1(0.363), 7.2(2)N1(1), 7.2(2)ZN(0.46) |
|
|
| |
| |
|
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: | 28-JAN-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) |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论