| |
|
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: | 19-APR-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(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), 7.3(0)N1(0.272) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz44008 | Title: | Nexus reboot __inst_001__isis_fabricpath crash |
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
Service: __inst_001__isis_fabricpath - Description: IS-IS Data-Center Ethernet Protocol
Exit code: signal 6 (no core)
Started at Thu Aug 16 04:46:15 2001 (509705 us)
Stopped at Fri Jun 7 05:58:24 2002 (319097 us)
Uptime: 295 days 1 hours 12 minutes 9 seconds
Last heartbeat 4.32 secs ago
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
RLIMIT_AS: 683885248
Virtual Memory TOTAL used: 667856 KB
NX-OS Core Decode Info (Info obtained from a NX-OS Core Decode)
Core Type is 'Nexus NXOS'
Found Build Type is 'final'
Found Build Root is '/auto/iluka/daily_build/iluka/nexus/184/src'
Found Hardware Model is 'n5000_uk9'
Found Release Version is '7.0(5)N1(1)S0'
VBE Version is '5.1.5.1'
Application Name is '/auto/iluka/daily_build/iluka/nexus/184/src/build/n5k/x86s/final/isis/supnuovaor/isis_l2mp'
CPU Architecture is 'Intel'
customize_target_fs
Build tree is /auto/iluka/daily_build/iluka/nexus/184/src
dir name is n5000_uk9
ucdfsp
ucdbsp /tmp/ucd.bDoDilkWXDwzZ31767
finallink is /auto/iluka/daily_build/iluka/nexus/184/src/build/n5k/x86s/final/libcrdcfgnuova/supnuovaor/libcrdcfgnuova_5k.so /tmp/ucd.bDoDilkWXDwzZ31767/isan/lib/libcrdcfgnuova.so
Program terminated with signal 6, Aborted.
1. 0x414875a6 raise ---> /tmp/ucd.bDoDilkWXDwzZ31767/lib/libc.so.6
2. 0x4148ad18 abort ---> /tmp/ucd.bDoDilkWXDwzZ31767/lib/libc.so.6
3. 0x082b5185 vni_sbmp_new ---> ../include/isan/sbmp_template.h:2122
4. isis_l2mp_show_vni_in_sbmp ---> ../routing-sw/routing/isis/isis_l2mp_ui.c:15216
5. 0x082ba252 isis_l2mp_show_vlan_range_cmd ---> ../routing-sw/routing/isis/isis_l2mp_ui.c:15305
6. 0x778e50b8 command_context_c::call_command ---> ../feature/vsh/cli/cli_common/cli_component.cc:1071
7. 0x778e58da cli_transient_run ---> ../feature/vsh/cli/cli_common/cli_component.cc:517
8. 0x77af602f procket_pthread_rtn ---> ../routing-sw/libs/syswrap/procket_pthread.c:843
9. 0x415c4140 start_thread ---> /tmp/ucd.bDoDilkWXDwzZ31767/lib/libpthread.so.0
10. 0x415278ce clone ---> /tmp/ucd.bDoDilkWXDwzZ31767/lib/libc.so.6
ucd 1.3b-cli +ucsm
Copyright (c) 2013-2015 Cisco Systems, Inc.
For Internal Use Only
A universal core decoder for UCS, Nexus, MDS & ACE products
across Intel, PowerPC, MIPS & ARM CPU architectures
INFO: Given Core Name is '/nobackup/bsitomer/smartdecoder-tmp/BHY-N5K-DC-041460031896_0x101_isis_fabricpath_log.7662.tar.gz'
INFO: Core Type is 'Nexus NXOS'
INFO: Found Build Type is 'final'
INFO: Found Build Root is '/auto/iluka/daily_build/iluka/nexus/184/src'
INFO: Found Hardware Model is 'n5000_uk9'
INFO: Found Release Version is '7.0(5)N1(1)S0'
INFO: VBE Version is '5.1.5.1'
INFO: Application Name is '/auto/iluka/daily_build/iluka/nexus/184/src/build/n5k/x86s/final/isis/supnuovaor/isis_l2mp'
INFO: CPU Architecture is 'Intel'
INFO: Creating NXOS target file system...
INFO: customize_target_fs
INFO: Build tree is /auto/iluka/daily_build/iluka/nexus/184/src
INFO: dir name is n5000_uk9
INFO: ucdfsp
INFO: ucdbsp /tmp/ucd.bDoDilkWXDwzZ31767
INFO: finallink is /auto/iluka/daily_build/iluka/nexus/184/src/build/n5k/x86s/final/libcrdcfgnuova/supnuovaor/libcrdcfgnuova_5k.so /tmp/ucd.bDoDilkWXDwzZ31767/isan/lib/libcrdcfgnuova.so
creating links .... /auto/andpkg/rep_cache//wr-x86/3.0FCS/sysroot/lib /tmp/ucd.bDoDilkWXDwzZ31767/lib
Core type is :: NEXUS
bld type is :: /auto/iluka/daily_build/iluka/nexus/184/src
warning: .dynamic section for "/tmp/ucd.bDoDilkWXDwzZ31767/isan/lib/libif_index.so" is not at the expected address (wrong library or version mismatch?)
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz28231 | Title: | N6K LACP Not being processed to SUP |
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
After an upgrade to NX-OS 7.0(8)N1(1), under rare conditions, LACP packets can get dropped and LACP port-channels go into an individual or suspended state
Conditions:
Seen under rare conditions after an upgrade.
Workaround:
None for LACP. Using static port-channels is a potential workaround.
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.0(8)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz01388 | Title: | Dell B22 fex does not detect Link Down on LACP Windows server. Linux OK |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
B22 Dell Fexes dual-homed to a pair of Nexus 6000 running 7.0(6)N1(1).
Server connected by eVPC with LACP NIC teaming, running Windows HyperV
When the server disables the NIC team member, the fex reports the link is still up. When the server re-enables the port, connectivity is broken.
Shut/no shut on the Fex side or reconfiguring the Fex port or power-cycling the Fex does not help.
Reloading the server resolves the issue.
Keeping the same HW configuration, if the same server is booted with Linux OS, there is no issue: the Fex detects the link down.
replacing the Fex with a pass-through module, when the Windows server disables one NIC, the parent switch correctly detects the link down.
Dell reproduced the problem. Opening this defect for tracking
Conditions:
Server running Hyper V NIC teaming and running Windows.
Workaround:
reload the Windows Server.
Further Problem Description:
|
|
Last Modified: | 01-APR-2016 |
|
Known Affected Releases: | 7.0(6)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 19-APR-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.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), 7.3(0)ZN(0.158) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz12597 | Title: | 5600: Fex fails to boot on 7.1(0)N1(1b) |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
A FEX plugged into a Nexus 5600 switch running 7.1(0)N1(1b) may remain stuck in "Image Download" state and not boot.
Conditions:
FEX attached to Nexus 5600
Workaround:
Contact Cisco TAC
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv99658 | Title: | VPC peer link is not coming up after peer-link flap |
|
Status: | Open |
|
Severity: * | 2 Severe |
Description: | Symptom:
VPC peer-link down.VPC peer link is not coming up after peer-link flap (reason:vPC peer is not reachable over cfs).
Conditions:
Its a timing issue and happens very very rarely. Mostly after first peer-link flap post reload.
Workaround:
Shut and no shut on the peer-link ie flapping the vpc peer-link will solve the issue.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.104) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
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: | 28-APR-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.186), 7.2(1)N1(0.286) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 27-APR-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.2(1)N1(0.246), 7.2(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw45151 | Title: | BrdCast Drop / incorrect Ofil with the elam Capture in Vinci Spine |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
mCast with Autoconfiguration is not supported
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.2(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux95887 | Title: | port-security internal information not cleared on feature de-activation |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When port-security is disabled from an interface, port-security internal information remains in the system.
Conditions:
Port-security enabled and disabled on a port.
Workaround:
Reload the FEX of disabled the port-security globally
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.2(1)N1(0.331) |
|
Known Fixed Releases: | 7.1(3)N1(4), 7.1(3)ZN(0.224), 7.1(4)N1(0.764), 7.1(4)N1(1), 7.3(1)N1(0.38), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv37294 | Title: | 2248: Packets getting Blackholed in the HIF VPC port-channel |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Packets will get black holed in the HIF VPC Port-channel
Conditions:
1) FEX 2248
2) 55xx based Platforms
3) Running 7.0(6)N1(1)
Workaround:
1) Keep one single HIF port in the HIF port-channel.
2) If there are more ports in port-channel, Change the hashing by shutting down ports on HIF side.
Further Problem Description:
|
|
Last Modified: | 24-APR-2016 |
|
Known Affected Releases: | 7.0(6)N1(0.1) |
|
Known Fixed Releases: | 7.0(3)I2(2d), 7.0(3)I4(0.90), 7.0(3)I4(1), 7.0(7)N1(0.288), 7.0(7)N1(1), 7.0(7)ZN(0.173), 7.1(3)N1(0.619), 7.1(3)N1(1), 7.1(3)ZN(0.25), 7.2(1)N1(0.283) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy83222 | Title: | N5696+N5696-M12Q with sub-interf;Snmppolling Cause MTS Buff leak-pfstats |
|
Status: | Open |
|
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: | 20-APR-2016 |
|
Known Affected Releases: * | 7.0(6)N1(1), 7.2(0)N1(0.144) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 19-APR-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.268) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.242), 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: | 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: | 19-APR-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.339) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.250), 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: | CSCui84039 | Title: | ascii-cfg core and n6k reload observed no feature-set fabricpath |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ascii-cfg process crash when doing "no feature-set fabricpath"
Nexus# sh core
Module Instance Process-name PID Date(Year-Month-Day Time)
------ -------- --------------- -------- -------------------------
1 1 ascii-cfg 3675 2011-03-27 00:00:46
Nexus(config)# no feature-set fabricpath
Feature-set Operation may take up to 30 minutes depending on the size of configuration.
[362482.443853] Shutdown Ports..
[362482.479243] writing reset reason 16, ascii-cfg hap reset
Broadcast message from root (console) (Fri MSending all processes the TERM signal...
Sending all processes the KILL signal...
Unmounting filesystems...
Conditions:
Issue command:
Nexus(config)# no feature-set fabricpath
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 6.0(2)N2(2), 6.0(2)N3(0.195) |
|
Known Fixed Releases: * | 5.2(1)N1(9.179), 5.2(1)N1(9a), 7.0(0)N1(0.501), 7.0(0)N1(1), 7.0(0)ZN(0.208) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw59277 | Title: | FEX 2348 A-A: Packets send to wrong FEX HIF interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms:
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 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.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another evaluation.
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: | 13-APR-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.1(3)N1(2.7), 7.1(3)N1(4), 7.1(3)ZN(0.196), 7.1(4)N1(0.740), 7.1(4)N1(1), 7.3(1)N1(0.319), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz16221 | Title: | FWM crash and switch reloads. |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
FWM crash and switch reloads.
Conditions:
1) lot of PVLAN MAC clone/delete calls around the time of crash from trace log and double mac delete as well).
2) Segmentation fault happen inside fwm_malloc/mtrack_alloc call.
3) Fix for CSCut55443 is present in image but never kicked-in, not seeing trace logs present on the fix on
collected trace log from core.
Workaround:
NONE
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 12-APR-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(3), 7.1(3)ZN(0.131), 7.1(4)N1(0.696) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw78727 | Title: | Nexus 6000 crash due to "fwm hap reset" |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:Nexus 6000 crash in "fwm hap reset".
Conditions:Customers moving from hyams to
Issues should not be seen in Nexus 56xx switches since pre iluka images are not supported in these.
Workaround:Customer has done a two step ND ISSU.
ND ISSU hyams to ND ISSU from
Switch has not been reloaded throughout the process.
Before triggering a ISSU from 7.0(6)N1(1) to 7.0(7)N1(1),
Scenario 1 :
if some VLANs were deleted in 7.0(6)N1(1) then you will not see the VLAN in running config but you can see the VLAN in PSS
1. The vlan will not be seen in "show platform fwm info vlan" or "running-config"
2. But, the vlan is present in "show platform fwm info pss runtime_vlan". This contains the stale entries.
Customer has hit the issue. At this stage, if customer triggers a subsequent ND ISSU, system will crash.
Workaround :-
Recreate all the VLANs before the ISSU, so the running config and PSS are in sync. After system is moved to 7.0(7)N1(1) VLANs can be deleted safely.
Upgrade the system in maintenance mode.
Scenario 2:
If some (S,G)s were delete, recreated and then deleted after first ISSU.
1. The (S,G) is not present in "sh ip igmp snooping groups"
2. But the (S,G) is present in "show platform fwm info pss runtime_sg".
Customer has hit the issue. At this stage, if customer triggers a subsequent ND ISSU, system will crash.
Workaround :-
Upgrade the system in maintenance mode.
"A cleaner approach to get rid of this issue at this point would be to suggest the customers which have moved from ?hyams" to ?
More Info:the same crash can be present in other areas as well.
VLAN
Multicast (S,G)
Static MAC
Reg MAC
Runtime IF
All the entries which use this structure ?fwm_pss_runtime_ha_key_t? to form the key in PSS.
Orginal issue was introduced in iluka, when we move from hyams to higher version, the size of fwm_pss_runtime_ha_key_t has changed from 28 to 32 byte, so when we perform a ND ISSU from hyams to higher version, it creates a stale entry of 28 bytes in PSS. PSS can read the 28 byte entry and restore it, but it is not altered with subsequent create and delete on that object. Subsequent operations on that object will only create/delete a 32 byte entry.
This issue was leading to crash for Multicast (S,G) in iluka(<7.0.7) where customer was perorming a double step ISSU from hyams to iluka and then higher version.This was fixed by CSCuo28747. As part of the fix, we are converting every 28 byte entry to a 32 byte entry and deleting any further duplicates if present. But one corner case was missed out, if we delete the entry after first step ISSU, then the stale entry of 28 byte still exists in PSS and with subsequent ISSU it gets converted to 32 bytes and we try restoring a entry which does not exists in runtime database so the systems asserts.
Note :- PSS can read 28 byte entry but will write 32 byte entry with create and delete.
Following scenarios are there :-
1 . Customer moving from hyams to >=iluka6(7.0.7) or iplus2(7.1.2) directly will not hi
|
|
Last Modified: | 11-APR-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy97195 | Title: | Nexus 6000: Switch reload due to Kernel Panic |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 6000 series switch running NX-OS 7.1(3)N1(1) can experience a reset due to Kernel panic
Conditions:
Nexus 6000 series switch running NX-OS 7.1(3)N1(1)
Workaround:
None. Contact Cisco TAC
Further Problem Description:
|
|
Last Modified: | 11-APR-2016 |
|
Known Affected Releases: | 7.1(3)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCur99346 | Title: | PPM_VSH_MAX_CMD_BUF_SIZE 4K limitation |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Output of command "show running-config" will not show all vlans configured.
Conditions:
If a large number of vlans are configured such that the textual running configuration of vlans exceeds 4000 characters, output will get truncated.
Workaround:
If the buffer to print the complete list of vlan's in the configuration is not big enough, pick a vlan in the middle of your range and give it a non default vlan name.
Exampel: vlan 2000
default vlan name: VLAN2000
change the name to: VLAN-2000
that breaks the buffer in two and you get the complete list vlan;s printed in the show running-config output.
Depending on how many vlan's are individually configured you may have to do this 2 or 3 times to get all vlans printed.
Another workaround is to create a consecutive range of vlans, i.e:
vlan 1 - 2000
instead of vlan 1, 3,5,7,9,......
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.386) |
|
Known Fixed Releases: | 7.1(3)N1(2.11), 7.1(3)N1(4), 7.1(3)ZN(0.234), 7.1(4)N1(0.770), 7.1(4)N1(1), 7.3(1)N1(0.36), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy22192 | Title: | Netapp Interop: Netapp F8040 LIF FDISC reject with Command not supported |
|
Status: * | Other |
|
Severity: * | 3 Moderate |
Description: | Symptom:
FDISC is rejected coming from FC ports on 2348UPQ.
Conditions:
Flogi will be accepted and Fdisc will be rejected on 2348UPQ FC ports
Workaround:
No workaround.
Further Problem Description:
|
|
Last Modified: | 06-APR-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.287) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv81286 | Title: | adm_eprom_get_hw_version_O2: Error: wbd failed to disable the black box |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
show version will show below
show version
adm_xbar_eprom_get_hw_version: Error: wbd failed to disable the black box <<<
adm_xbar_eprom_get_hw_version: writing to location failed, slot 0 <<<
adm_xbar_eprom_get_hw_version: cmd: dmesg > /tmp/i2cdebug <<<
Get hardware version failed <<<
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_series_home.html
Copyright (c) 2002-2014, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
Software
BIOS: version 1.6.0
loader: version N/A
kickstart: version 7.0(1)N1(1)
system: version 7.0(1)N1(1)
Power Sequencer Firmware:
Module 1: version v4.0
Module 2: version v4.0
Fabric Power Sequencer Firmware: not available <<<
Conditions:
5596 or 6001(running 7.0(1)N1(1)
Workaround:
none;
not seen in latest 7.3(0)N1(1)
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.91) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux81143 | Title: | Specific SNMP GET request causes 'snmpd' and 'licmgr' services to crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptoms:
Cisco NX-OS Software-based devices contain a buffer overflow vulnerability in the SNMP subsystem.
An authenticated, remote attacker can exploit the vulnerability by submitting a malicious SNMP
query via UDP port 161 to trigger a buffer overflow condition in the SNMP and License Manager
components of the device. Successful exploitation could allow the attacker to execute arbitrary
code with elevated privileges.
SNMP is disabled by default and must be explicitly configured by an administrator. Because SNMP
is primarily a UDP-based protocol, no TCP three-way handshake is required to exploit this vulnerability,
and the malicious request could contain a spoofed origin. The attacker must know the configured
community strings for SNMP version 1 and version 2. Exploitation also requires a valid username
and password when a device is configured for SNMP version 3.
This vulnerability can be triggered via SNMP over IPv4 and SNMP over IPv6.
Conditions:
The NX-OS device is configured for SNMP.
Workaround:
The SNMP community string should be secure.
Further Problem Description:
None.
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 9/7.4:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:S/C:C/I:C/A:C/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2013-1179, CVE-2013-1180 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: | 15-APR-2016 |
|
Known Affected Releases: | 7.0(7)ZN(0.265) |
|
Known Fixed Releases: * | 5.2(1)N1(8.173), 5.2(1)N1(9a), 7.0(7)ZN(0.266), 7.0(8)N1(0.316), 7.0(8)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: | 25-APR-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(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), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz18744 | Title: | N6K send-community gets removed on upgrade |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
send-community is removed from configuration
Conditions:
an upgrade from 6.0(2) to 7.0(0) or above
Workaround:
reapply configuration after upgrade.
Further Problem Description:
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 6.0(2)N1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCut92301 | Title: | EEM redirection to file adds Cannot change the ownership of file: lines |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
After triggering a python script via source or EEM that redirects to a file, "Cannot change the ownership of file:" is added to the redirected file. This causes issues when trying to read back the file.
Conditions:
Specified software installed on device.
Workaround:
Modify file before file read is performed.
Further Problem Description:
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz02835 | Title: | PBR -Applied PBR doesn't match the last ACE of the called ACL |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Packets follow the routing table path even though the PBR is applied.
This is noticed in N5600 (N56128P) version 7.0(2)N1(1).
Conditions:
ACL only using a remark entry
Workaround:
Add a ip ACE entry to the blank ACL
Further Problem Description:
From: gopasaha@cisco.com
To: "Abayomi Adefila (aadefila)" ,"Bing He (bhe2)" ,"Malaka Pathirana (mpathira)" ,"Nitin
Kakkar (nitkakka)" ,"Chandra Sekhar Vanka (cvanka)"
Cc: "email-in@cisco.com" ,"n5k6k-platform(mailer list)" ,"n5k6k-acl-dev(mailer list)" ,"nxos-rpm-dev(mailer list)" ,"nxos-aclmgr-dev(mailer list)" ,"nxos-acl-dev(mailer list)"
Subject: RE: SR 638307215 : Applied PBR doesn't match the last ACE of the called ACL
Hi,
Here is my analysis:
Due to the 'remark' ACE in the ACL "Latency-ACL-3" default permit all tcam entry (marked in red below) is getting added before the last ACE of ACL "Latency-ACL-2"
K:IPV4 (0x7/0x0) IN L-[V-0x1FF/0x3 ] routed
[1014] SA Label:0x0/0x0 DA Label:0x0/0x0
[1014] SA:0x00000000/0x00000000 DA:0xFFFFFFFF/0x0A0A7515
[1014]-> prio:7 stats:133 IFMAP REDIRECT:0 PERMIT
count:[0]-vmr_handle[460010104400136]
K:IPV4 (0x7/0x0) IN L-[V-0x1FF/0x3 ] routed
[1015] SA Label:0x0/0x0 DA Label:0x0/0x0
[1015] SA:0x00000000/0x00000000 DA:0xFFFFFFFF/0x0A0A7461
[1015]-> prio:7 stats:132 IFMAP REDIRECT:0 PERMIT
count:[0]-vmr_handle[460010104400137]
K:ALL (0x0/0xFFFF) IN L-[V-0x1FF/0x3 ] wide:h
[1016] SA Label:0x0/0x0 DA Label:0x0/0x0
[1016]-> prio:7 PERMIT
K:IPV4 (0x7/0x0) IN L-[V-0x1FF/0x3 ] routed
[1018] SA Label:0x0/0x0 DA Label:0x0/0x0
[1018] SA:0x00000000/0x00000000 DA:0xFFFFFFFF/0x0A0A7463
[1018]-> prio:7 stats:130 IFMAP REDIRECT:0 PERMIT
count:[0]-vmr_handle[460010104400138]
K:IPV4 (0x7/0x0) IN L-[V-0x1FF/0x3 ]
[1019] SA Label:0x0/0x0 DA Label:0x0/0x0
[1019] SA:0x00000000/0x00000000 DA:0x00000000/0x00000000
[1019]-> prio:7 stats:129 PERMIT
count:[0]-vmr_handle[460010100000000]
Looks like acl-manager is sending in this order. Due to this, the last entry [1018] of the ACL "Latency-ACL-2" is never getting hit and default permit entry [1016] is causing the traffic to take default RIB nexthop.
After removing the "Latency-ACL-3" , PBR next hop is taking effect.
513E.B.17-3750X-2#traceroute 10.10.116.99
Type escape sequence to abort.
Tracing the route to 10.10.116.99
VRF info: (vrf in name/id, vrf out name/id)
1 10.2.2.106 0 msec 0 msec 9 msec
2 10.2.2.170 0 msec * 0 msec
There are two issues here:
1. 'remark' ace for PBR is getting programmed as "permit all" entry in tcam. This is similar to "CSCus28695< https://cdetsng.cisco.com/webui/#view=CSCus28695>"; which was WCCP specific. Looks like for PBR also we need similar fix. I can build a private image with that fix and share it. Let me know from which release you need this private image.
2. Why 'rmark' ace s getting reorder ? May be acl-manager folks ca
|
|
Last Modified: | 03-APR-2016 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
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: | 01-APR-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.2(2)ZN(0.103), 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: | CSCuy85524 | Title: | Bios image should be md5 verified after extraction prior to application |
|
Status: | Open |
|
Severity: * | 3 Moderate |
Description: * | Symptom:
On a Nexus 5xxx or Nexus 6xxx series switch if the bios image gets corrupted during file extraction the image is not verified currently before trying to apply it. This is an enhancement to verify the image before removing the old bios to make sure it is good.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 12-APR-2016 |
|
Known Affected Releases: | 7.0(7)N1(1), 7.1(1)N1(1) |
|
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: | 19-APR-2016 |
|
Known Affected Releases: | 6.0(2)N2(5) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.242), 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: | CSCuj20687 | Title: | Enh: Configuring static multicast mac-address for N6K NLB implementation |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
This is an enhancement request being filed for the Nexus 6000 platform to provide us with the ability to configure static multicast mac addresses for NLB type implementations. Currently configuring static multicast mac addresses (by way of either a static mac or igmp static-group) is not supported since the N6K does layer 3 based multicast lookup.
Conditions:
This bug only applies to Nexus 6000 up until the 6.0(2)N2(1) release.
Workaround:
None.
Further Problem Description:
For NLB type implementations, we need to map a unicast IP to a multicast mac address. On the N5K, we achieve this by a workaround of configuring static-group using corresponding layer 3 multicast IP address for that multicast MAC in question:
5548-2(config)# vlan x
5548-2(config-vlan)# ip igmp snooping static-group interface x
If the N5K is the layer 3 boundary, then we would also need to add a static ARP entry on the interface vlan on the N5K
Interface vlan
ip arp
For the N7K, we perform the following:
vlan configuration 10
layer-2 multicast lookup mac
vlan configuration 10
ip igmp snooping static-group 239.1.1.1 interface Ethernet8/2
ip igmp snooping static-group 239.1.1.1 interface Ethernet8/4
ip igmp snooping static-group 239.1.1.1 interface Ethernet8/7
For the N6K, although you can configure the static-group, it still does not work since the N6K does multicast forwarding based on multicast IP lookup i.e. It does *,G or S,G based lookup unlike N5K which does lookup based on multicast mac. If destination IP is multicast IP, traffic gets forwarded. If dest IP is unicast IP, though MAC is multicast MAC, traffic does not get forwarded. Hence it worked for N5K and not for the N6K.
|
|
Last Modified: | 12-APR-2016 |
|
Known Affected Releases: | 6.0(2)N2(1), 6.0(2)N2(3) |
|
Known Fixed Releases: | 7.0(0)N1(0.394), 7.0(0)N1(1), 7.0(0)ZN(0.122) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy73026 | Title: | sh run for ascii-cfg not displayed correctly |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Configs under line vty, dont show up correctly during sh run
Conditions:
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 05-APR-2016 |
|
Known Affected Releases: | 7.1(3)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.241), 7.1(4)N1(0.776), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw01221 | Title: | N5K VPC orphan-port suspend (vpc peerlink is down) w/ peer adjacency OK |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After a reload of VPC primary, which comes up with VPC role primary, operational secondary, VPC orphan ports configured with 'orphan-port suspend' remain disabled with (vpc peerlink is down) after the delay restore timers expire. At the same time, vPC port-channels that meet consistency VPC requirements are up
R1-CS-5548-B-U41# sh vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
R1-CS-5548-B-U41# show interface brief | inc peer
Eth1/11 302 eth trunk down vpc peerlink is down 10G(D) --
Eth1/13 302 eth access down vpc peerlink is down 1000(D) --
Eth1/14 302 eth access down vpc peerlink is down 1000(D) --
Eth1/17 302 eth trunk down vpc peerlink is down 10G(D) --
Eth1/18 302 eth trunk down vpc peerlink is down 10G(D) --
Eth1/19 302 eth trunk down vpc peerlink is down 10G(D) --
Eth1/20 302 eth trunk down vpc peerlink is down 10G(D) --
Eth1/21 302 eth trunk down vpc peerlink is down 10G(D) --
Eth1/22 302 eth trunk down vpc peerlink is down 10G(D) --
Eth1/23 302 eth trunk down vpc peerlink is down 10G(D) --
Eth1/24 302 eth trunk down vpc peerlink is down 10G(D) --
Conditions:
Start with normalized VPC pair (roles resolved). Power cycle or reload VPC.
In this scenario, the peer-link was using 10G twinaxe cables SFP-H10GB-CU1M.
Workaround:
Configure shut / no shut on the VPC orphan port
Further Problem Description:
Un-reproduce-able in the lab so far.
|
|
Last Modified: | 19-APR-2016 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.242), 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(1)N1(0.21), 7.3(1)N1(0.27), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz06292 | Title: | n6k crash due to fwm hap reset |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
n6k crash due to fwm hap-reset
Conditions:
Workaround:
NONE
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 8.3(0)CV(0.54) |
|
Known Fixed Releases: | |
|
|
| |
没有评论:
发表评论