| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx54830 | Title: | Specific SNMP GET request causes 'snmpd' and 'licmgr' services to crash |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Summary
Cisco Nexus, Cisco Unified Computing Systemn (UCS), Cisco MDS 9000 Series Multilayer Switches, and Cisco 1000 Series Connected Grid Routers (CGR) are all based on the Cisco NX-OS operating system. These products are affected by one or more of the following vulnerabilities:
* Multiple Cisco Discovery Protocol Vulnerabilities in Cisco NX-OS-Based Products * Cisco NX-OS Software SNMP and License Manager Buffer Overflow Vulnerability * Cisco NX-OS Software SNMP Buffer Overflow Vulnerability * Cisco NX-OS Software Jumbo Packet Denial of Service Vulnerability
Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130424-nxosmulti
Conditions: See published Cisco Security Advisory
Workarounds: See published Cisco Security Advsiory
Further Problem Description: See published Cisco Security Advisory
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.0/7.4: https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:L/Au:S/C:C/I:C/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2013-1179 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: | 03-FEB-2016 |
|
Known Affected Releases: * | 5.2(1), 6.0(1), 7.0(7)ZN(0.265) |
|
Known Fixed Releases: | 5.2(4.11)S0, 7.1(0)BF(0.74), 7.1(0)ZD(0.158), 7.1(0)ZD(0.225) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw58529 | Title: | repeating aclqos crashes caused N7K line card hap reset |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom: N7K line card may see service "aclqos" crashes
Conditions: this was seen on N7K running code 6.2.12 on M1 card.
Workaround: no known for now.
Further Problem Description: This issue may be seen on N7K line cards under the following conditions -
1. Bank chaining is enabled 2. Statistics is enabled for ACLs 3. Due to resources being fully utilized, policies are not split across tcams.
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: * | 6.2(16)S16, 7.2(1)D1(1), 7.2(1)ZD(0.110), 7.2(2)D1(0.1), 7.3(0)D1(0.141), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)OTT(0.73), 7.3(0)RTG(0.115) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux60618 | Title: | BGP RR doesn't send update |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom: If inter-as vpnv4 configuration is present in BGP config RR doesn't send update to RR-clients
Conditions: inter-as vpnv4
Workaround: no workaround
Further Problem Description: .
|
|
Last Modified: | 19-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.241), 7.0(3)I3(0.242), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.100), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.3(0)D1(0.197), 7.3(0)D1(1), 7.3(0)HIB(0.3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw93592 | Title: | 6.1.0.169.S1::Titanium Ethernet Module Not Coming Up !!! |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: * | Symptom: Titanium Ethernet Module is going to failure state after loading image
Conditions: No Condition
Workaround: No Workaround |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: * | 6.1(0.169)S0 |
|
Known Fixed Releases: * | 6.1(0.169)S3, 6.1(0.173)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw86978 | Title: | F2E 6.2.(14) upgrade fail %VMM-2-VMM_SERVICE_ERR: VDC1: Service SAP |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom: upgrade fail with error message %$ VDC-1 %$ %VMM-2-VMM_SERVICE_ERR: VDC1: Service SAP Aclmgr SAP for slot 3 returned error 0x41040069 (Sufficient free entries are not available in TCAM bank) in if_bind sequence
and interfeces are removed , not shown in show interface though show module status is ok state.
`show module` Mod Ports Module-Type Model Status --- ----- ----------------------------------- ------------------ ---------- 1 0 Supervisor Module-2 N7K-SUP2 active * 3 48 1/10 Gbps Ethernet Module N7K-F248XP-25E ok
* this terminal session `show vdc membership` Flags : b - breakout port ---------------------------------
vdc_id: 0 vdc_name: XXXXXXXXX interfaces: vdc_id: 1 vdc_name: XXXXXXXXX interfaces: *Ethernet3/1 *Ethernet3/2 *Ethernet3/3 *Ethernet3/4 *Ethernet3/5 *Ethernet3/6 *Ethernet3/7 *Ethernet3/8 *Ethernet3/9 *Ethernet3/10 *Ethernet3/11 *Ethernet3/12 *Ethernet3/13 *Ethernet3/14 *Ethernet3/15 *Ethernet3/16 *Ethernet3/17 *Ethernet3/18 *Ethernet3/19 *Ethernet3/20 *Ethernet3/21 *Ethernet3/22 *Ethernet3/23 *Ethernet3/24 *Ethernet3/25 *Ethernet3/26 *Ethernet3/27 *Ethernet3/28 *Ethernet3/29 *Ethernet3/30 *Ethernet3/31 *Ethernet3/32 *Ethernet3/33 *Ethernet3/34 *Ethernet3/35 *Ethernet3/36 *Ethernet3/37 *Ethernet3/38 *Ethernet3/39 *Ethernet3/40 *Ethernet3/41 *Ethernet3/42 *Ethernet3/43 *Ethernet3/44 *Ethernet3/45 *Ethernet3/46 *Ethernet3/47 *Ethernet3/48
Conditions: F2E module 6.2.(14)
Workaround: reduce the number of SVI
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 6.2(8.13), 7.3(0)D1(0.165) |
|
Known Fixed Releases: * | 6.2(16)S16, 7.3(0)D1(0.190), 7.3(0)D1(1), 7.3(0)ZD(0.208), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux35827 | Title: | M2 lockup due to ED HANG exceptions prior to RewriteEngine diag Failure |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: * | Symptom:- protocol timeouts such as LACP, UDLD, etc... - RewriteEngineLoopback test failing for the M2 modules, such as:
%DIAG_PORT_LB-2-REWRITE_ENGINE_LOOPBACK_TEST_FAIL: Module:4 Test:RewriteEngine Loopback failed 10 consecutive times. Faulty module:Module 1 Error:Loopback test failed. Packets lost on the SUP in the transmit direction
- MC Buffer Hang exception slot show logging onboard internal qengine (where x is m2 module) ---- snip ---- __SKT_EEM_POLICY_SINGLE_LOG_ERR, egr ed: sch mc buffer hang [ED_SCH_MC_BUFFER_HANG]
Conditions:Current Known Conditions:
- M2 module in proxy VDC with F-series module. - varying dscp values - traffic ingress and egress on the M2 front-panel ports, as well as proxy traffic being serviced by the same M2 linecard.
Workaround:Module reload will clear the issue but one can still be exposed to hitting this condition again. Please contact TAC for workaround options.
More Info:
|
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(14) |
|
Known Fixed Releases: | 6.2(16)S39 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsv35775 | Title: | aclqos crash @ aclqos_tcam_resource_alloc while attaching egress netflow |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * |
Symptom: AclQos process crash on the line card.
Conditions:
When there is a large number of egress RACL entries in the ACL TCAM, and you try to attach egress netflow was also applied, with non-atomic update enabled, ACLQos may crash, and the policies may not be applied.
Workaround:
No workaround.
Further Problem Description:
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 4.0(4) |
|
Known Fixed Releases: * | 4.1(1.61), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn32477 | Title: | N7K/5.1: Configuration not applied in default VDC |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When attempting to change the layer of a L3 port that has sub-interfaces, the switch hangs and the following output is observed. The command is not executed successfully.
switch(config)# int ethernet 1/3 switch(config-if)# no shut Please check if command was successful using appropriate show commands switch(config-if)#
switch# sh int e1/3 Ethernet1/3 is down (Administratively down)
Conditions:
Nexus7000 running 5.x releases and "switchport" command is executed on an L3 port containing sub-intefaces
Workaround:
Switchover can be used as a workaround. To avoid this issue after switchover, we need to NOT change the layer of a L3 port containing sub-interfaces to L2. Instead first remove the sub-intefaces using the no int command before changing the layer.
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: * | 4.2(8)S9, 4.2(8.25)S0, 5.1(10.1)S0, 5.1(3)S28, 5.2(0.241)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt25022 | Title: | Mac address is not learning properly when port security enabled in AIDA |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Mac address is not learning properly when port security enabled in AIDA card.
Conditions:
Issue is seen only in AIDA card. Workaround:
No Workaround. |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 6.0(1)S6 |
|
Known Fixed Releases: * | 6.0(1)S24, 6.1(0.118)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx91886 | Title: | AUTODROMO 100: SYSMGR-2-SERVICE_CRASHED: Service "ifmgr" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Sysmgr crashed @ifmgr with version 6.1(0.209)S0
Conditions: Cores observed after successful addition and deletion of member ports in LACP channel.
Workaround: not known |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: * | 6.1(0.209)S0 |
|
Known Fixed Releases: * | 6.1(0.211)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtu30632 | Title: | L2FM crash @ cmd_rx_handle_validate |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: SUP crash due to l2fm crash
Conditions: 5.2.x & 5.1.3
Workaround: none |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 5.2(0) |
|
Known Fixed Releases: * | 5.2(3)S9, 5.2(3.8)S0, 6.0(2)S12, 6.1(0.151)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz33968 | Title: | FEX Goes Offline When Connected to F2 Module |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: A Nexus 7000 running 6.0(4) may experience a connected FEX going offline when one of two redundant links are shut down. In some instances, a FEX may fail to come online at all when connected to a F2 module.
Conditions: This issue has been seen with a N2K-C2232PP-10GE that has redundant links, connected to two separate F2 modules.
The following debugs are logged with 'debug fex error' during the issue:
2012 Sep 17 21:28:15 N7K-FEX %$ VDC-2 %$ %FEX-2-FEX_OFFLINE: FEX 199 has gone OFFLINE 2012 Sep 17 21:28:15 N7K-FEX %$ VDC-2 %$ %FEX-2-NOHMS_ENV_FEX_OFFLINE: FEX-199 Off-line (Serial Number JAF1518BGJD) 2012 Sep 17 21:28:15.057191 fex: satmgr_n7k_veobc_delete Unable to delete Pi for Veobc from ifndex 0x1a114000 2012 Sep 17 21:28:15.057217 fex: satmgr_n7k_act_fport_failover: no control port for slot 131 of port 0x1a114000 2012 Sep 17 21:28:15.064934 fex: Invalid mapped slot no:0 for slot:131 2012 Sep 17 21:28:15.066660 fex: Invalid mapped slot no:0 for slot:131 2012 Sep 17 21:28:16.044918 fex: satmgr_dequeue: (Error) SYSERR_FU_xx: 0x10, err_num (16) in fu_priority_select
Workaround: Reload the module in question. |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 6.0(3), 6.0(4) |
|
Known Fixed Releases: * | 5.2(8.1), 5.2(9), 6.1(0.268)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw70555 | Title: | Incorrect FEX LDB calculation on module 1 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Nexus 7000 with FEX modules connected to an M132 module in slot 1 may incorrectly experience LIF exhaustion. The switch log will report a failure to allocate LIF entries: %ELTMC-SLOT1-2-ELTMC_L2_LIF_ALLOC_FAIL_INTF: Failed to allocate L2 LIF entries in forwarding engine for interfac Ethernet
Conditions: The problem occurs only when the FEXes are connected to module 1 on the Nexus 7000.
Workaround: Connect the FEX modules to any M132 not in slot 1 or move the M132 from slot 1 to another slot. |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 5.2(1)S89 |
|
Known Fixed Releases: * | 5.2(3)S21, 5.2(3.21)S0, 6.0(2)S18, 6.1(0.161)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx25326 | Title: | NetApp - N7K appears to be dropping frames from target to host |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:After upgrade from a version less than 5.2(4) to a version greater than 6.x or downgrade in the reverse direction, PSS restore can fail leading to aclqos process crash or traffic drops. Conditions:Upgrade from an image version (strictly) less than 5.2(4) to a version greater than 6.x. Downgrade from a version greater than 6.x to a version (strictly) less than 5.2(4) Workaround:Upgrade (or downgrade) in steps from 5.2(x) to 5.2(4) to 6.x
|
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 5.2(5)S4, 6.0(1), 6.1(1) |
|
Known Fixed Releases: * | 6.1(0.263)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw78172 | Title: | Dont_learn not set on peer link |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Macs learnt on peer_link of M1 linecards.
Conditions: When the switch has multiple vdc's and on one vdc VPC is configured and another vdc VPC (emulated vpc) is configured, then DONOT learn on peer_link is not set in port asic for M1 Linecards. This causes packets coming in from peer link to be learnt by hardware.
Workaround(s): Removing emulated switch config from the switch will restore the correct behavior. 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: | 21-FEB-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(3)S24, 5.2(3.25)S0, 6.0(2)S21, 6.1(0.165)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw98574 | Title: | PIXMC cores upon mcast traffic on F2 ports |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom: On F2 module, we have 32 receivers on the same vlan joining same number of mcast group. And the aggregated mcast traffic is about 4.8Gbps.
The traffic can run for few minutes, then it got PIXMC core, and all mcast traffic could not be forwarded anymore. Conditions: none Workaround: None |
|
Last Modified: | 22-FEB-2016 |
|
Known Affected Releases: | 6.0(1) |
|
Known Fixed Releases: * | 6.0(2)S29, 6.1(0.174)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj48042 | Title: | N7K-OFF-DIAG:Sup 2:spine_diagdsp falure w. BIOS v.2.12 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: a
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 7.0(0)FR(0.5) |
|
Known Fixed Releases: * | 6.2(0)HS(0.10), 6.2(10)FM(0.3), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(0)KM(0.64), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut25162 | Title: | VPLS VC's don't come after delete/add VFI's in EFP scale setup |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Few VPLS PW's remain down
Conditions: With L2VPN VFI's scaled, delete all VFIs and Re-add all VFI's.
Workaround: clear l2vpn service vfi all
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.422), 7.2(0)D1(0.430) |
|
Known Fixed Releases: * | 15.5(1)S0.17, 15.5(1)S1.1, 15.5(1)S2, 15.5(1)S2.1, 15.5(1)S2.15, 15.6(0.16)S, 15.6(0.17)PI30d, 15.6(0.25)T, 15.6(1)SN, 15.6(1.1)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug67177 | Title: | Flanker: Repeated ipfib process crash brought module to Failure state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: multiple ipfib process crash leading to module in failure state.
Conditions: Initially configured Flanker ports as L3 ports, later checked route commands on both SUP and module . Observed ipfib crash followed by sync loss on the module after issuing "default interface e6/5" ,. Module went in to Failure state after this.
Workaround: None
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 7.0(0)FT(0.71) |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)FT(0.79), 7.3(0)DX(0.4), 7.3(0)EG(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut72659 | Title: | SSH connection failure with 'no matching cipher found ' syslog |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom: SSH connections initiated form the device fails with the below syslog
switch# ssh admin@10.196.98.73 vrf management no matching cipher found: client aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr switch#
Upon failed ssh connections connection, similar syslog is reported at the server also.
switch(config)# e2015 Mar 9 10:03:55 $ VDC-1 %$ %DAEMON-2-SYSTEM_MSG: fatal: no matching cipher found: client aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr - dcos_sshd[18259]
Conditions: The issue occurs only if the server does not support any CBC ciphers.
Workaround: The workaround is to add the client CBC ciphers in sshd_config/dcos_sshd_config file of the server to re-enable them, so that there will be matching ciphers. Edit the following files in the server from Linux prompt: /isan/etc/dcos_sshd_config + # Secure Ciphers and MACs + Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
/isan/etc/sshd_config + # Secure Ciphers and MACs + Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
Further Problem Description: Fix Description ================= As per openssh6.7 code, FIPS-approved ciphers are the following: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
For NXOS SSH client, ctr ciphers were not enabled by default on FIPs mode. Fixed the issue by setting the FIPS mode flag for ctr ciphers.
On Nexus 7000 this problem can manifest itself also in the following way: can not attach to rise nam from sup
N7K-6# attach rise slot 332 Attaching to RISE 332 ... Username:root no matching cipher found: client \ aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc server \ aes128-ctr,aes192-ctr,aes256-ctr N7K-6#
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.2(13)FM(0.66), 6.2(13)S12, 7.2(0)D1(0.430), 7.2(0)D1(0.451) |
|
Known Fixed Releases: | 5.2(8g), 5.2(8g)S9, 6.2(13), 6.2(13)S15, 6.2(13.501)S0, 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.0(0)KMS(0.11), 7.1(0)AV(0.81) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh67765 | Title: | F3:: MTM crash after system reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 7.0(0)FT(0.116) |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)FT(0.118), 7.0(0)FT(0.121), 7.1(0)D1(0.14), 7.2(0)D1(1), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo86388 | Title: | NXOS-VPC-VPLS Scale-after Core LC OIR,subset of PW Remain in Down state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: In a setup with scaled VFI's & PW's, some PW's may not come up.
Conditions: Line Card OIR
Workaround: clear l2vpn service all
Further Problem Description:
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 7.1(0)ZD(0.181) |
|
Known Fixed Releases: * | 15.4(3)M2.1, 15.4(3)M3, 15.4(3)M3.1, 15.4(3)S0.7, 15.4(3)S1, 15.4(3)S2, 15.4(3)SN1a, 15.5(0.18)S0.8, 15.5(1)S, 15.5(1)SN |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun50901 | Title: | Service (FEX) "satctrl" (PID 1723) hasn't caught signal 9 (no core) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: N7K FEXs might crash with below errors without save core dump
2014 Mar 3 08:18:25 DALS_SW1_C7009_MDF-Production SYSMGR-FEX109-3-BASIC_TRACE core_copy: PID 1476 with message Core not generated by system for satctrl(0). WCOREDUMP(9) returned zero . 2014 Mar 3 08:18:25 DALS_SW1_C7009_MDF-Production SYSMGR-FEX109-2-SERVICE_CRASHED Service (FEX) "satctrl" (PID 1723) hasn't caught signal 9 (no core). 2014 Mar 3 08:18:25 DALS_SW1_C7009_MDF-Production SYSMGR-FEX109-2-HAP_FAILURE_SUP_RESET System reset due to service "satctrl" in vdc 1 has had a hap failure
Conditions: normal operation but signal 9 might be related to memory leak. memleak would be a separate issue and need root cause to confirm.
Workaround: unknown at this time
Further Problem Description:
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 6.2(0)FH(0.152), 6.2(0)HS(0.10), 6.2(10), 6.2(10)EC(0.23), 6.2(10)FM(0.20), 6.2(10)NO(0.19), 6.2(8), 6.2(8)S16, 6.2(8.3)S0, 6.2(9)FM(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur14589 | Title: | vulnerability related to cmd injection via DHCP offer options |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Command injection via DHCP offer options used with PowerOn Auto Provisioning (POAP)
Conditions: NX-OS Switch would have to be in a state where POAP is initiated, and if an attacker can either: A) Inject their own DHCP server and respond to the POAP DHCP request with crafted DHCP options. B) Compromise an existing DHCP server, and craft the specific DHCP options.
Then during the POAP process, when the crafted DHCP options are processed arbitrary commands on the system could be executed in the context of root user.
Note this issue only occurs during the POAP DHCP boot process.
First Fixed Releases: 6.2(10) 7.1(0)N1(1) 7.1(2)N1(1) 7.2(0)N1(1)
Workaround: None.
More Info:
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 6.8/5.3: http://tools.cisco.com/security/center/cvssCalculator.x?vector=&version=2.0 patch=1&version=2&vector=AV:A/AC:H/Au:N/C:C/I:C/A:C/E:POC/RL:OF/RC:C
CVE ID CVE-2015-0658 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: | 24-FEB-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.226), 7.3(0.2) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S98, 6.2(10.17)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.291), 7.1(0)D1(0.292), 7.1(0)D1(0.293), 7.1(0)EV(0.116) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua43329 | Title: | N7k - sysmgr crash - Service (FEX) "lacp" without core file generated |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: A Nexus 2000 may crash when is receives a PDU larger than it expects. Conditions: This sill only be seen on a Nexus 2000 connected to a Nexus 7000. Nexus 2000 connected to Nexus 5000 are not effected. Workaround: None at this time.
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 6.0(1) |
|
Known Fixed Releases: * | 5.2(4)FD(0.21), 5.2(6.7)S0, 5.2(7), 6.1(0)FE(0.17), 6.1(1)S21, 6.1(1.20)S0, 7.0(2)FIP(0.4), 7.1(0)FGI(0.3), 7.3(0)FH(0.2), 7.3(0)FXK(0.12) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw98364 | Title: | F3: OTV broadcast/smac route PSSing wrong inst bitmap for tcam |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom: Broadcast packets in OTV environment can experience mis-forwarding such as drops or loops.
Conditions: The problem can happen in 6.2.14 and earlier if there is IPFIB restart or ISSU. Here is an example of a scenario.
1) In 6.2.10, broadcast route is inserted in inst 0. Inst_bitmap = 0x1. 2) There is inst bitmap update which will add the the broadcast route to inst 1. The correct bitmap is 0x3 but we PSSed bitmap 0x2. 3) ISSU to 6.2.12 or ipfib is restarted. FIB recovers bitmap 0x2 for broadcast route. 4) Broadcast route is deleted due Overlay down for example. FIB will only delete the broadcast route from inst 1. There is stale entry in inst 0. 5) Overlay comes up and broadcast route is added back again. However, on inst 0, we will have 2 entries. Let's say that the new entry is programmed at lower priority. Packets will hit the stale entry resulting in misforwarding. If new entry is programmed at higher priority, then there is no misforwarding but the stale entry is still there.
Workaround: Reload the modules with the stale entries.
Further Problem Description:
|
|
Last Modified: | 25-FEB-2016 |
|
Known Affected Releases: * | 6.2(16)S32, 7.3(0)D1(0.137) |
|
Known Fixed Releases: | 6.2(16)S10, 6.2(16)S29, 7.2(2)D1(0.16), 7.2(2)ZD(0.20), 7.3(0)D1(0.173), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.122), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu83574 | Title: | Error in syslog of interface flap event after reload in remote server |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: This can occur when logging source interface loopback is configured with ipv6 address and logging server is configured.
Conditions: This issue occurs in certain conditions when ipv6 address configured on loopback being used as logging source interface is in compact form: ex: 1::1/64
Workaround: Reconfigure the logging source interface with the loopback interface after reload.
Further Problem Description:
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 6.2(16)S32, 7.2(0)D1(1), 7.3(0)D1(0.86) |
|
Known Fixed Releases: * | 6.2(16)S40, 7.2(1)D1(0.5), 7.2(1)D1(1), 7.2(1)N1(0.239), 7.2(1)N1(1), 7.2(1)ZD(0.5), 7.2(1)ZN(0.5), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus77706 | Title: | Phy vpc: Can't bring up 2 orphan ports in I mode |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom: PXE boot servers won't work with phy. port vPC.
Conditions: PXE boot servers won't work with phy. port vPC.
Workaround: There is no workaround.
Further Problem Description:
|
|
Last Modified: | 25-FEB-2016 |
|
Known Affected Releases: * | 7.2(0)D1(0.390), 7.3(0)DX(0.87) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DX(0.64), 7.3(0)DX(0.73), 7.3(0)DX(0.88), 7.3(0)DX(0.96) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy17164 | Title: | 7.3(0)D1(1)S11 - observing ipfib core while running OTV regression |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Core in IPFIB and possible traffic lost for OTV broadcast traffic.
Conditions: OTV setup with F3 based LCs. The problem may happen if configuring OTV and extending VLAN which does not have any member port.
Workaround: In order to avoid hitting this issue, always make sure VLAN and vlan member ports are up before extending the vlan over the overlay.
Further Problem Description:
|
|
Last Modified: | 25-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)D1(1), 7.3(0)DX(0.89), 7.3(1)D1(0.7), 7.3(1)D1(0.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw95078 | Title: | M2 VLAN Translation Missing after Module Reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Traffic loss for VLAN translated flows crossing M2 module after recent module reload or possible link flap on M2 module ports with VLAN mapping configured.
Conditions: Noticed on M2 module, symptoms do not match other M2 VLAN translation defects, seen after module reload.
Workaround: Only current know workaround is to rebuild the port-channel configuration (delete port-channel, default member interfaces, reconfigure).
Further Problem Description: Example of missing translations in hardware:
interface Ethernet3/7 switchport switchport mode trunk switchport vlan mapping 499 500 switchport trunk allowed vlan 190-200,500 mtu 9216 channel-group 3 mode active no shutdown
module-3# show system internal eltmc info interface ethernet 3/7 vdc 4 | no ELTM Detailed info for Interface Ethernet3/7 vlan_xlt_tlb_en_egress : 1 vlan_xlt_tlb_en_ingress: 1 num_vlan_xlt_entries : 2 num_m2_ingress_vlan_xlt_entries : 0 num_m2_egress_vlan_xlt_entries : 0
Vlan Translation Table -------------------------------- dir tbl_idx in_vlan xlt_vlan <---- Missing translations
Correct table would show:
Vlan Translation Table -------------------------------- dir tbl_idx in_vlan xlt_vlan IG 0 499 500 EG 0 500 499
|
|
Last Modified: | 25-FEB-2016 |
|
Known Affected Releases: * | 6.2(14), 6.2(8b), 7.2(0)D1(1) |
|
Known Fixed Releases: | 6.2(14)E1, 6.2(16)S1, 7.2(2)D1(0.3), 7.2(2)ZD(0.1), 7.3(0)D1(0.162), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.103), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux67524 | Title: | FEX struck in Unknown state after delete FEX and System switchover |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Doing a switchover immediately after FEX delete without waiting for FEX to go offline results in FEX stuck in unknown state after switchover.
Conditions: Doing a switchover immediately after FEX delete without waiting for FEX to go offline.
Workaround: Need to wait for the FEX to be completely removed after FEX deletion before doing a switchover.
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.186) |
|
Known Fixed Releases: * | 7.3(0)D1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.233), 7.3(1)D1(0.1), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw73046 | Title: | Vinci MT-full L2 extension on Borderleaf requires configuration of BDI |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Flood entry missed in the vinci case if there is NO forwarding mode configured which might cause traffic halt.
Conditions: Unknown traffic drop.
Workaround: Need to declare the bd as dfa/vinci-capable. This can be done via creation of a bdi with either in ef/tf mode
interface bdi 3101 fabric forwarding mode anycast-gateway
Once this is done, we should be able to see end-to-end traffic with L2.
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.475), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.169), 7.3(0)D1(0.181), 7.3(0)D1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.199), 7.3(1)D1(0.6), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup22563 | Title: | Vulnerabilities in OpenSSL: LDAP over SSL |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: The following Cisco products
Cisco Nexus 7000 series switches Cisco MDS 9000 series switches
running software versions: 7.1(0), 6.2(8), 6.2(7), 5.2(8d)
are affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-0076 - Fix for the attack described in the paper "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack" CVE-2014-0195 - DTLS invalid fragment vulnerability CVE-2014-0221 - DTLS recursion flaw CVE-2014-0224 - SSL/TLS MITM vulnerability CVE-2014-3470 - Anonymous ECDH denial of service
This bug has been opened to address the potential impact on this product. The above list of versions are not exhaustive.
Conditions: Devices using LDAP in SSL mode, say, the ones with the following command may be vulnerable:
ldap-server host {ipv4-address | ipv6-address | host-name} [enable-ssl]
All versions prior to the first fixed version of a train are affected by one or more of the above CVE's.
Workaround: Not available. Either a patch has to be applied or the entire package has to be upgraded.
Further Problem Description: 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 10/9.5:
https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 5.2(8d), 6.2(7), 6.2(8) |
|
Known Fixed Releases: * | 5.2(8e), 5.2(8e)S4, 6.2(10), 6.2(10)S79, 6.2(10)S80, 6.2(10.16)S0, 6.2(12)BFP(0.8), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu89118 | Title: | N7K - ipqosmgr core when "show tech ipqos" on other vdc |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: N7K - ipqosmgr core when "show tech-support binary all" on other vdc
Conditions: We are not sure on the exact binary option that is triggered automatically by another core, but manually these 3 options with 'show tech-support binary all' which might trigger this core
N7K-83-64_abcdefghij123456789-64# show tech-support all binary ? bootflash: Select destination filesystem to save the binary output (NOTE: The output file name will be automatically generated and cannot be chosen) logflash: Select destination filesystem to save the binary output (NOTE: The output file name will be automatically generated and cannot be chosen) slot0: Select destination filesystem to save the binary output (NOTE: The output file name will be automatically generated and cannot be chosen) N7K-83-64_abcdefghij123456789-64#
When this problem was first seen, it was triggered by a different and non-related core. During the gathering stage of the other non-related core, that core issued the "show tech-support all binary ..." command. This means that the command does not need to be manually issued for ipqosmgr to core and does occur automatically from a different core even on a different vdc.
Workaround: No work around as such, but system should recover back after this crash.
Further Problem Description: When this problem was first seen, it was triggered by a different and non-related core. During the gathering stage of the other non-related core, that core issued the "show tech-support all binary ..." command. This means that the command does not need to be manually issued for ipqosmgr to core and does occur automatically from a different core even on a different vdc.
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1), 7.2(1)D1(0.96), 7.2(1)D1(1), 7.3(0)D1(0.24) |
|
Known Fixed Releases: * | 7.3(0)D1(0.146), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)PDB(0.112), 7.3(0)SC(0.14), 7.3(0)ZD(0.163), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv75088 | Title: | Phyport vPC with Esxi does not come up thr FEX |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Phyport vPC with Esxi does not come up thr FEX
Conditions: When trying to bring up phyport vPC thr FEX
Workaround: None
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.0(2)FIP(0.55), 7.2(1)D1(0.62), 7.2(1)D1(0.63), 7.2(1)D1(1), 7.2(1)ZD(0.54), 7.2(1)ZD(0.56), 7.3(0)D1(0.81), 7.3(0)D1(1), 7.3(0)DX(0.16) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw96276 | Title: | CVE-2013-4548 Vulnerability Nexus 7000 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Cisco Nexus 7000 (N7K) Series Switch includes a version of the Open Secure Host (OpenSSH) protocol that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2013-4548
This bug was opened to address the potential impact on this product.
Conditions: Device with default configuration.
Workaround: As a workaround, customers may disable AES-GCM in the SSH client configuration. The following sshd_config option will disable AES-GCM while leaving other ciphers active:
Ciphers aes128-ctr, aes192-ctr, aes256-ctr, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aes256-cbc.
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 6/5.7: http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:M/Au:S/C:P/I:P/A:P/E:F/RL:U/RC:C&version=2.0 CVE ID CVE-2013-4548 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: | 29-FEB-2016 |
|
Known Affected Releases: | 5.2(8), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(15)S10, 7.3(0)D1(0.147), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IZN(0.13), 7.3(0)N1(0.196), 7.3(0)N1(1), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)RTG(0.115) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv64056 | Title: | N7K/N77 support NX-OS mechanism to upgrade firmware on eUSB flash |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Over a period of several months or years, eUSB flash goes unresponsive. When the first flash fails GOLD's CF test report fails. At a later point in time,the boot-flash mounted will go to a state of read-only causing configuration copy to fail.
Conditions: This happens after several months of system being in use.
Workaround: 6.2.14 has a plugin Load the plugin on the active, which will attempt to repair single flash failures on both active and standby. Double flash failures cannot be repaired; a reload of the affected sup is needed for that.
Further Problem Description: kickstart images for 7.2(1)D1(1) and 7.3 have the eUSB firmware upgrade solution which is more than a workaround. Kickstart images will upgrade the firmware for the eUSB bootflash and eUSB obfl from Unigen vendor if the eUSB is responding at time of the firmware upgrade. The solution in CSCuv64056 is available for both N77 and N7K. This N77 and N7K solution in CSCuv64056 is unlike CSCus22805 which is only a workaround for N7K and does not help with N77.
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(13.16), 6.2(14), 6.2(14)FB(0.49), 7.2(0)D1(1), 7.2(1)D1(0.32), 7.3(0)D1(0.53) |
|
Known Fixed Releases: * | 6.2(14)E1, 6.2(14.4)S0, 6.2(16)S1, 7.2(1)D1(0.90), 7.2(1)D1(1), 7.2(1)ZD(0.81), 7.3(0)D1(0.120), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)IB(0.90) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw39581 | Title: | OSPF sessions flap seen when scaled upto 1000 sessions. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: OSPF session flap continuously when configured in 1000 sub-interfaces between 2 routers back to back.
Conditions: OSPF running in 1000 sub-interfaces between 2 routers back to back:
Box bring up. Interface flap. Reload.
Workaround: "timers throttle lsa 50 5000 15000" in router ospf mode.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.2(1)D1(0.82), 7.3(0)D1(0.98) |
|
Known Fixed Releases: * | 7.2(1)D1(1), 7.2(1)ZD(0.101), 7.2(1)ZN(0.95), 7.2(2)D1(0.2), 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.87), 7.3(0)N1(1), 7.3(0)PDB(0.112) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv71201 | Title: | Evaluation of n7k-infra for OpenSSL June and July 2015 Vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms: This product includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-4000, CVE-2015-1788, CVE-2015-1789, CVE-2015-1790, CVE-2015-1792, CVE-2015-1791, CVE-2014-8176
This bug has been opened to address the potential impact on this product.
Conditions:
Workaround:
Further Problem Description:
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: 7.8/6.4
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html |
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 5.2(8g), 5.2(9), 6.2(1), 6.2(11), 6.2(12), 6.2(13), 6.2(2), 7.3(0)ZD(0.60) |
|
Known Fixed Releases: * | 6.2(15)S3, 6.2(15)S4, 7.3(0)BZN(0.47), 7.3(0)D1(0.73), 7.3(0)D1(0.74), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)IB(0.67), 7.3(0)MMD(0.9), 7.3(0)N1(0.101) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw19605 | Title: | OAM session flaps when "link-monitor" cli is used |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Ethernet Link OAM sessions flap when entering configuration.
Conditions: Entering/exiting the eloam config mode causes the ELOAM process to stop sending the correct packets. This causes the session to flap. Once the session goes down, the packet to send is reevaluated and the session will come back up.
Workaround: None, but after the flap the session will come back up.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.88) |
|
Known Fixed Releases: * | 7.3(0)D1(0.99), 7.3(0)D1(1), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.74), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw65271 | Title: | OAM session goes down after applying trunk allowed vlan |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: ELOAM sessions do not come up on sessions with an allowed VLAN configured.
Also, ELOAM sessions do not come up on ports which are blocked by STP. A side effect of this is that when an interface is first configured as a switchport, it can take around 1 minute before the ELOAM session comes up.
Conditions: Any switchport interface running Ethernet Link OAM can be affected if STP blocks that port, or if the interface has "switchport trunk allowed vlan " config.
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.96) |
|
Known Fixed Releases: * | 7.3(0)D1(0.135), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.102), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv99977 | Title: | ARP reply not sent out on some FEX host ports |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Packets will get black holed in the HIF VPC Port-channel.
Conditions: Original bugfix on N5k CSCuv37294. RNE in this bug refer to RNE of the original bug. Issue seen on FEX 2248
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: Refer CSCuv37294 for more details
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(1A) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.0(2)FIP(0.83), 7.2(1)D1(0.91), 7.2(1)D1(0.93), 7.2(1)D1(1), 7.2(1)ZD(0.82), 7.2(1)ZD(0.83), 7.2(1)ZD(0.84), 7.3(0)D1(0.107), 7.3(0)D1(0.109) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw81299 | Title: | OAM session not coming up with F3-M2 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: ELOAM sessions do not come up on M2 linecards. Further, sessions may be incorrectly detected as miswired.
Conditions: ELOAM is configured on interfaces on an M2 linecard.
Workaround: None, but ELOAM works fine on F3 cards.
Further Problem Description: The problem occurs because metadata attached to received packets is incorrect, making it look as if ELOAMPDU packets were received on a different interface to that which they actually came in on.
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.127), 7.3(0.99) |
|
Known Fixed Releases: * | 7.3(0)D1(0.135), 7.3(0)D1(0.138), 7.3(0)D1(0.142), 7.3(0)D1(0.146), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)IB(0.122), 7.3(0)IZN(0.13), 7.3(0)N1(0.195), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv71568 | Title: | ELOAM Deamon unable to send heartbeats |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Syslog messages such as "%ELO_IO-SLOT2-6-CPU_STARVED: Ethernet Link OAM Daemon has been unable to send heartbeats for 1000 ms" appear on the console, emitted from linecards.
Conditions: Occurs intermittently when Ethernet Link OAM is configured on an interface.
Workaround(s): None.
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)DHB(0.21) |
|
Known Fixed Releases: * | 7.3(0)D1(0.99), 7.3(0)D1(1), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.74), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw16411 | Title: | HSRP state Active/Active after removing Anycast |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Nexus 5600 VPC+ peers will show Active/unknown for HSRP Active/standby states on both peers
N5k-1# sh hsrp br *:IPv6 group #:group belongs to a bundle P indicates configured to preempt. | Interface Grp Prio P State Active addr Standby addr Group addr # Vlan10 10 100 Active local 10.10.10.67 10.10.10.1 (conf) Vlan20 2 100 Active local unknown 20.20.20.1 (conf) <<<<<<<<<<
Conditions: Rolling back from HSRP Anycast to legacy HSRP on VPC+ peers. Seen only under following conditions
1)Bug is only seen if hsrp anycast <> ipv4 is configured and subsequently removed. 2)In addition ,one SVI on one vPC peer has to be shut after removing anycast configuration 2)Bug is not seen with same steps if "hsrp anycast <> both? is configured 3)Even if bug is seen, configuration for the group/vlan can be changed to "hsrp anycast <> both? and migrated to legacy HSRP without hitting the problem. 4)Problem not seen after migrating to legacy HSRP
Workaround: Change HSRP anycast configuration to include both IPv6 and IPv4 using command hsrp anycast <> both and then remove the anycast configuration.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.0(7)ZN(0.215) |
|
Known Fixed Releases: * | 7.1(3)N1(0.647), 7.1(3)N1(1), 7.1(3)ZN(0.55), 7.3(0)D1(0.112), 7.3(0)D1(1), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)IB(0.90), 7.3(0)IZN(0.7), 7.3(0)N1(0.150) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw50467 | Title: | F3 module drops to failure state after ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: After ISSU a LC drops to failure state. "sh system reset-reason module" lists the reason as "elo_io hap reset => [Failures < MAX] : powercycle"
Conditions: ELOAM must be configured and running on the LC while the ISSU occurs.
Workaround: Remove all ELOAM config before the ISSU and then reapply afterwards.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.112) |
|
Known Fixed Releases: * | 7.3(0)D1(0.122), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz59354 | Title: | cNTP ACL Does Not Continue Processing After Matching Deny Entry |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: When an NTP ACL is configured for "peer", "serve", "serve-only", or "query-only" and a deny ACE is matched, the other NTP options are not checked.
For example:
ntp access-list peer 10 ntp access-list serve 11
ip access-list 10 permit host 192.168.1.1 any ip access-list 10 deny ip any any
ip access-list 11 permit host 172.16.1.1 any
If the host matching ACL 11, 172.16.1.1, sends an NTP message it will be blocked by the "peer" ACL. However, it should be permitted by the "serve" ACL, but it is not.
Conditions: Multiple NTP ACLs configured.
Workaround: None
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 5.2(4), 6.1(3)S5, 6.1(3)S6, 6.2(1.121)S0, 7.2(1)D1(1), 7.3(0)ZN(0.161), 7.3(1)N1(0.1) |
|
Known Fixed Releases: * | 6.1(2.30)S0, 6.1(4.97)S0, 6.1(5), 6.1(5.32)S0, 6.2(0.285), 6.2(1.149)S0, 6.2(2), 7.0(0)ZD(0.84), 7.0(1)ZD(0.3), 7.0(3)I2(0.315) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus96878 | Title: | Nexus7700 FEX interface link flap with FET-10G |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Nexus7700 FEX interface may link flap with FET-10G
Conditions: Nexus7706 N77-F348XP-23 Nexus2232TM FET-10G NXOS 6.2.10
Workaround:
Further Problem Description:
|
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(14), 7.2(0)D1(1), 7.3(0)D1(0.45) |
|
Known Fixed Releases: * | 6.2(16)S34, 7.0(0)BZ(0.98), 7.0(2)FIP(0.126), 7.2(2)D1(0.11), 7.2(2)D1(0.12), 7.2(2)D1(0.14), 7.2(2)D1(0.15), 7.2(2)D1(0.16), 7.2(2)D1(0.17), 7.2(2)D1(0.18) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy51001 | Title: | service is not responding communicating with MTS_SAP_ETH_PORT_CHANNE |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom: service is not responding communicating with MTS_SAP_ETH_PORT_CHANNE , while allocating interfaces for default vdc following error occurred ,
<> 6.2(16) 1.2 india30(config-vdc)# vdc india30 india30(config-vdc)# allocate interface ethernet 1/1-32 Moving ports will cause all config associated to them in source vdc to be removed. Are you sure you want to move the ports (y/n)? [yes] yes 2016 Feb 18 14:06:16 india30-vdc_2 %$ VDC-2 %$ %ETHPORT-2-IF_SEQ_ERROR: Error ("required
Conditions: service is not responding communicating with MTS_SAP_ETH_PORT_CHANNE , while allocating interfaces for default vdc following error occurred ,
<> 6.2(16) 1.2 india30(config-vdc)# vdc india30 india30(config-vdc)# allocate interface ethernet 1/1-32 Moving ports will cause all config associated to them in source vdc to be removed. Are you sure you want to move the ports (y/n)? [yes] yes 2016 Feb 18 14:06:16 india30-vdc_2 %$ VDC-2 %$ %ETHPORT-2-IF_SEQ_ERROR: Error ("required
Workaround: service is not responding communicating with MTS_SAP_ETH_PORT_CHANNE , while allocating interfaces for default vdc following error occurred ,
<> 6.2(16) 1.2 india30(config-vdc)# vdc india30 india30(config-vdc)# allocate interface ethernet 1/1-32 Moving ports will cause all config associated to them in source vdc to be removed. Are you sure you want to move the ports (y/n)? [yes] yes 2016 Feb 18 14:06:16 india30-vdc_2 %$ VDC-2 %$ %ETHPORT-2-IF_SEQ_ERROR: Error ("required
Further Problem Description: service is not responding communicating with MTS_SAP_ETH_PORT_CHANNE , while allocating interfaces for default vdc following error occurred ,
<> 6.2(16) 1.2 india30(config-vdc)# vdc india30 india30(config-vdc)# allocate interface ethernet 1/1-32 Moving ports will cause all config associated to them in source vdc to be removed. Are you sure you want to move the ports (y/n)? [yes] yes 2016 Feb 18 14:06:16 india30-vdc_2 %$ VDC-2 %$ %ETHPORT-2-IF_SEQ_ERROR: Error ("required
|
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(16)S40 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy51650 | Title: | iscm cores for vdc deletion |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom: iscm cores for vdc deletion ,
bld type is :: /auto/andfreetown/REL_6_2_16_S40 Core was generated by `/isan/bin/iscm'. Program terminated with signal 6, Aborted. [New process 17360] #0 0x455fc3d8 in wait () from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0 #0 0x455fc3d8 in wait () from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0 #1 0x082e4115 in push_nice_configuration (cfg_file_name=0x839bdf5 "/tmp/itd_no_cfg_file") at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:2672 #2 0x082ec977 in iscm_svc_nice_clear_config (svc_ent=0x8fd99e0) at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:1043 #3 0x0823b5f0 in iscm_mts_fm_handler (event=0x8fb7040, ret_fsm_event_list=0xffb5f568) at ../feature/iscm/server/rise/iscm_rise_msg_handlers.c:1412 #4 0x080fe939 in iscm_demux (event=0x8fb7040, ret_fsm_event_list=0xffb5f568) at ../feature/iscm/server/iscm_fu.c:3112 #5 0xf676e273 in fu_fsm_engine_process_app_ev (event=0x8fb7040, new_ev=0x8fb70f0, fsm_event_list_ref=0xffb5f568, demux_ev_ref=0xffb5f564) at ../utils/fsmutils/fsm.c:2431 #6 0xf677d83d in fu_fsm_engine () at ../utils/fsmutils/fsm.c:2782 #7 0x081147b9 in main (argc=, argv=) at ../feature/iscm/server/iscm_main.c:393 warning: .dynamic section for "/ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/isan/lib/libsse_common.so" is not at the expected address All.Done.
Conditions: iscm cores for vdc deletion ,
bld type is :: /auto/andfreetown/REL_6_2_16_S40 Core was generated by `/isan/bin/iscm'. Program terminated with signal 6, Aborted. [New process 17360] #0 0x455fc3d8 in wait () from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0 #0 0x455fc3d8 in wait () from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0 #1 0x082e4115 in push_nice_configuration (cfg_file_name=0x839bdf5 "/tmp/itd_no_cfg_file") at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:2672 #2 0x082ec977 in iscm_svc_nice_clear_config (svc_ent=0x8fd99e0) at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:1043 #3 0x0823b5f0 in iscm_mts_fm_handler (event=0x8fb7040, ret_fsm_event_list=0xffb5f568) at ../feature/iscm/server/rise/iscm_rise_msg_handlers.c:1412 #4 0x080fe939 in iscm_demux (event=0x8fb7040, ret_fsm_event_list=0xffb5f568) at ../feature/iscm/server/iscm_fu.c:3112 #5 0xf676e273 in fu_fsm_engine_process_app_ev (event=0x8fb7040, new_ev=0x8fb70f0, fsm_event_list_ref=0xffb5f568, demux_ev_ref=0xffb5f564) at ../utils/fsmutils/fsm.c:2431 #6 0xf677d83d in fu_fsm_engine () at ../utils/fsmutils/fsm.c:2782 #7 0x081147b9 in main (argc=, argv=) at ../feature/iscm/server/iscm_main.c:393 warning: .dynamic section for "/ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/isan/lib/libsse_common.so" is not at the expected address All.Done.
Workaround: iscm cores for vdc deletion ,
bld type is :: /auto/andfreetown/REL_6_2_16_S40 Core was generated by `/isan/bin/iscm'. Program terminated with signal 6, Aborted. [New process 17360] #0 0x455fc3d8 in wait () from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0 #0 0x455fc3d8 in wait () from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0 #1 0x082e4115 in push_nice_configuration (cfg_file_name=0x839bdf5 "/tmp/itd_no_cfg_file") at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:2672 #2 0x082ec977 in iscm_svc_nice_clear_config (svc_ent=0x8fd99e0) at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:1043 #3 0x0823b5f0 in iscm_mts_fm_handler (event=0x8fb7040, ret_fsm_event_list=0xffb5f568) at ../f |
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(16)S40 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy51156 | Title: | Port stuck in authorization pending state after link flaps |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom: On nexus 7000/7700 series, a port configured with cts macsec encryption may be stuck in authorization pending state after link flaps. The port will pass traffic if cts is removed.
Conditions:
Workaround: A module reload clears the issue
Further Problem Description: |
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus97380 | Title: | plcmgr crash during OpenFlow extended sanity |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Crash in plcmgr.
Conditions: Occurs sometimes during addition of OpenFlow matches to end of policy.
Workaround: None known.
Further Problem Description:
|
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.402) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.1(0)ES(0.5), 7.3(0)D1(0.86), 7.3(0)D1(1), 7.3(0)DHB(0.32), 7.3(0)DX(0.16), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.37), 7.3(0)PDB(0.57) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy50170 | Title: * | after Lc reload %URIB-3-NO_L3VM_INFO_ERROR: urib [8922] no L3VM |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom: URIB error while allocating routed ports , refer to accounting logs for steps ,
%URIB-3-NO_L3VM_INFO_ERROR: urib [8922] no L3VM
Conditions: URIB error while allocating routed ports , refer to accounting logs for steps ,
%URIB-3-NO_L3VM_INFO_ERROR: urib [8922] no L3VM
Workaround: URIB error while allocating routed ports , refer to accounting logs for steps ,
%URIB-3-NO_L3VM_INFO_ERROR: urib [8922] no L3VM
Further Problem Description: URIB error while allocating routed ports , refer to accounting logs for steps ,
%URIB-3-NO_L3VM_INFO_ERROR: urib [8922] no L3VM
|
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(16)S38 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy51803 | Title: | otm cores found after switchover and powerup of Lc |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom: otm cores found after switchover and powerup of Lc,
#0 0xf68e7f92 in syscall () from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6 #0 0xf68e7f92 in syscall () from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6 #1 0xf6f45f12 in os_syscall_ioctl (fd=11, request=-2143204091, arg=0xffd3e95f) at ../routing-sw/routing/tcpudp/clt/os_syscalls.c:70 #2 0xf6f35bcd in ioctl (desc=11, req=2151763205) at ../routing-sw/routing/tcpudp/clt/tcp_api.c:5185 #3 0xf70d7865 in mts_recv (q=11, this_msg=0xffd3ecca, options=0xffd3eca0) at ../infra/mts/lib/libmts.c:1883 #4 0xf676054d in fu_mts_recv (q=11, this_msg=0xffd3ecca, options=0xffd3eca0) at ../utils/fsmutils/fsm.c:6514 #5 0xf6965aac in sla_api_query_stats (clnt_q_mts=11, probeid=10136, stats=0xffd3ef50) at ../feature/sla/nxos/public/lib/sla_api.c:281 #6 0x0806ebf6 in otm_check_ipsla_object_state (obj_node=0x876ea30, state=0xffd3f1c8) at ../infra/track/server/otm_ipsla.c:346 #7 0x080693e4 in otm_track_ipsla_object (obj_node=0x876ea30, vdc_id=0) at ../infra/track/server/otm_track.c:91 #8 0x080626d6 in otm_create_object_node (vdc_id=0, object_id=136, otm_rec=0x8729f84, obj_inst=0xffd3fc8c, restart=1) at ../infra/track/server/otm_util.c:806 #9 0x08075fc5 in otm_restore_config (pss_runtime_config=141172496, version=0, pss_runtime_info=141122256) at ../infra/track/server/otm_restore_pss_data.c:319 #10 0x080769ab in fu_cb_restore_pss_data (arg=0xffd4015c) at ../infra/track/server/otm_restore_pss_data.c:94 #11 0xf67a9b2d in fu_restore_pss_data (cb_vdc_id=4, call_application_restore=1) at
Conditions: otm cores found after switchover and powerup of Lc,
#0 0xf68e7f92 in syscall () from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6 #0 0xf68e7f92 in syscall () from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6 #1 0xf6f45f12 in os_syscall_ioctl (fd=11, request=-2143204091, arg=0xffd3e95f) at ../routing-sw/routing/tcpudp/clt/os_syscalls.c:70 #2 0xf6f35bcd in ioctl (desc=11, req=2151763205) at ../routing-sw/routing/tcpudp/clt/tcp_api.c:5185 #3 0xf70d7865 in mts_recv (q=11, this_msg=0xffd3ecca, options=0xffd3eca0) at ../infra/mts/lib/libmts.c:1883 #4 0xf676054d in fu_mts_recv (q=11, this_msg=0xffd3ecca, options=0xffd3eca0) at ../utils/fsmutils/fsm.c:6514 #5 0xf6965aac in sla_api_query_stats (clnt_q_mts=11, probeid=10136, stats=0xffd3ef50) at ../feature/sla/nxos/public/lib/sla_api.c:281 #6 0x0806ebf6 in otm_check_ipsla_object_state (obj_node=0x876ea30, state=0xffd3f1c8) at ../infra/track/server/otm_ipsla.c:346 #7 0x080693e4 in otm_track_ipsla_object (obj_node=0x876ea30, vdc_id=0) at ../infra/track/server/otm_track.c:91 #8 0x080626d6 in otm_create_object_node (vdc_id=0, object_id=136, otm_rec=0x8729f84, obj_inst=0xffd3fc8c, restart=1) at ../infra/track/server/otm_util.c:806 #9 0x08075fc5 in otm_restore_config (pss_runtime_config=141172496, version=0, pss_runtime_info=141122256) at ../infra/track/server/otm_restore_pss_data.c:319 #10 0x080769ab in fu_cb_restore_pss_data (arg=0xffd4015c) at ../infra/track/server/otm_restore_pss_data.c:94 #11 0xf67a9b2d in fu_restore_pss_data (cb_vdc_id=4, call_application_restore=1) at
Workaround: otm cores found after switchover and powerup of Lc,
#0 0xf68e7f92 in syscall () from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6 #0 0xf68e7f92 in syscall () from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6 #1 0xf6f45f12 in os_syscall_ioctl (fd=11, request=-2143204091, arg=0xffd3e95f) at ../routing-sw/routing/tcpudp/clt/os_syscalls.c:70 #2 0xf6f35bcd in ioctl (desc=11, req=2151763205) at ../routing-sw/routing/tcp |
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(16)S40 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu40239 | Title: | ARP traffic sent out on incorrect VLAN |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom: ARP traffic sent out on incorrect VLAN
Conditions: ++ Mixed chassis with F1 & M1 cards
Workaround: 1. Shut and no shut the SVI that is having problems, or 2. Disable glean fast-path via the config command ? no ip arp fast-path, or 3. Disable and reenable glean fast-path 4. Reload the switch.
Further Problem Description:
|
|
Last Modified: | 02-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.11)S0, 6.2(14), 7.2(1)D1(0.65), 7.2(1)D1(1), 7.2(1)ZD(0.57) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua48389 | Title: | AToM event spin loop when PW status disabled |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom: AToM pseudowire can go into an event loop if "no status" is enabled following an adjacecncy fault.
Conditions: "no status" on pseudowire class.
Workaround: clear xconnect all might help, else remove "no status"
Further Problem Description:
|
|
Last Modified: | 02-FEB-2016 |
|
Known Affected Releases: | 5.2(0)LV1(0.336) |
|
Known Fixed Releases: * | 15.2(2)S1.4, 15.2(2)S2, 15.2(2)SNH1, 15.2(2)SNI, 15.2(2.19)S0.12, 15.2(4)S, 15.3(0.10)S, 15.3(0.15)PI21b, 15.3(1.1)T, 15.6(1)SN |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu21286 | Title: | n5548UP - Kernel panic while doing ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: While ISSU was in process, kernel panic occurred and the box got reloaded.
fc-scale-n5548UP# sh system reset-reason ----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) --- 1) At 1937 usecs after Tue May 5 20:42:01 2015 Reason: Kernel Panic Service: Version: 7.2(0)N1(1)
Conditions: ISSU is happening
Workaround: None
Further Problem Description:
|
|
Last Modified: | 02-FEB-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.192) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)FFW(0.7), 7.0(0)HSK(0.474), 7.0(7)ZN(0.266), 7.0(8)N1(0.319), 7.0(8)N1(1), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.1(3)ZD(0.83), 7.1(3)ZN(0.178) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuh23173 | Title: | Xbow-sup3: SH crashed on swover running UTE script |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Issue is extremely rare and random in nature and seen only on few QA setups.
Symptom: System manager will detect core files of standard linux utilities like sh, tar etc.
Conditions: Its seen only on N7000 and N7700 SUP2 platforms. Its triggered during heavy memory related activities such as switchovers.
Workaround: None
Further Problem Description:
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.2(10)E1, 6.2(10)S102, 6.2(10)S23, 6.2(10)S36, 6.2(10)S65, 6.2(10)S82, 6.2(12)S12, 6.2(2)S21, 6.2(2)S23, 6.2(7.28)S0 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud54797 | Title: | cli enhancements for tls |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | This is an enhancement. |
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.2(0)OP(0.49) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(1.14)PI22c, 15.3(2.2)T, 15.3(2.3.1)CG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue90633 | Title: | L2VPN sending double delete for startup route to orib on clear l2vpn |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: When "clear l2vpn service all", "shut noshut AC interface", or "shut noshut BGP", saw the following message :%$ %ORIB-3-BAD_OWNER: orib [11131] "l2vpn" is trying to delete route (4, *, 255.255.255.255) owned by "(null)"
Conditions: Clear l2vpn service all, shut noshut AC, or shut noshut BGP.
Workaround:
More Info:
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.2(1.36)S3, 6.2(1.74)S4 |
|
Known Fixed Releases: * | 15.2(1.2.43)PI22, 15.3(2)S0.4, 15.3(2)S1, 15.3(2.15.4)XEB, 15.3(2.23)T, 15.4(0.1)S, 15.6(1)SN, 6.0(2)A4(1), 6.0(2)N3(0.61), 6.0(2)N3(0.69) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui43540 | Title: | l2vpn core with 6.2.2.S21 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: A random crash seen with l2vpn
Conditions: when remote PE is going through ISSU and has vpws and vpls config
Workaround: None
Further Problem Description:
|
|
Last Modified: | 04-FEB-2016 |
|
Known Affected Releases: | 6.2(2)S21 |
|
Known Fixed Releases: * | 15.3(3)M1.5, 15.3(3)M2, 15.3(3)S0.2, 15.3(3)S1, 15.3(3)S2, 15.4(0.12.6)PIH23, 15.4(0.17)S, 15.4(0.20)PI24d, 15.4(0.22)T, 15.4(0.22.1)PIH23 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur34065 | Title: | u6rib cored @u6rib_process_clt_stale while deleting vdc |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: the crash seems to occur because of a client clean up issue
Conditions: Crash is seen when vdc is reloaded
Workaround: No workaround
Further Problem Description:
|
|
Last Modified: | 04-FEB-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.96), 7.1(0)D1(0.303), 7.1(0)D1(0.308), 7.1(0)ZD(0.348), 7.1(0)ZD(0.355), 7.1(2)ZD(0.11), 7.2(0)ZD(0.5), 8.3(0)CV(0.162) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(3)I3(0.110), 7.0(3)I3(0.111), 7.0(3)I3(1), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.1(0)AV(0.38) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus74176 | Title: | boot loop w/ 'no logging logfile' in config w/ power outage/reload VDC3 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: core dump generated in boot loop when sudden power outage such as unplug power cord. soft reload worked fine. issue can be recreated with reload VDC 3
Conditions: suddenly lost power when the command 'no logging logfile' is in the configuration
Workaround: Remove 'no logging logfile' from the configuration
Further Problem Description:
|
|
Last Modified: | 04-FEB-2016 |
|
Known Affected Releases: | 6.2(10), 7.2(0)D1(0.430) |
|
Known Fixed Releases: * | /bin/sh:, 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.40), 7.0(3)I3(0.177), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul84608 | Title: | N7K-L2VPN VPLS Scale-No switchover after 4 times l2vpn Process crash |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: According to the HA policy, the router should perform an RP failover when the L2VPN process crashes and tries restarting 3 times, but instead it doesn't perform the failover and remains at the failure state.
Conditions: L2VPN crashes 4 or more times.
Workaround: No workaround.
Further Problem Description:
|
|
Last Modified: | 05-FEB-2016 |
|
Known Affected Releases: | 6.2(8)BF(0.2), 7.1(0)ZD(0.181) |
|
Known Fixed Releases: * | 15.4(2)S2, 15.4(2.17)S0.8, 15.4(3)M2.1, 15.4(3)M3, 15.4(3)M3.1, 15.4(3)S, 15.4(3)SN1a, 15.5(0.16)T, 15.5(0.16.1)CG, 15.5(0.20)PI27a |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv82106 | Title: | Multicast traffic gets blackholed when MVR configured |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: New Setup's with MVR configured will have issue with traffic getting blackholed in egress direction due to MVR vlan pruning
Conditions: 7.x Release
Workaround: shut / no shut of the receiver port will solve the issue
Further Problem Description:
|
|
Last Modified: | 11-FEB-2016 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.302), 7.0(7)N1(1), 7.0(7)ZN(0.206), 7.1(3)N1(0.633), 7.1(3)N1(1), 7.1(3)ZD(0.20), 7.1(3)ZN(0.41), 7.3(1)PIB(0.15) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu49365 | Title: | Wrong set of bd's are sent in TMC when no bridge-domain is done |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Here proper set of bd's or vlan's are not sent in port affected notif to ethpm for bringing them down. This will lead to inconsistency in peer-link i.e. vpc_mgr, ethpm and vlan components. This only pertains to vxlan setup and not vinci/autoconfig.
Conditions: Only on "no bridge-domain " and vxlan setup. This is not seen in vinci and autoconfig setup.
Workaround: For peerlink do shut/no shut i.e. flap the port. For normal ports aswell do the same flap them.
Further Problem Description:
|
|
Last Modified: | 11-FEB-2016 |
|
Known Affected Releases: * | 7.2(0)D1(0.512), 7.2(0)D1(1), 7.3(0)D1(0.34), 8.3(0)CV(0.230), 8.3(0)CV(99.179) |
|
Known Fixed Releases: | 7.2(0)D1(1), 7.2(0)D1(1.14), 7.2(0)ZD(0.221), 7.2(1)PIB(0.14), 7.3(0)SL(0.73) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy25870 | Title: | F2e modules reboot on a pair of N7Ks simultaneously |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom: One of the F2e modules on N7Ks went down. About 10 minutes later, the other one of the modules on the partner N7K went down.
The reset reason of both modules are the below. Reset Reason (HW): Reset due to bad intermediate bus voltage (95)
Conditions: No explicit trigger and conditions are found.
Workaround: There is no workaround.
Further Problem Description:
|
|
Last Modified: | 12-FEB-2016 |
|
Known Affected Releases: | 6.2(6a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy17372 | Title: | 7.3 - PVLAN trunk secondary association removal causing traffic drop |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:When having multiple port-channels with same PVLAN trunk secondary configuration, when translation/pvlan association on one port-channel is removed, it is getting removed from the Fabric Port itself. Though the removed vlan config is present in another Port-channel.
When Host Interface Port Channel (HIF-PC) is down with PVLAN configuration, all the other (Host Interface Port) HIF-PORTs and HIF-PC with the same PVLAN configuration does not work since the FabricPort-channel configuration is wiped out for that PVLAN mapping.
Conditions:PVLAN trunk secondary confguration is present and same Pvlan association is present in more than one port-channel.
Workaround:Vlan shut and no shut will solve the problem. However, This workaround is not persistent. The problem might happen again with the same trigger
More Info:It is recommended not to use PVLAN over HIFPC with this defect.
|
|
Last Modified: | 12-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv76651 | Title: | SGT registers not programmed properly for F3 LC |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: SGT Registers are programmed correctly for 10G F3 ports.But For 40G & 100G F3 ports, the egress insert and Ingress remove logic is not properly programmed, resulting in unexpected behaviour
Conditions: Issue would be seen when SGT is configured on 40G/100G F3 ports.
Workaround: there are no workarounds.
Further Problem Description:
|
|
Last Modified: | 14-FEB-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: * | 6.2(14), 6.2(14)S12, 6.2(14.3)S0, 7.2(1)D1(0.56), 7.2(1)D1(1), 7.2(1)ZD(0.49) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy19735 | Title: | N7K: aclqos crashed on multiple F1 module with signal 6 |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom: On Nexus7000 , aclqos crash on multiple F1 module with signal 6 %SYSMGR-SLOT8-2-SERVICE_CRASHED: Service "aclqos" (PID 2139) hasn't caught signal 6 (core will be saved).
Conditions: Nexus7000 NXOS6.1(3) F1 module
Workaround:
Further Problem Description:
|
|
Last Modified: | 15-FEB-2016 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy29300 | Title: | F3 Xbow Corrective action don't happen |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom: Corrective actions fail for F3 on 7710 chassis
Conditions: Corrective actions fail for F3 on 7710 chassis
Workaround: No workaround
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.79) |
|
Known Fixed Releases: | 7.3(0)DX(0.90) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu66415 | Title: | VINCI UI: ethpm receiving an empty vlan list from vlan_mgr |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: vlan_mgr sends notifications to ethpm with empty interest list
Conditions: happens during bridge-domain create
Workaround: this has no operational impact
Further Problem Description: this is an interaction between vlan_mgr and ethpm. the empty list becomes a NOP for ethpm and this has no impact on operation or functionality
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1), 7.2(1)D1(0.80), 7.3(0)D1(0.24) |
|
Known Fixed Releases: * | 7.2(1)D1(0.2), 7.2(1)D1(1), 7.2(1)ZD(0.2), 7.3(0)D1(0.70), 7.3(0)D1(0.71), 7.3(0)D1(1), 7.3(0)D1(1A), 7.3(0)EG(0.3), 7.3(0)IB(0.67), 7.3(0)MMD(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu34174 | Title: | UIN-1::After switch reload macs are not in sync between VPC peers |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Duplicate traffic is noticed on downstream FEX connected to F2 cards (not F2CR or F3)
Conditions: On switch reload, mac missing on one side of VPC and traffic hashes to the side missing.
Workaround: clear mac address dynamic OR clear mac address on the side present.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.506) |
|
Known Fixed Releases: * | 7.3(0)D1(0.69), 7.3(0)D1(1), 7.3(0)DHB(0.31), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.15), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu77709 | Title: | LISP: map-caches entries to non-routable RLOCs are installed in fwd |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: A LISP map-cache entry on a xTR lists a group of locators as being in state "up" even while the routing table does not have an entry to reach them. They should be listed in state "no-route". These locators are pushed down to the forwarding table and flows that match this forwarding entry are blackholed.
Conditions: The main condition to see this problem is that the setup has a "split" RLOC view, i.e. the eTR registering the lisp database entry is able to see the RLOCs while the iTR is not.
From there the following needs to happen simultaneously to face this problem: (1) Multiple map-cache entries in the xTR have the same locator set (2) Some of the RLOCs in this locator set are permanently unreachable (no routing entry in RIB) from iTR
Workaround: Enabling RLOC probing, which will complement the information from the routing table. "lisp loc-reach-algorithm rloc-probing"
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.17), 7.2(1)D1(1), 7.2(1)N1(0.248), 7.2(1)N1(1), 7.2(1)ZD(0.13), 7.2(1)ZN(0.14), 7.3(0)D1(0.72), 7.3(0)D1(1), 7.3(0)DHB(0.31), 7.3(0)EG(0.3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux48104 | Title: | DSCP rewriting cannot work on Nexus 7k and Nexus 7700 F series cards. |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom: DSCP rewriting to COS can not work properly when try to respect DSCP value on egress queue direction . example: table-map COPY_DSCP default copy policy-map type qos COPY_DSCP class class-default set dscp dscp table COPY_DSCP interface ingress/egress service-policy type qos input COPY_DSCP For bridged packets , on egress queuing should respect DSCP value to rewrite COS , but the policy-map COPY_DSCP could not take effect and rewrite DSCP value to COS correspondingly.
Conditions: Hardware: Nexus 7K and 7700 , F cards. Software: 7.2.1 When try to achieve DSCP rewriting COS on bridged packets.
Workaround: No workarounds
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur21785 | Title: | N7K - M1/M2 Egress Queuing behavior post 6.2(x) for control plane packet |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Control plane packet ( marked with DSCP value for Example PIM etc ) received on ACCESS port, and then get bridged into same VLAN do not queued in priority Queue on Egress port. The issue is not seen after doing "no ip igmp snooping"
Conditions: - Nexus 7000 running 6.2(x), 7.2(x) image; Earlier images like 5.2(x) do not see the same condition. - Packet is coming in ACCESS port and getting bridged into same VLAN via ACCESS or Trunk port. - M series Line cards
Workaround: Not available yet
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(14), 6.2(8a), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.38), 7.2(1)D1(1), 7.2(1)N1(0.272), 7.2(1)N1(1), 7.2(1)ZD(0.33), 7.2(1)ZN(0.36), 7.3(0)D1(0.72), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)MMD(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut86729 | Title: | vPC Multicast optimization doesn't work after disable/enable the CLI |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Multicast traffic flows through the MCT link (vpc peer-link) even though VPC Multicast optimization is enabled using CLI "no ip igmp snooping mrouter vpc peer-link".
Conditions: VPC Multicast optimization is enabled using CLI - "no ip igmp snooping mrouter vpc peer-link"
Workaround: If vPc multicast optimization is required such that multicast traffic doesn't traverse MCT link and if this issue is observed in the network, enabling the command by configuring "ip igmp snooping mrouter vpc peer-link" and disabling the command after some time by using "no ip igmp snooping mrouter vpc peer-link" will work.
Further Problem Description: Enabling Multicast optimisation through CLI doesn't take effect in a scale setup. No issue is seen if we do not enable VPC Multicast optimization. It is disabled by default.
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.163) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.22), 7.3(0)SC(0.14), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu53575 | Title: | sh vlan id 1 shows incorrect ports after doing ASCII replay twice |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Any port which is not in mode trunk should not have config for trunk allowed vlan's under it. For exmaple
int po10 switchport switchport mode fabricpath switchport trunk allowed vlan 11-20 no shutdown
Conditions: Only happens when "switchport trunk allowed vlan " is done after the mode is changed to no trunk mode.
Workaround: Do no switchport trunk allowed vlan in case of fabricpath/pvlan mode as this config is of no use.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.69), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.21), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus71454 | Title: | PVLAN VPC: peer-link flap causes primary legs in PVLAN host mode to flap |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: In a Private-Vlan VPC setup in private-vlan host mode, when peer link flaps, VPC leg in private-vlan host mode also flaps and comes back up in some time. There will be traffic loss from the VPC leg until the leg bringup happens again.
Conditions: The VPC legs have to be private-vlan host mode as follows: "switchport mode private-vlan host"
Example configuration: interface port-channel10 switchport switchport mode private-vlan host switchport private-vlan host-association 2 3 vpc 1
Workaround: None
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(12)S29 |
|
Known Fixed Releases: * | 6.2(13.18)S0, 6.2(14), 7.2(1)D1(0.43), 7.2(1)D1(1), 7.2(1)ZD(0.37), 7.3(0)D1(0.69), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut75457 | Title: | HSRP VACL Filter Broken |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: HSRP hello is passing through device with VACL in place to drop these packets.
Conditions: - 6.2(10) or 6.2(12) - F2, F2E, or F3 Line Card
Workaround: None.
Further Problem Description: This behavior is seen in 6.2(10) and 6.2(12). It is not seen in 6.2(8b).
A similar issue relating to PACL filtering HSRP packets fixed in 6.2(12): CSCur69114
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.66), 7.2(0)D1(1), 7.2(1)D1(0.63), 7.2(1)D1(1), 7.3(0)D1(0.80), 7.3(0)D1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo12118 | Title: | NXOS-L2VPN-VPLS-PWs are down after remove then add VFI/PW |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: PW to remote PE in VFI not present.
Conditions: Following are the conditions in which the issue would be encountered: - VFI is configured with BGP AD (AND) - BGP session with Address family L2VPN is configured and BGP session is established (AND) - PWs in the VFI are established - L2VPN Process Restarts - Reconfigure VFI (Un-configure/Configure VFI)
Workaround: clear ip bgp *
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.1(0)BF(0.48) |
|
Known Fixed Releases: * | 15.4(2.11)T, 15.4(2.12.1)PIH25, 15.4(2.16)S, 15.4(3)S, 15.6(1)SN, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.106), 7.1(0)BF(0.127), 7.1(0)D1(0.162) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu13792 | Title: | VPC doesn't come up after HMM is enabled |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: VPC peer-link comes up
Conditions: two sides of port-channel mismatch
Workaround: none
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)VZN(0.1) |
|
Known Fixed Releases: * | 7.0(0)FHS(0.23), 7.2(0)VZD(0.40), 7.3(0)D1(0.21), 7.3(0)D1(0.33), 7.3(0)D1(1), 7.3(0)DHB(0.2), 7.3(0)HM(0.36), 7.3(0)IB(0.35), 7.3(0)OTT(0.8), 7.3(0)RTG(0.39) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu84449 | Title: | IGMP snooping entries ageout in AA FEX topologies |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: IGMP snooping entries are expiring after 5 seconds on one of the two vPC switches, while the entries are stable on the other vPC switch, which might cause traffic loss for 15-16 seconds (depending on the port-channel hashing result).
Conditions: Issue can be seen in a vPC topology with AA FEX without having configured the IGMP snooping switch-querier (under "vlan configuration XYZ"), but when having PIM enabled SVI interfaces.
Workaround: Configure IGMP snooping querier under the "vlan configuration XYZ" configuration mode.
or
Configure "ip igmp query-interval 30" under the SVI configuration mode.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.1(0)N1 |
|
Known Fixed Releases: * | 7.2(1)D1(0.7), 7.2(1)D1(1), 7.2(1)N1(0.240), 7.2(1)N1(1), 7.2(1)ZD(0.6), 7.2(1)ZN(0.6), 7.3(0)D1(0.72), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)MMD(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum16110 | Title: | N6K: OIF on mroute not removed when interface is remotely shut |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: A particular interface is not removed from the OIF list in mroutes when a remote shut for the same interface happens.
Conditions: When a remote shut happens for a particular interface which is in the OIF list for a particular mroute, the interface does not get removed from the OIF list.
Workaround: None
Further Problem Description: A particular interface is not removed from the OIF list in mroutes when a remote shut for the same interface happens. This causes a problem as traffic gets forwarded immediately on actually bringing the link up
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.0(2)N2(2.43) |
|
Known Fixed Releases: * | 6.0(2)U6(5), 7.0(3)I3(0.271), 7.0(3)I3(1), 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RTG(0.90), 7.3(0)SC(0.14), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup56162 | Title: | Anycast HSRP custom VMAC not programmed after hsrp restart |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Anycast HSRP with custom VMAC is not programmed at L2FM as gateway after HSRP process stateful restart.
Conditions: Anycast HSRP is configured with non-default VMAC and HSRP engine process is restarted.
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.6), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv37216 | Title: | Callhome messages via HTTP transport is not sent due to L3VM error |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Callhome messages vis HTTP transport not sent due to l3vm_get_context_id failing.
Conditions: Try sending any call home message thru http transport.
Workaround(s): None.
Workaround: None.
Further Problem Description: None.
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.3(0)SLN(0.28) |
|
Known Fixed Releases: * | 7.3(0)D1(0.98), 7.3(0)D1(1), 7.3(0)FMD(0.9), 7.3(0)N1(1), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)SC(0.14), 7.3(0)SL(0.109), 7.3(0)SL(0.85), 7.3(0)ZD(0.112) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu58619 | Title: | IPFIB vrf dependency database doesnt cleanup on VDC reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Traffic drops can be seen for multicast and/or unicast flows.
Conditions: In the presence of Vinci configurations, when a VDC is reloaded, we can get into this condition of unicast/multicast routes not getting updated in certain asic instances
Workaround: reloading of the affected LC.
Further Problem Description: n/a
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1), 7.3(0)D1(0.64) |
|
Known Fixed Releases: * | 7.2(1)D1(0.8), 7.2(1)D1(1), 7.2(1)ZD(0.7), 7.3(0)D1(0.64), 7.3(0)D1(0.74), 7.3(0)D1(0.91), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)IB(0.72), 7.3(0)OTT(0.55) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui61230 | Title: | after reloading box when new pw is added under vfi it stays down |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: When a new PW is added under vfi context, it does not come UP
Conditions: Seen for manual PWs (i.e config of the type "member 1.2.3.4 encapsulation mpls" under the vpls context)
Workaround: "clear l2vpn service vfi name ", or deleting and reconfiguring the PW fixes the issue.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(2)S33 |
|
Known Fixed Releases: * | 15.3(3)M1.5, 15.3(3)M2, 15.3(3)S0.4, 15.3(3)S1, 15.3(3)S2, 15.4(0.12.6)PIH23, 15.4(0.19)S, 15.4(0.20)PI24d, 15.4(0.22)T, 15.4(0.22.1)PIH23 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu69256 | Title: | SSTE: SNMP user mem is increasing continuously polling from 3 stations |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: High memory usage shown by snmpd process. Conditions:With higher scale (768 ports, 700+ BGP sessions, 10K multicast approximately), we are doing getBulk from 3 NMS stations.. Over four days and seeing snmpd mem usage Workaround:As of now no crash has been seen as some of the memory held is freed so there is no need of workaround as of now.
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.28), 7.2(1)D1(1), 7.2(1)N1(0.263), 7.2(1)N1(1), 7.2(1)ZD(0.23), 7.2(1)ZN(0.27), 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux00743 | Title: | vpc Hitless RC trigger needs rejection on peer-switch is not enable/oper |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: vpc non-disruptive role change with peer-switch not enabled may cause traffic convergence issues
Conditions: peer-switch not enabled
Workaround: Enable peer-switch
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.138) |
|
Known Fixed Releases: * | 7.3(0)D1(0.179), 7.3(0)D1(1), 7.3(0)SC(0.14), 7.3(0)ZD(0.196) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw25153 | Title: | Traffic loss during HSRP Recovery |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | HSRP is configured on 2 Nexus 7700, one is active and the other one is standby. When the link on the active one is down, the standby one will take over the role of the active one. However, after the link is up, when the original active one try to take back the role, there will be a traffic loss of more than 1s. This issue occurs once in 30 trials.
Symptom: HSRP is configured on 2 Nexus 7700, one is active and the other one is standby. When the link on the active one is down, the standby one will take over the role of the active one. However, after the link is up, when the original active one try to take back the role, there will be a traffic loss of more than 1s. This issue occurs once in 30 trials.
Conditions: Hsrp sessions over BFD and we need to keep on doing shut and no shut
Workaround: No workaround is there for the drop. Its random.
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(13)S8, 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(16)S16, 7.2(2)D1(0.3), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZD(0.8), 7.2(2)ZN(0.7), 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)IB(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw62000 | Title: | Vtpv3: Not updating the vlan info after reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: After changing vtp domain password in primary server and reloading the primary server.Was not updating vlan information in secondary server .
Conditions: VLAN info is not updated after reload when the VTP password is configured. uut1---uut2 Step to repro:- 1. uut1 is primary server and uut2 is secondary server 2. on both password is configured in plain text format. 3. reload the uut1 and after reload create some vlan on uut1 , uut2 does not update the vlan due to md5 mismatch.
Workaround: None
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.118) |
|
Known Fixed Releases: * | 7.3(0)D1(0.177), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.129), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw20002 | Title: | N7k - Temperature sensors stalls for linecards after EPLD update |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: On N7k(N77-SUP2E), Temperature sensors may stalls or stops responding for linecards after EPLD update to 6.2.12 nx-os image. It seems like platform timer which runs every minute to poll the temperature is not running. Tried Manually reading the sensors..and it read the correct values. As these timers are managed by the epld code. Suspecting if EPLD upgrade trigged the event.
In customer setup we have seen some instance where for linecards polling never started after upgrade and in some instances it started the polling after the upgrade but stalls as soon as module hit the high temperature threshold.
Conditions: NX-OS and EPLD(system auto-upgrade epld) update to 6.2.12
Workaround: Failover the Supervisor Module.
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.84), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut17793 | Title: | SSTE:Traffic loss observed after flapp mpls interf with 7.2(0)D1(0.422) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Few VPLS PWs are down
Conditions: Flap MPLS interface used by PWs
Workaround: clear l2vpn service all
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.422), 7.2(0)D1(0.484) |
|
Known Fixed Releases: * | 15.5(1)S1.5, 15.5(1)S2.15, 15.5(1)S2.7, 15.5(1)S3, 15.6(0.16)S, 15.6(0.17)PI30d, 15.6(0.25)T, 15.6(1)SN, 15.6(1.1)T, 15.6(1.3)S |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw18366 | Title: | OTV core while bringing up 42+ OTV adjacency |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: OTV process crash.
Conditions: While add more than 42 OTV adjacency are added for on N7k.
Workaround: None
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: * | 7.3(0)D1(0.171), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.131), 7.3(0)RSP(0.7), 7.3(0)RTG(0.80), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu10618 | Title: | Traffic loss on some vlans after line card reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: after reload there is 100% packet drop on a few vlans
Conditions: LC reload on scaled setup
Workaround: clear l2vpn service all
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.471), 7.2(0)D1(0.475) |
|
Known Fixed Releases: * | 15.5(1)S1.5, 15.5(1)S2.15, 15.5(1)S2.7, 15.5(1)S3, 15.5(2.20)T, 15.5(2.21)S0.12, 15.5(2.21)S0.5, 15.5(3)S, 15.5(3)S0a, 15.5(3)S1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu38208 | Title: | VINCI: new member add to existing vpc+ PL fails for vlan 4045 |
|
Status: | Fixed |
|
Severity: * | 2 Severe |
Description: | Symptom: This happens when trying to add a new member port to the port channel. This can also happen when removing the already mapped port and then again trying to map it again to the port channel.
Conditions: There needs to be atleast one member port on the port-channel
Workaround: There are two workarounds;
1. interface port-channel100 switchport trunk allowed vlan all
2. interface eth1/2 channel-group 100 force
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: * | 7.2(0)D1(0.508), 8.3(0)CV(0.304) |
|
Known Fixed Releases: | 7.2(0)D1(1.20), 7.2(0)ZD(0.226), 7.3(0)SL(0.73) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw90876 | Title: | %ETHPORT-5-IF_SEQ_ERROR: Error ("IFTMC PD commit db search failed"). |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: After enabling cts role-based enforcement on a vlan, bounce of any interface in that vlan will cause it to become errdisabled due to "IFTMC PD commit db search failed" error.
Conditions: cts enabled, role-based policies downloaded, and role-based enforcement enabled on vlan.
Workaround: disable role-based enforcement on vlan
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(12), 7.2(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.3), 7.2(2)ZD(0.8), 7.3(0)D1(0.162), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.105), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw27044 | Title: | OSPFv3 takes 30 min to install route when using link-local addresses |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: When peering a nexus 7k with an ASR9k using OSPFv3 with link-local addresses only, it takes 30 minutes for the ASR9k to install the routes learned from the Nexus 7k. I have tried peering a nexus 7k with another device (i.e 6500 swith) and the result is the same: the 6500 device takes 30 minutes to install the route learned from the nexus 7k.
Conditions: Customer using layer 3 port-channels but it can happen for all types of interfaces.
Workaround: Configure regular IPv6 addresses
Further Problem Description: When peering a nexus 7k with an ASR9k using OSPFv3 with link-local addresses only, it takes 30 minutes for the ASR9k to install the routes learned from the Nexus 7k. I have tried peering a nexus 7k with another device (i.e 6500 swith) and the result is the same: the 6500 device takes 30 minutes to install the route learned from the nexus 7k.
This is day-1 issue with stub area. The link local lsa is not added to DB entries.
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(14a)S4, 6.2(16)S21, 7.0(3)I2(1.27), 7.0(3)I2(2), 7.2(1)D1(1), 7.2(1)ZD(0.103), 7.2(1)ZN(0.97), 7.2(2)D1(0.2), 7.3(0)D1(0.143), 7.3(0)D1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv99943 | Title: | pvlan port in error state after series of mode change sequence . |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: the primary vlan configured as pvlan access is set to err-vlan and the consistency check fails for vpc. as a result stp doesn't bring up the port-channel
Conditions: initially the port-channel is in pvlan promiscuous mode with pvlan mapping configured on the interface. then the port mode is changed to access. the primary vlan is configured as access vlan and the pvlan mappings are removed. this is followed by switching the mode to pvlan promiscuous, and re-application of the pvlan mappings.
Workaround: if the pvlan mappings are not removed during mode change, the issue will not occur. A flap of the interface will also recover the pvlan from err-vlan
Further Problem Description: This issue is seen only with this sequence of cli : 1. Configure port in promiscious mode 2. configure an operational mapping 3. move to access mode. 4. remove the operational mapping 5. change port mode to promiscious again
We see that the port is in err disabled state.
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 7.2(1)D1(0.54) |
|
Known Fixed Releases: * | 7.3(0)D1(0.162), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.93), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur00089 | Title: | vdc-admin on N7K can break out of vsh-"chroot" using symbolic links |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Cisco Nexus devices running Cisco NX-OS software contain a symbolic link vulnerability that could allow a local, authenticated attacker to break out of the chroot environment that their Virtual Device Context (VDC) has been assigned. This could result in the attacker gaining the ability to write files to locations that should be restricted to the context to which they belong. This could also have an extended impact of allowing the attacker to read data that should be restricted.
Conditions: Cisco Nexus devices running an affected version of Cisco NX-OS Software
Workaround: None.
Further Problem Description: Credit: Cisco would like to thank Jens Krabbenhoeft for reporting this vulnerability.
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.2/2.6: http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:P/I:P/A:N/E:F/RL:OF/RC:C&version=2.0
No CVE ID has been assigned to 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: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(13.4)S0, 6.2(14), 6.2(14)FB(0.74), 7.2(1)D1(0.30), 7.2(1)D1(1), 7.2(1)ZD(0.25), 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv87645 | Title: | Traffic not classified according to the static SGT |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: If an IP-SGT mapping overlapping with a VLAN-SGT mapping is first learned over SXP and then deleted the 7k will not classify the traffic with the static VLAN-SGT configured.
Conditions:
Workaround: force-delete the ARP entry for the source IP
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(10)E3, 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.156), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)RSP(0.7), 7.3(0)RTG(0.115), 7.3(0)SC(0.14), 7.3(0)ZD(0.171) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy02073 | Title: | M3 TE: F3 line card crash |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom: IPFIB process in the LC may crash when events like FRR, link down happen.
Conditions: When a primary TE tunnel that has a backup, is also a backup for a third tunnel When a tunnel that is backup is also a backup for a third tunnel
Workaround: There is no workaround. The above conditions must be avoided
Further Problem Description:
|
|
Last Modified: | 19-FEB-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.55), 7.3(0)DX(0.63) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus52139 | Title: | post L3, l2 flood traffic not going out on peer-link |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom: Post L3 Flood to BD packet are not forwarded in the Peer Link
Conditions: VPC setup with VxLAN configuration.
Workaround: MAC table should be populated.
Further Problem Description:
|
|
Last Modified: | 19-FEB-2016 |
|
Known Affected Releases: * | 7.2(0)D1(0.383), 7.3(0)D1(0.111), 7.3(0)D1(0.142), 7.3(0)DX(0.87) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn64672 | Title: | l2fm crash if too many MAC address move over vpc peer link |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: If there are too many mac address moves over vpc peer link. Somtimes, only the process l2fm crash. Sometimes the chassis may reload. Show system reset-reason shows that the reload reason is caused by l2fm hap reset.
Conditions: The exact condition is unknown. Issue has been seen in 5.1(x), 5.2(3a), 6.0(2) and below.
Workaround: None. Upgrading to 5.2(4), 6.0(3), or later will resolve issue. |
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 5.1(2), 5.2(3.38), 5.2(3a) |
|
Known Fixed Releases: * | 5.2(4)S1, 5.2(4.1)S0, 6.0(2)E1, 6.0(3)S1, 6.1(1), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn42451 | Title: | N7K/4.2: Configuration not applied in default VDC |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When attempting configuration in default VDC the switch hangs for approximately 60 seconds and the following output is observed. The command is not executed successfully.
switch(config)# int ethernet 1/3 switch(config-if)# no shut Please check if command was successful using appropriate show commands switch(config-if)#
switch# sh int e1/3 Ethernet1/3 is down (Administratively down)
Conditions:
The issue has been seen in NX-OS 4.2(6). if a no shut is done on a port-channel member
Workaround: system switchover can be used as a workaround.
Further Problem Description: |
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 4.2(6) |
|
Known Fixed Releases: * | 4.2(8)S11, 4.2(8.44)S0, 5.1(10.1)S0, 5.1(3)S27, 5.2(0.241)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr75627 | Title: | cbl-ftag wrong after issu/so/remove-add-po-memberport, on fp agg s1 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom: If a member is removed and re-added back to a dce-core port-channel, then in some cases it is possible that traffic will not flow on that member, since the CBL is set to blocked.
Conditions:
If a member is removed and re-added back to a dce-core port-channel, then in some cases it is possible that traffic will not flow on that member, since the CBL is set to blocked.
Workaround(s):
Shut/No-shut the impacted member port.
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 5.2(1)S84 |
|
Known Fixed Releases: * | 5.2(2)S15, 5.2(2.12)S0, 6.0(0.34)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj11367 | Title: | Mac address for HSRP Virtual IP address is dropped after link recovery |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: On a Nexus 7000 running vPC the HSRP gateway MAC address may be removed from the peer-link after a peer-link flap.
Conditions: The issue was observed during the recovery phase of the vPC peer-link and can be triggered by a loop condition that results in excessive traffic on the peer link. Under rare conditions, if the HSRP hellos are looped, it can result in the HSRP mac getting installed on the wrong port and remain there after the loop is broken and the peer-link is restored.
Workaround: A shut/no shut of the VLAN interface reprograms the MAC address on the peer link.
This bug is fixed only in 6.1.x release. It will not be backported to 5.2.x release. This bug effects all other release trains. |
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 4.2(8)S5, 5.0(3), 5.2(1), 5.2(4)S29, 6.0(3)S5, 6.0(4)S13, 6.1(0.274)S4 |
|
Known Fixed Releases: * | 6.1(0.284), 6.1(0.298)S2, 6.1(0.301)S0, 6.1(0.307)S0, 6.2(0.217), 6.2(2), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto35788 | Title: | After a sup switchover ISIS fails to advertise some mac addresses in OTV |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a Nexus 7000 series switch after a supervisor switchover, some mac addresses will fail to be advertised through ISIS across the layer 2 extension via OTV.
Conditions:
Supervisor switchover
Workaround:
Clear the mac address table for those mac addresses on the OTV edge device where the host is located locally and ISIS will start advertising it again.
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 5.1(3), 5.2(0.1) |
|
Known Fixed Releases: * | 5.2(0.275)S0, 5.2(1)S20, 5.2(1.23)S0, 7.2(0)ZN(0.111), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj29688 | Title: | VPC:VPC peer is not reachable after shut/no shut of peer-link |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom: Peer-link ports may get error disabled on the primary. Conditions: When peer-link is shut/no-shut with a large number of VPCs (250 or more). Workaround(s): Steps: 1) Before doing shut/no-shut of the peer-link, shutdown the VPCs on the secondary. 2) After the peer-link comes up, do "no shut" VPCs on the secondary.
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: * | 5.1(1), 5.1(1.1) |
|
Known Fixed Releases: * | 5.2(0.261)S0, 5.2(0.275)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy03467 | Title: | Aclqos crash seen for NAM mod with vdc reload. |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom: aclqos crash in NAM module crash can happen with differnet triggers like vdc reload, policy modification, interface state change
Conditions: pbr config with multiple next-hop with load share
Workaround: no workarounds.
Further Problem Description:
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux30775 | Title: | ipfib crash during ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: ipfib on F2 module may crash during ISSU
Conditions: F2 module has some VRF with no local member ports before ISSU.
Workaround: Unknown.
Further Problem Description:
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.157) |
|
Known Fixed Releases: * | 7.3(0)D1(0.175), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)ZD(0.191) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn84156 | Title: | N7K-Reg: SPAN session not coming up with PVLAN as source |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom: SPAN session will not come up on primary vlan
Conditions: When private-vlan is enabled and SPAN session is created on primary vlan
Workaround: None. |
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.1(10.1)S0, 5.2(0.249)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr79988 | Title: | After ISSU Peer link Might remain down due to SAP 176 returned error Unk |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After an ISSU upgrade, folllowing error messages can be seen when the VPC Peer link flaps:
%ETH_PORT_CHANNEL-3-PCM_HWCFG_FAIL_ERROR: Port-channel:port-channel1 mbr:Ethernet1/5 SAP 176 returned error Unknown error 1088421890 for opc MTS_OPC_PIXM_MOD_MEMB_LTL; if lacp port-channel please collect tech-support lacp all> or please collect Conditions:
Some conditions must be met: - VPC needs to be configured - A VPC needs to be configured *and* removed again before the ISSU - ISSU needs to be done - Peer links needs to be flapped (e.g. go down for any reason)
Workaround: - Delete and recreate the VPC peer link. |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.1(10.40)S0, 5.1(5)S2, 5.2(2)S7, 5.2(2.7)S0, 6.0(0.24)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux41397 | Title: | PVLAN crashed for clearing configs using default interface on fex |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: PVLAN crashed for clearing configs using default interface on fex
Conditions: PVLAN crashed for clearing configs using default interface on fex
Workaround: PVLAN crashed for clearing configs using default interface on fex
Further Problem Description: PVLAN crashed for clearing configs using default interface on fex
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.169) |
|
Known Fixed Releases: * | 7.3(0)D1(0.175), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)ZD(0.191) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsv02757 | Title: | DC3:When dynamic mac become gwmac, it's not removed from macdb |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
HSRP is active on the Nexus, but the mac table in hardware does not contain a Gateway mac entry for the HSRP mac address. Instead, it contains a dynamically learnt mac-address. This results in L3 functionality via HSRP mac to break.
Conditions:
This problem can happen under the following conditions: - HSRP were not configured on the box, and the Nexus L2 learns the HSRP mac address. - Now, HSRP is configured - this leaves behind a stale entry in the software dynamic mac table in addition to the static gwmac table. - Upon a flap of the port-channel on the remote end, all dynamic macs (rather than only the mac addresses related to the port-channel) are deleted from the line card.
These conditions lead to the purge of the gwmac entries from the LC, thus creating an inconsistency between software and hardware.
Workaround:
The workaround is to shut/no-shut the SVI interface on which hsrp is configured.
Further Problem Description:
None
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 4.0(2) |
|
Known Fixed Releases: * | 4.0(4), 4.1(1.46), 4.1(1.50), 4.1(1.52), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux38877 | Title: | "private-vlan mapping" needs tobe blocked at fex interface ports |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: "private-vlan mapping? needs tobe blocked at fex interface ports
Conditions: "private-vlan mapping? needs tobe blocked at fex interface ports
Workaround: "private-vlan mapping? needs tobe blocked at fex interface ports
Further Problem Description: "private-vlan mapping? needs tobe blocked at fex interface ports
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.169) |
|
Known Fixed Releases: * | 7.3(0)D1(0.179), 7.3(0)D1(1), 7.3(0)PDB(0.130), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux41744 | Title: | ITD scale of services would result in malloc failed , |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: ITD scale of services would result in malloc failed ,
Conditions: ITD scale of services would result in malloc failed ,
Workaround: ITD scale of services would result in malloc failed ,
Further Problem Description: ITD scale of services would result in malloc failed ,
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.169) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.194), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.62), 7.0(3)IDP3(2), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.3(0)D1(0.185) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur71772 | Title: | EIGRP fails to redistribute connected route after configuration change |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: EIGRP fails to redistribute connected route after configuration change
Conditions: "no ip router eigrp <>" is executed on the interface
Workaround: shut/no shut the interface
Further Problem Description:
|
|
Last Modified: | 02-FEB-2016 |
|
Known Affected Releases: | 6.2(12)FT(0.9) |
|
Known Fixed Releases: * | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.20), 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(1)ZN(0.693), 7.0(3)F1(0.171), 7.0(6)N1(0.202), 7.0(6)N1(1), 7.1(0)AV(0.74) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue48724 | Title: | NXOS CD2: no session max requires session number |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: no session max CLI requires a number Conditions: onep is enabled, and session max is configured Workaround: provide a number to session max
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.2(1) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(2.13)S, 15.3(2.15.1)XEB, 15.3(2.6)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux48530 | Title: * | 40Gb LC LED does not flash on running IO |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom: Running IO at 40G MDS line card, LED does not flash. However there is no impact in functionality
Conditions: No precondition required. For 40G MDS LC, LEDs do not glow while traffic IO.
Workaround: None
Further Problem Description: Running IO at 40G MDS line card, LED does not flash. However there is no impact in functionality.
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.176) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue51248 | Title: | Remove enum ONEP_IF_STATE_ADMIN_UP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Removal of ONEP_IF_STATE_ADMIN_UP
Conditions: Removal of ONEP_IF_STATE_ADMIN_UP
Workaround: Removal of ONEP_IF_STATE_ADMIN_UP |
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.2(0.78) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(2.13)S, 15.3(2.15.1)XEB, 15.3(2.6)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud75918 | Title: | An extra app-mode-prompt-prefix attribute is generated by xslt. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: An extra app-mode-prompt-prefix is generated by xslt. For example:
This causes the xsd validation fail.
Conditions: All
Workaround: When loading to the switch, use the generated xsd as it is. If the xsd is needed to be valid or used to generate xml serialization code, remove the extra app-mode-prompt-prefix. i.e. use
and then do the validation or code generation.
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.2(0.82s) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(1.14)PI22c, 15.3(2.2)T, 15.3(2.3.1)CG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud13458 | Title: | VRRPv3 : Feature vrrpv3 is not removed from ADMIN VDC after migration |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: After admin-VDC migration "feature vrrpv3" remains in the running-configuration of the admin-vdc.
Conditions: Only occurs when "feature vrrpv3" is configured, and admin migration has been initiated.
Workaround: After migration, perform the command "no feature vrrpv3". |
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.2(1) |
|
Known Fixed Releases: * | 15.1(1)IC66.5, 15.1(1)ICA4.3, 15.1(1)ICB40.1, 15.2(1.1)PSR, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(2.11)S, 15.3(2.4)T, 15.3(3)JA100 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue60063 | Title: | NXOS CD2: onep_intf_get_sub_intf_list returns parent, peer subinterface |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: If subinterface is passed to the onep_interface_get_sub_interface_list() API, it returns parent interface and the peer subinterface as well Conditions: Onep is enabled, and application is connected to UUT. Workaround: Call the API on the interfaces other than subinterface. |
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.2(1) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(2.15.4)XEB, 15.3(2.8.2)PIB23, 15.3(2.9)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue44348 | Title: | transport allows same port for TCP and TLS |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: The transport CLI allows the same port on tls and tcp Conditions: Nxos 110 Image was installed Workaround: None |
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.1(1) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(2.15.4)XEB, 15.3(2.8)T, 15.3(2.8.1)PIB23 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue71975 | Title: | NXOS CD2: OIREvent.getOIRType return unknown for all types |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: OIR event returns OIR type as ONEP_OIR_UNKNOWN for all of OIR event types (insert, remove, all) Conditions: Application is connected to the device and registered for OIR events. Workaround: None |
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.2(1) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(2.13)S, 15.3(2.15.1)XEB, 15.3(2.6)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue93156 | Title: | OWNER type for EIGRP/BGP/HSRP routes return incorrect value |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Using ONEPK if one try to develop application to read routes from the NE and the returned routes will have the incorrect owner type for the EIGRP,BGP and HSRP routes
Conditions: This is specific to ONEPK
Workaround: There is no workaround for this issue. |
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(2.15.4)XEB, 15.3(2.8.2)PIB23, 15.3(2.9)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum91499 | Title: | vsh core with "show l2vpn internal event-history events" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: VSH crash on "show l2vpn internal event-history events" or show tech {l2vpn|vpls}
Conditions: Unknown
Workaround: Do not issue these commands
Further Problem Description:
|
|
Last Modified: | 05-FEB-2016 |
|
Known Affected Releases: | 6.2(7.19)S0, 6.2(8)EC(0.10), 7.1(0)D1(0.19) |
|
Known Fixed Releases: * | 15.4(2)S0.4, 15.4(2)S1, 15.4(2)T1, 15.4(2)T1.1, 15.4(2.1.2)S, 15.4(2.15)S, 15.4(3)S, 15.4(3.6)PIB25, 15.6(1)SN, 6.2(0)HS(0.10) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul79113 | Title: | vpws_en bit is not reset when xconnect is moved between phy and efp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: vpws_en bit in eltm not cleared on removing ac member from xconnect
Conditions: VPWS service with either AC-AC or AC-PW xconnect
Workaround: Delete the xconnect to clear vpws_en bit in AC and then reconfigure as required
Repro-Steps ===========
Configure AC-PW xconnect, remove one member in xconnect.
SS-Eval =======
$NOSS
Please review,
Thanks
Wadood J Yahya [wyahya]
Further Problem Description:
|
|
Last Modified: | 05-FEB-2016 |
|
Known Affected Releases: | 6.2(5)MP(0.14) |
|
Known Fixed Releases: * | 15.4(2.11)S, 15.4(2.5)T, 15.4(3)S, 15.4(3.1)XEB, 15.4(3.6)PIB25, 15.6(1)SN, 7.0(0)BNZ(0.23), 7.0(0)KM(0.106), 7.1(0)D1(0.113), 7.1(0)FC(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo01824 | Title: | PW creation failure after delete/recreation in scale scenario |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Config rejected in Scale Scenario when User tries to add and delete around 8K PW. It applies only to PW Interfaces that are autogenerated.
Conditions: 1. Configured very high scale of PWs and/or VFI (8K). For PWs, "member " command is used, intead of "interface pw" 2. Remove and add the configuration without delay
Workaround: Small wait between consecutive config delete and add.
Further Problem Description:
|
|
Last Modified: | 05-FEB-2016 |
|
Known Affected Releases: | 6.2(8)S2 |
|
Known Fixed Releases: * | 15.4(2.17)S0.11, 15.4(3)M2.1, 15.4(3)M3, 15.4(3)M3.1, 15.4(3)S, 15.4(3)SN1a, 15.5(0.16)T, 15.5(0.16.1)CG, 15.5(0.20)PI27a, 15.5(1.2.1a)GB |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup00873 | Title: | EFP VC type changes after disable/enable L2VPN |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: show l2vpn service all shows VC type "Eth VLAN" instead of "Ethernet".
Conditions: This problem occurs when Ethernet service instance (EFP) config is added after L2VPN xconnect config.
Workaround: Add EFP config before L2VPN xconnect config.
Further Problem Description:
|
|
Last Modified: | 05-FEB-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.151), 7.1(0)ZD(0.200) |
|
Known Fixed Releases: * | 15.4(3)M2.1, 15.4(3)M3, 15.4(3)M3.1, 15.4(3)S0.1, 15.4(3)S1, 15.4(3)S2, 15.4(3)SN1a, 15.5(0.16)T, 15.5(0.16.1)CG, 15.5(0.20)PI27a |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun35120 | Title: | EoMPLS VC stays UP in case of MTU mismatch between the AC interfaces |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: VC aka PW remains up on Switchport AC MTU change.
Conditions: 1. Switchport AC configured as xconnect member 2. Change the MTU of switchport
Workaround: Shut and unshut the interface
Further Problem Description:
|
|
Last Modified: | 05-FEB-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.47) |
|
Known Fixed Releases: * | 15.4(2.12)S, 15.4(2.5)T, 15.4(3)S, 15.4(3.1)XEB, 15.4(3.6)PIB25, 15.6(1)SN, 7.0(0)BNZ(0.23), 7.0(0)KM(0.106), 7.1(0)D1(0.113), 7.1(0)FC(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo75830 | Title: | [XRUT] Unexpected state in RIB, ATOM observed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: With multiple VFIs configured with BGP-AD and LDP signaling, stale Pseudowires observed when changing back and forth L2 router-id and/or LDP router-id.
Conditions: 1- Configure multiple VFIs with BGP-AD/LDP-SIG 2- In a quick sequence, change L2 router ID and LDP router id back and forth.
Workaround: Do not change L2 router-id or LDP router multiple times quickly. Between each change, wait for a minute or two.
Further Problem Description:
|
|
Last Modified: | 05-FEB-2016 |
|
Known Affected Releases: | 7.2(0)MV(0.1) |
|
Known Fixed Releases: * | 15.4(3)M2.1, 15.4(3)M3, 15.4(3)M3.1, 15.4(3)S0.1, 15.4(3)S1, 15.4(3)S2, 15.4(3)SN1a, 15.5(0.16)T, 15.5(0.16.1)CG, 15.5(0.20)PI27a |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux15293 | Title: | RD config marks routes as invalid in BGP in a non mpls or evpn vrf |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: VRF routes within a VRF are marked as "path is invalid, no labeled nexthop" in BGP and not advertised to neighbors
Conditions: When RD is configured under the VRF using either "rd auto" or "rd ASN" and vrf isn't being used in mpls / evpn setup
Workaround: Remove RD from vrf context
Further Problem Description:
|
|
Last Modified: | 08-FEB-2016 |
|
Known Affected Releases: | 7.0(3)I2(1.1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.282), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.100) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux98681 | Title: | MRIB-3-MALLOC_FAILED: Include utilization/threshold alerts in syslog |
|
Status: * | Other |
|
Severity: * | 3 Moderate |
Description: | Symptom: MRIB-3-MALLOC_FAILED: mrib_smalloc() failed for mrib_mpib_route_datatype
Conditions: m4route-mem usage exceeded the limit set for the VDC at some point.
Workaround: Increase memory allocation for m4route-mem resources to avoid hitting critical state.
This bug is to add additional alerting around the m4route-mem usage.
Further Problem Description:
|
|
Last Modified: | 08-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy04933 | Title: | Wrong timestamps in netflow data |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom: Wrong timestamps in netflow data
Conditions: Unknown
Workaround: None
Further Problem Description:
|
|
Last Modified: | 09-FEB-2016 |
|
Known Affected Releases: * | 6.2(14), 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy28576 | Title: | Observed Lose Ejector Block on Pescarca-40 CB from Taurus Program |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom: Observed Lose Ejector Block on Pescarca-40 CB from Taurus Program
Conditions: Fit check
Workaround:
Further Problem Description:
|
|
Last Modified: | 13-FEB-2016 |
|
Known Affected Releases: | 9.9(9.9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur44587 | Title: | Route-map applied to RISE control VLAN after LC reload |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom: A route-map and ACL are created and applied to the RISE control vlan.
Conditions: A static route is configured on the N7K and the line card is reloaded.
Workaround: Manually remove the route-map from the RISE control vlan.
Further Problem Description:
|
|
Last Modified: | 15-FEB-2016 |
|
Known Affected Releases: * | 6.2(10)S102, 7.3(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue44687 | Title: | N7k - 'peer-switch' vpc feature affects non-vpc vlans |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom: when customer configures 'peer-switch' features under 'vpc domain' config mode, spanning-tree root changes even for vlans which are not enabled on vpc peer-link.
Impact of this is that customer cannot bring up (non vpc peer-link) link between two N7k switches - it gets blocked as a backup link, since both switches have same switch id.
Conditions:
Workaround:
Further Problem Description: This is expected behavior and will be documented Once peer-switch is enabled on the switches, both the N7Ks act as one system with one mac address as the bridge address. This is true for even for non-vpc mst-instance/vlans. So, a (non peer-link) link between the two N7Ks, just acts as loopback link on this system. This is the reason why one port is in forwarding, and the other in blocking.
|
|
Last Modified: | 15-FEB-2016 |
|
Known Affected Releases: * | 6.0(4), 7.0(3)I3(0.275) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui54200 | Title: | NAM DP-1 Port-Channel flaps once, after initiating ISSU/SSO command |
|
Status: * | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom: NAM DP-1 Port-Channel will flaps once momentarily, after ISSU command is initiated. User will see messages similar to the following:
2013 Aug 6 15:55:41 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DOWN_CFG_CHANGE: Interface port-channel4096 is down(Config change) N7k-16# 2013 Aug 6 15:55:41 N7k-16 %$ VDC-1 %$ %ETH_PORT_CHANNEL-5-PORT_DOWN: port-channel4096: Ethernet7/2 is down 2013 Aug 6 15:55:41 N7k-16 %$ VDC-1 %$ %ETH_PORT_CHANNEL-5-PORT_DOWN: port-channel4096: Ethernet7/1 is down 2013 Aug 6 15:55:42 N7k-16 %$ VDC-1 %$ %ETH_PORT_CHANNEL-5-FOP_CHANGED: port-channel4096: first operational port changed from Ethernet7/1 to none 2013 Aug 6 15:55:43 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface port-channel4096 is down (No operational members) 2013 Aug 6 15:55:43 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_BANDWIDTH_CHANGE: Interface port-channel4096,bandwidth changed to 10000000 Kbit 2013 Aug 6 15:55:43 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DOWN_CFG_CHANGE: Interface Ethernet7/1 is down(Config change) 2013 Aug 6 15:55:43 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_BANDWIDTH_CHANGE: Interface port-channel4096,bandwidth changed to 100000 Kbit 2013 Aug 6 15:55:43 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DOWN_CFG_CHANGE: Interface Ethernet7/2 is down(Config change) 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-SPEED: Interface Ethernet7/1, operational speed changed to 10 Gbps 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DUPLEX: Interface Ethernet7/1, operational duplex mode changed to Full 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface Ethernet7/1, operational Receive Flow Control state changed to off 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface Ethernet7/1, operational Transmit Flow Control state changed to off 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-SPEED: Interface Ethernet7/2, operational speed changed to 10 Gbps 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DUPLEX: Interface Ethernet7/2, operational duplex mode changed to Full 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface Ethernet7/2, operational Receive Flow Control state changed to off 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface Ethernet7/2, operational Transmit Flow Control state changed to off 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-SPEED: Interface port-channel4096, operational speed changed to 10 Gbps 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DUPLEX: Interface port-channel4096, operational duplex mode changed to Full 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface port-channel4096, operational Receive Flow Control state changed to off 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface port-channel4096, operational Transmit Flow Control state changed to off 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DOWN_CFG_CHANGE: Interface port-channel4096 is down(Config change) 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface port-channel4096 is down (No operational members) 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DOWN_CFG_CHANGE: Interface Ethernet7/1 is down(Config change) 2013 Aug 6 15:55:44 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DOWN_CFG_CHANGE: Interface Ethernet7/2 is down(Config change) 2013 Aug 6 15:55:46 N7k-16 %$ VDC-1 %$ %ETHPORT-5-SPEED: Interface Ethernet7/1, operational speed changed to 10 Gbps 2013 Aug 6 15:55:46 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_DUPLEX: Interface Ethernet7/1, operational duplex mode changed to Full 2013 Aug 6 15:55:46 N7k-16 %$ VDC-1 %$ %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface Ethernet7/1, operational Receive Flow Control state changed to off 2013 A |
|
Last Modified: | 15-FEB-2016 |
|
Known Affected Releases: | 6.2(2)S27 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup16042 | Title: | BUG0500645 : NS shows "ISSU in progress" even after process completes |
|
Status: * | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom: The Citrix Netscaler ADC shows ISSU status as "in-progress" for the affected RISE service in "show rise profile". It will stay in this state indefinitely.
Conditions: An ISSU is initiated on the Nexus 7000 switch while one or more RISE services are active.
Workaround: Reboot the NetScaler ADC or the Nexus 7000 switch.
Further Problem Description:
|
|
Last Modified: | 15-FEB-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.151) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy01671 | Title: | disabling partition is not working from DCNM after vrf flap. |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom: disabling partition using DCNM (deleting VRF is not working) Conditions:This issue happen when we manually shut/no shut vrf, after that we delete VRF through DCNM it take different path, it try to remove all sub commands under VRF and then finally remove VRF(which has issue). If we don't do shut/no shut to VRF then it follow different path which only delete VRF(This case work) Workaround:If we are Using DCNM then dont use manually command(shut/no shut VRF), if we happen to use Manual command then delete VRF manually
|
|
Last Modified: | 16-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy29267 | Title: | Nexus7k- not sending debug outputs to local log file |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom: Nexus7k- not sending debug outputs to local log file
Conditions: None
Workaround: None
Further Problem Description:
|
|
Last Modified: | 16-FEB-2016 |
|
Known Affected Releases: | 7.2(2.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq94800 | Title: | config/CLI issues for vrrpv3 done under a range of interfaces |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: If mac address is configured under pathway for a range of interfaces, say int vlan 2-200, the config does take effect(vMAC changes) but doesn't reflect in running-config or vrrp config
Conditions: Specific config to a range of interfaces
Workaround: Apply the config individually
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(10)S73 |
|
Known Fixed Releases: * | 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.2(0)AB(9), 7.2(0)BA(0.12), 7.2(0)D1(0.442), 7.2(0)D1(1), 7.2(0)N1(1), 7.2(0)PDB(0.379), 7.2(0)RTG(0.129), 7.2(0)VZN(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut46889 | Title: | OV intf stuck at "Cleanup in Progress" when bouncing overlay interface |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: OV intf stuck at "Cleanup in Progress" when bouncing overlay interface.
Conditions: Bring down and bring up link on overlay interface of secondary/backup adjacency server.
Workaround: Reload VDC (after the problem occurs).
To prevent this issue we need to make sure no IPv6 addresses are present on the join interfaces of all device connecting the unicast core on that overlay. This will prevent the secondary AS device to be stuck in the "Cleanup In Progress" state.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S28 |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.47), 7.3(0)SC(0.14), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut84448 | Title: | N7K - OSPF type problem when redistribution of static routes |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:When the next-hop of a route is being redistributed is replaced by more than one better next-hop, the protocol which was redistributing the route continues to advertise the old path. Conditions:A route is redistributed. More than one new next-hops from a different source replace the former next-hop for the route. Workaround:- Restart OSPF using 'restart ospf XXX'. - Instead of redistributing static routes with higher AD, redistributed with adjust metric.
More Info:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(13.4)S0, 6.2(14), 7.0(3)I2(0.545), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.2(1)D1(0.9), 7.2(1)D1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu30252 | Title: | N7K:aclmgr: cmd_dynamic_string_add bad item |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Access-list is completely not removed after executing the command no ip access-list [name] The command will be accepted but if you do "show ip access-list ? " then you still will be able to see that deleted access-list name
Conditions: Observed in 6.2.12 code
Workaround: None.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(12)E5 |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.23), 7.3(0)SC(0.14), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu70539 | Title: | N5K bgp process crash after configuring default-originate |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: N5K BGP process crash caused hap reset.
Conditions: Configure "default-originate route-map |
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.0(3)I2(0.470), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.0(7)N1(0.73), 7.0(7)N1(1), 7.0(7)ZN(0.154), 7.1(2)N1(0.576), 7.1(2)N1(1), 7.1(2)ZD(0.27) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur18621 | Title: | Show snmp trap cmd doesn't show status of msdp trap configs. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Status of MSDP trap is not shown in the output of 'show snmp trap'
Conditions: Trap type, Description and status is not shown for show snmp trap command for MSDP.
Workaround: None
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(10)S89 |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110), 7.1(0)AV(0.38), 7.1(0)EV(0.137), 7.1(0)PDB(0.317), 7.1(0)SIB(99.82), 7.2(0)D1(0.360), 7.2(0)D1(1), 7.2(0)N1(0.43) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu66267 | Title: | LISP: implicit iid 0 does not get assigned with proxy-itr configuration |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: LISP traffic encapsulated with no Instance-ID may fail to be forwarded on the eTR/PeTR
Conditions: The problem depends on configuration sequence and timing, i.e. is a race condition.
Workaround: Configure explicitly "lisp instance-id 0" in the VRF that receives LISP-encapsulated packet with no Instance-ID
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0.70), 7.3(0)ZD(0.10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 7.3(0)DHB(0.31), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.21), 7.3(0)SC(0.14), 7.3(0)ZD(0.85) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu39555 | Title: | Sometimes few HSRPVIP removed ISSU 6.0.2.N2(7)>7.0.6.N1(1)>7.2.0.N1(1) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: IP address with be removed after we do ISSU from "H+MR6 [6.0(2)N2(7)] to IMR5[7.0(6)N1(1)] then to JJ[7.2(0)N1(1)]"
Conditions: Need to perform 2step ISSU from H+MR6 [6.0(2)N2(7)] to IMR5[7.0(6)N1(1)] then to JJ[7.2(0)N1(1)] with virtual ip configured in HSRP. After doing ISSU from H+MR6 to IMR5 ISSU will succeed, then when we do ISSU from IMR5 to JJ, will get below error
<<<%NETSTACK-2-CRIT_FAILURE: netstack [4007] Failed to configure IP address on Vlan834. IP address overlaps with one of the address configured on Vlan833. Vlan834 has been shutdown.Please change the IP address to avoid overlap and perform a "no shutdown">>> and ip address will be removed on the vlan or vlan interface will be shutdown.
Workaround: Need to reconfigure the ip address after correcting the network mask of HSRP ip in the vlan.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.206) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.0(0)FHS(0.23), 7.3(0)D1(0.45), 7.3(0)D1(1), 7.3(0)DHB(0.14), 7.3(0)HM(0.47), 7.3(0)IB(0.35), 7.3(0)MMD(0.9), 7.3(0)N1(0.61), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub06428 | Title: | route-target export not removed from config after "no route-target <RT>" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: "no route-target export |
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(0.1) |
|
Known Fixed Releases: * | 15.4(1.10)S, 15.4(1.10)T, 15.4(1.9.1)XEB, 15.4(2)S, 15.4(2.1.1)S, 15.6(1)SN, 6.0(2)N3(0.117), 6.0(2)N3(1), 6.2(0)HS(0.10), 6.2(9)FM(0.37) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut75788 | Title: | CC reports inconsistency for TEP prefixes in vxlan-evpn setup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: When consistency checker is run on the vxlan/evpn setup route inconsistencies would be reported for TEP prefixes.
Conditions: When consistency checker is run on the vxlan/evpn setup route inconsistencies would be reported for TEP prefixes.
Workaround: NONE
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.1(1)BT(0.2), 7.2(0)D1(0.451) |
|
Known Fixed Releases: * | 7.2(1)D1(0.43), 7.2(1)D1(1), 7.2(1)ZD(0.37), 7.3(0)D1(0.74), 7.3(0)D1(0.79), 7.3(0)D1(1), 7.3(0)D1(1A), 7.3(0)EG(0.3), 7.3(0)IB(0.67), 7.3(0)MMD(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv34380 | Title: | vPC switch keeps sending (S, G) joins even after (*, G) entry gone. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: PIM (S, G) joins are sent upstream even when corrosponding (*, G) entry has expired.
Conditions: vpc-peers with "ip pim pre-built spt" configured. Active source but receivers are expired.
Workaround: clear ip mroute will remove the unwanted (S, G) entry.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)ZD(0.99) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 7.3(0)DHB(0.31), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.43), 7.3(0)SC(0.14), 7.3(0)ZD(0.85) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu15391 | Title: | vsi config is allowed on range of interface even with switchport |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | The issue is that "service instance" (vsi) command is visible under a "range of parent port interfaces" even though few or all of the parent ports are configured as switchport. If a parent port is switchport vsi command should be rejected or not be visible.
Symptom: If a parent port in the range command is switchport vsi command should be rejected or not be visible.
Conditions: Configuration time: The issue is that "service instance" (vsi) command is visible under a "range of parent port interfaces" even though few or all of the parent ports are configured as switchport. If a parent port is switchport vsi command should be rejected or not be visible.
Workaround: Do not configure a VSI under a range of parent ports if few or all parent ports are switchport configured.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.490) |
|
Known Fixed Releases: * | 7.3(0)D1(0.42), 7.3(0)D1(0.43), 7.3(0)D1(1), 7.3(0)DHB(0.14), 7.3(0)HM(0.36), 7.3(0)OTT(0.14), 7.3(0)PDB(0.15), 7.3(0)RTG(0.44), 7.3(0)ZD(0.56) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu36071 | Title: | Packets encaped with wrong VNI after addition of new link to Peerlink PC |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Receivers at remote vxlan L2 gateway may experience traffic lose. This is because the packets at vPC L3 gateway is encapped with wrong VNI value. This can be confirmed by examine the VNI field of the vxlan encapped packet received at remote L2 gateway.
Conditions: The condition to hit the issue is to configure new vPC peer-link in a new hardware instance. This may cause timing issue when program the encap route in the new peer-link instance.
Workaround: unconfig, then reconfig the multicast encap for this bridge-domain under nve interface will clear the wrong encap route and reprogram with correct information.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.490), 7.2(0)VZD(0.33) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.1(0)ES(0.24), 7.2(1)D1(0.36), 7.2(1)D1(1), 7.2(1)ZD(0.31), 7.3(0)D1(0.34), 7.3(0)D1(0.45), 7.3(0)D1(0.52), 7.3(0)D1(0.53), 7.3(0)D1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut71442 | Title: | "PIM Data Register" debug message missing after receiving data packets |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: When the FHR receives the data packets, a data register is sent to the RP. As part of the conformance test, the script expects following debug msg - 2014 Dec 2 00:58:13.070567 mcastfwd: libpim [6339] Sent PIM Data Register for (10.10.2.201, 239.23.23.23) to RP 10.10.10.1, ttl 254 (1 registers in last sec)
But the above debug is not observed on the console
Conditions: There is no functionality impact here. Only when we enable mcastfwd debugs, we expect the debugs to show up on the console but for some reason the debugs are not showing up on the console.
Workaround: No workaround. The bug is purely for development purpose.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.475), 7.2(0)D1(0.499), 7.2(1)D1(0.54) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.54), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw81451 | Title: | Changing member priority is not reflected properly in PWRED mbackup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: 1. set up PWRED with multiple backup.
l2vpn xconnect context foo member e1/1.1 member pseudowire 100 group blue priority 1 member pseudowire 101 group blue priority 3 member pseudowire 102 group blue priority 5 member pseudowire 103 group blue priority 7
where the pseudowire 100 is the highest priority PW and currently active,
change the configuration such that member pseudowire 102 has priority 0, and it should become the active PW, but it is not.
Conditions: When set up is PWRED with multiple backup, and trying to change the priority of the PW in the configuration to change the active PW.
Workaround: There is no work around
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 5.2(0)LV1(0.150) |
|
Known Fixed Releases: * | 15.2(2.9)S, 15.2(4)S, 15.3(0.15)PI21b, 15.3(1.1)T, 15.6(1)SN, 7.3(0)D1(1), 7.3(0)IB(0.72), 7.3(0)RTG(0.78), 7.3(0)ZD(0.114), 7.3(0)ZN(0.125) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut75242 | Title: | ISSU upgrade: igmp HAP reset |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom: An ISSU upgrade on a Nexus 6000 experiences a HAP reset when upgrading to 7.0(5)N1. On the vPC peer, each chassis crashes while the other is in the process of upgrading:
At 764728 usecs after Reason: Reset triggered due to HA policy of Reset Service: igmp hap reset Version: 7.0(2)N1(1) << crash on standby as primary is in the process of upgrading during ISSU At 203979 usecs after Reason: Reset triggered due to HA policy of Reset Service: igmp hap reset Version: 7.0(5)N1(1) << crash on primary as standby is in the process of upgrading during ISSU
Conditions: The device(s) experiences an 'igmp' process HAP reset during this upgrade regardless of whether or not the Aggregate is provisioned for igmp/multicast.
Workaround: N/A
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.117) |
|
Known Fixed Releases: * | 7.0(3)I2(0.519), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.0(7)N1(0.293), 7.0(7)N1(1), 7.0(7)ZN(0.188), 7.2(1)D1(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug65911 | Title: | bgp-ad/ldp-sig vc's are not setup when vpls-id is changed & reverted |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: VC is not set up when we set explicit vpls-id in bgp autodiscovery config with ldp signalling.
Conditions: This condition occurs when VPLS service is configured with BGP autodiscovery and LDP Signalling is used. Issue is seen when:
1. Change in the VPLS-ID in both PEs while the VFI is up. This change in VPLS is triggered from config. 2. Reverting back the vpls-id to its original value will still not get the VC up.
Workaround: Reconfigure VPN on both PEs. Do not change or configure vpls-id if not absolutely essential.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(1.143)S8, 6.2(1.91)S3, 6.2(2)S23 |
|
Known Fixed Releases: * | 15.4(1.14)S, 15.4(1.14.11)PIH24, 15.4(1.19)T, 15.4(1.20)PI25, 15.4(1.9.2)XEB, 15.4(2)S, 15.4(2.1.1)S, 15.6(1)SN, 6.0(2)N3(0.117), 6.0(2)N3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux09435 | Title: | N7K - MSDP SA information not exchange after reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Source Active messages not sent to MSDP peers after router reload.
The MSDP session is established, control messages exchanged periodically to keep state up, but SA not created/exchanged.
Conditions: Anycast RP with MSDP implementation. Issue occurs after device reload with overlapping RP groups.
Workaround: The issue clears and SA exchange resumes after MSDP process restart
restart msdp
Further Problem Description:
|
|
Last Modified: | 19-FEB-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.156), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.3(0)D1(0.156), 7.3(0)D1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut22695 | Title: | "mts_drop:2265 proc(/isan/bin/acllog) errno(22)" msg seen in 7.2.0.D1 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: "show logging ip access-list internal event-history errors throws errors"
Conditions: Configure access list (RACL/VACL/PACL) on any interface. Pump traffic through that interface so that there is a hit on the packet because of configured access-list. Then run "show logging ip access-list internal event-history errors throws errors"
Workaround: This is not breaking any functionality. Its just reported in event-history debug message
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.409), 7.2(0)D1(0.437), 7.2(1)D1(0.54), 7.3(0)ZD(0.23), 7.3(0)ZD(0.49), 8.3(0)CV(0.183) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.8), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.213), 8.3(0)KMS(0.20) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw99736 | Title: | Pim hellos should be sent with DR-Prio 0 during DR-delay timer |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: PIM neighbor ship formation delay.
Conditions: Reload of router. Interface shut/no shut.
Workaround: Configuring Pim-Dr delay timer as 0.
Further Problem Description:
|
|
Last Modified: | 19-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1.9) |
|
Known Fixed Releases: * | 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)RTG(0.104), 7.3(0)SC(0.14), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw47708 | Title: | N7K - sub-int populated in ciscoCdpMIB even after CLI removal of sub-int |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: N7K/N77 - sub-interface(s) populated in ciscoCdpMIB even after CLI removal of sub-interface
Conditions: Port config includes sub-interface configuration(s). Only relates to sub-interfaces. If no sub-interfaces are configured, then this problem does not exist.
Workaround: WORKAROUNDS: 1.) Stop and restart cdp process 2.) Reload the module. 3.) Reload the switch
Further Problem Description: Extra cdp entries can exist in SNMP that does not exist in CLI.
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.82) |
|
Known Fixed Releases: * | 7.3(0)D1(0.173), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.122), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu32143 | Title: | [VxLAN EVPN] N7k sup standby is allowing to execute critical restart CLI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: restart bgp <> on sup-standby causes the sup console to hang for around 10+ minutes.
Moreover, this is not just for BGP but also for other options like restart ospf /eigrp.
Conditions: in sup-standby we have restart cli's. PE11(standby)# restart ? amt Restart the AMT multicast routing protocol bgp Border Gateway Protocol (BGP) eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) igmp Restart the IGMP multicast routing protocol ospf Open Shortest Path First (OSPF) PE11(standby)#
B_Spine1(standby)# sh clock Time source is NTP 23:53:32.203 UTC Thu May 07 2015 B_Spine1(standby)# restart bgp 65001 <<<<< hangs here B_Spine1(standby)# sh clock Time source is NTP 00:04:14.116 UTC Fri May 08 2015 B_Spine1(standby)#
Workaround: This CLI should not be used in stand-by as it could lead system to unknown state.
Further Problem Description: restart cli shouldn't be allowed to execute in the stand-by SUP and the CLI will be blocked.
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.493) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)IB(0.11), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut10399 | Title: | MAC address flooding on F3 linecard |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Brief flooding is noticed when vPC leg, on which the mac-address is learnt, is shut.
Conditions: 1. Happens only on F3 modules. 2. The mac-address is learnt only on one leg of vPC due to polarized flow.
Workaround: No work around- default behavior.
Further Problem Description: Per original design, when vPC leg is shut, the mac-address aging logic purges the mac-address if it was learnt only on that vPC leg causing a temporary flooding till the mac-address is learnt on the other vPC leg.
This fix provides a configuration knob ?mac address-table aging-mode portchannel-refresh? to prevent the temporary flooding. Rather the MAC would wait for a full age cycle across all the members before it would get purged.
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(12), 7.3(0)D1(0.64) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.27), 6.2(14)FB(0.29), 6.2(14)FB(0.30), 7.3(0)D1(0.162), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.93), 7.3(0)RSP(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw09891 | Title: | BGP peers flap continuously |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom: BGP peers will flap continuously and not stabilize even after several hours have passed.
Conditions: Outbound policy with multiple AS Path regex matches that deny the route, coupled with non-default holdtimers (4/12, 10/30).
Workaround: Change holdtimer to default values. Simplify the regex is possible and match the access-list *after* the prefix list in the route-map sequence.
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(10)S102 |
|
Known Fixed Releases: * | 7.3(0)D1(0.171), 7.3(0)PDB(0.131), 7.3(0)RSP(0.7), 7.3(0)RTG(0.71), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus61895 | Title: | MPLS:Inconsistent routes with MPLS in 6.2.12.S26 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Routes going over mpls next-hops may be falsely reported as "inconsistent in software".
Conditions: Routes going over mpls next-hops may be falsely reported as "inconsistent in software".
Workaround: none
Further Problem Description: Routes going over mpls next-hops may be falsely reported as "inconsistent in software". This does not impact traffic, rather is a false +ve that may be ignored.
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(12)S26, 7.2(1)D1(0.49) |
|
Known Fixed Releases: * | 7.3(0)D1(0.126), 7.3(0)D1(1), 7.3(0)OTT(0.73), 7.3(0)PDB(0.74), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur09129 | Title: | Snmp walk on syslogMessageSeverity returns raw enum 3112 for vmm. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: SNMP query for syslogMessageSeverity returns raw enum 3112 for VMM facility.
Conditions: SNMP query for syslogMessageSeverity.
Workaround: It is just display issue.
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(10)S87 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.29), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy36418 | Title: | N7K: Doc bug regarding rebind interfaces requirement |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom: This is a documentation bug to remove the following statement from the documentation linked below:
"Beginning with Cisco NX-OS Release 6.2(2), F2e module type can exist with M1, M1XL, and M2XL module types in the same VDC. You do not need to enable the interface rebind process using the rebind interfaces command. The interface rebind process is meant for earlier releases." http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/nx-os/virtual_device_context/configuration/guide/b-7k-Cisco-Nexus-7000-Series-NX-OS-Virtual-Device-Context-Configuration-Guide/managing-vdc.html#concept_90BEF2977FAE454CA21D6D33F22A07A9
This implies that an interface rebind is never required with 6.2(2) and later which is incorrect. This should be replaced with the following:
"Note - On 6.2(8) and later, the user is now presented with a yes/no prompt if the interface rebind is required, opposed to having to manually enter the rebind interfaces command."
Conditions: Modifying VDC module type allocations on a Nexus 7000 Series Switch via the "limit-resource module-type" command.
Workaround: If the switch prompts that rebind interfaces is needed than proceed with it.
Further Problem Description:
|
|
Last Modified: | 19-FEB-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc27224 | Title: | FEX : MTU not Configurable on Sattelite Ports |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: The following message is seen when configuring MTU on a FEX port:
Error: MTU cannot be configured on L2 satellite port(s)
Conditions: Occurs while configuring jumbo MTU for a FEX port.
Workaround: Configure MTU on Fabric ports (between N7K and N2K). This configuration will be used for the FEX interfaces.
Additional Information: This is expected behavior. MTU cannot be configured on FEX ports. |
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 5.0(0.124f) |
|
Known Fixed Releases: * | 5.0(0.124f), 5.0(1), 5.1(0.28), 5.1(0.8), 5.1(1), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsv61257 | Title: | Netflow : exporter command causes "aclqos" crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom :
Addition or removal of "exporter" in flow monitor causes "aclqos" crash when flow entry exists on a LC. Multiple LCs crash if flow entries exist on multiple LCs. LCs that crashed due to this gets failure status and needs to be reloaded.
Condition :
- Seen with 4.0(3) and 4.0(4) image. - When add or remove an exporter. - Flow entry exists on LC. - ip flow monitor configured to vlan |
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 4.0(4) |
|
Known Fixed Releases: * | 4.1(1.66), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf60852 | Title: | AP port connected to AIDA port is error disabled due to unknown enum 223 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
AIDA port is in err-disable state due to "unknown err num 223"
Condition: The problem will be seen if the connected peer port is dcbx capable and is sending dcbx tlv while the local port is not sending any dcbx tlv.
Workaround(s): None. The problem is fixed in 5.1(1) |
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 5.1(0.43) |
|
Known Fixed Releases: * | 5.0(3)S32, 5.0(3.41)S0, 5.1(0.78a), 5.1(0.85), 5.1(0.92), 5.1(0.92)S9, 5.1(0.94), 5.1(1), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn78549 | Title: | Non PI Mac address missing in FE ( 5.1.3) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom: Remote macs are not populated on fabricpath port fes according to mcm membership for M1 - F1 chassis
Conditions: Two members of same fe(x & y) belong to same fabricpath port-channel( containing any number of port-channel members) and one of them is brought down(x or y).
Workaround(s): After bringing down one of the members(x or y) in the above mentioned condition, shut/no shut on the port-channel will restore normal working
This is only for fabricpath enabled switches
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 5.1(3)S31 |
|
Known Fixed Releases: * | 5.2(1)S17, 5.2(1.20)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto01869 | Title: | MAC addr not re-learnt after"clear mac addr dyn intf" when int peer-link |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptoms MAC addresses are not learned on the modules in an Nexus 7000, although the supervisor appears to learn them correctly.
This results in unicast flooding.
In other words, a MAC will be seen the output of "show mac address dynamic", but will not be seen in "show mac address-table dynamic" or "show hardware mac address-table dynamic"
Conditions This is seen whenever the dynamic MAC entries have been cleared on that interface via the command "clear mac address-table dynamic interface "
Workaround Avoid using the "clear mac address-table dynamic interface" command. If you clear all MAC address globally using "clear mac address-table dynamic" the issue is not seen.
Once in the error condition, you can recover by flapping the link. |
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 5.1(3), 5.2(0.909)S1 |
|
Known Fixed Releases: * | 4.2(8)S12, 4.2(8.49)S0, 5.1(10.1)S0, 5.1(3)E5, 5.1(4)S0, 5.2(1)S17, 5.2(1.20)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua85526 | Title: | qos stats shows a huge and incorrect value after ISSU from 5.2(5) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Byte statistics for QoS policy-map classes show huge values after ISSU from 5.2 releases.
Conditions: There has been traffic, matching the applied policy-map classes in earlier releases and ISSU upgrade to 6.x release is done.
Workaround(s): Doing 'clear qos statistics' would clear the incorrect statistics and further statistics collection in 6.x would reflect the actual numbers for byte statistics. |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 6.1(1)S16, 6.1(1)S22 |
|
Known Fixed Releases: * | 6.1(1.76)S0, 6.1(2), 6.2(0.285), 6.2(2), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua44951 | Title: | Traffic Block when wccp redirect acl contains deny for the subnet |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ICMP / All Traffic will be blocked to a network segment if WCCP redirect list contains deny entry for it
Conditions:
When WCCP redirect out is configured
Workaround:
Remove WCCP redirect statement and re-apply. OR remove deny statement from ACL |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 6.0(3) |
|
Known Fixed Releases: * | 6.1(1)S13, 6.1(1.11)S0, 6.2(0.217), 6.2(2), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua07528 | Title: | L3 Multicast 1 to 1 low peformance numbers on Autodromo 40G |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Low performance numbers seen from 1024 to 9216 B FS for L3 Multicast
Conditions: The performance numbers from 1024 to 9216 B FS for L3 Multicast are lower on Sup2 when compared to Sup 1
Workaround: Currently no work around available. |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 6.1(0.293)S5 |
|
Known Fixed Releases: * | 6.1(1)S13, 6.1(1.12)S0, 6.2(0.217), 6.2(2), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy11493 | Title: | Errors ""tlvu_table_convert_tlv_to_indv_field" when issuing startup |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom: Seeing errors when issuing a 'show startup' after upgrading to 7.2(0)D1(1).
Conditions: Not known.
Workaround: None at this time.
Further Problem Description:
|
|
Last Modified: | 22-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua88996 | Title: | PortLoopback test failed after reset a monitor port to default config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: PortLoopback test fail after default a monitor port.
Conditions: Configure a port as monitor port and use default interface to reset
Workaround: shut, then no-shut the interface.
|
|
Last Modified: | 22-FEB-2016 |
|
Known Affected Releases: | 5.2(5), 5.2(7)S12, 6.0(3) |
|
Known Fixed Releases: * | 5.2(6.16)S0, 5.2(7), 6.1(1)S31, 6.1(1.33)S0, 6.1(1.69), 6.2(0.217), 6.2(2), 7.2(0)VZN(0.30), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui15370 | Title: | Intermittent CHASSIS-PS_INTR failure Emerson PS across all corners |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: During the diag test CHASSIS-PS_INTR test failure is seen intermittently across all corner conditions.
Conditions: Diag Image Used: diag-sup3dc3-el-6.2.0.238d1.046.gbin diag-n7k-6.2.0.238d1.046.mzg
Failing Corners: Failure seen at NT/NV, HT/NV, and LT/NV
Workaround: Test was skipped to avoid further failure since the fix is not available at this time.
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.2(0.302)S24 |
|
Known Fixed Releases: * | 6.2(10)FM(0.3), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(0)KM(0.64), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq79793 | Title: | IPv6 ND processes NA with Link-layer address 0000.0000.0000 as valid |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom: IPv6 ND will install a neighbor entry for an IPv6 host that sends a NA who's Link-layer address field is populated with mac address 0000.0000.0000: N7K# show debug logfile arp 2010 May 15 01:07:49.931933 icmpv6: Received NA from 2405:200:311:51::11 on Vlan666(Ethernet8/3)(Ethernet8/3) to 2405:200:311:51::1, length: 32, hop_limit: 254, ismct: 0, peergwayrx: 0 2010 May 15 01:07:49.932089 icmpv6: NA has flags: RSO 2010 May 15 01:07:49.932103 icmpv6: "Target Link-layer Address" TLV present 2010 May 15 01:07:49.932118 icmpv6: icmpv6_nd_check_adjacency: nd_adj 0x9107f94 got from ICMPv6 iftype for neighbor 2405:200:311:51::11 (0 3 1) on interface Vlan666 2010 May 15 01:07:49.932130 icmpv6: icmpv6_nd_get_adjacency: (0x9107f94) Found adjacency 2405:200:311:51::11 (0 3 1) in SDB on interface Vlan666 2010 May 15 01:07:49.932168 icmpv6: icmpv6_nd_add_adjacency: (0x9107f94) adj_mac: 0000.0000.0000, mac in packet: 0000.0000.0000, stale_request: 0 2010 May 15 01:07:49.932190 icmpv6: icmpv6_nd_start_reachable_timer: (0x9107f94) Set expires timer to 22 sec for a neighbor 2405:200:311:51::11 (0 0 0) on Vlan666 2010 May 15 01:07:49.932209 icmpv6: icmpv6_nd_set_reachable_state: (0x9107f94) Entering REACHABLE state from INCOMPLETE for 2405:200:311:51::11 (0 0 0) on interface Vlan666 2010 May 15 01:07:49.932254 icmpv6: icmpv6_nd_add_adjacency: (0x9107f94) Update timestamp for neighbor 2405:200:311:51::11 (0000.0000.0000) (0 0 0) learnt on interface Vlan666 in SDB. local_ptr: 0x9107f94 2010 May 15 01:07:49.932283 icmpv6: ----- 2010 May 15 01:08:11.944708 icmpv6: icmpv6_nd_ager (0x9107f94) Current State REACHABLE 2010 May 15 01:08:11.944850 icmpv6: icmpv6_nd_set_stale_state: (0x9107f94) Entering STALE state from REACHABLE for 2405:200:311:51::11 (0 0 0) on interface Vlan666 2010 May 15 01:08:11.944864 icmpv6: icmpv6_nd_set_stale_state: (0x9107f94) Set expires timer to 1476 sec for a neighbor 2405:200:311:51::11 (0 0 0) on Vlan666 F340.14.06-7700-1# sh ipv6 neighbor Flags: # - Adjacencies Throttled for Glean G - Adjacencies of vPC peer with G/W bit IPv6 Adjacency Table for VRF default Total number of entries: 1 Address Age MAC Address Pref Source Interface 2405:200:311:51::11 00:04:13 0000.0000.0000 255 icmpv6 Vlan666
Conditions: Nexus 7000 or 5000 receives an IPv6 Neighbor Advertisement from a host with the following MAC address populating the Link-layer address field: 0000.0000.0000
Workaround: None.
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S77, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.303), 7.1(0)OTT(0.41), 7.1(0)PDB(0.249), 7.1(0)ZD(0.348) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy41083 | Title: | Nexus 7000: snmp operations on IF-MIB returns zero value |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom: SNMP operations on a Nexus 7000 switch running , returns a zero value for objects such as ifHCInMulticastPkts, ifHCInUcastPkts, ifHCOutOctets, ifHCInOctets etc intermittently.
Conditions: SNMP operations on a Nexus 7000 switch running , returns a zero value for objects such as ifHCInMulticastPkts, ifHCInUcastPkts, ifHCOutOctets, ifHCInOctets etc intermittently.
Workaround:
Further Problem Description: NMS cannot manage N7K switch .
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.1(2)S9 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux94893 | Title: | N77: There is difference to detect removing linecard by slot number |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: N77: There is difference to detect removing linecard by slot number
Conditions: - port-channel member port is in one slot. - when remove module, there is difference by slot number. - time for down lag - remove connected route - slot of highest number is about one second. - slot of lowest number is about three seconds.
Workaround: none in this time.
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: * | 6.2(16)S39, 7.3(0)DX(0.91) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux41326 | Title: | Evaluation of n7k-infra for OpenSSL December 2015 vulnerabilities |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Cisco MDS 9000 Series Multilayer Switches ;Cisco Nexus 5000 Series Switches;Cisco Nexus 6000 Series Switches;Cisco Nexus 7000 Series Switches; includes a version of OpenSSL that is affected by the vulnerability identified by one or more of the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-3193, CVE-2015-3194, CVE-2015-3195, CVE-2015-3196 and CVE-2015-1794
And disclosed in http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20151204-openssl
This bug has been opened to address the potential impact on this product.
Conditions: Exposure is not configuration dependent.
Cisco has reviewed and concluded that this product is affected by one or more of these vulnerabilities.
Cisco MDS 9000 Series Multilayer Switches ;Cisco Nexus 5000 Series Switches;Cisco Nexus 6000 Series Switches;Cisco Nexus 7000 Series Switches; is affected by:
CVE-2015-3194 and CVE-2015-3195
Cisco MDS 9000 Series Multilayer Switches ;Cisco Nexus 5000 Series Switches;Cisco Nexus 6000 Series Switches;Cisco Nexus 7000 Series Switches; is not affected by:
CVE-2015-3193, CVE-2015-3196 and CVE-2015-1794
Workaround: Not available.
Further Problem Description: Additional details about those vulnerabilities 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: 4.3/3.4
http://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.235), 7.3(0)N1(0.252), 7.3(0.99) |
|
Known Fixed Releases: * | 6.2(16)S39 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur57084 | Title: | FEX Core Fails to Upload in Non-default VDC - No Workaround on NPE Image |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Nexus 2000 may fail to copy the core file to the Nexus 7000 during a crash but continues to try over and over: N7k-2 SYSMGR-FEX101-3-CORE_OP_FAILED Core operation failed: send_msg_to_ccdmon: Could not send to CORE_DMON return -1 errno 32 N7k-2 SYSMGR-FEX101-5-SUBPROC_TERMINATED "System Manager (core-client)" (PID 1903) has finished with error code SYSMGR_EXITCODE_CORE_CLIENT_ERR (11).
Conditions: When the Nexus 2000 connected to a non-default VDC crashes.
Workaround: Contact Cisco TAC.
Further Problem Description: Fix is present starting in 7.2. Issue exists in all releases prior to 7.2.
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)FHS(0.23), 7.0(0)HSK(0.395), 7.0(0)KM(0.119), 7.0(0)KMS(0.11), 7.0(2)FIP(0.19), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)IB(122), 7.1(0)SIB(99.109) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue31348 | Title: | tacacsd process crash during authentication/authorization |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: tacacsd process in NX-OS can crash during authentication/authorization. Seen on both N7K and N6K platforms.
Conditions: dns lookup for the authenticated host results in more than 4 entries
Workaround: Disable dns resolution on switch "no ip domain-lookup"
Further Problem Description: The tacacsd core files may be written to /var/sysmgr/logs and must be retrieved via a debug plugin to grant access to the linux shell. The file permissions must be changed from the shell in order for the core files to be copied off the switch.
Linux(debug)# ls -l total 974920 -rw------- 1 root root 250216448 Apr 10 15:35 core.13815 -rw------- 1 root root 250216448 Apr 10 17:57 core.16590
Linux(debug)# chmod 777
Contact TAC in order to verify this issue.
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 6.1(2), 6.2(1), 7.1(0)N1(0.339) |
|
Known Fixed Releases: * | 5.2(1)N1(7.108), 5.2(1)N1(8), 5.2(9), 5.2(9)S57, 5.2(9.104)S0, 6.1(4.10)S0, 6.1(4.11)S0, 6.1(5), 6.2(1)S15, 6.2(1)S17 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux80178 | Title: | SSTE: Error for ISIS topology changes during ISSU for BD Flood prog |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: PIXM syslog seen if there is any change in topo during ISSU
Conditions: Topo change when LC ISSU going on.
Workaround: No functional impact because ISSU done should automatically will recover.
Further Problem Description:
|
|
Last Modified: | 25-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.194) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DX(0.87) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy47125 | Title: | cshcNetflowResourceUsageTable return incorrect values in SNMP |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom: Object cshcNetflowResourceUsageTable from CISCO-SWITCH-HARDWARE-CAPACITY-MIB returns incorrect values for Netflow utilization.
Conditions: None.
Workaround: N/A
Further Problem Description: |
|
Last Modified: | 25-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy16984 | Title: | 'otm' core on N7K running 7.3_D1_S12 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: When "show track" CLI is issued, there is a possibility that OTM might crash.
Conditions: Some track objects are configured and at least one client like HSRP is tracking it.
Workaround: Instead of running "show track", we can retrieve each object track info using CLI "show tack <1-500>"
Further Problem Description:
|
|
Last Modified: | 25-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DX(0.94) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy49752 | Title: | N7K-C7700 : Unable to manually walk nexus coppoids cbQosPoliceStatsTable |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom: Cu reported, they are not able to poll CoPP OIDs ( cbQosPoliceConformedPkt64 & cbQosPoliceViolatedPkt64) for their Nexus 7700 SWs. NX-SW - Nexus7700 NX-OS version : 6.2(10)
Conditions: This issue is noticed for only Nexus 7700 platform release : 6.2(10). Not applicable for Nexus 70xx platforms.
Workaround: None
Further Problem Description: BU DE team identified as the other bug fix brake the CoPP MIB functionality. Engineering team confirmed that, this issue is exist in 6.2.12 and 6.2.14 releases also.
|
|
Last Modified: | 27-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux47285 | Title: | LISP: race condition LISP/RIB when programming FIB |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: In a LISP ESM deployment a host/VM that has been detected on one DC moves (EAST-WEST) accross the DCI. A map-cache for the host is installed on the original DC site to forward traffic to the new DC, however traffic is lost.
A detailed observation of the forwarding table reveals that the map-cache is not present in the forwarding table, but a punt route to the supervisor (that corresponds to the lisp null0 (away) route installed by lisp).
Conditions: The origin of the problem is a race condition between LISP and uRIB were the order in which LISP writes the map-cache and away routes is not kept when writing down to forwarding.
Both the away route and the map-cache are installed in close time proximity to each other and end-up written in reverse order. The end result is that the away route is written later and overwrites the map-cache in the linecard.
Workaround: Clearing the specific map-cache will solve the problem (it triggers a rewrite of the forwarding entry)
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.194), 7.3(0)D1(1), 7.3(0)HIB(0.3), 7.3(0)IZN(0.13), 7.3(0)N1(0.249), 7.3(0)N1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.211), 7.3(0)ZN(0.225), 7.3(1)PDB(0.19) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux70796 | Title: | CFD: CSCtr11247 - UDLD enabling CDP CFD failed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: "udld enable" command is not configurable on copper ports. This command is rejected with the message below -
"ERROR: UDLD is rejecting a config that is valid only for the copper port on: Ethernet3/31."
Conditions: This command is working fine on fiber ports but not on copper ports.
Workaround: no workaround.
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.178) |
|
Known Fixed Releases: * | 7.3(0)D1(0.200), 7.3(0)D1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.228), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux48649 | Title: | OTV with F3 can only support 50 data-groups after AED failover |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: On a Nexus 7xxx chassis when using F3 modules for OTV; if the OTV data-group range is configured with a larger subnet mask than /27, some multicast groups could fail to pass across the OTV.
Conditions: The following things need to happen to see this issue:
1) Have a data-group range configured under the overlay with a subnet mask greater than /27 2) Have experienced an AED failover event
Workaround: Reduce the subnet mask on the OTV data-group to /27 to /32.
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 6.2(14), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 6.2(16)S10, 7.3(0)D1(0.197), 7.3(0)D1(1), 7.3(0)HIB(0.3), 7.3(0)RSP(0.7), 7.3(0)ZD(0.224), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux52081 | Title: | N7k: Spacing issue in show snmp community. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: show snmp community.
Conditions: show command/SNMP
Workaround: NA
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.142), 7.3(0)D1(0.190), 7.3(0)DX(0.40) |
|
Known Fixed Releases: * | 7.3(0)D1(0.198), 7.3(0)D1(1), 7.3(0)HIB(0.3), 7.3(0)IZN(0.13), 7.3(0)N1(0.258), 7.3(0)N1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.225), 7.3(0)ZN(0.234), 7.3(1)PDB(0.19) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux14098 | Title: | N7K/N77: write error: No space left on device |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: After issue : switchto vdc <> error message:AQ6-PT-7010-03# switchto vdc ixIA /isan/bin/first-setup.core: line 45: echo: write error: No space left on device date: write error: No space left on device /isan/bin/first-setup.core: line 47: echo: write error: No space left on device date: write error: No space left on device /isan/bin/first-setup.core: line 80: echo: write error: No space left on device /isan/bin/first-setup.core: line 81: echo: write error: No space left on device /isan/bin/first-setup.core: line 82: echo: write error: No space left on device date: write error: No space left on device
Conditions: issue command : switchto vdc <> AQ6-PT-7010-03# sh module Mod Ports Module-Type Model Status --- ----- ----------------------------------- ------------------ ---------- 1 48 1/10 Gbps Ethernet Module N7K-F248XP-25 ok 2 32 10 Gbps Ethernet XL Module N7K-M132XP-12L ok 3 32 10 Gbps Ethernet XL Module N7K-M132XP-12L ok 5 0 Supervisor Module-2 N7K-SUP2E active * 6 0 Supervisor Module-2 N7K-SUP2E ha-standby 7 24 10 Gbps Ethernet Module N7K-M224XP-23L ok 8 32 1/10 Gbps Ethernet Module N7K-F132XP-15 ok 9 48 1/10 Gbps Ethernet Module N7K-F248XP-25E ok 10 12 10/40 Gbps Ethernet Module N7K-F312FQ-25 ok
Workaround: 1. reload switch . 2. load a debug-plugin and then free up some space from /nxos/tmp
Further Problem Description: the error message has no function impact. the first-setup script logs the debugging to /nxos/tmp which is much smaller than /var/tmp that is used before.
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.191), 7.3(0)D1(1), 7.3(0)HIB(0.3), 7.3(0)IZN(0.13), 7.3(0)N1(0.247), 7.3(0)N1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.209), 7.3(0)ZN(0.223), 7.3(1)PDB(0.19) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux63641 | Title: | EEM script not being deleted from running-config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Nexus 5600 platforms on newer code can fail to purge the EEM script from the running-config in some cases. Also, after reloading N5600 some part of EEM config can be lost.
Conditions: Nexus 5600 running 7.2(1)N1(1) with EEM script configured
Workaround: Performing a full write erase / reload is the only way to clear out the EEM script once and for all. There is no workaround for cases when part of config is lost after reloading.
Further Problem Description: Nexus 5600 platforms on newer code can fail to purge the EEM script from the running-config in some cases.
+ Add an EEM script + Do copy run start + show startup EEM shows the script in the startup config + Reload the switch if you want. The EEM script is still in the running config. + Write erase (clear the startup config) + Remove the EEM scripts from the running-config + Copy run start + Reload
+ Result: The EEM script is still partially in the running-configuration!
+ Apply original EEM config to running-config + Do copy run start and reload the device + Verify that the running config is the same as before the reload. + Delete an existing EEM action line, and add a new EEM action line. + Do copy run start and reload the device
+ Result: in some cases both deleted and added lines are lost.
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.2(1)N1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.202), 7.3(0)D1(1), 7.3(0)IZN(0.13), 7.3(0)N1(0.263), 7.3(0)N1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.230), 7.3(0)ZN(0.239), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux62214 | Title: | L2FM consistency checker can cause memory leak / crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: L2fm process crashes with signal 6
Conditions: Either running CLI "show forwarding consistency checker" every 5 minutes or at a higher frequency on switch Or running CLI in background via script (EEM with scheduler OR py script)
Workaround: There is no workaround Do not use this CLI more often than a day.
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(1), 7.3(0)ZD(0.238), 7.3(1)D1(0.2), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw90721 | Title: | LISP: RNH notifies for db RLOCs gone when coincide with map-cache RLOCs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: On a LISP site with multiple eTRs, one of the eTRs shows an incorrect status of the locators of the rest of eTRs. As an example it may mark the locator as "down" but have a route to the locator.
Conditions: In order to reach this state the eTR (that is also working as iTR) must receive a map-reply in which one of the locators is part of the database-mapping locator-set. The problem is that this map-cache will be rapidly removed, as it is considered local, which also removes RNH tracking for the affected locators.
An easy way to reproduce this problem is to issue a "lig self"
Workaround: The only possible workaround now is to reapply the configuration of the affected database-mapping, so that RNH tracking is reinstated
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.6), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZD(0.11), 7.2(2)ZN(0.10), 7.3(0)D1(0.202), 7.3(0)D1(1), 7.3(0)IZN(0.13), 7.3(0)N1(0.264), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux55089 | Title: | N5K: EEM triggered by wrong event in case of using boolean "AND" logic |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: N5K: EEM triggered by wrong event in case of using boolean "and" logic
Conditions: 1 and 2
1. use EEM tags to link some syslog events to EEM action. 2. use boolean "AND" logic to link 4 events to EEM action as follow.
tag ONE and TWO and THREE and FOUR happens 1 in 60
Workaround: use tags less than 3 tags
Further Problem Description: you can check EEM events history with a following command.
show event manager history events detail
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.191), 7.3(0)D1(1), 7.3(0)HIB(0.3), 7.3(0)IZN(0.13), 7.3(0)N1(0.247), 7.3(0)N1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.209), 7.3(0)ZN(0.223), 7.3(1)PDB(0.19) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux42981 | Title: | Display issue in running-config for FP vlans |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: We see that when we delete some fp vlans from within a range of fp vlans so that it becomes non-contiguous, the running-config gets scrambled and inserts an unexpected ','.
For example
vlan 1101,1263,1270,1273-1274,1277,1281-1283,1286,1290-1291,1412,1651,1680-1685, 1687,1690-1696,1700-1707,1714-1717,1720-1725,1730-1736,1740-1742,1744,1900-1907, 1910-1911,1913-1917,1920-1927,1930-1935,1937,1940-1947,1950-1951,1953-1957,2030- 2031,2033-2036, mode fabricpath >>>>>>>>>>> notice the ?,? and then ?mode fabricpath?
Conditions: Deleting range of vlans.
Before vlan deletion ---------------------------
vlan 1-989 mode fabricpath vlan 990 mode fabricpath name Dell_FluidFS_Internal vlan 991-3967 mode fabricpath
vlan deletion -------------------
no vlan 2-900,902-935,940-989 no vlan 991-1100 no vlan 1102-1262 no vlan 1264-1269,1271-1272,1275-1276,1278-1280 no vlan 1284-1285,1287-1289,1292-1411,1413-1650 no vlan 1652-1679,1686,1688-1689,1697-1699 no vlan 1708-1713,1718-1719,1726-1729,1737-1739 no vlan 1743,1745-1899,1908-1909,1912,1918-1919 no vlan 1928-1929,1936,1938-1939,1948-1949 no vlan 1952,1958-2029,2032,2037-2039,2048-2049 no vlan 2058-2379,2388-2389,2398-2430,2432-2449 no vlan 2451-2459,2462-2509,2511-2529,2532-2579 no vlan 2581-2589,2591-2599,2601-2609,2611-2619 no vlan 2621-2629,2631-2639,2641-2649,2651-2659 no vlan 2661-2669,2671-2679,2681-2689,2691-2699 no vlan 2701-2859,2861,2864-3500 no vlan 3501-3967
Workaround: Issue not seen on 6.2.2 and 6.2.14. Downgrade to 6.2.x train
6.2.14 --------
vlan 1101,1263,1270,1273-1274,1277,1281-1283,1286,1290-1291,1412,1651,1680-1685, 1687,1690-1696,1700-1707,1714-1717,1720-1725,1730-1736,1740-1742,1744,1900-1907, 1910-1911,1913-1917,1920-1927,1930-1935,1937,1940-1947,1950-1951,1953-1957,2030- 2031,2033-2036,2040-2047,2050-2057,2380-2387,2390-2397,2431,2450,2460-2461,2510, 2530-2531,2580,2590,2600,2610,2620,2630,2640,2650,2660,2670,2680,2690,2700,2860, 2862-2863 mode fabricpath
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.194), 7.3(0)D1(1), 7.3(0)HIB(0.3), 7.3(0)RSP(0.7), 7.3(0)ZD(0.211), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux58308 | Title: | Configuring 'delay restore interface-vlan 30' defaults timer to 10 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: When the interface-vlan delay restore timer be configured to 30s, it is still shown 10s in CLI when execute "show running configure vpc all".
Conditions: This bug will be triggered when the interface-vlan delay restore timer be configured to 30s.
Workaround: Not applicable.
Further Problem Description: Not applicable.
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.190), 7.3(0)D1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.208), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu39870 | Title: | NAM Module flooding accounting log |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: When a N7K-SM-NAM-9G-K9 Network Analysis Module is inserted into a chassis and powered up, it floods the accounting logs with unhelpful information:
Wed May 6 04:20:05 2015:type=start:id=vsh.5698:user=root:cmd= Wed May 6 04:20:05 2015:type=stop:id=vsh.5698:user=root:cmd= Wed May 6 04:20:07 2015:type=start:id=vsh.5714:user=root:cmd= Wed May 6 04:20:08 2015:type=stop:id=vsh.5714:user=root:cmd= Wed May 6 04:21:05 2015:type=start:id=vsh.5758:user=root:cmd= Wed May 6 04:21:05 2015:type=stop:id=vsh.5758:user=root:cmd=
Conditions: - Neuxs 7K with NX-OS 6.2(12) or other newer NX-OS - This problem happens when the NAM module is powered on.
Workaround: No workaround except to poweroff the NAM module.
Further Problem Description: This is an issue for the accounting log that impacts TAC's ability to troubleshoot. This is a very serious issue. When the NAM module is inserted and powered up, it floods 4 empty accounting log messages every minute, which basically makes the "show accounting log" command useless to TAC. See below for an example of the flooding:
Wed May 6 04:20:05 2015:type=start:id=vsh.5698:user=root:cmd= Wed May 6 04:20:05 2015:type=stop:id=vsh.5698:user=root:cmd= Wed May 6 04:20:07 2015:type=start:id=vsh.5714:user=root:cmd= Wed May 6 04:20:08 2015:type=stop:id=vsh.5714:user=root:cmd= Wed May 6 04:21:05 2015:type=start:id=vsh.5758:user=root:cmd= Wed May 6 04:21:05 2015:type=stop:id=vsh.5758:user=root:cmd=
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.188), 7.3(0)D1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.206), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw29235 | Title: | "restart igmp" command or ND ISSU results in "igmp hap reset" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Non-Disruptive ISSU is performed from version 7.1(2)N1(1) (or older version) to version 7.2(1)N1(1).
Conditions: 1. Have L2 Multicast/Unicast on N5k vPC pair switches running with 7.1(3)N1(1) build. 2. Perform ND ISSU to 7.2(1)N1(1) image on vPC primary switch. 3. vPC Primary switch will be crashing due to "IGMP hap reset".
Workaround: N/A
Further Problem Description: N/A
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 7.2(1)N1(0.328), 7.2(2)N1(0.349), 7.3(0)N1(0.113) |
|
Known Fixed Releases: * | 7.3(0)N1(0.276), 7.3(0)N1(1), 7.3(0)ZN(0.254), 7.3(1)D1(0.5), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv44967 | Title: | Unable to modify access-list using config session |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Unable to modify ACL using config session Following error is shown
N7K# conf session impulse Config Session started, Session ID is 1 Enter configuration commands, one per line. End with CNTL/Z. N7K(config-s)# ip access-list test N7K(config-s-acl)# permit ip host 1.1.1.1 any N7K(config-s-acl)# commit Failed to start Verification: Checkpoint Name already exists N7K(config-s)#
N7K# conf session test Config Session started, Session ID is 1 Enter configuration commands, one per line. End with CNTL/Z. N7K(config-s)# ip access-list test Maximum number of commands reached N7K(config-s)#
Conditions: This problem was observed on 6.2.10 code after using config session for couple of days.
Workaround: Clear the checkpoint database and try to do the session commit
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.2(10)S92 |
|
Known Fixed Releases: * | 7.3(0)D1(0.87), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.37), 7.3(0)PDB(0.57), 7.3(0)RTG(0.78), 7.3(0)SC(0.14), 7.3(0)SL(0.115), 7.3(0)ZD(0.102) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv04106 | Title: | need "MAINTENANCE" as (special) reset-reason for GIR |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: while in Maintenance Mode, if the switch reloads because of any reason that is not part of handful that are covered under mmode today ,it should come back up in Maintenance mode.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(0)BZ(0.108), 7.0(3)F1(0.188), 7.0(3)I3(0.180), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.33), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), 7.0(3)ITI2(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw66926 | Title: | errors observed in xml validation |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: The XML generated by ELOAM in response to manageability requests does not conform to the schema.
Conditions: This impacts all ELOAM show commands.
Workaround: Running the show commands from the CLI works successfully.
Further Problem Description: The XML interface returns all the correct data but not in a schema compatible form.
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.96) |
|
Known Fixed Releases: * | 7.3(0)D1(0.135), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.102), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw56149 | Title: | ELOAM should identify interfaces of rx packets based on VQI |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
ELOAM does not come up on interfaces which are members of a port-channel. In particular, the sessions on such interfaces will not process any packets sent to them.
Conditions:
Any interface which is configured with both "ethernet oam" and "channel-group will be affected.
Workaround:
None. Either remove ethernet oam or remove the interface from the port-channel.
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0.99) |
|
Known Fixed Releases: * | 7.3(0)D1(0.126), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw81680 | Title: | ELOAM syslog to all VDCs does not work during LC boot |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
During LC boot, if ELOAM hits any errors it is unable to syslog to alert the user.
Conditions:
- ELOAM must be configured - The linecard must be booting up - ELOAM must hit an unexpected error condition
Workaround:
This is a secondary failure in which the user might not be alerted to potential errors. No workaround should be needed, but the "show ethernet oam" commands can be used to verify protocol state. |
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.127) |
|
Known Fixed Releases: * | 7.3(0)D1(0.135), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.102), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw54273 | Title: | "where" returning empty under profile level config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: The CLI command "where" does not work inside the ethernet link oam profile configuration, CLI submode.
Conditions: Always happens inside the ethernet oam profile submode. For example:
switch# conf Enter configuration commands, one per line. End with CNTL/Z. switch(config)# ether oam profile profile-name switch(config-eoam)# where
Does not happen in other CLI submodes, including the ethernet link oam interface submode.
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.96) |
|
Known Fixed Releases: * | 7.3(0)D1(0.126), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv56604 | Title: | N7K:ospf pushing BFD into admin down state |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: All BFD/OSPF sessions flap on the local chassis.
Conditions: This happens when sup switchover through physical removal or through CLI "system switchover" command with OSPF having passive-interface default in SR mode and no ip ospf passive-interface in certain interfaces.
Workaround: The following workaround solved the issue - no bfd echo - bfd timers 150 min-rx 150 interval 3
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.267), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.100), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.1(3)N1(0.611), 7.1(3)N1(1), 7.1(3)ZD(0.9), 7.1(3)ZN(0.16) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw35258 | Title: | Memory leak observed in elo_io process during LC ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: The elo_io process leaks memory when receiving a packet from an unexpected interface.
Conditions: Whenever a packet on an unexpected interface is received the elo_io process will leak a small amount of memory.
Workaround: None, but unless the elo_io process receives a high volume of packets it is not expecting, the actual impact is likely to be low.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.96) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)D1(1), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.74), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw51036 | Title: | %ETHPORT-3-IF_UNSUPPORTED_TRANSCEIVER:" for LOROM twinax cable |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Syslog Message:
2015 Sep 2 13:12:31 TXD-SA03-A %ETHPORT-3-IF_NON_CISCO_TRANSCEIVER: Non-Cisco transceiver on interface Ethernet1/9 is detected
Conditions: When we use the following twinax cable
transceiver trunk TXD-SA03-A# show int e1/9 transceiver Ethernet1/9 transceiver is present type is SFP-H10GB-CU3M name is CISCO-LOROM part number is LRHSPB54D030 revision is B0 serial number is LRM191487QD nominal bitrate is 10300 MBit/sec Link length supported for copper is 3 m cisco id is -- cisco extended id number is 4
Workaround: Issue is cosmetic in nature as switch detects the SFP okay and interface also comes up okay.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(1), 7.2(1)ZD(0.110), 7.2(2)D1(0.1), 7.3(0)D1(0.140), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.80), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw61767 | Title: | eloam_bugfix/32 BnB commit into hsk_bundle |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | This DDTS was used to release CSCuw54273 and CSCuw56149. See the release notes for those. |
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.120) |
|
Known Fixed Releases: * | 7.3(0)D1(0.126), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)IB(0.122), 7.3(0)IZN(0.7), 7.3(0)N1(0.166), 7.3(0)N1(1), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)RSP(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv90027 | Title: | NXOSv Interface ACL config should be blocked until supported |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: NXOSv (virtual) will allow interface ACL configs to be configured without error. But if applied to non management interfaces, they won't block traffic.
Conditions: ONly applies to virtual NXOS (a.k.a. titanium)
Workaround: None
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.2(1)D1(0.57) |
|
Known Fixed Releases: * | 7.2(1)D1(0.70), 7.2(1)D1(1), 7.2(1)ZD(0.62), 7.3(0)D1(0.91), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.67) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy51899 | Title: | default logging level mvrp 2 shown with show run |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom: Observed logging level mvrp 2 popped in show run
Conditions: mvrp feature enabled
Workaround:
Further Problem Description: |
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.2(14)S9 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur56960 | Title: | VRRS pathway stuck in "Currently being removed" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: VRRS pathway stuck in "Currently being removed"
Conditions: When we move from VRRS pathway to VRRP, VRRS pathway stuck in "Currently being removed" state for all slaves. Due to this error, we cannot configure the VIP when we try to move the slave to a vrrp group. The trigger of this issue is to remove the SVI completely.
Workaround: Instead of removing the SVI completely, remove VRRS pathway config only.
Further Problem Description: .
|
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)D1(0.190), 7.3(0)D1(1), 7.3(0)DX(0.93), 7.3(0)IZN(0.13), 7.3(0)N1(0.246), 7.3(0)N1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.208), 7.3(0)ZN(0.222) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu78360 | Title: | Vlans not getting registered properly when mvrp configured with VPC |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: When mvrp is configured with vpc, sometimes vlans may not get declared or registered.
Conditions: The issue is triggered with following known conditions.
1. Flap the MCT and vPC in a quick succession. After few tries, the issue may be seen.
2. Change the access vlan of interface to different value. After few tries, the issue may be seen.
Note that the above list may not be exhaustive.
Workaround: Enable/Disable MVRP on both peer switches resolves the issue.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.2(16)S32, 7.2(0)D1(1), 7.3(0)D1(0.86) |
|
Known Fixed Releases: * | 6.2(16)S45, 7.2(1)D1(0.43), 7.2(1)D1(1), 7.2(1)ZD(0.38) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03144 | Title: | OpenSSH: Evaluation of Multiple OpenSSH CVEs for NX-OS |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Cisco Nexus Operation System (NX-OS), running on the Cisco Nexus 5000 Series Switches, Cisco Nexus 6000 Series Switches, Cisco Nexus 7000 Series Switches and Cisco MDS 9000 Series Multilayer Switches include a version of Open Secure Shell (OpenSSH) software that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-5600, CVE-2015-6563, CVE-2015-6564, CVE-2015-5352 and CVE-2015-6565
This bug was opened to address the potential impact on this product.
Conditions: Device with default configuration.
Workaround: Not currently available.
Further Problem Description: Additional details about the vulnerabilities listed above can be found at
http://cve.mitre.org/cve/cve.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5600 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6563 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6564 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6565 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5352
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 6.9/6.9: http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:M/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C&version=2.0 CVE ID CVE-2015-5600, CVE-2015-6563, CVE-2015-6564, CVE-2015-6565, CVE-2015-5352 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: | 29-FEB-2016 |
|
Known Affected Releases: | 6.2(12), 7.3(0)ZN(0.89) |
|
Known Fixed Releases: * | 6.2(15)S10, 6.2(16)S16, 7.2(1)D1(1), 7.2(1)N1(0.331), 7.2(1)N1(1), 7.2(1)ZD(0.98), 7.2(1)ZN(0.92), 7.2(2)D1(0.2), 7.3(0)D1(0.90), 7.3(0)D1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux77234 | Title: | F3 packets are flooded for 2-3 sec during receiving gratuitous arp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom: Packets are flooded for 2-3 seconds during receiving gratuitous arp.
Conditions: Nexus 7700 series with F3 line cards. This symptom seen on both NX-OS release 6.2(14) and 7.2(1)D1(1). Port where traffic is received and gratuitous arp is received are located on different SoC.
Workaround: Not available at this moment.
Further Problem Description: Root cause is identified and solution is provided in further software releases. Fix is to change internal timer for quicker processing.
|
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(14), 7.2(1)D1(1) |
|
Known Fixed Releases: | 7.3(0)DX(0.103) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut18591 | Title: | tshark: Segmentation Violation with IP Protocol 89 Capture Filter |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Ethanalyzer crashes with the following reason:
tshark: Child dump cap process died: Segmentation violation
Conditions: Unknown at this time
Workaround: None.
Further Problem Description: Issue was due to overflow issue in memcpy.
|
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)D1(0.144), 7.3(0)D1(0.162), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)IB(0.122), 7.3(0)OTT(0.73), 7.3(0)PDB(0.89), 7.3(0)PDB(0.93), 7.3(0)RSP(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup01143 | Title: | OSPF unicast packet sent out with CoS 5 |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: Ospf packets should be sent out with CoS5 but only unicast packets are sent out with DSCP6/ CoS5.
Conditions: OSPF unicast packet (LS Acknowledgement/LS update) are always sent out with CoS5.
Workaround: none
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.2(8)S3 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.48), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus53354 | Title: | N7K-OFF-DIAG:Pescara N7K 100: DSH can't start all dsps in BB |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: some dsp can't startup automatcially. It need more time.
Conditions: NTNV
Workaround: init group need be refined
Further Problem Description:
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 7.2(0)ZN(0.87) |
|
Known Fixed Releases: * | 6.2(10)CR(0.35), 7.0(0)BZ(0.46), 7.0(0)HSK(0.325), 7.1(320)MQ(0.60), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua92729 | Title: | configure Order of show run vlan x is changed by feature dhcp |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: Order of configuration of interface vlan is changes by 'feature dhcp'
Conditions: - confire 'feature dhcp', and then order of the configuration changes at interface vlan. - To my knowledge, 'description' and 'no shutdown' is effected. - This issue is no impact for system.
// before interface Vlan4 description VLAN4 <<<< no shutdown <<<< ip address 10.32.192.9/29 ip router eigrp 1 ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 tsbinternet hsrp 4 preempt priority 105 ip 10.32.192.14
// after interface Vlan4 ip address 10.32.192.9/29 ip router eigrp 1 ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 tsbinternet hsrp 4 preempt priority 105 ip 10.32.192.14 description VLAN4 <<<< no shutdown <<<<
Workaround: none
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 5.2(4), 5.2(7), 6.0(2), 6.1(2), 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.79), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)IB(0.67), 7.3(0)MMD(0.9), 7.3(0)OTT(0.32), 7.3(0)PDB(0.45), 7.3(0)RTG(0.68), 7.3(0)SC(0.14), 7.3(0)ZD(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto97863 | Title: | startup-config missing few configs when the module is powered down |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom: After the N7K is reloaded or one of the modules is powered down it is possible that there is interface configuration missing from either the startup or running configurations.
Conditions: The N7K chassis or individual module is reloaded.
Workaround: The missing interface configuration has to be added manually.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: * | 5.2(0.270)S7, 6.2(12)S31, 6.2(16)S35 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug96112 | Title: | Configuration Session editable for user with same privilege |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: The user gets an error when trying to access the configuration session of a second user when the roles are the same.
Conditions: The user of "configuration sessions" with different usernames and roles.
Workaround: Use role network-admin or user admin. Further workarounds being investigated. The code is fixed to make the users with the same role to access and modify the session
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.52), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur71635 | Title: | F1 is showing 'Speed' as 'a-10G' for SR/LR SFP |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: M and F series 10G port with the same SFP and configuration but they had different result in 'Speed' column a below.
M card: Eth8/9 -- connected routed full 10G SFP-H10GB-C
F card: Eth1/48 -- connected trunk full a-10G SFP-H10GB-C
Conditions: F-series card using 10G SFP
Workaround: N/A
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)D1(1), 7.3(0)PDB(0.34) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy47252 | Title: | DOC: Nexus "Storm Control Unicast" |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom: Command on Nexus 5k/7k "Storm Control Unicast" will be applied to ALL Unicast traffic.
Conditions: Nexus 5K/7K
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.1(4.6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy47249 | Title: | DOC: Nexus "Storm Control Unicast" |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom: Command on Nexus 5k/7k "Storm Control Unicast" will be applied to ALL Unicast traffic.
Conditions: Nexus 5K/7K
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.1(4.6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue01036 | Title: | N7K OSPF unable to set metric for redistributed route as zero |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: Unable to set metric for redistributed routes as zero in NxOS OSPF
Conditions: We can set metric as zero by a route-map. However, in that case NxOS applies the value of default-metric instead of the one set by the route-map.
Workaround: none.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.0(3) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.46), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo56967 | Title: | incorrect msg when otv is enabled in "f2e f3" vdc |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: When a user tries to enable 'feature otv' in a VDC that has F3 and F2e it prints the following error:
switch-al-otv(config)# feature otv Feature otv not supported in F2E without M1, M1XL or M2XL VDC
OTV can be enabled with F3 when the VDC is a F3 only VDC. OTV cannot be enabled for F3/F2e VDCs. The error message should read:
"Feature OTV is not supported on F3 + F2E VDC, only pure F3 VDC type is supported"
Conditions: - Nexus 7000 - F3/F2e VDC
Workaround: None
Further Problem Description: A user will be able to enable 'feature otv' in a F3 only VDC, then go back and add the F2e module-type and interfaces but this is unsupported and should not be allowed. Please see CSCuj08074: Feature OTV enabled on a f2e f3 module-type vdc
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(10)FM(0.18) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)RTG(0.57), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz75099 | Title: | name of the access-list does not get changed under the spm-policy |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | output of "show system internal command " shows wrong redirect access-list name
when a redirect access-list is defined and changed later the access-list name remains unchnaged
restart of feature would display correct access-list name |
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 6.1(0.281) |
|
Known Fixed Releases: * | 6.1(0.301)S0, 6.2(0.217), 6.2(2), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy03733 | Title: | SNMP polling of entPhysicalTable not getting info for sensors (s29-31) |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom: SNMP polling of entPhysicalTable should provide all the details for other sensors(s2-s28) except 29-31. However, "show environment temperature module 3" provides the required the information.
kmuruga2@last-call-2% snmpwalk -Os -c cisco -v 1 172.16.153.28 1.3.6.1.2.1.47.1.1.1.1.2 | grep module-3 mib-2.47.1.1.1.1.2.726 = STRING: "module-3 processor-1" mib-2.47.1.1.1.1.2.21719 = STRING: "module-3 MAC0Sn0(s2)" mib-2.47.1.1.1.1.2.21720 = STRING: "module-3 MAC0Sn1(s3)" mib-2.47.1.1.1.1.2.21721 = STRING: "module-3 MAC0-Buf0(s4)" mib-2.47.1.1.1.1.2.21722 = STRING: "module-3 MAC0-Buf1(s5)" mib-2.47.1.1.1.1.2.21723 = STRING: "module-3 MAC0-Buf2(s6)" mib-2.47.1.1.1.1.2.21724 = STRING: "module-3 MAC0-Buf3(s7)" mib-2.47.1.1.1.1.2.21725 = STRING: "module-3 MAC1Sn0(s8)" mib-2.47.1.1.1.1.2.21726 = STRING: "module-3 MAC1Sn1(s9)" mib-2.47.1.1.1.1.2.21727 = STRING: "module-3 MAC1-Buf0(s10)" mib-2.47.1.1.1.1.2.21728 = STRING: "module-3 MAC1-Buf1(s11)" mib-2.47.1.1.1.1.2.21729 = STRING: "module-3 MAC1-Buf2(s12)" mib-2.47.1.1.1.1.2.21730 = STRING: "module-3 MAC1-Buf3(s13)" mib-2.47.1.1.1.1.2.21731 = STRING: "module-3 Fwd0Sn0(s14)" mib-2.47.1.1.1.1.2.21732 = STRING: "module-3 Fwd0Sn1(s15)" mib-2.47.1.1.1.1.2.21733 = STRING: "module-3 Fwd1Sn0(s16)" mib-2.47.1.1.1.1.2.21734 = STRING: "module-3 Fwd1Sn1(s17)" mib-2.47.1.1.1.1.2.21735 = STRING: "module-3 Fwd2Sn0(s18)" mib-2.47.1.1.1.1.2.21736 = STRING: "module-3 Fwd2Sn1(s19)" mib-2.47.1.1.1.1.2.21737 = STRING: "module-3 Fwd3Sn0(s20)" mib-2.47.1.1.1.1.2.21738 = STRING: "module-3 Fwd3Sn1(s21)" mib-2.47.1.1.1.1.2.21739 = STRING: "module-3 QEng0Sn0(s22)" mib-2.47.1.1.1.1.2.21740 = STRING: "module-3 QEng0Sn1(s23)" mib-2.47.1.1.1.1.2.21741 = STRING: "module-3 QEng1Sn0(s24)" mib-2.47.1.1.1.1.2.21742 = STRING: "module-3 QEng1Sn1(s25)" mib-2.47.1.1.1.1.2.21743 = STRING: "module-3 QEng2Sn0(s26)" mib-2.47.1.1.1.1.2.21744 = STRING: "module-3 QEng2Sn1(s27)" mib-2.47.1.1.1.1.2.21745 = STRING: "module-3 QEng3Sn0(s28)" mib-2.47.1.1.1.1.2.25942 = STRING: "module-3 FwdEngine-1" mib-2.47.1.1.1.1.2.25943 = STRING: "module-3 FwdEngine-2"
N7K-1# sh environment temperature module 3 Temperature: -------------------------------------------------------------------- Module Sensor MajorThresh MinorThres CurTemp Status (Celsius) (Celsius) (Celsius) -------------------------------------------------------------------- 3 MAC0Sn0(s2) 115 105 39 Ok 3 MAC0Sn1(s3) 115 105 40 Ok 3 MAC0-Buf0(s4) 115 105 46 Ok 3 MAC0-Buf1(s5) 115 105 40 Ok 3 MAC0-Buf2(s6) 115 105 46 Ok 3 MAC0-Buf3(s7) 115 105 43 Ok 3 MAC1Sn0(s8) 115 105 41 Ok 3 MAC1Sn1(s9) 115 105 42 Ok 3 MAC1-Buf0(s10) 115 105 42 Ok 3 MAC1-Buf1(s11) 115 105 45 Ok 3 MAC1-Buf2(s12) 115 105 36 Ok 3 MAC1-Buf3(s13) 115 105 42 Ok 3 Fwd0Sn0(s14) 115 105 75 Ok 3 Fwd0Sn1(s15) 115 105 75 Ok 3 Fwd1Sn0(s16) 115 105 68 Ok 3 Fwd1Sn1(s17) |
|
Last Modified: | 06-FEB-2016 |
|
Known Affected Releases: | 6.2(14), 7.2(1)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCte72045 | Title: | ACL logging for permit entries donot work for input ACL+dhcp relay/snoop |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Problem/Symptom:
Under specific feature combination (as mentioned below) ACL logging of permit entries may not work.
DHCP relay and/or DHCP snooping configured on interface and Input ACL permit logging configured on the same interface.
Workaround:
If Input ACL logging for permit entries is desired, remove one of the above mentioned features from the interface.
More details:
Input Deny ACL logging, and Output ACL logging (permit or deny) are not affected.
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 4.2(3), 5.2(0.215) |
|
Known Fixed Releases: * | 5.2(0.241)S0, 5.3(0.187)S0, 6.0(0.2)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc52099 | Title: | NX-OS eBGP multipath may not kick in |
|
Status: | Terminated |
|
Severity: | 4 Minor |
Description: * | Symptom: eBGP multipath may not work properly even if multipath conditions, which are weight, local preference, AS path length, origin, med, are met.
Conditions: From eBGP neighbor, different AS path length are learnt and they have multipath flag. Then, one of them is cleared due to having same next hop information.
Network Next Hop Metric LocPrf Weight Path * e10.10.10.0/24 172.16.123.20 0 65002 65000 i <<--- * e 172.16.123.20 0 65002 65000 i <<--- * e 192.168.124.30 0 65002 65000 i * e 192.168.124.10 0 65002 65000 i * e 172.16.123.20 12 0 65000 i <<- should be selected as multipath! *>e 192.168.124.20 12 0 65000 i
The problem is seen on 6.0 and 6.1 release.
Workaround: Use AS path filter for unnecessary routes
Further Problem Description:
|
|
Last Modified: | 05-FEB-2016 |
|
Known Affected Releases: | 6.0(3), 6.2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux49719 | Title: | pam_aaa_motd:cannot open motd file : /vdc_4/etc/motd - dcos_sshd |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom: when we do switchto vdc , PAM infra tries to read motd file specific to VDC . However exec banner as a feature is specific to the box/device but not to vdc . This is vdc unaware file . This is not an issue with respect to motd . so we can ignore this message. it is not a harmful msg
Conditions: This issue will be seen during switchto vdc
Workaround: it will be seen in the console if logging level of the console is set to error level & above. workaround: 1.logging level console 2 2 .if customer is not happy with changing the logging level to 2, then we can ignore this msg.
Further Problem Description: when we do switchto vdc , PAM infra tries to read /etc/motd file specific to VDC . However exec banner as a feature is specific to the box but not to vdc . This is vdc unaware file . This is not an issue with respect to motd . so we can ignore this message. it is not a harmful msg for the customers .
|
|
Last Modified: | 12-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.172), 7.3(0)D1(0.179) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy35518 | Title: | sh run all not updated on unconfiguring the snmp trap bgp |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom: sh run all not updated on unconfiguring the snmp trap bgp
Conditions: unconfiguring the snmp trap bgp
Workaround: NA
Further Problem Description:
|
|
Last Modified: | 19-FEB-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.201) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy32055 | Title: | N7K HSRP VIP route on Standby does not display correctly |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom: Routing Table on the HSRP Standby Switch shows "client-specific data: deadbeef" when displaying the routing table for the HSRP VIP.
Switch# sh ip route 10.0.0.1/32 detail IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%' in via output denotes VRF
100.0.0.1/32, ubest/mbest: 1/0 *via 100.0.0.1, Vlan130, [0/0], 11:33:33, hsrp client-specific data: deadbeef
Conditions: The routing table on the HSRP Standby shows "client-specific data: deadbeef" which should be ignored as it is NOT affecting the forwarding of packets destined to the HSRP VIP.
Workaround: None
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz50653 | Title: | OTV Enh: Clear OTV forwarding multicast counters |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: Enhancement request to clear otv forwarding counters shown in
sh forwarding otv multicast route vlan 10 mod 7
Conditions: Currently no way to clear these counters manually.
Workaround: NA. Enhancement request
Further Problem Description:
|
|
Last Modified: | 25-FEB-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DX(0.65), 7.3(0)EG(0.14), 7.3(0)UCI(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf82063 | Title: * | Supervisor shows reset reason as 'CATERR' |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom: Supervisor may erroneously indicate that the CPU was reset due to a CATERR event when it did not. This masks the actual reset reason for the card.
Conditions: This issue may occur when the supervisor is power cycled or reset.
Workaround: Ignore this reset reason.
Further Problem Description: This issue is caused by unstable CATERR signal during the CPU's power-up sequence.
|
|
Last Modified: | 25-FEB-2016 |
|
Known Affected Releases: | 6.2(1.56)S5 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz92306 | Title: | n7k/n2k FEX sprom shows incorrect PS SN |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
A N2K-C2248TP FEX connected to a Nexus 7K running OS 5.2.4 or earlier will not update the serial number after an RMA if a "sh sprom fex ___ all | begin power-supply is issued.
HMPLABBHZ-DN70200-HMPLABBHZ-DN702v4# sh sprom fex 102 all | begin power-supply DISPLAY FEX 102 power-supply 1 sprom contents: Common block: Block Signature : 0xabab Block Version : 3 Block Length : 160 Block Checksum : 0x1831 EEPROM Size : 65535 Block Count : 2 FRU Major Type : 0xab01 FRU Minor Type : 0x0 OEM String : Cisco Systems, Inc. Product Number : N2200-PAC-400W Serial Number : LIT14300AF7 Part Number : 341-0375-04 Part Revision : A0 Mfg Deviation : H/W Version : 1.1 Mfg Bits : 0 Engineer Use : 0 snmpOID : 9.12.3.1.6.273.0.0 Power Consump : 3300 RMA Code : 0-0-0-0 CLEI Code : COUPAE2BAB VID : V02 DISPLAY FEX 102 power-supply 2 sprom contents: Common block: Block Signature : 0xabab Block Version : 3 Block Length : 160 Block Checksum : 0x1830 EEPROM Size : 65535 Block Count : 2 FRU Major Type : 0xab01 FRU Minor Type : 0x0 OEM String : Cisco Systems, Inc. Product Number : N2200-PAC-400W
Serial Number : LIT14300AF6 >>>>This power supply is in my hands. What I have inserted in the FEX module is Serial#LIT15120UW7
Part Number : 341-0375-04 Part Revision : A0 Mfg Deviation : H/W Version : 1.1 Mfg Bits : 0 Engineer Use : 0 snmpOID : 9.12.3.1.6.273.0.0 Power Consump : 3300 RMA Code : 0-0-0-0 CLEI Code : COUPAE2BAB VID : V02 HMPLABBHZ-DN70200-HMPLABBHZ-DN702v4# sho inventory fex 102 NAME: "FEX 102 CHASSIS", DESCR: "N2K-C2248TP-1GE CHASSIS" PID: N2K-C2248TP-1GE , VID: V02 , SN: JAF1442BGHA NAME: "FEX 102 Module 1", DESCR: "Fabric Extender Module: 48x1GE, 4x10GE Supervisor" PID: N2K-C2248TP-1GE , VID: V02 , SN: SSI142800CA NAME: "FEX 102 Fan 1", DESCR: "Fabric Extender Fan module" PID: N2K-C2248-FAN , VID: N/A , SN: N/A NAME: "FEX 102 Power Supply 1", DESCR: "Fabric Extender AC power supply" PID: N2200-PAC-400W , VID: V02 , SN: LIT14300AF7 NAME: "FEX 102 Power Supply 2", DESCR: "Fabric Extender AC power supply" PID: N2200-PAC-400W , VID: V02 , SN: LIT14300AF6 >>>> Was replaced with LIT15120UW7
Conditions:
A N2K-C2248TP FEX connected to a Nexus 7K running OS 5.2.4 or earlier will not update the serial number after an RMA if a "sh sprom fex ___ all | begin power-supply is issued.
Workaround:
Power cycling the FEX will correct.
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 5.2(4), 6.0(4)S13 |
|
Known Fixed Releases: * | 5.2(4)FD(0.19), 5.2(5)S10, 5.2(5)S11, 5.2(5.14)S0, 5.2(5.16)S0, 6.0(4)S3, 6.1(0)FE(0.13), 6.1(0.298)S0, 7.0(2)FIP(0.4), 7.1(0)FGI(0.3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr77620 | Title: | FEX: System minor alarm on power supply 1 & Recovered |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The following is observed regarding a FEX connected to a Nexus7K running 5.2(1): %SATCTRL-FEX113-2-SOHMS_DIAG_ERROR: FEX-113 System minor alarm on power supply 1: failed %SATCTRL-FEX113-2-SOHMS_DIAG_ERROR: FEX-113 Recovered: System minor alarm on power supply 1: failed
%SATCTRL-FEX113-4-SOHMS_PS_GPIO: FEX-113 System PS access failure on Power supply: 2 %SATCTRL-FEX113-2-SOHMS_DIAG_ERROR: FEX-113 Module 1: Runtime diag detected major event: GPIO access failure
This seems to be cosmetic since the FEX remains online.
Conditions:
Observed on a FEX connected to Nexus7K running 5.2(1).
Workaround(s): None.
This defect is fixed in Nexus 7k release 5.2(7) and later. |
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 5.2(1)S88 |
|
Known Fixed Releases: * | 5.2(4)FD(0.25), 5.2(7), 5.2(7)S18, 5.2(7)S19, 5.2(7.24)S0, 6.0(4)S19, 6.1(0)FE(0.16), 6.1(0)FE(0.17), 6.1(1), 6.1(1)S14 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq62069 | Title: | QSFP BiDi gives out bogus DOM info when DOM is not supported |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: When issuing "show interface transceiver det" on an interface with QSFP BiDI with 6.2.8a and later releases, the output contains all 0 or N/A. The output should be either removed or clarified to indicate that DOM is not supported for BiDi.
Conditions: Using QSFP BiDi on n7k runnig 6.2.8a and later
Workaround: Expected behavior, refer to the DOM compatible matrix:
http://www.cisco.com/c/en/us/td/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_8031.html#36364
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.2(8a), 7.3(0)DX(0.18) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.3(0)DX(0.40), 7.3(0)DX(0.41), 7.3(0)EG(0.14), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu19139 | Title: | "Default information originate always" not working |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: "default-information originate always" not working
Conditions: When a learnt route replaces the route added and then the learnt route is lost
Workaround: unconfigure and re-configure the command
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.3(0)TD(0.1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.27), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus63973 | Title: | "STP Pseduo-info" missing in "show run/start" when MST is used in VPC+ |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: 'show running-config spanning-tree' or 'show startup-config' does not show 'spanning-tree pseduo-infomation'when its configured specifically.
Example:- ======== show run spanning-tree or show startup-config ! spanning-tree mode mst spanning-tree mst 0-2 priority 4096 spanning-tree mst configuration name cisco instance 1 vlan 100 instance 2 vlan 200 spanning-tree pseudo-information => ONLY THIS LINE IS MISSING <= mst 0-2 root priority 0
Conditions: - MST is used in vPC+ set up - spanning-tree pseduo config is used to change the priority of the root.
Workaround: Not needed as issue seems to be cosmetic i.e. it does not affect the functionality of pseudo config
Further Problem Description: This can be seen Nexus 7000/5000/6000 configure in vPC+
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.0(0)FHS(0.23), 7.1(0)ES(0.24), 7.2(0)BA(0.25), 7.3(0)D1(0.28), 7.3(0)D1(1), 7.3(0)DHB(0.2), 7.3(0)HM(0.36), 7.3(0)IB(0.35), 7.3(0)OTT(0.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut80582 | Title: | logging level spm6 missing after non-ISSU from 6.0.4 to 6.2.10 |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: After upgrade from 6.0(4) to 6.2(10), customer lost the config: 'logging level spm6'
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.171), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.131), 7.3(0)RTG(0.72), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum77376 | Title: | Need to Supress Pim Message PIM-6-ROUTE_LOOKUP |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: 2014 Jan 13 15:08:35 nexus2 PIM-6-ROUTE_LOOKUP pim [5984] Couldn't find PIM route (*, 224.0.0.0/4) in pim_process_mfdm_stats_msg() 2014 Jan 13 15:08:45 nexus2 PIM-4-SYSLOG_SL_MSG_WARNING PIM-6-ROUTE_LOOKUP: message repeated 3 times in last 78 sec 2014 Jan 13 15:09:26 nexus2 PIM-6-ROUTE_LOOKUP pim [5984] Couldn't find PIM route (*, 224.0.0.0/4) in pim_process_mfdm_stats_msg()
Conditions: When upgraded to 6.2(x) code
Workaround: reduce the pim logging severity to 4 or 5.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 7.3(0)DHB(0.31), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.43), 7.3(0)SC(0.14), 7.3(0)ZD(0.85) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur25927 | Title: | "logging level session-mgr 7" not shown in running config after sso |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: Logging level configuration "logging level session-mgr 7" got lost after switchover.
Conditions: Problem happened only after switchover.
Workaround: Manually configure "logging level session-mgr 7" again after switchover.
Further Problem Description:
|
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(10)S98 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.46), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum09975 | Title: | SSTE: show tech bfd throws error if size greater than 500M |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: When collecting a showtech from the Command Line Interface (CLI) on a N7K chassis with many Line Cards (LCs) which are of type "F3" the user can error message saying "No space left on device" in the volatile: disk.
Conditions: Incomplete show tech ouput.
Workaround: Need to collect the show tech output from the particular LC's for which error message is displayed.
Further Problem Description: Whenever there is too many LC's plugged in, and the show tech output greater than 500M, the error message will be displayed "No space left on device".
Since only 500M is allocated.
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(6)S12 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.85), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue35705 | Title: | Getting password prompt even when entering password in copy ftp command |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: When specifying the user password in the copy ftp command, the password prompt is still popped:
nexus# copy ftp://test:test@ftpserver/file bootflash: Enter vrf (If no input, current vrf 'default' is considered): management Password: <<<<<<<<<<<
Conditions: Nexus switch
Workaround: - Use the "terminal password" command to set the password to be used for the password prompts on this terminal session:
nexus# terminal password test nexus# copy ftp://test@ftpserver/file bootflash: Enter vrf (If no input, current vrf 'default' is considered): management ***** Transfer of file Completed Successfully ***** Copy complete, now saving to disk (please wait)... nexus#
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 5.2(3a), 6.1(2), 6.2(10)S53 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.51), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus40106 | Title: | EIGRP might incorrectly advertise tag values in ECMP case |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: There is a route-map which matches tags and set a new value. This route-map is used in an EIGRP outbound distribute list. One in 10 times based on the received route tag, the correct route tag value is not set while advertising out.
Conditions: The symptom is observed when you use a route map which matches tags and sets a new tag.
Workaround: Clear the EIGRP process or re-advertise the route.
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 7.2(0)ZD(0.6) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.17), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv80855 | Title: | BGP Nexthop is not correct in the case of Multiaccess Networks |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: eBGP nexthop is not the third party address for the route that is learned via IGP on a multi-access network(eg. Ethernet).
Conditions: eBGP peering on multi-access network, and routes are learned internally.
Basically, it's the "BGP Next Hop (Multiaccess Networks)" case in http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#bgpnexthop
Workaround: Set an outbound policy map on the neighbor with "set ip next-hop unchanged".
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.0(3)I3(0.123), 7.0(3)I3(1), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)RSP(0.7), 7.3(0)RTG(0.102) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo02299 | Title: | Overlay1 Last link flapped timer is flushed after 24 hours |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom: In "show interface Overlay1" output , counter "Last link flapped" never goes above 24 hours. It is reseted to 00:00:00 every 24 hours , so it can't be used to access how long interface was UP. sh int o1 Overlay1 is up Last link flapped 23:59:59 Last clearing of "show interface" counters 07:45:30
zixu-PE2# sh int o1 Overlay1 is up Last link flapped 00:00:00 Last clearing of "show interface" counters 07:45:31
Conditions: Normal operations
Workaround: None. It' just a cosmetic issue it doesn't affect OTV communications. To check liveliness of OTV connections please use "show otv isis adjacency detail" and check for how long ISIS sessions has been stable.
show otv isis adjacency detail OTV-IS-IS process: default VPN: Overlay1 OTV-IS-IS adjacency database: System ID SNPA Level State Hold Time Interface Site-ID nexus-OTV1 001b.54c2.4242 1 UP 00:00:12 Overlay1 0000.0000.0001 Up/Down transitions: 1, Last transition: 20:23:22 ago <---------------- last transition 20 hours ago ... nexus-OTV2 001b.54c2.4244 1 UP 00:00:12 Overlay1 0000.0000.0002 Up/Down transitions: 1, Last transition: 20:19:26 ago <---------------- last transition 20 hours ago
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.57), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo45167 | Title: | Multicast v6 Vinci: src type is still named "ngmvpn" not "fabric_mcast" |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom: OIF name is listed as ngmvpn instead of fabric_mcast in the show ipv6 mroute output when fabric_mcast process has added the OIF.
Conditions: All conditions
Workaround: no workaround
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.0(0)FVX(0.114) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.66), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty88307 | Title: | Logging config in show run changes after reload |
|
Status: | Terminated |
|
Severity: | 5 Cosmetic |
Description: * | Symptom: Configure 'logging X.X.X.X ' without defining the vrf shows 'use-vrf management'. After a reload the 'use-vrf management' is missing
Before reboot -------------------- N5K(config)# sh run | in logg logging level aaa 5 logging level tacacs 5 N5K(config)# logging server X.X.X.X N5K(config)# logging server X.X.X.X 5 use-vrf default
N5K(config)# sh run | in logg logging level aaa 5 logging level tacacs 5 logging server X.X.X.X 5 use-vrf management <--- default show in running config logging server X.X.X.X 5 use-vrf default <---------- testing default
N5K(config)# end
N5K# sh run | in logging logging level aaa 5 logging level tacacs 5 logging server X.X.X.X
After reboot --------------- N5K# sh run | in logging logging level aaa 5 logging level tacacs 5 logging server X.X.X.X <-------------- no longer shows use-vrf management since this is the default logging server X.X.X.X 5 use-vrf default <-------- stayed the same as it isn't the default.
Conditions: Configure logging X.X.X.X then reload
Workaround: None // cosmetic // vrf management is the default for logging, this should not show in the running config unless we configure it for a different vrf other than management as management is the default.
Further Problem Description:
|
|
Last Modified: | 09-FEB-2016 |
|
Known Affected Releases: | 6.1(5a)S3 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx66278 | Title: | Enhance %MTM-SLOT2-2-MULTICAST_SOURCE_MAC_LEARNT syslog |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: * | Symptom:
The CLI provided in the following syslog message is incorrect.
%MTM-SLOT2-2-MULTICAST_SOURCE_MAC_LEARNT: Inserted dynamically learnt multicast source mac xx:xx:xx:xx:xx:xx! Please execute from switch: clear mac address table dynamic multicast-entries
Conditions:
Workaround:
The correct cli is:
clear mac address-table dynamic multicast-entries
|
|
Last Modified: | 21-FEB-2016 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: * | 6.1(0.239)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux47124 | Title: | Nexus7700 error count up on link down interface with FET |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom: On Nexus7700 , some errors are counted on link down interface with FET. The port is no shut state but cable is not connected.
Conditions: Nexus7700 NXOS6.2.10 , 6.2.14 FET-10G
Workaround: shutdown the port
Further Problem Description:
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(14) |
|
Known Fixed Releases: * | 7.3(0)D1(0.186), 7.3(0)D1(1), 7.3(0)RSP(0.7), 7.3(0)ZD(0.204) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv45421 | Title: | Multicast source address inverted in igmpv3 event-history log message |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom: Incorrect SRC address in log IGMP event-history message: #show ip igmp snooping event-history vlan 2015 Jul 15 15:00:48.128938 igmp [1663]: [1676]: SN: <405> Received v3 Group-source-specific query for 239.195.1.3 from 10.21.25.252 on Vlan405 (mrt 1 sec) 2015 Jul 15 15:00:48.128928 igmp [1663]: [1676]: SN: <405> Received a v3 GSS-Query for group 239.195.1.3 (source-count 1) on Vlan405 (mrt 1 sec) src0:225.253.203.91, srcN:225.253.203.91
Conditions: N7k + IGMPv3 + IGMP snooping
Workaround: none
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.50), 7.3(0)SC(0.14), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv03431 | Title: | NSSA non-ABR performing LSA7 to LSA5 translation |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom: A non-ABR within an NSSA area shows the message "Perform type-7/type-5 LSA translation" when issuing the command "show ip ospf". Only ABRs should display this message.
Conditions: Router1 is performing the ABR role in a Totally NSSA Area.
Router2 is performing the ASBR role in the same area.
Router2 is injecting external prefixes within the NSSA area
When the command "show ip ospf" is issued on Router2, the following outpout is shown
" ... Perform type-7/type-5 LSA translation ... "
Workaround: Apply the command "area nssa translate type7 never "
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.1(2), 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.54), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum22663 | Title: | Missing description for parameter under show lisp internal event-history |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom: miss description for parameter under show lisp internal event-history
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.66), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtu54802 | Title: | Syslog server cannot see origin-id from Nexus 5000 |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom: This is an enhancement bug to add a configurable option to make the Nexus 5k to send origin-id to syslog server similar to IOS's command "logging origin-id ?". For example, having this option would allow the Nexus 5K to send syslogs messages with the hostname of the Nexus 5K at the beginning so it would be easy for the network administrator to identify which device the syslog came from.
Conditions: n/a
Workaround: n/a
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.2(0.9) |
|
Known Fixed Releases: * | 7.2(1)N1(0.293), 7.2(1)N1(1), 7.2(1)ZN(0.57), 7.3(0)BZN(0.47), 7.3(0)N1(0.108), 7.3(0)N1(1), 7.3(0)ZN(0.101), 8.3(0)CV(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus61786 | Title: | Need external loopback test added to GOLD |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:Need to add external loopback test to the Generic Online Diagnostics(GOLD) tests.
Conditions:Applies to platforms that use GOLD such as MDS 9700.
Workaround:None.
More Info:OHMS, which is the internal testing infrastructure on other MDS platforms, does have an external loopback test. GOLD needs to offer similar functionality.
Resolution Summary:
The "ExtPortLoopback" test is now available in the GOLD diagnostic commands. This test requires an external wrap plug be installed at the remote end of the cable connected to the port.
|
|
Last Modified: | 01-MAR-2016 |
|
Known Affected Releases: | 6.2(13)FM(0.15), 6.2(9) |
|
Known Fixed Releases: * | 6.2(11.4)S0, 6.2(11c), 6.2(11c)S1, 6.2(13)FM(0.31), 6.2(13)FM(0.65), 6.2(13)GS(0.13), 6.2(13.1)S0, 7.0(0)BZ(0.98), 7.1(1.72)S0, 7.2(0.55)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw82759 | Title: | Nexus 5600/6000: No LAN_BASE should disable FHRP CLI or throw error |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom: + FHRP hellos do not get punted to CPU. + Both peers assume active (master) roles and do not resolve active/standby or master/backup states + HW programming of router VMAC points to l2mp-nh instead of sup-eth HOU-CORESW-02# sh platform fwm info hw-stm asic 0 | grep 0000.5e00.0111 1.17 0000.5e00.0111 l2mp-nh 1:12298:0 1:0:1 2.a.bd.0.0.0 (e:0) + ELAM shows sup-redirect is not set
Conditions: configured VRRP or HSRP LAN_BASE_SERVICES_PKG is NOT installed
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 8.3(0)CV(0.261) |
|
Known Fixed Releases: * | 7.3(0)DX(0.102) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy49502 | Title: | Enhancement: N7K option to print all module exceptionlogs to the syslog |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom: New exceptionlogs in "show module internal exceptionlogs" are not printed to the logging logfile.
There is also no way to change any level of logging or enable any configuration to do this.
Conditions: Nexus 7000
Workaround: None
Further Problem Description:
|
|
Last Modified: | 27-FEB-2016 |
|
Known Affected Releases: | 7.2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo67369 | Title: | show lldp dcbx interface comand for fex interfaces throws error |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom: lldp commands for fex are not working
Conditions: -
Workaround: -
Further Problem Description:
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.129) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(2)FG(0.15), 7.0(2)FG(0.17), 7.0(2)FIP(0.4), 7.1(0)D1(0.168), 7.1(0)D1(0.169), 7.1(0)D1(0.170), 7.1(0)FC(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud96635 | Title: | Gibraltar:Feature mvrp |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Feature implementation
Conditions:
Feature implementation
Workaround:
Feature implementation |
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.2(5.7), 7.0(0.1)S0, 7.0(0.5)S0 |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)KM(0.64), 7.0(0)MV(0.1), 7.0(0)MV(0.10), 7.0(0)MV(0.11), 7.0(0)MV(0.12), 7.0(0)MV(0.13), 7.0(0)MV(0.14), 7.0(0)MV(0.15) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt32569 | Title: | ENH N7K: portion of NTP authentication key does not encrypt |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom: NTP authentication key numerals do not get encrypted
Conditions: N7k running Version 6.2(6)
Workaround(s):
If 7 is not included at the end of the ntp authentication key command then the letters will encrypt but the numerals will not.
r12.7k(config)# ntp authentication-key 1 md5 c1sc0 7 r12.7k(config)# sh run ntp
!Command: show running-config ntp !Time: Fri Aug 8 16:06:38 2014
version 5.2(4) logging level ntp 7 ntp server 172.18.108.15 use-vrf management ntp authenticate ntp authentication-key 1 md5 c1sc0 7 ntp logging ntp master 3
r12.7k(config)# ntp authentication-key 1 md5 c1sc0 r12.7k(config)# sh run ntp
!Command: show running-config ntp !Time: Fri Aug 8 16:07:48 2014
version 5.2(4) logging level ntp 7 ntp server 172.18.108.15 use-vrf management ntp authenticate ntp authentication-key 1 md5 f1wh0 7 ntp logging ntp master 3
Workaround:
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 5.2(1), 6.2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh10646 | Title: | gibt-mvrp project collapse into Gibraltar |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom: this is an internal tracking ID for a source code merge Conditions: not a bug, tracking ID Workaround: N/A More Info: N/A |
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.2(5.7), 7.0(0.7) |
|
Known Fixed Releases: * | 7.0(0)KM(0.64), 7.0(0.8)S0, 7.0(1)ZD(0.3), 7.1(0)D1(0.14), 7.1(0)D1(0.15), 7.2(0)D1(1), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui99939 | Title: | N7K-OFF-DIAG : Pescara N7K-100 : Development |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom: Create code for product pescara N7K-100
Conditions:
Workaround: Create code for product pescara N7K-100
Further Problem Description: Create code for product pescara N7K-100
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 7.0(0)FR(0.5) |
|
Known Fixed Releases: * | 6.2(0)HS(0.10), 6.2(10)CR(0.3), 6.2(10)EC(0.12), 6.2(10)FM(0.3), 6.2(10)NO(0.19), 6.2(12)FM(0.6), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy28010 | Title: | Need to provide ALERT when Layer 3 License for HSRP is not installed |
|
Status: * | Other |
|
Severity: * | 6 Enhancement |
Description: | Symptom: Nexus 6000 do not generate any ALERT while enabling HSRP feature when LAN_BASE_SERVICES_PKG is not installed.
Conditions: When LAN_BASE_SERVICES_PKG is not installed.
Workaround: NONE
Further Problem Description:
|
|
Last Modified: | 22-FEB-2016 |
|
Known Affected Releases: | 8.3(0)CV(0.261) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj35939 | Title: | HSRP VMAC marked with the drop flag intermittently during failover |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Packet loss might be seen for a duration = 1 HSRP hello interval during an HSRP failover. During this time the HSRP vMAC would be marked with the "drop" flag (as shown in the output below):
MUCRTP47(config-if)# show mac add vlan 100 | i 0c07 * 100 0000.0c07.ac01 static - F F Drop <<<<
Conditions: This happens only immediately after an HSRP failover.
Workaround: There is no workaround. |
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: * | 5.2(2.78)S0, 5.3(0.212)S0, 6.0(0.2)S0, 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc71813 | Title: | L3 routing over vPC3 feature support tracking |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Due to hardware limitations, L3 routing over vPC feature isn't currently supported. This is a tracking bug to document the future implementation of the feature. Workaround: One of the following supported topologies can be used: ??? A Separate L3 link between the vPC peers ??? A dedicated L2 link between the vPC peers along with a dedicated vlan(s) ??? A backup routing vlan which exists on the two peers only.
Please refer to the release notes for the feature support |
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 4.2(2a), 5.0(2) |
|
Known Fixed Releases: * | 6.3, 7.0(1)ZD(0.3), 7.2(0)ZN(0.111), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz87353 | Title: | Nexus Power Syslog Enhancement on power resumption |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom: Currently on the Nexus7000 we see syslogs as follows:
When power input removed: ===================
2009 May 21 09:18:40 n7k-ts-1 %$ VDC-1 %$ %PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS1 changed its capacity. possibly due to power cable removal/insertion (Serial number DTM123402CG)
2009 May 21 09:18:40 n7k-ts-1 %$ VDC-1 %$ %PLATFORM-2-PS_AC_IN_MISSING: Power supply 1 present but all AC inputs are not connected, ac-redundancy might be affected
When power input added back: ======================= 2009 May 21 09:18:57 n7k-ts-1 %$ VDC-1 %$%PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS1 changed its capacity.possibly due to power cable removal/insertion (Serial number DTM123402CG)
The syslog is the same when power is resumed and is confusing for customer who rely on syslog messages for NOC remediation. They have to rely on "sh environment power" to see if the power status is good.
Conditions: Power loss/resumption.
Workaround: See the "show environment power"
Further Problem Description:
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 4.1(5) |
|
Known Fixed Releases: * | 5.0(0.221), 5.0(0.224), 5.0(1), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb48863 | Title: | cannot use SVI as source-interface for syslog/AAA group/NTP |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom: It isn't possible to use a SVI as source-interface for syslog, AAA (TACACS+/RADIUS) group or NTP while it should be possible to use any physical or logical interface configured as L3 as the source of those protocols.
Conditions:
Workaround: Make use of a loopback interface to originate packets from.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 4.2(1), 4.2(1j) |
|
Known Fixed Releases: * | 5.0(0.201), 5.0(0.214), 5.0(1), 7.0(0)BZ(0.98), 7.0(0)FHS(0.23), 7.1(0)ES(0.24), 7.1(0)ZN(0.231), 7.2(0)BA(0.25), 7.2(0)ZN(0.111), 7.3(0)D1(0.22) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy18090 | Title: | ENH: N7K support for VPLS local termination |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom: No forwarding happens between VFI/xconnect and SVIs if they are defined on the same VPLS VDC. EVC functionality also cannot do local termination.
Conditions: Attempt to do local termination on a VPLS VDC.
Workaround: Currently we require to use a routed VDC, and allow the needed vlans on a switchport trunk to properly terminate the traffic.
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur08416 | Title: | NX-OS python allows users from one VDC to delete files from another VDC |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom: Cisco Nexus 7000 devices that have been configured with multiple Virtual Device Context (VDC) contain a privilege escalation vulnerability within the Python scripting subsystem that could allow an authenticated, local attacker to delete files owned by a different VDC on the device.
The vulnerability exists due to incomplete privilege separation of the python scripting engine across multiple VDC's. This could allow an attacker with administrative privileges in a specific VDC to remove files owned by a separate VDC. This could result in a denial of service condition on the affected device.
Conditions: Cisco Nexus 7000 devices running an affected version of Cisco NX-OS software.
Devices configured for multiple Virtual Device Contexts.
Workaround: Restrict access to python related commands to highly trusted users only via AAA policy.
Further Problem Description: Credit: Cisco would like to thank Jens Krabbenhoeft for discovering and reporting this vulnerability.
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 4.6/4.4: http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:N/I:C/A:N/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2015-4231 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: | 17-FEB-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)D1(1), 7.3(0)OTT(0.73), 7.3(0)PDB(0.102), 7.3(0)SC(0.14), 7.3(0)ZD(0.155) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun85740 | Title: | RPM crash when route-map assigned to interface (w/ ~450 seq entries) |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom: Unable to use more than 512 sequences in a single route-map used for PBR.
Conditions: In PBR when a single route-map containing match and set statements attached at an interface.
Workaround: Split the single route-map into multiple route-maps and try to use multiple route-maps instead of single route-map for PBR.
Further Problem Description: When a single route-map containing more than 512 sequences is used for PBR, we bail out with an error. With the enhancement we can configure more than 2048 sequences in a single route-map.
|
|
Last Modified: | 15-FEB-2016 |
|
Known Affected Releases: * | 4.1(3), 6.1(1)S60, 6.2(8)S1 |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)CF(0.11), 7.2(0)D1(0.408), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)N1(1), 7.2(0)PDB(0.353) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy17911 | Title: | Nexus WCCP Label sharing support, causing TCAM issues |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom: N7K stop redirecting traffic or in some cases cause traffic blackhole when WCCP is applied on large number of interfaces with moderate size ACL.
Conditions: WCCP, multiple redirect in statements
Workaround: Try using redirect out on egress interface if supported by line card and topology. reduce WCCP MASK
Further Problem Description:
|
|
Last Modified: | 09-FEB-2016 |
|
Known Affected Releases: | 7.3(0.143) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue55576 | Title: | op_id Declaration Inconsistent in onep Policy APIs |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.2(1) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(2.13)S, 15.3(2.15.1)XEB, 15.3(2.6)T, 15.3(2.8.1)PIB23 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj41443 | Title: | L2FM MTS buffer leak when l2fmc on a module is unresponsive |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom: On a Nexus 7000 series switch, 'l2fm' service crashed repeatedly :
%SYSMGR-2-SERVICE_CRASHED: Service "l2fm" (PID 4040) hasn't caught signal 6 (core will be saved).
Conditions: l2fmc on a module is not responding to mts messages from l2fm service running on the supervisor.
Workaround:
Further Problem Description:
|
|
Last Modified: | 04-FEB-2016 |
|
Known Affected Releases: | 4.2(6) |
|
Known Fixed Releases: | |
|
|
| |
没有评论:
发表评论