| |
Bug Id: | CSCtx66099 |
Title: | CDP crashes when receiving malformed packet |
|
Description: | Symptoms:
Cisco Nexus 1000, 3000, 4000, 5000, and 7000 switches as well as Cisco Unified Computing System Fabric Interconnect devices may restart after receiving malformed Cisco Discovery Protocol (CDP) Packets. An adjacent attacker, with the ability to submit malformed CDP traffic to an affected device could cause a denial of service condition while the device reloads or fails over to a redundant Supervisor card if so equipped.
Conditions:
Cisco Nexus Switches running an affected version of NX-OS.
Cisco Unified Computing System, Fabric Interconnect devices running an affected version of UCS Software.
Workaround:
Disable CDP on the affecte device, the CDP protocol is enabled by default.
NX-OS:
no cdp enable
UCS:
Add the 'disable cdp' command to all Network Control Policies
Further Problem Description:
This issue was identified through internal hardening efforts on the NX-OS platform.
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.1/5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2012-1322 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | 5.2(4.12)S0 |
|
|
| |
| |
Bug Id: | CSCtx54818 |
Title: | Specific SNMP GET request causes 'ipqosmgr' to crash on Nexus 7K |
|
Description: | Symptoms:
Cisco Nexus 7000 devices contain a denial of service vulnerability within the SNMP subsystem. This vulnerability could allow an authenticated,
remote attacker to crash the device by submitting a malformed SNMP request to a specific MIB.
Conditions:
Cisco Nexus 7000 devices running an affected version of Cisco NX-OS Software.
Workaround:
None.
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
6.8/6.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:N/I:N/A:C/E:F/RL:U/RC:C
CVE ID CVE-2012-4126 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(1), 6.0(1) |
|
Known Fixed Releases: | 5.2(4.9)S0 |
|
|
| |
| |
Bug Id: | CSCtn13065 |
Title: | BGP does not filter BGP update with incorrect AS-PATH Segment Length |
|
Description: |
Symptom:
Cisco NXOS based devices configured for BGP routing do not properly filter invalid AS Path Segment Lengths. This could allow an upstream BGP
neighbor to pass an invalid update to an NXOS based device that would then be propagated down stream of the affected device. This will likely result in
a rest of and resync with the BGP peer that received the invalid update.
Conditions:
Cisco devices running an affected version of NXOS software and configured for BGP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?
dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4099 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-4099
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(0.180)S14 |
|
Known Fixed Releases: | 5.2(0.218)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCts56669 |
Title: | Read-only user can create and overwrite files |
|
Description: |
Symptom:
Cisco Nexus devices contain an input validation vulnerability. This issue could allow a local, authenticated attacker to create or overwrite arbitrary files
on the device. This issue affects all user account types including Read-Only users.
This issue affects Nexus 7000 series and Nexus 5000 series devices.
Conditions:
Devices running an affected version of NX-OS Software.
Workaround:
Restrict access to trusted users only.
Further Problem Description:
This issue was identified during an internal security audit of Cisco Nexus devices.
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/3.8:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:N/I:C/A:N/E:F/RL:OF/RC:C
CVE ID CVE-2012-4122 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-4122
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: | 6.2(0.41)S0, 6.2(2), 7.0(1)ZD(0.3) |
|
|
| |
| |
Bug Id: | CSCuj13702 |
Title: | Make 'to' option of lig only available to admin-level users |
|
Description: |
Symptom:
Cisco IOS and Cisco NX-OS contain a vulnerability that could allow an authenticated, local attacker to poison the LISP routing cache on the router
configured as a ITR.
Conditions:
An attacker needs to have a privilege 0 local access to the ITR router and execute ''lig'' commands.
Workaround:
1. configure ''privilege exec level 15 lig'', to prevent privilege level 1 users from executing the lig command.
2. use separate VRFs for the EID and RLOC spaces, assuming the attacker does not have access to the RLOC case.
3. using GETVPN or other crypto in the RLOC space may mitigate against this, but not in the common deployment scenario, where crypto maps are
applied to the LISP0 interface.
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 1.5/1.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:M/Au:S/C:N/I:P/A:N/E:F/RL:W/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(5)BF(0.23), 6.2(5.42)S0, 6.2(6) |
|
|
| |
| |
Bug Id: | CSCtn13055 |
Title: | BGP does not filter updates with incorrect AS-PATH values |
|
Description: |
Symptom:
Cisco NXOS based devices configured for BGP routing do not properly filter invalid AS Path values. This could allow an upstream BGP neighbor to pass
an invalid update to an NXOS based device that would then be propagated down stream of the affected device. This will likely result in a rest of and
resync with the BGP peer that received the invalid update.
Conditions:
Cisco devices running an affected version of NXOS software and configured for BGP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?
dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4098 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-4098
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(0.180)S14 |
|
Known Fixed Releases: | 5.2(0.218)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCtx54822 |
Title: | Specific SNMP GET request causes 'snmpd' service to crash on Nexus 7K |
|
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
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-1180 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(1), 6.0(1) |
|
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) |
|
|
| |
| |
Bug Id: | CSCtx54830 |
Title: | Specific SNMP GET request causes 'snmpd' and 'licmgr' services to crash |
|
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.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(1), 6.0(1) |
|
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) |
|
|
| |
| |
Bug Id: | CSCtx54797 |
Title: | Specific SNMP GET request causes 'vlan_mgr' to crash on Nexus switches |
|
Description: | Symptoms:
Cisco Nexus 1000v, Nexus 3000, Nexus 5000, and Nexus 7000 devices contain a denial of service vulnerability within the SNMP subsystem. An
authenticated, remote attacker could submit a request to an affected device designed to trigger a null pointer dereference error that results in a crash
and reload of the affected device.
Conditions:
Cisco Nexus 1000v, Nexus 3000, Nexus 5000, and Nexus 7000 devices running an affected version of Cisco NX-OS Software.
Workaround:
None.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are
6.8/6.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:N/I:N/A:C/E:F/RL:U/RC:C
CVE ID CVE-2012-4125 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(1), 6.0(1) |
|
Known Fixed Releases: | 5.2(4.47)S0 |
|
|
| |
| |
Bug Id: | CSCtj73415 |
Title: | RIP crash at rip_ipv4_pkt_debug_message during UDP port reconnaisance |
|
Description: |
Symptom:
Cisco NXOS based devices contain a denial of service vulnerability within the Routing Information Protocol (RIP) service engine. An unauthenticated,
remote attacker with the ability to submit a malformed RIPv4 or RIPv6 message to port UDP/520 could cause the RIP service engine to restart. This
may result in a temporary inability for the device to pass traffic to a destination populated in the route table by RIP.
Conditions:
Cisco devices running an affected version of NXOS software and configured to utilize RIP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 5/3.9:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?
dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4091 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-4091
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: | 5.0(0)MP1(0.420), 5.1(1.49)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCud69928 |
Title: | N7K: Received Duplicate DBD packets cause 7K to increase sequence number |
|
Description: | Symptom:
N7K may incorrectly increment its DBD sequence number by 2 instead of 1 when it receives
duplicate DBD packets. This will cause the neighboring device to detect a bad sequence number
and reset the neighbor relationship to extart state.
Conditions:
N7K is Master in the Neighbor relationship. N7K sends a DBD with relative sequence number of 1:
Neighbor <--------seq 1------- N7K
Neighbor echos DBD with sequence number of 1 as per RFC but it sends one or more duplicates:
Neighbor ----------seq 1-------> N7K
Neighbor ----------seq 1-------> N7K
N7K should discard the duplicate packets but in some instances it may incorrectly increment the
relative sequence number buy 2 instead of 1:
Neighbor <-------seq 3--------- N7K
This will cause the neighbor to detect a bad sequence number and send a DBD with the I bit set
which will move the state machine from exchange to exstart:
Neighbor ----------seq 2(I bit set)----- N7K
Workaround:
Eliminate the duplicate DBD packets.
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 2.9/2.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:M/Au:N/C:N/I:N/A:P/E:ND/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.1(5) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S26, 5.2(9.50)S0, 6.0(2)A1(1), 6.0(2)N2(1), 6.0(2)U1(1), 6.1(3), 6.1(3)S30, 6.1(3.44)S0, 6.2(1.93) |
|
|
| |
| |
Bug Id: | CSCus77610 |
Title: | N7710G: ports down due to UDLD empty echo after neighbor LC reloaded |
|
Description: | Symptom:
Link may go to errdisable state with "UDLD empty echo" very rarely when line card reload
Conditions:
On 10G board, configure
1. UDLD protocol enabled
2. Option "system default link-fail laser-on" enabled
3. interface debounce time is set to 0
then reload the line card.
Workaround:
1. shut/no shut the port that in "errdisable" state, or
2. configure the link debounce time to 10ms or larger, or
3. disable the UDLD protocol, or
4. configure "no system default link-down laser-on" option
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)D1(0.453), 7.2(0)D1(1), 7.2(0)PDB(0.373), 7.2(0)VOF(0.2), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCus88425 |
Title: | pvlan configured ports error disabled iftmc: invalid argument |
|
Description: | Symptom:
<>
india-29(config-vlan)# sh int bri | i error
india-29(config-vlan)# sh int bri | i dis
Eth1/10 1 eth access down Error disabled auto(D) --
Eth1/16 1 eth access down Error disabled auto(D) --
Eth1/30 1 eth access down Error disabled auto(D) --
Eth1/34 1 eth access down Error disabled auto(D) --
Eth1/36 1 eth access down Error disabled auto(D) --
Eth1/38 1 eth access down Error disabled auto(D) --
india-29(config-vlan)#
india-29(config-vlan)#
india-29(config-vlan)# sh int eth1/10
Ethernet1/10 is down (Error disabled, iftmc: invalid argument to function call)
admin state is up, Dedicated Interface
Hardware: 10/100/1000 Ethernet, address: 0024.986f.20e5 (bia 0024.986f.20e5)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, medium is broadcast
Port mode is access
auto-duplex, 1000 Mb/s
Conditions:
<>
india-29(config-vlan)# sh int bri | i error
india-29(config-vlan)# sh int bri | i dis
Eth1/10 1 eth access down Error disabled auto(D) --
Eth1/16 1 eth access down Error disabled auto(D) --
Eth1/30 1 eth access down Error disabled auto(D) --
Eth1/34 1 eth access down Error disabled auto(D) --
Eth1/36 1 eth access down Error disabled auto(D) --
Eth1/38 1 eth access down Error disabled auto(D) --
india-29(config-vlan)#
india-29(config-vlan)#
india-29(config-vlan)# sh int eth1/10
Ethernet1/10 is down (Error disabled, iftmc: invalid argument to function call)
admin state is up, Dedicated Interface
Hardware: 10/100/1000 Ethernet, address: 0024.986f.20e5 (bia 0024.986f.20e5)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, medium is broadcast
Port mode is access
auto-duplex, 1000 Mb/s
Workaround:
<>
india-29(config-vlan)# sh int bri | i error
india-29(config-vlan)# sh int bri | i dis
Eth1/10 1 eth access down Error disabled auto(D) --
Eth1/16 1 eth access down Error disabled auto(D) --
Eth1/30 1 eth access down Error disabled auto(D) --
Eth1/34 1 eth access down Error disabled auto(D) --
Eth1/36 1 eth access down Error disabled auto(D) --
Eth1/38 1 eth access down Error disabled auto(D) --
india-29(config-vlan)#
india-29(config-vlan)#
india-29(config-vlan)# sh int eth1/10
Ethernet1/10 is down (Error disabled, iftmc: invalid argument to function call)
admin state is up, Dedicated Interface
Hardware: 10/100/1000 Ethernet, address: 0024.986f.20e5 (bia 0024.986f.20e5)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, medium is broadcast
Port mode is access
auto-duplex, 1000 Mb/s
Further Problem Description:
<>
india-29(config-vlan)# sh int bri | i error
india-29(config-vlan)# sh int bri | i dis
Eth1/10 1 eth access down Err
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(0.2), 7.2(0.4) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.65), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.2(0)BA(0.12), 7.2(0)D1(0.454), 7.2(0)D1(1), 7.2(0)RTG(0.143) |
|
|
| |
| |
Bug Id: | CSCut28707 |
Title: | stale/no MAC on Hw of F1 as FE not programmed on MTM due to DFTM |
|
Description: | Symptom:
Unicast flooding or traffic blackhole if the MAC is not programmed or programmed with wrong index respectively.
Conditions:
F1 module.
Workaround:
remove the affected ports from PC and add it back.
or
reload module
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.19), 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)D1(0.493), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.175), 7.3(0)IB(0.19) |
|
|
| |
| |
Bug Id: | CSCub81080 |
Title: | MTM cores found during l2fm |
|
Description: | Symptoms:
Line card may crash when processing a number of packets with broadcast source MAC address.
Conditions:
receiving multiple packets with source MAC address set to broadcast on a F2 Line Card.
Workaround:
None
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
3.3/2.7:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(7), 6.1(1.62)S0, 6.1(2) |
|
Known Fixed Releases: | 5.2(7.23)S0, 5.2(9), 6.1(2.27), 6.1(2.6)S0, 6.2(0.285), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCti11629 |
Title: | Cisco NX-OS VDC SSH Privilege Escalation Vulnerability |
|
Description: | Symptom:
Advisory ID: cisco-sa-20140521-nxos
Revision 1.0
For Public Release 2014 May 21 16:00 UTC (GMT)
Summary
=======
Cisco Nexus, Cisco Unified Computing System (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:
* Cisco NX-OS Virtual Device Context SSH Privilege Escalation Vulnerability
* Cisco NX-OS Virtual Device Context SSH Key Privilege Escalation Vulnerability
* Cisco NX-OS-Based Products Smart Call Home Buffer Overflow Vulnerability
* Cisco NX-OS Message Transfer Service 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-20140521-nxos
Conditions:
A device running an affected version of software.
Workaround:
None
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.1/6.2:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:S/C:C/I:C/A:C/E:H/RL:OF/RC:C
CVE ID CVE-2014-2200 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
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: | 5.0(3)N1(1), 5.0(5.1)S0 |
|
|
| |
| |
Bug Id: | CSCus57051 |
Title: | Hsrp_Engine crash during ISSU from 6.2(8a) to 6.2.10 |
|
Description: | Symptom:
Failure recovery action::
"Standby will be rebooted to force netboot and image download".
Install has failed. Return code 0x4093005E (system switchover failed).
Please identify the cause of the failure, and try 'install all' again.
Conditions:
ISSU from 6.2(8a) to 6.2.10
Workaround:
Upgrade without ISSU
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a) |
|
Known Fixed Releases: | 6.2(12)S27, 6.2(12.4)S0, 7.1(0)AV(0.38), 7.1(0)SIB(99.92), 7.1(2)N1(0.543), 7.2(0)AB(2), 7.2(0)BA(0.12), 7.2(0)D1(0.398), 7.2(0)D1(1), 7.2(0)N1(0.87) |
|
|
| |
| |
Bug Id: | CSCut01933 |
Title: | default route not withdrawn after removing "default originate" |
|
Description: | Symptom:
Default route will not be withdrawn from vpnv4 table.
Conditions:
Multiple [no] default-originate command toggles being configured in addess-family vpnv4. More especifically, the following steps are the minimum required to hit the issue considering the vpnv4 unicast address-family is clean of any configurations:
1. default-information originate always rd route-target |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 7.2(0)ZN(0.36) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(2)N1(0.554), 7.1(2)ZD(0.9), 7.1(2)ZN(0.13), 7.2(0)D1(0.451), 7.2(0)D1(1), 7.2(0)FM(0.3) |
|
|
| |
| |
Bug Id: | CSCtw98915 |
Title: | Cisco NX-OS Message Transfer Service DoS Vulnerability |
|
Description: | Symptom:
Advisory ID: cisco-sa-20140521-nxos
Revision 1.0
For Public Release 2014 May 21 16:00 UTC (GMT)
Summary
=======
Cisco Nexus, Cisco Unified Computing System (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:
* Cisco NX-OS Virtual Device Context SSH Privilege Escalation Vulnerability
* Cisco NX-OS Virtual Device Context SSH Key Privilege Escalation Vulnerability
* Cisco NX-OS-Based Products Smart Call Home Buffer Overflow Vulnerability
* Cisco NX-OS Message Transfer Service 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-20140521-nxos
Conditions:
A device running an affected version of software.
Workaround:
None
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.1/5.9:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2014-2201 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.0(1), 6.0(2) |
|
Known Fixed Releases: | 6.0(2)S30, 6.0(2)S31, 6.1(0.174)S0, 7.0(1)ZD(0.3), 7.2(0)N1(1), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCum42151 |
Title: | Enable secret hashes improperly calculated |
|
Description: | Symptoms:
The salt of 'enable secrets' is not randomized properly.
Conditions:
'feature privilege' is configured.
Workaround:
None
Further Problem Description:
None
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | 6.0(2)A4(0.764), 6.0(2)A4(1), 6.0(2)U4(0.764), 6.0(2)U4(1), 6.2(10), 6.2(8)KR(0.8), 6.2(8.13)S0, 6.2(9)FM(0.67) |
|
|
| |
| |
Bug Id: | CSCut38574 |
Title: | Wrong EIGRP delay calculation |
|
Description: | Symptom:
Two port-channels with different bandwidth are being populated in the routing table as equal-path. And two port-channels with same bandwidth are not both populated as equal-path in the routing table.
Conditions:
Using EIGRP with 40G links/port-channels.
Workaround:
We figure out the issue. The delay value is getting cached and we are no updating it on b/w change.
I will fix this issue.
The main thing is we need to update delay on bandwidth change. Or we need to flush it. So it will get updated with correct value
corresponding to updated bandwidth.
Work around:
That can be done with,
#SVS-N7K-C1-61# conf t
#SVS-N7K-C1-61(config)# interface port-channel 12
#SVS-N7K-C1-61(config-if)# ip delay eigrp 100 200000 << some random value
#SVS-N7K-C1-61(config-if)#no ip delay eigrp 100 200000
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.23), 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)IB(120), 7.2(0)D1(0.481), 7.2(0)D1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCuc19553 |
Title: | RADIUS insufficient attribute length check |
|
Description: | Symptoms:
Cisco NXOS contains a vulnerability in the RADIUS authentication code.
Conditions:
Malformed packets are returned from a RADIUS authentication server.
Workaround:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2012-6377 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.0(3) |
|
Known Fixed Releases: | 6.1(2.45)S0, 6.2(0.273)S0, 6.2(0.285), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCtz01813 |
Title: | N7K-F248XP-25 fex port may hang when in vntag mode |
|
Description: | Symptom:
Any port that connects any Fabric Extender (FEX) device terminated on a N7K-F248XP-25 module of
a Nexus 7000 chassis may go err-disable and possibly take the FEX offline.
Conditions:
Only seen on N7K-F248XP-25 ports in fex mode
Workaround:
Reload the module to recover from the condition.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | 6.0(3)S2, 6.0(3)S5, 6.1(0.252)S0 |
|
|
| |
| |
Bug Id: | CSCuu11331 |
Title: | N7K - SNMP snmpd core os_syscall_ioctl, tcp_api.c, libmts.c running UTE |
|
Description: | Symptom:snmpd crashed. In the background 8 out of 10 times its aclqos mib causing the problem.
Conditions:This happens when CPU utilization is high from the normal.
Workaround:snmpd restart is stateful so it boots up with all the configs intact.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S102, 7.2(0)D1(0.475), 7.2(0)D1(0.484), 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud24904 |
Title: | DIAGCLIENT-2-EEM_ACTION_HM_SHUTDOWN: Test <RealTime Clock> disabled |
|
Description: | Symptom:
Diagclient failures are reported on the sup.
%DIAGCLIENT-2-EEM_ACTION_HM_SHUTDOWN: Test has been disabled as a part of default EEM action
%DEVICE_TEST-2-RTC_FAIL: Module 1 has failed test RealTimeClock 20 times on device RealTimeClock due to error The clock jiffies were found to be not moving
%MODULE-4-MOD_WARNING: Module 1 (Serial number: <>) reported warning due to The clock jiffies were found to be not moving in device DEV_UNDEF (device error 0x0)
MDS# sh module
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 0 Supervisor module-1X N7K-SUP1 active *
2 0 Supervisor module-1X N7K-SUP1 ha-standby
3 48 1/10 Gbps Ethernet Module N7K-F248XP-25 ok
4 48 1/10 Gbps Ethernet Module N7K-F248XP-25 ok
5 32 10 Gbps Ethernet XL Module N7K-M132XP-12L ok
6 32 10 Gbps Ethernet XL Module N7K-M132XP-12L ok
.....
....
Mod Online Diag Status
--- ------------------
1 Fail
2 Pass
3 Pass
4 Pass
5 Pass
6 Pass
Conditions:MDS 9700 or Nexus 7K
There were no specific triggers prior to these failures.
Workaround:None at this time.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.1(3)S11, 6.1(3)S18, 6.1(3)S4, 6.1(4a)S11, 6.1(4a)S12, 6.2(1.121)S0, 6.2(1.121)S1, 6.2(1.131), 6.2(1.23)S3, 6.2(2)S1 |
|
Known Fixed Releases: | 6.1(4a), 6.1(4a)S14, 6.1(5)S8, 6.1(5.6)S0, 6.2(0)HS(0.10), 6.2(1.112)S0, 6.2(1.156)S0, 6.2(2), 6.2(2)S25, 6.2(2)S9 |
|
|
| |
| |
Bug Id: | CSCut20914 |
Title: | EIGRP IPv6 neighbour sessions flaps after LC reload |
|
Description: | Symptom:
EIGRP ipv6 neighbor sessions flap
Conditions:
After LC reload
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 7.1(0)IB(103) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)IB(120), 7.2(0)D1(0.481), 7.2(0)D1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCus09312 |
Title: | PVLAN:VPC PO member (M1 LC) flaps. |
|
Description: | Symptom:
Port-channels which have
1) PVLAN trunk secondary config
and
2)LACP or other control protocols running,
could flap continuously, due to BPDU's not flowing. They don't flow because the native vlan is in CBL disabled state, instead of being in CBL Blocking state.
Conditions:
The issue is specific to M1 module since the programming model is different on F2/F3 LC's.
There is no issue on F2 and F3 modules.
Even if the customer uses M1 module there is NO issue, if customer is allowing native VLAN on VPC Leg.
Below are the 3 conditions that need to be satisfied to hit this bug:
1) PVLAN port mode should be TRUNK Secondary
2) Native VLAN is NOT allowed on VPC Leg
3) LC Module should be M1 module
Workaround:
Workaround is to have customer have the native vlan in allowed list for the port, by configuration.
For a private-vlan port, the command to add trunk allowed vlan 1 would be:
switchport private-vlan trunk allowed vlan 1
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.2(10)S102, 6.2(12)FT(0.7) |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.2(0)D1(0.459), 7.2(0)D1(1), 7.2(0)PDB(0.382) |
|
|
| |
| |
Bug Id: | CSCut29918 |
Title: | UIN-1::Seeing IPV6 eigrp auth failure during system switchover |
|
Description: | Symptom:
IPV6 eigrp auth failure during system switchover
Conditions:
Authentication is enabled for IPv4 EIGRP on the same interface
Workaround:
Unconfigure/Reconfigure ipv6 eigrp on the interface
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.437) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)SIB(99.109), 7.2(0)AB(9), 7.2(0)BA(0.12), 7.2(0)D1(0.444), 7.2(0)D1(0.456), 7.2(0)D1(0.457), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCue67277 |
Title: | Interface does not recover from err-disable state during ISSU from 5.2.7 |
|
Description: | Symptom:
During ISSU, if any ports flap they get error disabled and stay error disabled even after ISSU is completed.
Conditions:
Issue occurs only if ports flap while ISSU is in progress.
Workaround(s):
shut/no shut will bring up the error disabled ports.
Workaround:
Workaround for recovering error disabled ports :
- Wait till the ISSU is over. Once the system is ready, issue a "shut / no shut" on the ports to recover them to normal state.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(5)S2, 6.1(3)S47, 6.2(1.111)S4, 6.2(1.118)S1, 6.2(1.125)S5, 6.2(1.91)S7, 6.2(5.7), 7.0(0)FV(0.88), 7.0(0.1) |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(5), 6.1(5.20)S0, 6.2(1.121)S0, 6.2(1.127)S0, 6.2(2), 7.1(0)D1(0.14), 7.2(0)VZN(0.30) |
|
|
| |
| |
Bug Id: | CSCua10013 |
Title: | During ISSU from FH1a to GC181,traffic loss due to ISIS tree computation |
|
Description: | Symptom:
With peer link having the default ISIS metric in vPC+ environment -during ISSU from 5.1.3 to 5.2.1, L2MP traffic can be lost.
NOTE: usually mct(peer-link) is configured with higher ISIS metric to avoid data taking this path. To make data go through the DCE cloud.
Trigger:
1.peer-link should have default ISIS metric on both vpc peers
2.ISSU from 5.1.3 to 5.2.1
Conditions:
Workaround:
Configure a high metric for peer link and then do the ISSU.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(1), 6.1(3) |
|
Known Fixed Releases: | 6.2(0.260)S0, 6.2(2) |
|
|
| |
| |
Bug Id: | CSCud44300 |
Title: | EntitySensor MIB handler should validate if_idx before query port client |
|
Description: | Symptom:
On a Nexus 7000 switch, if an interface index is queried that is higher than the number of
ports on the specific linecard, there is a chance that mts memory may be held indefinitely by
snmpd and eventually will exhaust mts resources. In a dual supervisor environment , snmpd will
core and a HAP reset will be observed. In a single sup, a core should be saved and the system
will crash/reboot.
Conditions:
This problem would typically happen if a higher-density linecard is replaced in the same slot
with a lower-densitiy card, and the management station continues to try and poll the
non-existant higher ports.
Workaround:
Workaround is to rediscover the devices to eliminate the out of bounds polling of the
non-existant interfaces or if the device is statically-configured with the mib, disable polling
for that non-existant object.
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.8/5.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2012-6396 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.2(7), 6.1(2) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S26, 5.2(9.50)S0, 6.0(2)A1(1c), 6.0(2)U1(3), 6.0(2)U2(1), 6.1(3), 6.1(3)S19, 6.1(3.29)S0, 6.2(1.93) |
|
|
| |
| |
Bug Id: | CSCut47663 |
Title: | SSTE: OSPF Adj are struct in TWO-WAY state after ospf process restart |
|
Description: | Symptom:
OSPF Adj are struct in TWO-WAY state
Conditions:
restart opsf 100. If there is no BDR.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.444) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)D1(0.468), 7.2(0)D1(1), 7.2(0)N1(1), 7.2(0)PDB(0.401), 7.2(0)VZD(0.26), 7.2(0)VZN(0.34) |
|
|
| |
| |
Bug Id: | CSCuu29945 |
Title: | SSTE: m2rib core on POAP + autoconfig |
|
Description: | Symptom:
m2rib core
Conditions:
POAP + autoconfig
Workaround:
NA
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.499) |
|
Known Fixed Releases: | 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)D1(0.506), 7.2(0)D1(0.510), 7.2(0)D1(1), 7.2(0)ZD(0.190), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCut19573 |
Title: | some vpc portchannels are not up upon RAX config |
|
Description: | Symptom:
When the port-channel configured with LACP individual and shut and no shut of VPC or port-channel will trigger. Extented fix for CSCus90226
Conditions:
LACP Individual configured on the port-channel
Workaround:
Remove the LACP Individual config for the Port-channel
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.2(12)E2 |
|
Known Fixed Releases: | 6.2(12)E2, 6.2(13.3)S0, 6.2(14)FB(0.11), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.442), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.368), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCum58738 |
Title: | On vdc reload: netstack and syslogd cored and vdc remained in fail state |
|
Description: | Symptom:
On VDC reload , the VDC goes into a failed state.
In the logs you would see "netstack" and "syslogd" fail.
%SYSMGR-2-SIGKILL_FAILURE: Service "netstack" failure to respond to SIGKILL causing supervisor to reset. Last heartbeat 122.0 8 secs ago.
Conditions:
when VDC is reloaded or suspended
Workaround:
none - need to reload the switch to recover
This issue is resolved in code 6.2(6a) and later
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.2(6a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur38749 |
Title: | Connection to a non-existent host is consumed/precessed by xTR itself |
|
Description: | Symptom:
A vulnerability in Cisco Locator/ID Separation Protocol (LISP) feature of Cisco NX-OS could allow an authenticated, remote attacker to use SSH connection to a non-existent host covered by lisp mobile prefix
from outside of the DC and get presented with the xTR login prompt.
An attacker still needs to have login credentials for NX-OS device in order to be able to log in.
Conditions:
LISP mobility and lisp enabled interface need to be configured.
Workaround:
VTY ACL preventing login prompt to be displayed to the user connecting from the outside can
prevent unauthorized logins
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 3.5/2.9:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:S/C:P/I:N/A:N/E:F/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.11), 6.2(12)FT(0.5), 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)EV(0.112), 7.1(0)PDB(0.317), 7.2(0)D1(0.368) |
|
|
| |
| |
Bug Id: | CSCur54182 |
Title: | NX-OS Tacacs Daemon hap reset |
|
Description: | <B>
Symptom:</B>
Device configured for TACACS may face crash due to "Tacacs
Daemon hap reset"
Reason: Reset triggered due to HA policy of Reset
Service: Tacacs Daemon hap reset
<B>
Conditions:</B>
On a switch running NX-OS 6.2(8a) or later, if a very long command is
given with remote authorization using TACACS enabled, a crash is seen in TACACS. Because
TACACS expects the strings to be of size 255, it is unable to handle strings greater than 255.
<B>
Workaround:</B>
None.
More Info:
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.4/3.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:M/Au:S/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2014-8013 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.0(2)A6(0.41), 6.0(2)A6(1), 6.0(2)U6(0.41), 6.0(2)U6(1), 6.1(2)I3(2.15), 6.1(2)I3(3), 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.12), 7.0(0)BZ(0.46) |
|
|
| |
| |
Bug Id: | CSCuq22841 |
Title: | M1 Module: Invalid COS (0x41040021) after ISSU from 5.2(x) to 6.2(x) |
|
Description: | Symptom:
Ports are not allocated to a secondary VDC with the following logs:
2014 Jul 24 16:14:26.864 N7K %IM-3-IM_RESP_ERROR: Component MTS_SAP_VMM opcode:MTS_OPC_IM_IF_VDC_BIND in vdc:2 returned error:Invalid COS value.
2014 Jul 24 16:14:35.568 N7K last message repeated 1 time
2014 Jul 24 16:14:35.568 N7K %VDC_MGR-3-VDC_ERROR: vdc_mgr: Error for port Ethernet . Port is currently in vdc N7K-VDC2 [2]. GIM returned 41040021 [Invalid COS value.]. Please run the command "allocate interface Ethernet force" to try again
In 'show vdc membership status' we see the following as the reason for the ports not being allocated: 'ERROR:Invalid COS value. (0x41040021)'.
Conditions:
- ISSU from 5.2(x) to 6.2(x)
- M1 Module
Workaround:
Reload affected module.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.2(8a), 6.2(8a)S3 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuf47376 |
Title: | Trunk/FEX FPC port config removed by "system def switchport fabricpath" |
|
Description: | Symptom:
adding/removing 'system default switchport fabricpath' cli seems to affect the configuration of trunks/access/fex fabric ports.
On a system with this command, a disruptive upgrade/reload might also cause config issues
Conditions:
adding/removing 'system default switchport fabricpath' cli / reload/disruptive upgrade with this command
Workaround:
If reload/disruptive upgrade has to be done, take a config backup first to restore
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.37), 7.1(0)AV(0.38), 7.1(0)PDB(0.324), 7.2(0)D1(0.392), 7.2(0)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCus52139 |
Title: | post L3, l2 flood traffic not going out on peer-link |
|
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:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.383) |
|
Known Fixed Releases: | 7.1(0)AV(0.38), 7.1(0)SIB(99.82), 7.2(0)BA(0.12), 7.2(0)D1(0.386), 7.2(0)D1(0.388), 7.2(0)OTT(0.5), 7.2(0)RTG(0.91), 7.2(0)ZD(0.75) |
|
|
| |
| |
Bug Id: | CSCut25162 |
Title: | VPLS VC's don't come after delete/add VFI's in EFP scale setup |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
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, 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)IB(122), 7.1(0)LR(0.4) |
|
|
| |
| |
Bug Id: | CSCuu58619 |
Title: | IPFIB vrf dependency database doesnt cleanup on VDC reload |
|
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.8) |
|
|
| |
| |
Bug Id: | CSCuo67870 |
Title: | VTP Pruning causes traffic outage in a vPC when primary leg is flapped |
|
Description: | Symptom:
vPC VLANs on a trunk interface are incorrectly pruned by VTP on the vPC Operational Secondary Nexus 7000. The interface can be configured as a vPC leg or as a vPC Orphan port.
Conditions:
This issue will only occur on a Nexus 7000 vPC setup running NX-OS version 6.2(6) or higher that is also configured to use VTP for VLAN pruning.
The trigger for the issue is a flap of a vPC leg on the vPC Operational Primary switch. After the link flap, VTP does not successfully process join messages for the VLANs, resulting in a timeout and the VLANs being pruned from the link.
Workaround:
1) Flap any vPC leg on the vPC Operational Secondary switch to force a VTP to recalculate the pruning state
2) Remove and re-add the VTP Pruning configuration*
* Note: When VTP is removed, all broadcast traffic for VLANs in the trunk allowed list is allowed expectedly to be flooded out of the interface
The issue is resolved in the 6.2(10) release of NX-OS for the Nexus 7000.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.2(6), 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S59, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.238), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.176), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCut03089 |
Title: | After ISSU from 6.2.10 to 6.2.12 Optical Modules doesn't show DOM info |
|
Description: | Symptom:
On N7K running 6.2.12 code, some of the DWDM optical modules will not show DOM info.
Example Output.
switch-core# sh int e1/25 trans de
Returning from 1
unknown error 0x40290003
Ethernet1/25
transceiver is present
type is DWDM-SFP10G-35.04
name is CISCO-FUJITSU
part number is FIM35060/201W53
revision is 0002
serial number is FLJ1718K016
nominal bitrate is 11100 MBit/sec
Link length supported for 9/125um fiber is 80 km
cisco id is --
cisco extended id number is 4
cisco part number is 10-2779-01
cisco product id is DWDM-SFP10G-35.04
cisco vendor id is V01
switch-core#
Conditions:
This behavior is seen only after ISSU from 6.2.10 to 6.2.12 on DWDM optical modules.
This behavior is not seen while performing traditional code upgrade from 6.2.10 to 6.2.12
Workaround:
Problem is not seen after traditional code upgrade from 6.2.10 to 6.2.12
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.20), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.439), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.365), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCuf65721 |
Title: | IGMP frames not forwarded correctly in VPC+ setup |
|
Description: | Symptom:
IGMP joins/leaves received on on VPC+ device may not correctly be forwarded through the fabricpath domain.
VPC+ edge switches may not have the proper IGMP state showing the interested clients.
Conditions:
Nexus 7000 In a vPC+ setup, all multi destination frames (broadcast, multicast, unicast flood) are forwarded by the VPC designated forwarder (DF). This issue occurs when an IGMP message is received on the VPC device that is not the DF for the mrouter port-channel.
Workaround:
Disable IGMP snooping
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: | 6.0(2)U3(0.641), 6.0(2)U3(1), 6.1(4.50)S0, 6.1(5), 6.2(1.69)S0, 6.2(2), 7.0(0.7) |
|
|
| |
| |
Bug Id: | CSCut93487 |
Title: | OTV: AED stays inactive for all VLANs |
|
Description: | Symptom:
One AED stays inactive for all VLANs
Conditions:
Using OTV with 2 AEDs
Workaround:
Remove the vlans that won't come up and add them back to the OTV vdc.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut84904 |
Title: | Process "mtm" Cores on F3 Cards Shortly After Boot |
|
Description: | Symptom:
Repeated "mtm" cores on an F3 linecard
Conditions:
Unknown, first seen after an ISSU from 6.2(8b) to 6.2(10)
Workaround:
Unknown
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo93631 |
Title: | N7K MAC address in hardware but missing from software after ISSU |
|
Description: | Symptom:
Nexus 7000 does not learn new MAC addresses in software after ISSU.
"show hardware mac address-table " contains MAC entry in hardware (x = ingress module in question)
"show mac address-table" does not contain MAC entry in software
Conditions:
a) ISSU performed on N7K
b) In combination with ISSU, a new learn mac address caused by a new mac, or a flush of the mac table and re-learn of existing macs while system is undergoing ISSU.
Workaround:
Run the following command: "test l2fm pending-ack slot for all modules which have the "sup_ack_pend" bit set to 1. To check what the bit is set to run the following command:
- slot show system internal mtm info global | eg -i ack_pend
nl_mv_rd num_ack_pending 1 sup_ack_pending 1
age num_ack_pending 0 sup_ack_pending xxx
- any module with "ack_pending" status = "non-zero" is the module(s) to be reloaded
A reload of the module also resolves this issue.
Also, "clear mac address-table dynamic" resolves this issue
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.143), 7.1(0)D1(0.146), 7.1(0)D1(0.153) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S22, 7.1(0)D1(0.196), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)IF(99.16), 7.1(0)NF(0.32), 7.1(0)OTT(0.18), 7.1(0)RTG(0.12), 7.1(0)SIB(99.6) |
|
|
| |
| |
Bug Id: | CSCum81252 |
Title: | Merge XOS/LPSS with NXOS pss2: XOS/LPSS part |
|
Description: | Symptom:
Need to merge xos/lpss@dev1 to NXOS. There are some small issues fixed in this merger
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.162), 7.1(0)ZN(0.22) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(3)I1(0.64), 7.0(3)I1(1), 7.1(0)BF(0.107), 7.1(0)BF(0.108), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)IF(99.16) |
|
|
| |
| |
Bug Id: | CSCuo02430 |
Title: | SSTE: hsrp process crashed with SSO trigger |
|
Description: | Symptom:
HSRP process on the standby sup becomes unresponsive and eventually crashes with heartbeat timeout when system switchover is performed. HSRP process is then restarted by sysmgr.
Conditions:
HSRP groups are configured on interfaces with invalid VRFs (i.e. where the VRF is shutdown or not defined). Switch is booted up with saved startup config. System switchover is performed.
Workaround:
Ensure VRFs are valid before system switchover, i.e. if the VRF is shutdown then "no shut" the VRF, and if VRF is not defined then define it.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 6.2(8)S11, 6.2(8)S19, 6.2(8)S9, 7.0(3)I2(0.375) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)FM(0.28), 6.2(10)NO(0.18), 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(3)I2(0.390), 7.0(3)I2(1), 7.1(0)BF(0.98) |
|
|
| |
| |
Bug Id: | CSCuu84358 |
Title: | N77/F3/MPLS: mcast traffic drop 6-8 secs after SSO |
|
Description: | Symptom:
traffic loss is seen after SSO
Conditions:
SSO is performed, traffic outage is seen for a very short duration and then recovers
Workaround:
no workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.8), 7.2(1)N1(0.241), 7.2(1)N1(1), 7.2(1)ZD(0.7), 7.2(1)ZN(0.7) |
|
|
| |
| |
Bug Id: | CSCuu57637 |
Title: | FCOE traffic is dropped at FEX FPC if storage vdc is created after ISSU |
|
Description: | Symptom:
CRC giant-drops(ingress_giant_drops) seen on fex FPC ports on any qos template change after issu.
Conditions:
after issu if you do any qos template change and if you have fex in your setup, you will see MTU mismatch resuling in giant/CRC drops in the ingress of FPC ports.
Workaround:
configure/change qos template before issu.
or
shut/no-shut on fex FPC ports to reconfigure the mtu
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.514) |
|
Known Fixed Releases: | 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)ZD(0.205), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCut61977 |
Title: | Crash after show forwarding route adjacency <interface> <ip address> |
|
Description: | Symptom:
A ipfib process crash is seen. This may lead a HAP-Reset which could reload a module:
Nexus# sh core vdc-all
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
1 4 1 ipfib 18455 2015-03-26 11:06:19
1 4 1 ipfib 2173 2015-03-26 11:06:23
1 3 1 ipfib 12089 2015-03-26 11:06:29
1 3 1 ipfib 2173 2015-03-26 11:06:3
Conditions:
This occurs after the show forwarding route command is entered with the adjacency options.
Workaround:
Avoid using the show forwarding route adjacency command
Further Problem Description:
This is similar to the CSCur91392 bug but additional changes are needed.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.41), 7.2(1)D1(0.9) |
|
|
| |
| |
Bug Id: | CSCur52940 |
Title: | N7K - snmpd cores cause Supervisor HAP reset - transceivers |
|
Description: | Symptom:
The "snmpd" process may crash continuously leading to a supervisor HAP reset.
Conditions:
Polling "ciscoEntitySensorMIB", that result in reading DOM information from 10G or 40G or 100G transceiver, during (re)initialization of the transceiver.
(Re)Initialization of transceiver happens only when -
- The transceiver is being reseated
- The linecard in which the transceiver is seated is reseated or reloaded
- The switch itself is being reloaded
Workaround:
Block ciscoEntitySensorMIB from being polled. This can be done by creating a new role, as follows:
(config)# role name skipEntSensor <--------------------- name can be anything.
(config-role)# rule 1 permit read
(config-role)# rule 2 deny read oid 1.3.6.1.4.1.9.9.91
(config-role)# end
(config)# snmp-server community safeWalk group skipEntSensor <-------------- safeWalk in this example is the community name. Change it to whatever is used in production.
After this when a snmpwalk (getnext) is done ciscoEntitySensorMIB is skipped.
All community strings configured on the switch will need the
role group skipEntSensor applied to include public, private, etc. community strings
Further Problem Description:
The snmpd crash is caused by invalid data returned by port-client due to an internal timeout when reading the DOM of a transceiver that is still initializing.
This problem is seen only on 6.2.10 software version.
DOM is not accessible through CLI when the port/transceiver is still initializing.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(10)E6, 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.14), 6.2(12)FT(0.20), 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)EV(0.137) |
|
|
| |
| |
Bug Id: | CSCut57953 |
Title: | N7K "ipfib" process crash |
|
Description: | Symptom:
N7K line card crash with "ipfib" core file generated.
Conditions:
crash observed on N7K running ospfv3 on 6.2.12 code
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.58), 7.2(1)D1(0.10) |
|
|
| |
| |
Bug Id: | CSCua82201 |
Title: | BGP process fail due to constant BGP socket open/close state changes |
|
Description: | Symptom
BGP process fails due to constant BGP socket open/close state changes. If there are several idle peers, over a period of time due to excessive churn of netstack client for BGP sockets, newly provisioned BGP session fail to come up with the following error
BGP-3-SOCKCREATE: bgp-XXXX [24958] Cannot create socket for peer X.X.X.X: Bad file descriptor, stats: 28391553/496156/28887500/14303942/14143771
Workaround
If BGP graceful restart is configured, then clear all BGP neighbors may clear the issue
If BGP graceful restart is not configured then disabling and enabling 'feature bgp' from the active configuration will clear this issue
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 6.0(2)S31 |
|
Known Fixed Releases: | 6.0(2)U2(1), 6.0(2)ZD(0.6), 6.1(2), 6.1(2)E10, 6.1(2)E10.4, 6.1(2)S6, 6.1(2.11)S0, 6.2(0.285), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCui36490 |
Title: | BGP outbound messages can get stuck in certain conditions. |
|
Description: | Symptom:
BGP outbound messages can get stuck in certain conditions
Conditions:
If BGP has caught up with updating its peers with all route updates, the sender thread may inadvertently go to sleep because of this bug. In such a case, residual outbound messages to the peers will be stuck until another message (keepalive, update, etc.) gets queued to wake the sender thread
Workaround:
"clear ip bgp" or "restart bgp" may resolve the issue but it may end up in the same situation later.
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 2.6/2.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 6.2(0)PF(0.296), 6.2(2)S31, 6.2(8) |
|
Known Fixed Releases: | 6.0(2)N3(1), 6.2(10), 6.2(10)CM(0.34), 6.2(11)FM(0.7), 6.2(8)E1, 6.2(8)IAS(0.18), 6.2(9.4)S0, 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)ZD(0.122) |
|
|
| |
| |
Bug Id: | CSCut76387 |
Title: | FEX crashed at "satctrl" process |
|
Description: | Symptom:
FEX crashed at "satctrl" process
Conditions:
UNKOWN
Workaround:
NONE
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuf60213 |
Title: | F2 card reload with "clp_mac" cores |
|
Description: | Symptom:
F2 crashes due to the "clp_mac" process. Within the core file, we see the EEM is trying to process an error message "CLM_CFG_PARITY_ERR".
Conditions:
Issue is triggered by a port config register parity error. Current code only gracefully handles ASIC-level parity errors, not port-level errors -- this will be changed.
Workaround:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 6.1(2), 6.2(1.79)S2 |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(5), 6.1(5.5)S0, 6.2(1.101)S0, 6.2(2), 7.0(0)ZD(0.53), 7.0(0)ZD(0.55) |
|
|
| |
| |
Bug Id: | CSCut39102 |
Title: | stp disputes are seen during vdc reload in vPC + setup |
|
Description: | Symptom:In a VPC+ setup running MST and with a large scale logical port count , on reloading the primary peer, stp disputes may sometimes be seen on the secondary switch.
Conditions:*VPC+ scenario.
*Primary Peer reload
Workaround:More Info:If disputes occur, they will clear as soon as the secondary switches to Operational primary.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.441), 7.2(0)D1(0.451) |
|
Known Fixed Releases: | 7.1(0)ES(0.18), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.2(0)BA(0.12), 7.2(0)D1(0.451), 7.2(0)D1(0.455), 7.2(0)D1(0.470), 7.2(0)RTG(0.143), 7.2(0)RTG(0.150), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCuo22348 |
Title: | port-state request triggers burst of bpdu's from VPC primary switch. |
|
Description: | Symptom:
Nexus 7000 switch may exhibit excessive TX inband traffic rates affecting control-plane services after attempting to collect show interface trunk command output.
Bug is not specific to show int trunk command. It can happen anytime port state info request event is processed.
Request may come via SNMP request or another show command.
Check output of "sh hardware internal cpu-mac inband stats" for TX packet rate. With this bug, TX rate shoots up very high.
N7K1# sh hardware internal cpu-mac inband stats | in rate
Packet rate limit ........... 64000 pps
Rx packet rate (current/max) 1 / 16 pps
Tx packet rate (current/max) 15215 / 18753 pps <<====
AND
Check for below logs in the output of "show spanning-tree internal interactions".
+++++++++++++++++++++
1080) Event:(null), length:87, at 988005 usecs after Wed Oct 29 10:26:46 2014
stp_send_bpdu_now(4995): Start: reason During handling of port state info request
1081) Event:(null), length:85, at 980152 usecs after Wed Oct 29 10:26:46 2014
stp_send_bpdu_now(5017): End: reason During handling of port state info request
++++++++++++++++++++++
Conditions:
Nexus 7000 running 6.2(2) or later release with a high VLAN count. Whenever a port-state request is sent to STP, there are additional BPDUs sent out for each STP logical port in the system.
Workaround:
Do not use the command.
If using AAA with command authorization, the commands may be blocked in the ACS profile.
Further Problem Description:
To monitor CPU-Mac inband stats during an event use show hardware internal cp-mac statistics. The Tx rate increases drastically.
Rx packet rate (current/max) 632 / 3372 pps
Tx packet rate (current/max) 3174 / 31054 pps <<<<<
To verify when the MAX rate was triggered use "sh hardware internal cpu-mac inband events"
Note: The command will only record the MAX rate event if it surpasses the previously recorded max rate event.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 6.2(6), 6.2(6a), 6.2(8), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)EC(0.22), 6.2(10)FM(0.26), 6.2(10)NO(0.20), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73) |
|
|
| |
| |
Bug Id: | CSCuo51846 |
Title: | N7K: 3rd party SFP-10G-SR reported as "Unsupported transceiver" |
|
Description: | Symptom:
3rd-party SFP-10G-SR reported as "Unsupported transceiver":
ETHPORT-3-IF_UNSUPPORTED_TRANSCEIVER Transceiver on interface Ethernet2/1 is not supported
To verify if its the same issue
module-7# sh hard int transceiver ins 0 sprom raw
+-------------------------------------------------------------------------------
| Get sprom/dom data for XCVR_USD Driver
SPROM in raw format:
-------------------
Comment Addr Value
------- ---- -----
Identifier 0 03
Ext. Identifier 1 04
Connector Type 2 07
10G Ethernet Compliance Code 3 00
ESCON/SONET Compliance Code 4 00 00
Ethernet Compliance Code 6 00
Transceiver (Fibre Channel) 7 40 >>>>> Having 7,8 and 9th bytes programmed with any non-zero number will result in this bug.
Transceiver (Fibre Channel) 8 40
Transceiver (Fibre Channel) 9 0c
Transceiver (Fibre Channel) 10 80
Conditions:
This is observed on a Nexus 7000 or 7700 port running a 6.2(8) release.Its not seen in any other releases
before 6.2.8 . Its fixed in 6.2.10
It is applicable for all LCs and only affects some of the 3rd party transceivers.
Workaround:
Use a Cisco Transceiver.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.4), 6.2(8)E1, 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.12)S0, 6.2(8a)E2 |
|
|
| |
| |
Bug Id: | CSCus58902 |
Title: | Potential of opening al back door |
|
Description: | Symptom:
If the admin user is able to reach the underlying OS shell, it migh be possible to create a fully functional operating system account that could have unlimited access to the underlying operating system.
Conditions:
Requires full administrative access to the device and the existence of a separate bug that would allow the administrator to access the underlying operating system
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 7.2(0)ZN(0.36) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup90186 |
Title: | Queuing policy of eth interface is removed when added to port-channel |
|
Description: | Specific to case where queuing policy on the port-channel and port moving to it are same.
Symptom:
When queuing policy on port-channel and port moving to it are same, policy on physical port resets to default.
Conditions:
Only when queuing policy on the port-channel and port moving to it are same.
Workaround:
Remove the queuing policy from physical port before moving to port-channel.
Or if the error has already occured:
Move physical port out of port-channel and bring it back in. Moving out resets queuing to default, bringing back will apply port-channel queuing policy.
Further Problem Description:
Q. How does customer land in this situation?
A. If customer configures the "same" queuing policy on an eth interface and a port-channel. And then he moves the eth interface to the port-channel, he will hit this bug. Please notice that the "same" policy should be configured on both eth interface as well as port-channel to land into this situation.
Q. How do I resolve this situation?
A. If you are in this situation, just move your port out of the port-channel and bring it back in. Just a simple out-in of the eth port will resolve this condition.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 6.2(12)FF(0.8), 7.1(0)D1(0.197) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.12), 7.2(0)D1(0.402), 7.2(0)D1(1), 7.2(0)OTT(0.5), 7.2(0)PDB(0.329) |
|
|
| |
| |
Bug Id: | CSCup47983 |
Title: | F3 CB-10:Ports in same port-group flap when speed change on another port |
|
Description: | %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet6/29 is down (Link failure)
%ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet6/30 is down (Link failure)
%ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet6/31 is down (Link failure)
Symptom:%ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet6/29 is down (Link failure)
%ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet6/30 is down (Link failure)
%ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet6/31 is down (Link failure)
Port on same SOC may flap during while removing 10G SFP and using 1G SFP instead.
Conditions:When an SFP is inserted into an interface after module is UP and no shut is executed on that interface, the port of the same speed and in the same port-group might flap.
Workaround:- Insert SFPs into all ports in the port-group before bringing up any port in the port group
OR
- Link debounce time of 50 ms or more on both ends of the link
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 6.2(8)E5, 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S9, 6.2(10.5), 6.2(8)E5 |
|
|
| |
| |
Bug Id: | CSCtj86613 |
Title: | n7k standby sup may continuously reset after bootup |
|
Description: | A Nexus 7000 system's standby supervisor may continuously reset after
the system is reloaded or powercycled. The following error messages may
be seen on the active supervisor:
%BOOTVAR-5-NEIGHBOR_UPDATE_AUTOCOPY: auto-copy supported by neighbor supervisor, starting...
%SNMPD-2-CRITICAL: SNMP log critical : do_pssurl_snapshot : SNMP Could not do a snapshot to volatile:/dev/shm/im_sdb_extension_267_0 from sync:/mnt/pss/snmp.d/engine_db
%SYSMGR-2-GSYNC_SNAPSHOT_SRVFAILED: Service "snmpd" on active supervisor failed to store its snapshot (error-id 0xFFFFFFFF).
%SYSMGR-STANDBY-5-SUBPROC_TERMINATED: "System Manager (gsync controller)" (PID 4238) has finished with error code SYSMGR_EXITCODE_GSYNCERR (7).
%SYSMGR-2-STANDBY_BOOT_FAILED: Standby supervisor failed to boot up.
%SNMPD-2-CRITICAL: SNMP log critical : do_pssurl_snapshot : SNMP Could not open the PSS file sync:/mnt/pss/snmp.d/engine_db
%SYSMGR-2-GSYNC_SNAPSHOT_SRVFAILED: Service "snmpd" on active supervisor failed to store its snapshot (error-id 0xFFFFFFFF).
%SYSMGR-2-STANDBY_BOOT_FAILED: Standby supervisor failed to boot up.
%SYSMGR-STANDBY-3-SERVICE_TERMINATED: Service "ntp" (PID 4165) has finished with error code SYSMGR_EXITCODE_SYSERR (1).
Workaround:
None.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo61576 |
Title: | FTAG tree seems to be incorrectly formed affecting broadcast/multicast |
|
Description: | Symptom:
Broadcast/multicast/flooded might be affected depending on which FTAG tree has RPF failures.
That is, if FTAG-1 seems to be incorrect, Broadcast/multicast/flooded will be affected and if FTAG-2 is incorrect, multicast is affected for certain flows. As we know multicast is load balanced between FTAG 1 and 2.
Conditions:
FP domain with multiple paths.
Workaround:
Shut the link that is failing RPF link.
Bundle multiple links to a port-channel if possible.
Reload does not seem to fix the problem once the issue is seen.
Further Problem Description:
This issue will be seen on Nexus 5K/6K goldcoast images. H+ onwards has the fix.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCty88512 |
Title: | Netstack Crash and Core File |
|
Description: | Symptom:
%SYSMGR-2-SERVICE_CRASHED: Service "netstack" (PID 4143) hasn't caught signal 11 (core will be saved).
Core file visible on system:
Issue "show cores vdc-all" from default vdc or show cores from VDC with the crash.
Conditions:
Nexus 7000 running NX-OS 5.2(1)
Workaround:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | 5.2(1)N1(1), 5.2(4.56)S0, 5.2(5)S1, 5.2(5.2)S0, 6.0(2)A1(1), 6.0(2)N1(1), 6.0(2)U1(1), 6.0(4)S13, 6.1(0.294)S0, 6.2(0.217) |
|
|
| |
| |
Bug Id: | CSCuv09863 |
Title: | IF-MIB::ifInDiscards erroneously increment for SNMP on M2 |
|
Description: | Symptom:
Interface discards (ifInDiscards) erroneously increment for some interfaces when polling via SNMP but those same discard counters don't increment for the CLI
Conditions:
Problem occurs on the Nexus M2 series linecard. On the N7K-M224XP-23L the problem occurs on port pairs ( 1,11) (13,23). At some point valid input discards incremented on these ports but because of this software problem the discards increment for SNMP
Workaround:
reload the affected linecard to clear out the problem
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.78) |
|
Known Fixed Releases: | 6.2(13.4)S0 |
|
|
| |
| |
Bug Id: | CSCut89882 |
Title: | NXOS-MPLS-TE:Traffic loss after SUP Failover |
|
Description: | Symptom:
TE tunnels flap 2 minutes after the 1st switchover.
Conditions:
The issue is present when RSVP graceful restart is configured and head-end TE tunnels are present. The issue occurs only after the 1st failover occurs after the mpls traffic-eng feature is enabled.
Workaround:
As only the first failover triggers the issue, performing a manual switchover after enabling the mpls traffic-eng feature will prevent this issue from being seen subsequently.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 7.2(0)ZD(0.145) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu11602 |
Title: | M2 linecard reset due to EOBC heartbeat failure |
|
Description: | Symptom:
A M2 linecard may be reset by the supervisor due to EOBC heartbeat being missed by the linecard
Conditions:
1. There should be NO cpu/eobc hog on LC.
2. Upon LC bring up, post_code should be in range 0x00 and 0xf0 only. (sh mod internal act mod shows PWR_MGMT_POST_CODE_REG(0xb) = 0xab)
Workaround:
Further Problem Description:
This was fixed in 6.2(10) via CSCup20959, but the problem is still seen
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu77244 |
Title: | port-profile core at ppm_profile_global_level_2_acfg_gen after- sh start |
|
Description: | Symptom:
PPM will crash when issued show run or show start. This happens when there are lots of aging of profile and at the same time traffic is being sent and there are errors in the profiles being applied.
Conditions:
Happens when there are errors in application of network profiles like failure of command and aging happening at the same time.
Workaround:
System is already buggy. Do a write erase and reload.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu90608 |
Title: | nvt: mcecm and vpc cores on doing a cold boot from S22 to S28 |
|
Description: | Symptom:
vPC process crashes
Conditions:
no graceful type-1 check configured and switch reloads
Workaround:
turn on graceful type-1 check by default
Further Problem Description:
This is memory overrun issue.
The issue is only hit when graceful type-1 check is disable. Because from 6.2.10, the check is enabled by default, we decided to fix after GBR.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.7), 7.2(1)ZD(0.6) |
|
|
| |
| |
Bug Id: | CSCtz53329 |
Title: | Standby sup stuck in powered-up: syslogd failed to store its snapshot |
|
Description: | Symptom:
This bug affects both Nexus 7000 and MDS platforms.
Standby supervisor reloads continuously. show logging nvram
contains the following messages:
%SYSMGR-2-GSYNC_SNAPSHOT_SRVFAILED: Service "syslogd" on active supervisor
failed to store its snapshot (error-id 0x80480018).
%SYSMGR-2-STANDBY_BOOT_FAILED: Standby supervisor failed to boot up.
Conditions:
This issue only occurs if the standby supervisor reloads many times.
Workaround:
None. Contact Cisco TAC to recover from this issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 5.2(2d), 5.2(4) |
|
Known Fixed Releases: | 5.2(4.80)S0, 7.0(1)ZD(0.3) |
|
|
| |
| |
Bug Id: | CSCuu77709 |
Title: | LISP: map-caches entries to non-routable RLOCs are installed in fwd |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus90226 |
Title: | 6.2.12: Route programming inconsistency between instances on a LC |
|
Description: | Symptom:
When the port-channel configured with LACP individual and shut and no shut of VPC or port-channel will trigger
Conditions:
LACP Individual configured on the port-channel
Workaround:
Remove the LACP Individual config for the Port-channel
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E2, 6.2(13.3)S0, 6.2(14)FB(0.4), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.430), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.358), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCuu30447 |
Title: | F2/F2E port will keep up even the rx power is -26dBm due to ISP break |
|
Description: | Symptom:
Topology:
N7K-c1(port e4/31)---15454-1===ISP===15454-2------(port4/3)N7K-c2
Software:
both N7K-c1 and N7K-c2 are running with 6.2.12.
module 4 is the N7K-F248XP-25E
Transceiver info:
both e4/31 and e4/3 are installed with GLC-SX-MMD.
Configuration for port e4/31 and e4/3:
interface Ethernet4/31
no shutdown
interface Ethernet4/3
no shutdown
Failure scenario:
if we break the ISP fiber, you might see one of the port e4/31 and e4/3 will be up while the other one is in link failure status.
N7K-3-c1# show int e4/31
Ethernet4/31 is down (Link not connected)
admin state is up, Dedicated Interface
Hardware: 1000/10000 Ethernet, address: 8478.ac56.4645 (bia 8478.ac5a.0fb2)
MTU bytes (CoS values): MTU 1500(0-2,4-7) bytes MTU 2112(3) bytes
BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, medium is broadcast
Port mode is routed
auto-duplex, auto-speed, media type is 1G
Beacon is turned off
Auto-Negotiation is turned on
Input flow-control is off, output flow-control is off
Auto-mdix is turned on
Rate mode is dedicated
Switchport monitor is off
EtherType is 0x8100
EEE (efficient-ethernet) : n/a
Last link flapped 00:26:03
Last clearing of "show interface" counters 02:27:02
8 interface resets
Load-Interval #1: 30 seconds
30 seconds input rate 0 bits/sec, 0 packets/sec
30 seconds output rate 0 bits/sec, 0 packets/sec
input rate 0 bps, 0 pps; output rate 0 bps, 0 pps
Load-Interval #2: 5 minute (300 seconds)
300 seconds input rate 0 bits/sec, 0 packets/sec
300 seconds output rate 0 bits/sec, 0 packets/sec
input rate 0 bps, 0 pps; output rate 0 bps, 0 pps
L3 in Switched:
ucast: 0 pkts, 0 bytes - mcast: 0 pkts, 0 bytes
L3 out Switched:
ucast: 0 pkts, 0 bytes - mcast: 0 pkts, 0 bytes
RX
76 unicast packets 90 multicast packets 0 broadcast packets
90 input packets 25587 bytes
0 jumbo packets 0 storm suppression packets
0 runts 0 giants 0 CRC/FCS 0 no buffer
0 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
TX
76 unicast packets 89 multicast packets 0 broadcast packets
89 output packets 19394 bytes
0 jumbo packets
0 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause
N7K-3-c1# show int e4/31 tran details
Ethernet4/31
transceiver is present
type is 1000base-SX
name is CISCO
part number is FTLF8519P3BNL-CS
revision is A
serial number is FNS17371AE5
nominal bitrate is 1300 MBit/sec
cisco id is --
cisco extended id number is 4
cisco part number is 10-2626-01
cisco product id is GLC-SX-MMD
cisco vendor id is V01
number of lanes 1
SFP Detail Diagnostics Information (internal calibration)
----------------------------------------------------------------------------
Current Alarms Warnings
Measurement High Low High Low
----------------------------------------------------------------------------
Temperature 38.44 C 90.00 C -10.00 C 85.00 C -5.00 C
Voltage 3.30 V 3.59 V 3.00 V 3.50 V 3.09 V
Current 7.13 mA 15.00 mA 1.00 mA 12.00 mA 2.00 mA
Tx Power -5.11 dBm 0.00 dBm -13.49 dBm -2.99 dBm -9.50
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.64), 7.2(1)D1(0.13), 7.2(1)ZD(0.9) |
|
|
| |
| |
Bug Id: | CSCuu53826 |
Title: | MPLS QoS : not enough memory after vdc suspend/resume |
|
Description: | Symptom:
*With more 50% of aggregate policer usage and subinterface configuration, an vdc reload or suspend/resume event will trigger this issue.
Conditions:
*vdc suspend
no vdc suspend
reload vdc
Workaround:
*reload the module.
Further Problem Description:
*
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.65) |
|
|
| |
| |
Bug Id: | CSCuf38843 |
Title: | IF_SEQ timeout with SPM for op MTS_OPC_ETHPM_PORT_PRE_CFG on mod reload |
|
Description: | Symptom:
%ETHPORT-5-IF_SEQ_ERROR: Error ("sequence timeout") communicating with MTS_SAP_SPM for opcode MTS_OPC_ETHPM_PORT_PRE_CFG (RID_PORT: Ethernetx/y)
%ETHPORT-5-IF_DOWN_ERROR_DISABLED: Interface Ethernetx/y is down (Error disabled. Reason:sequence timeout)
Conditions:
Multiple linecards coming online at once
Workaround:
none, this is a scalability issue that will be corrected in future releases.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua77416 |
Title: | Sup reload or Switchover may occur due to Leap second update |
|
Description: | Symptom:
There are periodic leap second events which can add or delete a second to global time.
When the leap second update occurs a N7K SUP1 could have the kernel hit what is known a "livelock" condition under the following circumstances:
a. When the NTP server pushes the update to the N7K NTPd client, which in turn schedules the update to
the Kernel. This push should have happened 24 hours before June 30th, by most NTP servers.
b. When the NTP server actually updates the clock
Conditions:
The leap second update will be propagated via Network Time Protocol (NTP) or via manually setting the clock.
Workaround:
Please note this is an issue for the SUP1 only and the SUP2 is not susceptible to leap second.
On switches configured for NTP and running affected code, following workaround can be used.
1) Remove NTP/PTP configuration on the switch at least two days prior to June 30, 2015 Leap second event date. Note the entire NTP configuration does not need to be removed and the user can do "no feature ntp" so the NTP feature will be disabled but the NTP configuration will remain in place.
2) Add NTP/PTP configuration back on the switch after the Leap second event date(July 1, 2015). Note if just the feature was disabled the user can now do "feature ntp".
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 5.1(1), 5.1(5)E2, 5.2(5), 6.0(4) |
|
Known Fixed Releases: | 5.2(6.16)S0, 5.2(7), 6.1(1)S28, 6.1(1.30)S0, 6.1(1.69), 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCua34604 |
Title: | OTV : OTV_ISIS cored on deleting redistributed route-map |
|
Description: | Symptom:
ISIS-OTV cores on deleting the route-map applied for filtering HSRP packets.
Conditions:
Making changes to route-map
Workaround:
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 5.2(5)S14, 6.1(1)S11 |
|
Known Fixed Releases: | 6.1(1)S18, 6.1(1.18)S0, 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCup19027 |
Title: | N7K Dual SUP lost configurations after power up |
|
Description: | Symptom:
The N7K SUP1 had the configuration saved and was powered down. When the N7K was then powered up it came up with no configuration. The startup-configuration had been corrupted due to an abnormal termination when it had been previously saved.
Conditions:
When the "copyrunning-config startup-config" was entered it was terminated abnormally either the user entering CNTRL-C or the connection to the N7K, for example via SSH, being terminated before the "copy" was complete.
Workaround:
The configuration must be restored manually.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 5.2(7) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S64, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.195), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)IF(99.16), 7.1(0)N1(0.245) |
|
|
| |
| |
Bug Id: | CSCug37851 |
Title: | N7K - entPhysicalTable and BRIDGE-MIB slow with FEX indexes |
|
Description: | Symptom:Nexus 7000 may experience SNMP timeouts when using SNMP Bulk Get requests. It is also possible that under aggressive SNMP polling that the N7K SNMP application could restart and write out a core file.
If the SNMP process crashes 3 times, a supervisor switchover can be expected
Conditions:
This is more likely when using SNMP polling to the BRIDGE-MIB and ENTITY-MIB especially when using FEX modules.
Workaround:Increase timeout of SNMP polling.
More Info:Fixes had been integrated in 5.2(9)E2, 6.1(4a), 6.2(2) and later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 5.2(9)S71, 6.1(1), 6.1(4)S13, 6.2(1.74)S3 |
|
Known Fixed Releases: | 5.2(9)E2, 5.2(9.157)S0, 6.1(4.97)S0, 6.1(4a), 6.1(4a)S4, 6.1(5.11)S0, 6.1(5.12)S0, 6.2(1.107)S0, 6.2(1.112)S0, 6.2(1.113)S0 |
|
|
| |
| |
Bug Id: | CSCur28450 |
Title: | [6210-S100] Rollback to a checkpoint fails verification at FEX SAT PO |
|
Description: | Symptom:
Rollback fails the verification phase, saying "flowcontrol send on" is present in the running-config on the port-channel.
switch# rollback running-config checkpoint checkpoint_name
Verification patch contains the following commands:
---------------------------------------------------
!!
interface port-channel###
no flowcontrol send on
exit
Conditions:
When trying to rollback to a checkpoint where a current HifPC (a port-channel with FEX host interfaces as its members) becomes a simple port-channel (no FEX host interfaces as its members), rollback will fail the verification phase.
Workaround:
Rollback running checkpoint checkpoint_name best-effort
So that it wont do verification and won't revert back to original running config.
And then do "no flowcontrol send on" on the affected interfaces
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 6.2(10)S100 |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.2(0)D1(0.439), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.360), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCus91417 |
Title: | Nexus 7000 fails to trasmitt RSTP BPDUs consistently |
|
Description: | Symptom:
STP Instability in layer 2 domain with N7K (Rapid PVST)
Conditions:
unknown
Workaround:
enable peer-switch if N7K is the root to mitigate this issue
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12)S33 |
|
Known Fixed Releases: | 6.2(12)E1, 6.2(13)FM(0.52), 6.2(13)GS(0.13), 6.2(13.1)S0, 6.2(13.3)S0, 6.2(14)FB(0.21), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)D1(0.453), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCus96272 |
Title: | pvlan Channel-group members add/remove fails . |
|
Description: | Symptom:
pvlan Channel-group members add/remove fails .
Conditions:
pvlan Channel-group members add/remove fails .
Workaround:
pvlan Channel-group members add/remove fails .
Further Problem Description:
pvlan Channel-group members add/remove fails .
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 7.2(0.8) |
|
Known Fixed Releases: | 6.2(13.6)S0, 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)D1(0.469), 7.2(0)D1(1), 7.2(0)PDB(0.390), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCul47752 |
Title: | Unicast packets getting dropped as the Mac is pointing to an Invalid DI |
|
Description: | Symptom:
Traffic can be leaked between VDCs or dropped in specific VDCs
Conditions:
This is observed on Nexus 7000 with F2 modules running 6.1(4) and 6.2(2)
Workaround:
Reload of F2 modules absolute necessary to fix the issue, before upgrade to fixed in Version
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 6.1(1), 6.2(5.52)S0 |
|
Known Fixed Releases: | 6.1(4.99)S0, 6.1(5), 6.2(6) |
|
|
| |
| |
Bug Id: | CSCuu79551 |
Title: | routes installed with recursive next hop have null next hop in hardware |
|
Description: | Symptom:
next hop in show forwarding route shows null for recursive routes
nexus# sh forwarding route X.X.X.X vrf VRF_N7K
slot 1
=======
IPv4 routes for table VRF_N7K/base
'*' denotes recursive route
------------------+------------------+----------------------+-----------------
Prefix | Next-hop | Interface | Labels
------------------+------------------+----------------------+-----------------
*X.X.X.X/29 0.0.0.0 Null0
Conditions:
recursive next hop
Workaround:
none known at this time
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue19535 |
Title: | Fabric Sync loss brings resets all the modules |
|
Description: | Symptom:
All linecards fail to sync to a single fabric module, causes the modules to be reset, instead of
the fabric module being powered down.
Conditions:
As above.
Workaround:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 4.2(8), 5.2(7), 6.1(2) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S41, 6.1(4), 6.1(4)S6, 6.1(4.8)S0, 6.2(1.93), 6.2(2), 7.1(0)D1(0.14) |
|
|
| |
| |
Bug Id: | CSCuu37319 |
Title: | F3:QoS Policer is inconsistent in policing traffic to the desired rate. |
|
Description: | Symptom:
Traffic policing applied on a vlan is not providing the desired policing rate.
The actual traffic rate through the vlan with policing in place could be higher or lower than the configured limit.
Conditions:
issue seen on F3/6.2.8a
Workaround:
Remove and reapply the service policy on the vlan may work.
if it does not then please reach out to TAC for further troubleshooting
Further Problem Description:
Any subsequent member addition/deletion operation from a VLAN or a port-channel is triggering this problem.
ISSU does not auto correct the problem. Reapply the policy configuration
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.62), 7.2(1)D1(0.15), 7.2(1)ZD(0.11) |
|
|
| |
| |
Bug Id: | CSCuh75899 |
Title: | N7K -core in xbar_driver_usd |
|
Description: | Symptom:
Process xbar_driver_usd on a module will leak memory, and eventually core.
The module will reboot.
Eventually, after three occurrences of running out of memory and then rebooting, the module will remain powered off.
A log message similar to the following will be generated:
1970 Jan 1 00:00:00.000 switch %MODULE-1-MOD_DIAG_FAIL: Module 1 (Serial number: JAF0000ABCD) reported failure due to Service on linecard had a hap-reset in device DEV_SYSMGR (device error 0xfe)
A core file for xbar_driver_usd will be generated and saved in logflash:core/
switch# show cores
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
1 1 1 xbar_driver_usd 2182 1970-01-01 00:00:00
On the module, show logging onboard will have the following error:
module-1# show logging onboard
Exception Log Record : Sun Jan 1 00:00:00 1970 (000000 us)
Device Id : 34304
Device Name : 0x8600
Device Error Code : fe000000(H)
Device Error Type : NULL
Device Error Name : NULL
Device Instance : 0
Sys Error : (null)
Errtype : CATASTROPHIC
PhyPortLayer : 0x0
Port(s) Affected :
Error Description : xbar_driver_usd hap reset
DSAP : 0
UUID : 16777216
Time : Sun Jan 1 00:00:00 1970
(000000 usecs 00000000(H) jiffies)
Conditions:
Polling ciscoSwitchFabricMIB with SNMP
Executing commands beginning with show hardware fabric-utilization internal snmp
Walking ciscoSwitchFabricMIB roughly 1000-2000 times will use all 100MB of available memory for the xbar_driver_usd process.
Workaround:
Restrict access to the following:
show hardware fabric-utilization internal snmp
ciscoSwitchFabricMIB (1.3.6.1.4.1.9.9.803)
More Info:
Memory usage can be monitored with the following command:
slot slot show processes memory | grep xbar_driver_usd
2182 3051520 MemoryLimit CurrentMemoryUsage 7fe3aa80/7fe3a460 xbar_driver_usd
Example configuration for blocking only ciscoSwitchFabricMIB:
role namename
rule 1 permit read
rule 2 deny read oid 1.3.6.1.4.1.9.9.803
snmp-server community communityString group name
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 6.1(4), 6.1(4.9)S0, 6.2(1.143)S3, 6.2(1.159)S1, 6.2(5.7), 7.0(0.50)S0 |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(4a), 6.1(4a)S1, 6.1(5.32)S0, 6.2(2), 6.2(2)S1, 6.2(3)S1, 6.2(3.5)S0, 6.2(5.2)S0, 7.0(0)ZD(0.84) |
|
|
| |
| |
Bug Id: | CSCur14589 |
Title: | vulnerability related to cmd injection via DHCP offer options |
|
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:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dis
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.226) |
|
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) |
|
|
| |
| |
Bug Id: | CSCtc83165 |
Title: | SNMP crash due to mutex lock assert fail in 4.2(2a) |
|
Description: |
Problem/Description:
Both Nexus 7000 and Nexus 5000 boxes will crash on snmpd pid.
Workaround:
Software upgrade
Further Actions:
gather show tech details and engage Cisco TAC.
Other:
`show cores`
Module-num Instance-num Process-name PID Core-create-time
---------- ------------ ------------ --- ----------------
1 1 snmpd 3870 Oct 2 10:30
Look for this in the output of
show logging nvram:
%SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 3870) hasn't caught signal 11
(core will be saved).
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 4.2(2a) |
|
Known Fixed Releases: | 4.2(1)N2(1), 4.2(3), 4.2(3.19), 4.2(4), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuv21910 |
Title: | after ISSU itd shows raise/ invaild/unknown values |
|
Description: | Symptom:
After ISSU from 6.2.10 to 6.2.14 ,
<< issue >>
switch# sh runn services
Conditions:
After ISSU from 6.2.10 to 6.2.14 ,
<< issue >>
switch# sh runn services
Workaround:
After ISSU from 6.2.10 to 6.2.14 ,
<< issue >>
switch# sh runn services
Further Problem Description:
After ISSU from 6.2.10 to 6.2.14 ,
<< issue >>
switch# sh runn services
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.79) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu55233 |
Title: | Mac addresses not learnt after Port-security violation stops |
|
Description: | Symptom:
On a Nexus 7700 mac addresses are not learnt on an interface after port-security violation happens and then stops.
Conditions:
This issue has currently been observed on Nexus 7700 with F3 module running on 6.2(12).
Issue only happens after max. mac address violation occurs and then stops.
shut/no-shut of interface does NOT recover mac-learning.
Workaround:
Default-interface and reconfiguring interface fixes the problem.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.70) |
|
|
| |
| |
Bug Id: | CSCuv16195 |
Title: | NX-OS 6.2(12) ISIS + IPv6 + BFD + F3 only form two neighbours |
|
Description: | Symptom:
Unable to form more than two neighbours when using ISIS routing protocol with IPv6 and BFD with upstream ASR9K. N77K_A can form neighbours with ASR9K_1 and ASR9K_2 but not with it's back-to-back N77K_B. When supervisor is re-booted, we get N77K_A connected to ASR9K_1 and N77K_B connected to ASR9K_2, only. In third case, we see N77K_B connected to both ASR9K_1 and ASR9K_2 but not to it's back to back N77K_A.
Conditions:
ISIS protocol using IPv6 with BFD on NX-OS code 6.2(12) running in multi-access or broadcast medium.
Workaround:
Toggling the port-channel connected to the broadcast medium.
Further Problem Description:
We have not tested ISIS with BFD with IPv4 or in point to point environment - because customer does not require this solution.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv05652 |
Title: | itd scale swover SAP 230 (iscm sap not respod)" and stby powerup forever |
|
Description: | Symptom:
after itd scale switchover SAP 230 (iscm sap not respod)? and takes 3 m
Conditions:
after itd scale switchover SAP 230 (iscm sap not respod)? and takes 3 m
Workaround:
after itd scale switchover SAP 230 (iscm sap not respod)? and takes 3 m
Further Problem Description:
after itd scale switchover SAP 230 (iscm sap not respod)? and takes 3 m
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.79), 7.2(0)D1(1.20) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus26870 |
Title: | December 2014 ntpd CVEs for Nexus 5k/6k/7k/MDS |
|
Description: | Symptom:
The following Cisco products:
NEXUS 7000
NEXUS 6000
NEXUS 5000
MDS
include a version of NTPd that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-9293
CVE-2014-9294
CVE-2014-9295
CVE-2014-9296
This bug has been opened to address the potential impact on this product.
Conditions:
This issue is configuration dependant and applies only when the following command is configured:
feature ntp
All prior versions of NX-OS are affected.
Workaround:
1. If the upstream mgmt0 device supports uRPF then ensure it is configured.
2a. Filter incoming NTP queries and restrict them to trusted NTP server addresses only by using the ntp access-group configuration command.
2b. For affected platforms that do not support the ntp access-group command, configure an inbound ACL for trusted NTP server addresses to the NTP port (UDP port 123) on mgmt0.
Further Problem Description:
All previously released versions of SAN-OS and NX-OS software are affected. The fix will be delivered for currently supported releases as follows:
Nexus 50xx:
NX-OS 5.2 release - a to be determined release
Nexus 55xx, 56xx
NX-OS 7.0 release - first fixed release is 7.0(6)N1(1), available in Apr 2015
Nexus 60xx:
NX-OS 7.0 release - first fixed release is 7.0(6)N1(1), available in Apr 2015
Nexus 7xxx:
NX-OS 6.2 release - first fixed release is 6.2(12), released on 03 Feb 2015
MDS:
NX-OS 5.2 release - first fixed release is 5.2(8f), released on 20 Feb 2015
NX-OS 6.2 releases:
- 6.2(9b), released on 01 Apr 2015
- 6.2(11b), released on 02 Mar 2015
- 6.2(13), to be released in June 2015
There are no fixed MDS NX-OS releases that are FICON certified yet. There will not be any fixed releases for software trains that are past the end of software maintenance support.
A Cisco Security Advisory has been published to document this vulnerability at:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141222-ntpd
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.5/7.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:P/A:P/E:H/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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUL-2015 |
|
Known Affected Releases: | 6.0(3), 6.2(13)FM(0.8), 6.2(9)S32, 6.2(9a)S5, 7.2(0)ZD(0.1), 7.2(0)ZN(0.4), 7.9(0)ZD(0.4), 8.0(0.1), 9.9(9) |
|
Known Fixed Releases: | 5.2(1)N1(8.155), 5.2(1)N1(8.158), 5.2(1)N1(9), 5.2(8f), 5.2(8f)S9, 6.0(2)N2(6.132), 6.0(2)N2(6.133), 6.0(2)N2(7), 6.2(11b), 6.2(11b)S4 |
|
|
| |
| |
Bug Id: | CSCtw77593 |
Title: | ERROR: Entry not found in copp database while apllying custom copp polic |
|
Description: | Symptom:
Modifying the CoPP profile or CoPP policy throws error "ERROR: Entry not found in copp database"
Conditions:
The issue happens when a reload based upgrade is performed.
Workaround(s):
Please follow the below steps:
1) Reload the switch with NX-OS version where the CoPP profile was last changed/applied
2) Removing the current CoPP profile
3) Upgrade the switch to the newer version and apply the new CoPP profile or CoPP policy
Description:
CoPP uses shadow database to delete the current CoPP profile if the current software version and CoPP profile version are different. Shadow database is created only when the install all based upgrade is performed. It is not created for reload based upgrade.
The issue is fixed by creating shadow database when the running-config is stored as startup-config. So that the shadow database can also be used to delete the CoPP profile when the reload based upgrade is performed. In case if the shadow database is not present, CoPP will delete the current CoPP profile by using the running CoPP database.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUL-2015 |
|
Known Affected Releases: | 5.2(3), 5.2(3)S24 |
|
Known Fixed Releases: | 5.2(3.44)S0, 6.1(1) |
|
|
| |
| |
Bug Id: | CSCuv21939 |
Title: | Linecard Kernel Panic due to Kernel Stack Overflow |
|
Description: | Symptom:
Linecards on a 7k reloaded unexpectedly from kernel panics.
Conditions:
Currently believe it was due to some large traffic event impacting these cards from the remote device, details are unknown.
Workaround:
Unknown
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.1(4a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut10829 |
Title: | sac_usd crash on standby supervisor |
|
Description: | Symptom:
hw sw
n7000-s2-dk9.6.2.8a
N7K-C7009
Conditions:
None
Workaround:
None
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun86405 |
Title: | Orphan Ports on FEX have the MAC learnt on ES ID instead of local SWID |
|
Description: | Symptom:
Orphan ports connected over FEX HIF may observe traffic getting black holed due to incorrect learning of MAC address in a VPC+ domain.
The MAC is learned from Emulated SWID (ESID) instead of Local SWID as observed on other switches in FabricPath Domain.
On the problem switch:
Software MAC learning would pick on the right physical port, though hardware MAC tables would shows MAC learned from ESID instead of Local SWID.
Conditions:
Problem may trigger if ports which were part of VPC+ complex (VPC port-channel) and were then moved to FEX-Fabric mode using channel-group force option.
This does not clear the register setting properly and MAC learning still picks on ESID as is treated to be coming across a VPC+ Port-channel.
This is the only known and analyzed trigger though may not be the only one.
Workaround:
- Shutdown the affected Ports.
- Move them out of FEX Fabric PO.
- Make them regular Access or Trunk ports (not VPC)
- Unshut them. >>>>>>>>> If FET's (Fabric Extender Transceiver) are used then once these ports are taken out from FEX Fabric mode FET SFP's would fail validation hence software state machine would not be complete to unset the corresponding registers. "service unsupported-transceiver" will help bypass validation checks.
- Move ports back to FEX-Fabric mode. This should clear the problem.
Further Problem Description:
N7k-switch# sh mac address-table address 0000.0000.0001
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False
VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+------------------
* 106 0000.0000.0001 dynamic 0 F F Eth150/1/2 >>>>> Here it looks correct
Module-X# show hardware mac address-table address 0000.0000.0001
FE | Valid| PI| BD | MAC | Index| Stat| SW | Modi| Age| Tmr| GM| Sec| TR| NT| RM| RMA| Cap| Fld|Always| PV | RD| NN| UC|PI_E8| VIF | SWID| SSWID| LID
1 1 1 32 0000.0000.0001 0x012d1 0 0x089 1 35 1 0 0 0 0 0 0 0 0 0 0x00 0 0 1 0 0x004 0x2de 0x001 0x012d1
SWID is picked as ESID and not as local SWID. Hardware MAC table will reflect the problem.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.17), 6.2(8)TS(0.28), 6.2(9.1)S0, 7.1(0)D1(0.162), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)OTT(0.4), 7.1(0)PDB(0.92), 7.1(1)SP(0.4) |
|
|
| |
| |
Bug Id: | CSCut77411 |
Title: | Assess April 2015 NTPd vulnerabilities for N5k/N6k/N7k |
|
Description: | Symptom:
This has been opened to document the potential impact on the following products:
Cisco Nexus 5/6k switch family
Cisco Nexus 7k switch family
of the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-1798
CVE-2015-1799
Conditions:
Exposure is configuration dependent. The configuration that can expose the vulnerability are
ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234
ntp peer 1.2.3.4 key 1
Workaround:
Remove the applicable configuration.
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: 4.3/3.2
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:P/A:N/E:U/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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.3), 7.3(0.9) |
|
Known Fixed Releases: | 5.2(1)N1(8.167), 5.2(1)N1(9), 6.0(2)N2(6.141), 6.0(2)N2(7), 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.0(7)ZN(0.108), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(2)N1(0.545) |
|
|
| |
| |
Bug Id: | CSCuu20761 |
Title: | Delete MAC sync issue after LC module reload that does not have PL |
|
Description: | Symptom:
VxLAN Mac inconsistency across VPC peers OR
Stale vxlan mac on one side of VPC complex
Conditions:
LC reload which contains VxLAN coreports but does not contain the peerlink.
Workaround:
clear mac address dynamic.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu76634 |
Title: | CFS process crash with Eth and IPv4 distribution configured in VPC setup |
|
Description: | Symptom:
CFS process my crash if running:
- cfs ipv4 distribute
- cfs eth distribute
This configuration is not supported on Nexus 7000 with VPC configuration
Conditions:
If both IPv4 and Eth distribution are configured for CFS
Workaround:
Remove unsupported configuration, IPv4 is not required.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.2(6b), 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtz04952 |
Title: | STP-2-SET_PORT_STATE_FAIL: Port state change req to PIXM failed |
|
Description: | Symptom:
Port-channel or interface fails to come up with the following logs
%STP-2-SET_PORT_STATE_FAIL: Port state change req to PIXM failed, status = 0x12 [fu hashtable key not present] vdc 3, tree id 0, num ports 1, ports state BLK, opcode MTS_OPC_PIXM_SET_MULT_CBL_VLAN_BM_FOR_MULT_PORTS, msg id (66549), rr_token 0x103F5
Conditions:
Reload VDC or Chassis
Workaround(s):
No workaround. Try reloading chassis again for a possible recovery
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.1(0.249), 6.1(0.298), 6.1(1) |
|
Known Fixed Releases: | 5.2(7), 5.2(7)S13, 5.2(7.18)S0, 6.1(1)S31, 6.1(1)S32, 6.1(1.33)S0, 6.1(1.34)S0, 6.1(2.27), 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCuu93248 |
Title: | IPFIB core due to SW index leak in MFIB for F3 modules |
|
Description: | Symptom:
On a nexus 7000/7700 series switch, ipfib service may reset on a linecard as indicated by the following log in the main vdc :
%SYSMGR-SLOT4-2-SERVICE_CRASHED: Service "ipfib" (PID 1200) hasn't caught signal 6 (core will be saved).
Conditions:
This can possibly be seen when there has been a significant number of adjacencies updates on the system.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.79), 7.2(1)D1(0.13), 7.2(1)ZD(0.9) |
|
|
| |
| |
Bug Id: | CSCug47000 |
Title: | HSRP Standby unknown for one group |
|
Description: | Symptom:HSRP hellos may not be received for some HSRP groups.
Conditions:This issue was experience across a VPC peer link.
Workaround:Flapping the effected peer link interface will recover HSRP temporarily but the issue may resurface.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.1(2), 6.1(3) |
|
Known Fixed Releases: | 6.2(1.135)S0, 6.2(2), 7.1(0)D1(0.14) |
|
|
| |
| |
Bug Id: | CSCus63847 |
Title: | 7.2.0::XBOW DCE F3::Seeing l2fm hap reset with switch reload trigger |
|
Description: | Symptom:
L2FM crashes with a similar looking backtrace:
Thread 1 (process 6961):
#0 0x081f09e8 in l2fm_conv_and_send_flush_vlan_mp_to_lcs_es (p_req=0x8f1a76c)
at ../feature/forwarding-sw/l2fm/server/l2fm_msg_handlers.c:20482
#1 0x08168efb in l2fm_send_flush_l2ft_vlan_mp (mts_event=0x0,
p_req=0x8f1a70c, p_filtered_req=0x8f1a76c, p_rsp=0x8f1a744,
reason=L2FM_FLUSH_PVLAN_ASSOC_CREATE,
cb_func=0x816620a , num_req=0)
at ../feature/forwarding-sw/l2fm/server/l2fm_msg_handlers.c:5808
#2 0x0816801a in l2fm_flush_l2ft_vlan_mp (mts_event=0x0, p_req=0x8f1a70c,
pp_rsp=0xffb68a00, reason=L2FM_FLUSH_PVLAN_ASSOC_CREATE)
at ../feature/forwarding-sw/l2fm/server/l2fm_msg_handlers.c:5701
Conditions:
Triggers: Per-Vlan based flush coming from CLR MAC, STP, PVLAN, VLAN DEL, etc are some triggers which will cause this [any trigger using vlan multi port flush]
Conditions: VPC+ configured AND MCT_down AND some condition like LC's are not up or coming up or MTS message send failed, etc.
All this happens during Switch reload or LC reload.
Workaround:
Move to fix version. Crash cannot be avoided.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.390) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.67), 7.2(0)D1(1), 7.2(0)ZD(0.87) |
|
|
| |
| |
Bug Id: | CSCur68350 |
Title: | F3: MAC Address is not Learned in Software after ISSU |
|
Description: | Symptom:
A MAC address is present in hardware but not software. Since the MAC is not in software other processes and features are not notified of new MAC address. This can result in black-holed traffic.
Conditions:
- ISSU to 6.2(10)
- F3 module
- OTV or vPC
Workaround:
Upgrade via a traditional reload.
If issue is hit via ISSU, flap the interface. If they are part of a port channel that spans multiple forwarding engines (FE), flap the member interfaces one at a time force mac learning on a different FE.
If the internal interface is not a port channel or the members are on the same FE then flapping the interface in OTV will trigger OTV AED failover or in vPC shut down the vPC leg.
If you believe problem exist even after flapping the interface please contact TAC for further workaround.
Further Problem Description:
This impacts OTV as locally learned MAC address will not be advertised to the remote otv site and vPC as new MAC learns will not be advertised to the vPC peer
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.24), 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.303), 7.2(0)D1(0.387), 7.2(0)D1(1), 7.2(0)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCun49409 |
Title: | ISSU (6.1.5 (S4) to 6.2.6 CCO) failed with naxos_usd core. |
|
Description: | Symptom:
June 10, 15: Issue Didn't reproduced when I did ISSU. See the attached logs.
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.1(5)S4 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu83574 |
Title: | Error in syslog of interface flap event after reload in remote server |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.5), 7.2(1)N1(0.239), 7.2(1)N1(1), 7.2(1)ZD(0.5), 7.2(1)ZN(0.5) |
|
|
| |
| |
Bug Id: | CSCud75360 |
Title: | F2 module fails to install routes after CLP_FIB_TCAM_PF_INSERT_FAIL seen |
|
Description: | Symptom:
A Nexus 7000 with F2 modules may experience an issue with the following message:
2012 Nov 30 16:38:31 switch %IPFIB-SLOT3-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 4
2012 Nov 30 16:38:31 switch %IPFIB-SLOT2-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 5
2012 Nov 30 16:38:31 switch %IPFIB-SLOT3-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 5
2012 Nov 30 16:38:31 switch %IPFIB-SLOT2-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 7
2012 Nov 30 16:38:31 switch %IPFIB-SLOT3-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 7
2012 Nov 30 16:38:31 switch %IPFIB-SLOT2-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 8
2012 Nov 30 16:38:31 switch %IPFIB-SLOT2-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 10
2012 Nov 30 16:38:31 switch %IPFIB-SLOT3-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 8
2012 Nov 30 16:38:31 switch %IPFIB-SLOT2-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 11
2012 Nov 30 16:38:31 switch %IPFIB-SLOT3-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 10
After this log appears, it is possible that the fib tcam may freeze, and no new prefixes can be inserted.
Conditions:
This issue occurs when the fib capacity is near the upper advertised limit of the F2 module, even if only for a brief period of time
Workaround:
To prevent the issue it is required to reduce the fib size. The only way to recover is to reload the module affected.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: | 6.1(2)E4, 6.1(4), 6.1(4)S4, 6.1(4)S5, 6.1(4.25)S0, 6.1(4.39)S0, 6.2(1.93), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCuu21836 |
Title: | Port was Error disabled, Reason:Port not found when NAM module installed |
|
Description: | Symptom:
If there is a NAM module installed and when a dce (core/edge) interface belonged to an another module flaps, then Port Client process in NAM sends "Port Not found".
This makes the EthPM to put the port to ErrDisable state
Example syslog:
============
ETHPORT-5-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/41 is down (Error disabled. Reason:Port not found)
Conditions:
NAM module is present on the box
dce (core/edge) interface belonged to an another module flaps
Workaround:
If Customer could afford to reload the NAM module, secure a maintenance window and reload the NAM module.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.2(9c), 7.2(0)D1(0.392) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.51), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.504), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.184), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCug39011 |
Title: | N7K: F2 may reset in case of receiving excessive error frames |
|
Description: | Symptom:
A faulty F2 module may cause resetting other multiple F2 modules
within the chassis.
Conditions:
very rare condition. the faulty F2 module may send out excessive error
frames to other F2 modules.
Workaround:
Module reload to recover. Isolate the faulty module and remove from the chassis.=
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | 6.2(10)E7, 6.2(10)E8, 6.2(13.3)S0, 6.2(14)FB(0.34), 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.482), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCut23557 |
Title: | N7K platform: netstack crash while saving tech-support in bootflash |
|
Description: | Symptom:
The netstack process on a Nexus 7000 switch running 6.2(8a) may unexpectedly crash while collecting a 'show tech' and redirecting it to bootflash
Conditions:
saving tech-support in bootflash
Workaround:
please do not save "show-tech" to bootflash.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a)S2 |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.28), 7.0(0)HSK(0.433), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.479), 7.2(0)D1(1), 7.2(0)ZD(0.159), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCut96140 |
Title: | 6.2.12: L2 port channels not programmed correctly in LACP INDI |
|
Description: | Symptom:
Port configured as LACP individual mode.
ELTM does not have the PC member in the database after port becoming part of port-channel.
"show system internal eltm info interface port-channel xyx" does not contain all the PC members.
Conditions:
L2 port-channel with LACP Individual mode
Workaround:
Flap port-channel members which is not added to the PC member
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E5, 6.2(13.3)S0, 6.2(14)FB(0.36), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.485), 7.2(0)D1(1), 7.2(0)ZD(0.167), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCut78387 |
Title: | l2fm crash @l2fm_rvtep_free_entry after shut/no shut nve interface. |
|
Description: | Symptom:
l2fm crash
Conditions:
shut/no shut nve interface
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471) |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.482), 7.2(0)D1(1), 7.2(0)ZD(0.162), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCut94069 |
Title: | libbmp memory leak because libnve_pd calls libbmp incorretly |
|
Description: | Symptom:
libbmp memory leak
Conditions:
nve peers flapping
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.475), 7.2(0)D1(0.485), 7.2(0)D1(1), 7.2(0)N1(0.179), 7.2(0)N1(1), 7.2(0)ZD(0.166) |
|
|
| |
| |
Bug Id: | CSCup10643 |
Title: | Enabling netflow causes Line card to crash |
|
Description: | Symptom:
Nexus Line card crashes with netflow is enabled
Conditions:
hardware rate-limiter layer-2 netflow 500 module 3
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.2(6a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.31), 6.2(11)FM(0.7), 6.2(8)TS(0.28), 6.2(9.4)S0 |
|
|
| |
| |
Bug Id: | CSCtt38844 |
Title: | DHCP relay does not flood packet to BD with broadcast bit set |
|
Description: | Symptom:
Nexus 7000 DCHP relay is not flooding DHCP Offer received from the server where client set broadcast bit. The destination mac address is ffff.ffff.ffff, but the cpu is sending the packet out the interface that the corresponding DHCP Discover packet was received from the client and not flooding it to the vlan.
Conditions:
When broadcast bit is set to client. the result should be flood to vlan. In this case, the DHCP offer is not flooded, and if the client is now known via a different interface, or circumstances prevent that broadcast packet making it to the client via the original path, DHCP will time out.
Workaround:
To ensure that the DHCP Offer arrives back on the client, ensure that to path to the client has not moved due to some layer 2 topology change.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 5.1(1) |
|
Known Fixed Releases: | 5.2(2.74)S0, 6.0(2)S7, 6.1(0.131)S0 |
|
|
| |
| |
Bug Id: | CSCuu02941 |
Title: | linecard crashing due to clp_fwd hap reset |
|
Description: | Symptom:
N7K-SM-NAM-K9 and LCs with less than 12 instances of Clipper will have their clp_fwd process crash when the system has Fex with L2 mcast is active. I.e. when the Fex ports are flapped or when the LC itself is reloaded, then clp_fwd will crash.
Conditions:
The issue happens when we boot the module on 6.2(10)
Workaround:
None
Further Problem Description:
l2mcast assumes that in every line card 12 Forwarding instances are available. With this assumptions, when it sends a message to clp_fwd driver, the clp_fwd driver does not handle this error correctly. Hence, crash.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.43), 6.2(14)FB(0.47), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.494), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.176) |
|
|
| |
| |
Bug Id: | CSCut06258 |
Title: | F1 card MTM misprogramming on "VLAN UP/Down" event |
|
Description: | Symptom:
MAC are not learned in HW on F1 card. From SUP , show mac address-table shows correct info, but show hardware mac address-table X for module X - is incorrect.
Affects on per VLAN/per port-pair basis (e.g. port-pairs are : 1,2 ; 3,4; ... 31,32. and some of them may stop learning MACs on some of the VLANs)
This lead to Unknown Unicast Flood scenario
Conditions:
shut/no shut of VLAN on a busy system (especially on many VLANs simultaneously). Removing and adding many VLANs at once.
Workaround:
Reload affected module
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E2, 6.2(13.3)S0, 6.2(14)FB(0.21), 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.493), 7.2(0)D1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCud63152 |
Title: | F2/F2E/F3 improper programming gateway mac on some instances |
|
Description: | Symptom:
Traffic destined to CPU is flooded instead of being punted.
This causes symptoms such as ARP being incomplete, L3 routed traffic not getting routed correctly
Conditions:
We have determined this is a result of the Interface VLAN MAC address not programmed in the hardware
Workaround:
shut/no shut of the interface vlan
This will force the switch to reprogram the router mac address
Further Problem Description:
Additional information regarding this fix:
After ISSU to a fixed release (ie., 6.1(5) and above), reload of F2/F2E/F3 modules are required to get the fix applicable. If the F2/F2E/F3 modules are not reloaded, this problem may continue to happen.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.0(3) |
|
Known Fixed Releases: | 6.1(5), 6.1(5)S11, 6.1(5.10)S0, 6.2(0)HS(0.10), 6.2(8), 6.2(8)S1, 6.2(8.5) |
|
|
| |
| |
Bug Id: | CSCub16539 |
Title: | SNMP MTS Buffer Leak on VLAN MIBs - dot1d bridge, vlan membership, smon |
|
Description: | Symptom:
A Nexus 7k or 5k switch may experience crashes in the SNMPd process. Errors leading up to the crash hint at an MTS issue with the SAP used by SNMP. Eg:
KERN-2-SYSTEM_MSG mts_is_q_space_available_old(): NO SPACE - node=4, sap=27, uuid=26, pid=28679, sap_opt = 0x1, hdr_opt = 0x0, rq=1122(322640), lq=0(0), pq=0(0), nq=0(0), sq=0(0), fast: rq=0, lq=0, pq=0, nq=0, sq=0 - kernel
KERN-2-SYSTEM_MSG mts_print_longest_queue_state: opcode counts for first and last 50 messages in recv_q of sap 27: - kernel
KERN-2-SYSTEM_MSG mts_print_msg_opcode_in_queue: opcode 7679 - 100 messages - kernel
KERN-2-SYSTEM_MSG mts_do_msg_input() failing since no space available in 27 (src_sap = 27, opc = 8923) - kernel
Conditions:
The leak occurs when polling a VLAN MIB and performing a walk down the MIB's subtree -- specifically the dot1d bridge MIB, vlan membership MIB, and smon MIB.
Workaround(s):
None known.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 5.2(5), 6.1(1) |
|
Known Fixed Releases: | 5.2(1)N1(5), 5.2(6.23)S0, 5.2(7), 6.0(2)A1(1), 6.0(2)N1(1), 6.0(2)U1(1), 6.1(1)S50, 6.1(1.48)S0, 6.1(1.69) |
|
|
| |
| |
Bug Id: | CSCut87473 |
Title: | bfd crash @bfd_sys_get_remote_ip_info on BDI/peer link i/f shut/unshut |
|
Description: | Symptom:
bfd crash
Conditions:
On BDI/VPC peer link interface shut/no shut few times with scaled configuration
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471), 7.2(0)D1(0.490) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.504), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.184), 7.2(1)PIB(0.14), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCtz65462 |
Title: | broadcast get dropped on F2, learning source broadcast frame |
|
Description: | Symptoms:
ARP requests and other Layer 2 traffic with a broadcast destination address is NOT flooded to all ports on the same VLAN.
In addition to that, the following message may be seen on the device logs:
%MTM-SLOT3-2-MULTICAST_SOURCE_MAC_LEARNT: Inserted dynamically learnt multicast source mac ff:ff:ff:ff:ff:ff!
Conditions:
Upon receiving a Layer 2 frame with a broadcast source address (FFFF.FFFF.FFFF), the F2 line card will learn and add this address to its hardware
table. Having this entry on the hardware table, Layer 2 traffic with a broadcast destination address (such as ARP requests) will be dropped on the
Nexus 7000 device because the ingress controller fails to flood it to the broadcast domain.
Workaround:
Clear the entry from the dynamic MAC address table by executing the following command from a privileged EXEC prompt:
clear mac address dynamic vlan x address ffff.ffff.ffff
Replace ''x'' with the appropriate VLAN number.
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.1/5.8:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:U/RC:C
CVE ID CVE-2012-3048 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | 6.1(0.307)S0, 6.1(1)S23, 6.1(1.22)S0, 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCuq93334 |
Title: | [Performance impact] M2 reload stuck in power cycle for 17-18 minutes |
|
Description: | Symptom:
Module power cycle takes 17-18 mins to complete.
Conditions:
we observed this issue with the reload module scenario with more than about 100+ BFD session in the system.
as module goes off, PPF session can't reach the destination which cause ppf server do a retry internally and it takes approximately 10 sec for each session. we got over 100 session (1000 sec =16 mins) that's the reason why power-cycle took 17~18 mins
Workaround:
before reloading the module, I recommend doing a no feature bfd, and then do a module reload, finally add bfd feature back to the system.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.2(10)E1, 7.2(0)ZD(0.106) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.476), 7.2(0)D1(1), 7.2(0)PDB(0.408), 7.2(0)VZD(0.26), 7.2(0)ZD(0.156) |
|
|
| |
| |
Bug Id: | CSCut43413 |
Title: | DCi: HSRP Virtual MAC Flapping through FHRP Isolation PACL |
|
Description: | Symptom:
FHRP hello causing vMAC to flap between local interface and Layer 2 vPC DCi.
Conditions:
- FHRP isolation PACL on Layer 2 vPC DCi interface
- Device acting as L2 vPC DCi is not FHRP gateway
Workaround:
Two options dependent on the design of the network:
- If the DCi device is only connected to the FHRP gateway, a VACL with an ARP inspection filter is recommended to isolate the data centers.
- If the DCi device has connections to other devices in the local data center using the PACL with a static MAC entry is the only option. This will not stop the duplicate gateway gratuitous ARPs between the two sites.
Further Problem Description:
This is a hardware limitation. The MAC learning process takes place before the PACL drops the HSRP hello.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut63393 |
Title: | Border Leaf needs to advertise hash-len for BSR |
|
Description: | Symptom:
Border Leaf doesn't advertise the correct hash-len as advertised by PIM running @ the Border-Leafs for BSR in Vinci Asti Multicast.
Conditions:
BSRs listen and accumulate candidate RP announcements. For every group range known, the BSR builds a set of candidate RPs, including all routers that advertised their willingness to service this range. This is called group range to RP set mapping. The resulting array of group range to RP set mappings is distributed by the BSR. Ultimately, the bootstrap messages containing Group to RP-set mappings are received by every multicast router in the domain and used to populate their RP caches. It's up to the routers to select the best matching RP from the sets advertised by the BSR router. It is important that all routers select the same RP for the same group, otherwise the multicast sources might miss receivers. Based on a consistent hash-len information sent from the BL's the routers will ensure they pick the same RP for the same group.
In the present Janjuc image, although PIM advertises a hash-len to be chosen for BSR, this communication doesn't get sent to NGMVPN @ Border-leaf node which results in PIM @ all leaf nodes using a default hash-len of 0 to calculate the RP for the group. This causes mismatch in hash-len information between PIM @ Border-Leaf vs PIM @ Leaf node.
Workaround:
Work-around is not to configure the candidate-RP's in the RP-set for BSR case with the same priority.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 7.2(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua39287 |
Title: | System reloads due to TACACS+ process crash |
|
Description: | Symptom:
NX-OS system running 5.2.5 may reload due to TACACS+ process crash.
Conditions:
This issue may occur when TACACS+ is configured for remote accounting. It is caused by a high rate of invalid accounting packets (2 to 3 every second) which create "invalid_ip@" records in the accounting log. This may be confirmed with the following command:
show accounting log | i invalid_ip@
Workaround:
Disable the remote accounting for tacacs.
This can done by removing the aaa accounting config statement for tacacs.
ex:
switch(config)# no aaa accounting default xxxx
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 5.2(5)S8 |
|
Known Fixed Releases: | 5.2(1)N1(5), 5.2(6)S14, 5.2(6.16)S0, 5.2(7), 6.1(1)S39, 6.1(1.41)S0, 6.1(1.69), 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCut83358 |
Title: | nve memory leak@ libnve_pd in n7k-platform |
|
Description: | Symptom:
nve memory leak
Conditions:
nve peer down and up
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.475), 7.2(0)D1(0.476), 7.2(0)D1(1), 7.2(0)N1(0.168), 7.2(0)N1(1), 7.2(0)PDB(0.408) |
|
|
| |
| |
Bug Id: | CSCtj07918 |
Title: | Eigrp flap on switchover |
|
Description: | Symptom:
EIGRP sessions flap on switchover.
Conditions:
This will happen if large number of eigrp passive interfaces are used (over 500) on a redundant system with heavy load and multiple features running. After switchover, the processing on the standby supervisor takes longer than the hold timer. Subsequently, the remote end times out the peer hold timers resulting in the sessions going down.
Workaround(s):
By increasing the hold timer to 20 to 25 seconds the switchover node will have enough time to send the hellos out before the sessions time out on the remote end. For even larger number of passive interfaces, larger hold timer must be used.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 5.1(1), 5.2(5)S18, 6.1(1)S11 |
|
Known Fixed Releases: | 5.1(1.26)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuv30404 |
Title: | vrf name change and switchover - routing table mapped to previous vrf |
|
Description: | Symptom:
Our customer changed vrf names as below and those changes are saved.
And they did switchover and found that vrf for routing table was not updated and mapped to previous one.
BACKUP_BB ---> Backup_NW
RND_BB ---> Ext_RND
PRIBIT_NETWORK ---> Private_NW
Conditions:
version : n7700-s2-dk9.6.2.12.bin
module:
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 48 1/10 Gbps Ethernet Module N77-F348XP-23 ok
3 48 1/10 Gbps Ethernet Module N77-F348XP-23 ok
5 0 Supervisor Module-2 N77-SUP2E active *
6 0 Supervisor Module-2 N77-SUP2E ha-standby
7 48 1/10 Gbps Ethernet Module N77-F348XP-23 ok
Our customer changed vrf names as below and those changes are saved.
And they did switchover
Workaround:
None
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.2(9c)S5 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCum52399 |
Title: | Fixing EIGRP to take Interface MTU as default Max-Packet Size |
|
Description: | Symptom:
Symptom:
In 6.2.2, the default EIGRP mtu is 16384 regardless of the interface MTU. If system receives large update packets then they will get fragmented. The CoPP on the nexus can drop these fragments as they get classified under default-class of CoPP. These fragments are not considered as EIGRP packets being fragmented packets.
Conditions:
EIGRP MTU is 16384.
Workaround:
Modify COPP.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.0(2)A4(0.814), 6.0(2)A4(1), 6.0(2)U4(0.814), 6.0(2)U4(1), 6.2(10), 6.2(10)EC(0.12), 6.2(10)FM(0.10), 6.2(10)NO(0.6), 6.2(8)KR(0.8), 6.2(8)TS(0.28) |
|
|
| |
| |
Bug Id: | CSCur70861 |
Title: | F3 - Ports should not be err-disabled for TCAM single bit ECC errors |
|
Description: | Symptom:
If F3 module experiences repeated single bit ECC errors it will error-disable the associated ports with that forwarding instance.
exception information --- exception instance 1 ----
Module Slot Number: 5
Device Id : 197
Device Name : Flanker L3 Driver
Device Errorcode : 0xcc503600
Device ID : 197 (0xc5)
Device Instance : 03 (0x03)
Dev Type (HW/SW) : 06 (0x06)
ErrNum (devInfo) : 00 (0x00)
System Errorcode : 0x429b0026 failure recovery threshold
Error Type : Minor error
PhyPortLayer : Ethernet
Port(s) Affected : Ethernet5/25-32
Error Description : FLN_FW_INT_STATUS_TCAM_MATCH0_ECC_0
DSAP : 0 (0x0)
UUID : 0 (0x0)
Time : Tue Nov 11 16:37:55 2014
(Ticks: 546281B3 jiffies)
Conditions:
When repeated single-bit ECC errors are detected.
Workaround:
No known workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.16), 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.301), 7.2(0)D1(0.387), 7.2(0)D1(1), 7.2(0)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCup42943 |
Title: | DMAC 0000.0000.0000 loops endlessly between fabricpath peers |
|
Description: | Symptom:
In a mixed VDC M2/F2E running fabricpath, a frame with DMAC 0000.0000.0000 is looping endlessly between the fabricpath peers.
A mac flap can be seen between the GPC and peer SW.ID
This could increase the bandwidth utilizaiton on the link.
Conditions:
Issue seems to be seen in a M2/F2E chassis running fabricpath. This bug applies to 6.2(6) and 6.2(8) only.
Workaround:
downgrade to 6.2(2a) OR
upgrade to 6.2.8a or 6.2.6b or 6.2.8e6 or 6.2.10
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.2(6), 6.2(8)S2 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S8, 6.2(10.5), 7.1(0)D1(0.186), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)NF(0.32), 7.1(0)OTT(0.14), 7.1(0)RTG(0.12), 7.1(0)SIB(99.6) |
|
|
| |
| |
Bug Id: | CSCuu96175 |
Title: | L2FM/MCEM/CFS need more robust registration & retry infra |
|
Description: | Symptom:
This is to address possible timeouts between L2FM and CFS under failure condition (CFS crash, control plane congestion) that could cause registration issues between applications.
Conditions:
This may occur under high control plane load.
Workaround:
Perform Supervisor Switchover or reload device
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.2(6b) |
|
Known Fixed Releases: | 6.2(13.7)S0, 7.2(1)D1(0.20) |
|
|
| |
| |
Bug Id: | CSCup10049 |
Title: | ACLQOS crash and %IPQOSMGR-3-QOSMGR_PPF_ERROR: PPF library error: |
|
Description: | Symptom:
A Nexus C7009 running NX-OS version 6.2(2a) may have a crash in aclqos with accompanied core file(s).
%SYSMGR-SLOT3-2-SERVICE_CRASHED: Service "aclqos" (PID ) hasn't caught signal 6 (core
will be saved).
Post crash, the below messages may also be seen:
%IPQOSMGR-3-QOSMGR_PPF_ERROR: PPF library error: MTS
Error 0x801c0010 (Device or resourc e busy) after 1706 retries .
Conditions:
there were too many queries from ipqosmgr and COPP to aclqos
Workaround:
Not known at this time.
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.2(2a), 6.2(6) |
|
Known Fixed Releases: | 6.1(2)I3(1.19), 6.1(2)I3(2), 6.2(10), 6.2(10)S92, 6.2(10)S93, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)D1(0.326) |
|
|
| |
| |
Bug Id: | CSCut44076 |
Title: | ISSU from 628/6212 to GBR:HMM-3-AUTO_CONF_PROFILE_ERROR |
|
Description: | Symptom:
HMM-3-AUTO_CONF_PROFILE_ERROR: hmm [16977] Data Snooping Host: Unable to find mapping for encap 31 on interface Ethx/y/z
Conditions:
Enable "feature-set fabric and feature vni after ISSU from 62x to GBR. Both of them must be enabled. If only one of them enabled, then issue not seen. Seen only with private-vlan pairs.
Packet start coming on secondary vlan , but since dhcp relay is configured only on primary vlan, it fails.
Delete secondary vlan, but primary vlan is pointing to a secondary vlan. Dhcp doesn't work at all for primary vlan since pktmgr sending packet on secondary vlan which is not present.
Workaround:
Try in the following order. If one doesn't work, move on to the next.
1) Disable one or both features (feature-set fabric or feature vni).
2) Delete secondary vlan and then recreate secondary vlan.
3) Delete and recreate the pvaln primary and secondary vlans.
3) "copy r s" switch reload.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.441) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv23184 |
Title: | Mac is egress learnt pointing to index in different VDC on M |
|
Description: | Symptom:
Mac is pointing to wrong DI in different VDC. Packet may leak between VDC.
Conditions:
Have a linecard in the admin VDC and configure some port channels not necesarily on this port-channel.
Move all ports of this LC at once to another VDC.
Workaround:
reload LC
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.78), 6.2(8b) |
|
Known Fixed Releases: | 6.2(13.9)S0, 7.2(1)D1(0.17), 7.2(1)ZD(0.13) |
|
|
| |
| |
Bug Id: | CSCtf36357 |
Title: | n7k: Need ability to configure ingress netflow sampling with dhcp relay |
|
Description: | A Nexus 7000 switch does not currently support having ingress netflow sampling and DHCP relay configured on the same interface. We need this restriction removed.
Symptom:
When trying to configure the two features together you might see error message similar to:
%$ VDC-1 %$ %NFM-2-VERIFY_FAIL: Verify failed - Client 0x87000146, Reason: feature combination is not supported in tcam, Interface: Vlan601
Verify failed - Client 0x83000146, Reason: feature combination is not supported in tcam, Interface: Vlan601
Conditions:
none
Workaround:
When you remove the ip monitor netflow input, you need to bounce the l3 interface to take a effect.
Fix is available in 6.2(2)
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 4.2(2a), 4.2(3), 5.2(0.266) |
|
Known Fixed Releases: | 6.2(0.279)S0, 6.2(0.287)S0, 6.2(2), 7.0(1)ZD(0.3) |
|
|
| |
| |
Bug Id: | CSCuo90184 |
Title: | NXOS/OTV: ARP ACL Applies to all VLAN without Arp inspection Filter |
|
Description: | Symptom:
ARP packets will not processed and all ARP packets will be dropped due to block ACL due to the following ARP access-list,
N7k-TEST(config)# arp access-list OTV-BLOCK-HSRP-ARP
N7k-TEST(config-arp-acl)# 10 deny ip any mac 0000.0c07.ac00 ffff.ffff.ff00
N7k-TEST(config-arp-acl)# 20 deny ip any mac 0000.0c9f.f000 ffff.ffff.f000
N7k-TEST(config-arp-acl)# 30 permit ip any mac any
without calling the arp inspection filter(ip arp inspection filter OTV-BLOCK-HSRP-ARP vlan), the ARP access-list will be applied to all vlans and block ARP.
Conditions:
The issue is seen after the ip arp inspection filter command is applied twice on the same vlan and then if we try to remove the config.
ip arp inspection filter OTV-BLOCK-HSRP-ARP vlan 1-10
ip arp inspection filter OTV-BLOCK-HSRP-ARP vlan 1-10
no ip arp inspection filter OTV-BLOCK-HSRP-ARP vlan 1-10
Workaround:
Reload ASCII
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.2(2a), 6.2(8)S8, 6.2(8)S9 |
|
Known Fixed Releases: | 6.2(12)E2, 6.2(13.3)S0, 6.2(14)FB(0.7), 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.422), 7.2(0)D1(1), 7.2(0)FM(0.3) |
|
|
| |
| |
Bug Id: | CSCut51575 |
Title: | VPC breaks due to incorrect emulated switch-id after ISSU upgrade |
|
Description: | Symptom:
Emulated switch-id changed to default value(2750) instead of configured one causing network connectivity issue. Software shows the correct switch-id.
Software:
`show vpc`
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 150
vPC+ switch id : 2010--------------------------------------------->Correct value
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
vPC fabricpath status : peer is reachable through fabricpath
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : secondary
Number of vPCs configured : 85
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)
`show platform fwm info l2mp myswid`
switch id
-------------------------------------------------------------------
switch id manager
-------------------------------------------------------------------
vpc role: 0
my primary switch id: 1011 (0x3f3)
emu switch id: 2750 (0xabe)--------------------------------???instead of 2010
peer switch id: 1010 (0x3f2)
Conditions:
ISSU upgrade
Workaround:
Remove the switch-id and reconfigure the same.
Conf ter
Vpc domain 150
No fabricpath switch-id 2010
fabricpath switch-id 2010
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: | 7.0(6)N1(0.276), 7.0(6)N1(1b), 7.0(7)N1(0.70), 7.0(7)N1(1), 7.0(7)ZN(0.148), 7.1(2)N1(0.576), 7.1(2)N1(1a), 7.1(2)ZD(0.26), 7.1(2)ZN(0.38), 7.2(1)D1(0.14) |
|
|
| |
| |
Bug Id: | CSCur99327 |
Title: | N7K10G: Rollback is failing on the scale setup |
|
Description: | Symptom:
Rollback to a previously created checkpoint might fail at "no license grace-period" command.
Conditions:
This only happened when performing rollback after "write erase" and on scale setup.
This issue is not always reproducible.
Workaround:
Issue another rollback with "best-effort" option first. And do "no license grace-period" manually if necessary.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 6.2(12)FT(0.26) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut29799 |
Title: | Privilege escalation with o+w files and directories |
|
Description: | Symptoms:
Cisco NX-OS based devices contain a number of files and directories that are assigned weak file permissions. This could allow an attacker that was able to gain access to the
underlying operating system to view or modify certain files that should be restricted.
Conditions:
Nexus devices running an affected version of NX-OS Software.
Workaround:
None.
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 1.7/1.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:N/I:P/A:N/E:F/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 7.0(0)HSK(0.392), 7.3(0)PDB(0.11) |
|
|
| |
| |
Bug Id: | CSCuv30417 |
Title: | vrf name changed and switchover - routing table mapped to previous vrf |
|
Description: | Symptom:
After changed vrf names as below and those changes are saved.
And did switchover and found that vrf for routing table was not updated and mapped to previous one.
Conditions:
version : n7700-s2-dk9.6.2.12.bin
module:
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 48 1/10 Gbps Ethernet Module N77-F348XP-23 ok
3 48 1/10 Gbps Ethernet Module N77-F348XP-23 ok
5 0 Supervisor Module-2 N77-SUP2E active *
6 0 Supervisor Module-2 N77-SUP2E ha-standby
7 48 1/10 Gbps Ethernet Module N77-F348XP-23 ok
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 6.2(9c)S5 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus57881 |
Title: | VPC PO continuously flapping when untagged frame statement exist |
|
Description: | Symptom:
When a profile containing a "untagged frame VNI" configuration is mapped to a vPC port channel the port channel will be unstable and continuously flap.
Conditions:
The issue will be seen with link level protocols like LACP etc. Due to the 'untagged VNI frame' configuration applied to the port, the following behavior is seen: the LACP untagged packet coming in hits the port profile and gets the VNI encapsulation. Then the VSI if index is determined when the packet reaches the SUP. The packet is then forwarded to the client (LACP in this case )with the physical if index value replaced by the VSI ifindex. The client expects the packet to contain the physical if index and not the VSI if index, this causes the port lookup to fail and the packet gets dropped at the client.
Workaround:
NONE
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.386) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc40079 |
Title: | Reserved vlan range reverts to default after upgrade |
|
Description: | Symptom:
After upgrade from version 5.2.1 to version 5.2.5 or later the reserved vlan list changes back to default settings. Any vlans in that range will show up in the startup config but are not active and not in running config. This occurs randomly but is reproducible.
Work Around:
Add the missing line to the config " system vlan xxx reserve" and reboot.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 5.2(5), 6.1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo05318 |
Title: | Vlan in blocking state (CBL) on one vpc leg |
|
Description: | Symptom:
VPC leg on N7K VPC Primary may be in STP Disable (DIS) state while the vpc leg is being brought up.
Conditions:
* VPC Leg on VPC Primary Switch
* There are one or more member link flaps while the VPC leg is being brought up.
Workaround:
Step 1: Shut the problem VPC leg on both Primary and Secondary.
Step 2: No-shut the problem VPC leg on both Primary and Secondary.
Further Problem Description:
When a VPC leg on a N7K is being brought up, if there are member-link flaps causing port-channel cleanups, the STP state for the VPC leg be in DIS state when the VPC leg is up. The issue is resolved by the above workaround.
The issue exists in 6.2(6) and 6.2(8). Issue is resolved in 6.2(10) and all later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 6.2(8)S1, 6.2(8)S11, 6.2(8)S30, 6.2(8)S33, 7.1(0)D1(0.82) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)EC(0.8), 6.2(10)FM(0.18), 6.2(10)NO(0.19), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.1(0)GF(0.36) |
|
|
| |
| |
Bug Id: | CSCuu68566 |
Title: | NVT-DC1:IGMP snooping for VLANs disabled in hardware |
|
Description: | Symptom:
IGMP Snooping remains disabled in hardware. In some VPC setup, there could be duplicate traffic also.
Conditions:
There are some IGMP snooping related commands for a vlan but the vlan itself is not present in the running config. ie the vlan is not created either through CLI or VTP. When such configs are present, it is possible that IGMP may pack updates for such vlans along with explicitly created vlans to m2rib module for hardware programming. But that message might be rejected by m2rib due to some vlans not explicitly created.
If the update contained snooping status info, then, we will end up with snooping status unchanged in the hardware.
Workaround:
Deleting all unnecessary configs and restarting igmp will fix the problem.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuu63346 |
Title: | vPC leg no BD after multiple link flaps |
|
Description: | Symptom:
vPC leg (on one side) ended up without BD after a particular sequence of link flap. The other side, vPC leg is in STP BLK state.
vPC status
---------------------------------------------------------------------
id Port Status Consistency Active VLANs Active BDs
----- ------------ ------ ----------- ---------------- --------------
100 Po100 up success - - <<< No BD
200 Po200 up success - 100-107
A#
Conditions:
Happens with below particular sequence:
vPC Peerlink down -> A vPC leg(100) down -> vPc peerlink up -> A vPC leg(100)up
Workaround:
The sequence of recovery steps that will avoid the system coming into this unrecoverable bad state is to bring up the primary vpc leg up first followed by the peer link. This will ensure consistency and correctness in the final state.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus02026 |
Title: | PIM crash seen on with high scale mcast source on VPC |
|
Description: | Symptom:
PIM may crash with high number of sources per group in VPC setup
Conditions:
High scale of sources per group
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.0(2)A6(0.44), 6.0(2)A6(1), 6.0(2)U6(0.44), 6.0(2)U6(1), 6.2(12), 6.2(12)S2, 6.2(12.4)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110) |
|
|
| |
| |
Bug Id: | CSCuj82684 |
Title: | "fips mode" enable before the All LC s are online leads to LC failure |
|
Description: | Symptom:
"fips mode" enable before the All LC s are online leads to LC failure
Conditions:
"fips mode" enable before the All LC s are online leads to LC failure
Workaround:
enable fips mode only after all the LC s are up .
Further Problem Description:
for more details refer to test plan ,
NEXUS_FIPS_140-2_Detailed_Test_Plan
http://wwwin-eng.cisco.com/Workgroup/Eng/DC_OS/QA/NEXUS_FIPS_140-2_Detailed_Test_Plan.doc
Status: AP EDCS Rev: 5 Date: 27-AUG-2010 Size: 2 M
Doc No: EDCS-664107 Format: WORD PDF
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu73376 |
Title: | multicast traffic loss due to snooping entry programmed with wrong LTL |
|
Description: | Symptom:
After these set of triggers,
a)ASCII replay ( with mcast config on a vxlan setup)
b)switchover
c) LC ISSU ,
there may be loss of few mcast streams .
RCA-
Problem surfaces wherein we see some "pending" l2mcast entries in the LC. These pending entries look to be stale ones - those that were added before the ISSU. Pending entries are those routes psuhed to the LC by MFDM wherein the ltl index for the OIF is not resolved. MFDM typically sends an update after the ltl is resolved and these pending entries are popped off the list and progarmmed to hw.. Some how that never seems to happen for these entries and after the ISSU is done they will be recovered again with the stale RID info ( index for set of ltls) . Any update coming in for the RID after the ISSU will cause these entries to be programmed with wrong LTL.
Conditions:
The issue is ocassionally when the following sequence was done
1. ASCII replay - followed by
2. switchover - followed by
3. LC ISSU
Workaround:
To do away with the wrong entries LC reload is the only workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.22), 7.2(1)ZD(0.17) |
|
|
| |
| |
Bug Id: | CSCuu68733 |
Title: | N77/SNMP: show sys intern snmp mem-stats incr memory leak - snmpmib_proc |
|
Description: | Symptom:
Continuous polling a range of OIDs
Conditions:
Continuously polling of OIDs from DCNM tool
Workaround:
snmpd is freeing up the memory acquired after returning the response query to the polling
Further Problem Description:
Leak is not that much to initiate a process crash because the analysis showed that the memory is going up but its also getting freed after sometime.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1), 7.3(0)D1(0.24) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur34065 |
Title: | u6rib cored @u6rib_process_clt_stale while deleting vdc |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 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) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.315), 7.1(0)OTT(0.45), 7.1(0)PDB(0.269), 7.1(0)SIB(99.52), 7.1(2)N1(0.576), 7.1(2)ZD(0.26), 7.1(2)ZN(0.38) |
|
|
| |
| |
Bug Id: | CSCuu40239 |
Title: | ARP traffic sent out on incorrect VLAN |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.11)S0 |
|
|
| |
| |
Bug Id: | CSCut49295 |
Title: | 7.2.0.D1.0.444.S3::UIN-1::Seeing BFD/EIGRP flap after doing 2nd SSO |
|
Description: | Symptom:
EIGRP session flap after SSO
Conditions:
Seen after multiple consecutive SSOs
Workaround:
None
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.444) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo50084 |
Title: | 6.2.10 :ERROR: internal error: Failed to get if record on ASCII |
|
Description: | Symptom:
The following error messages may be seen occasionally when applying an ascii config to switch which contains a large number of HSRP groups:
"ERROR: internal error: Failed to get if record"
"ERROR: HSRP V6 groups are not supported on HSRPV1 interface"
Conditions:
Issue only occurs when there are HSRP groups configured on interfaces that are VRF members.
Workaround:
The failed HSRP config can be reapplied manually afterwards and will be accepted.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.2(10)FM(0.20), 6.2(10)FM(0.24), 6.2(12)E2, 6.2(12)FM(0.8) |
|
Known Fixed Releases: | 6.2(12)E1, 6.2(12)E5, 6.2(13.11)S0, 7.1(0)BF(0.123), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)OTT(0.6), 7.1(0)PDB(0.115), 7.1(0)VXE(0.2) |
|
|
| |
| |
Bug Id: | CSCuv26132 |
Title: | Evaluation of n7k-infra for OpenSSL July 2015 vulnerability |
|
Description: | b>
Symptom:
Cisco Nexus 6000 Series Switches;Cisco Nexus 7000 Series Switches; includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) ID:
CVE-2015-1793
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent.
Workaround:
Not available.
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: 4.3/3.4
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:P/A:N/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
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 7.2(1)S8 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu53383 |
Title: | Multicast IP packet with Unicast dmac is punted to the control plane |
|
Description: | Symptom:
High RX rate on the inband interface due to IP multicast packets.
Conditions:
IP multicast packet (224.0.0.0/4) with a unicast destination mac address of which the Nexus 7000 ingress L3 interface owns.
Workaround:
None.
Further Problem Description:
This traffic should be dropped in hardware by the parser as it violates packet format standards. This traffic should not be sent to the control plane for processing.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a), 6.2(8b) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuh20873 |
Title: | IPV6 default route URIB and UFIB inconsistency cause traffic drop |
|
Description: | Symptom:
In the customer testing setup, there are eBGP ECMP for IPv6 default route, which works fine at stable mode, but upon any path fail, the URIB and UFIB shows inconsistent, and UFIB point to th epath which is already down which cause traffic blackholed.
Conditions:
NONE
Workaround:
"clear ipv6 route 0::0/0" will cause default route reprogrammed, and can clear the issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 5.0(3)U5(1f) |
|
Known Fixed Releases: | 5.0(3)U5(1f), 5.2(1)N1(6), 6.0(2)N2(1), 6.0(2)U1(1a), 6.0(2)U1(2), 6.2(1.137)S0, 6.2(2), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuv16257 |
Title: | iscm crash at in raise () from /ramfs/ |
|
Description: | Symptom:
iscm crash at in raise () from /ramfs/
Conditions:
iscm crash at in raise () from /ramfs/
Workaround:
iscm crash at in raise () from /ramfs/
Further Problem Description:
iscm crash at in raise () from /ramfs/
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.79) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu00672 |
Title: | vMotion across DCI fails due to RARP packet drop on BL |
|
Description: | Symptom:
A Cisco Nexus 7000 Border Leaf switch does not forward incoming RARP frame toward DCI links if Enhanced Forwarding is configured on the VLAN. This may cause vMotion move failures for Virtual Machines (VMs) moving from one fabric to another across DCI.
Conditions:
This problem occurs if Enhanced Forwarding mode is configured on the Border Leaf VLAN.
Workaround(s):
Use Traditional Forwarding mode.
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup16103 |
Title: | N7k: Copp fails to rate limit Pause frames from Hosts on 2248TP type FEX |
|
Description: | Symptom:
Pause frames from Host reach the 7K CPU
Conditions:
Issue seen when host is connected to FEX N2248TP and host is sending a PAUSE storm
Affects both 6.2(6a)/6.2(8)
Workaround:
Offending host generating pause frames can be taken offline.
Further Problem Description:
Issue reported:
=========
Pause frames from FEX front panel (HIF) ports, end up at the SUP on N7K.
Observation:
=========
* On FEX type N2248TP, Pause frames are not handled correctly. Even with Rx flow-control enabled on the interface, pause frames are being forwarded upstream to the N7K instead of being consumed on the FEX.
* For all other FEX types including the latest N2248PQ, Pause frames are consumed at the FEX if Rx flow-control is enabled.
Potential Impact:
===========
* If volume of pause frames generated from the servers connecting to the FEX is EXTREMLY HIGH, then control path to the SUP can get congested
** Other control plane traffic destined to SUP can be dropped
Common case:
=========
* Pause frames volume is typically not so high in a real network to really congest SUP
* If there are malicious servers which are generating such high volume of traffic, those servers need to turned off.
Desired (Can be tracked as a separate enhancement requests):
============================================
1. Presently, Rx flow-control is not enabled by default for FEX HIFs. Behavior is documented.
*** Desired that Rx flow-control be enabled by default
2. Even if flow-control is not enabled, quench the pause frames at the MAC layer.
*** Must be tracked with FEX hardware/platform team (SAVTG)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.2(6a), 6.2(8) |
|
Known Fixed Releases: | 7.1(2)N1(0.574), 7.1(2)ZN(0.35), 7.2(0)N1(0.172), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.174), 7.3(0)N1(0.25), 7.3(0)N1(1), 7.3(0)ZN(0.24) |
|
|
| |
| |
Bug Id: | CSCus96878 |
Title: | Nexus7700 FEX interface link flap with FET-10G |
|
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:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCub15899 |
Title: | constant high cpu in snmpd - upon polling invalid tunnel interfaces |
|
Description: | Symptom:
Under rare conditions SNMPd process may cause high CPU utilization even without SNMP polling
Conditions:
This happens when SNMPd consumes maximum allowed amount of memory and no more memory cannot be allocated for received packet processing
Workaround:
Currently possible workarounds are being investigated.
TAC can help to restart snmpd process to clear the issue. Supervisor switchover should also clear the issue
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 4.2(8) |
|
Known Fixed Releases: | 5.2(6.16)S0, 5.2(7), 6.0(2)A1(1), 6.0(2)N1(1), 6.0(2)U1(1), 6.1(1)S46, 6.1(1.45)S0, 6.1(1.69), 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCut93469 |
Title: | SUP2,F2E ,arp response failing with SI set as GPC LTL |
|
Description: | Symptom:
ARP responses for the HSRP VIP are dropped.
Conditions:
An ARP response from the active HSRP Anycast is dropped on the HSRP Anycast standby when enabling Dynamic ARP Inspection.
This problem only occurs when having the vdc configured for 'limit-resource module-type F2 F2E' and only hosting F2E linecards on the chassis.
Workaround:
Reconfigure the vdc for F2E only support and rebind the interfaces.
vdc xxx id 1
limit-resource module-type f2e
This ensures that the F2E linecard is using the physical source interface instead of using the HSRP anycast GPC as the source interface for incoming ARP responses.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 6.2(10)E8 |
|
Known Fixed Releases: | 6.2(10)E3, 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCus68473 |
Title: | urib crash after running "clear ip route vrf xxx *" |
|
Description: | Symptom:
N7K running 6.2(8E10) crash on the urib process after clearing all routes in the VRF rib.
Conditions:
Clearing all routes in the RIB when there is high route count
Workaround:
Clear individual routes, instead of the entire table using *
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 6.2(8)E10 |
|
Known Fixed Releases: | 6.2(13.4)S0, 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)SIB(99.109), 7.1(2)N1(0.569), 7.1(2)ZD(0.21), 7.1(2)ZN(0.29), 7.2(0)AB(9), 7.2(0)D1(0.451), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCtq62339 |
Title: | NX-OS 5.1 Kernel Memory Leak |
|
Description: | Symptom:
Nexus7000 may report platform memory alert due to high memory utilization:
%PLATFORM-2-MEMORY_ALERT: Memory Status Alert: MINOR. Usage 85% of Available Memory
%PLATFORM-2-MEMORY_ALERT: Memory Status Alert: SEVERE. Usage 90% of Available Memory
N7K# sh system internal memory-status
MemStatus: Severe Alert
N7K# sh system internal memory-alerts-log | inc "ALERT INFO|MemTotal|MemFree|LowTotal|LowFree"
MINOR ALERT INFO
MemTotal: 8254672 kB
MemFree: 4295324 kB
LowTotal: 727120 kB
LowFree: 109332 kB
SEVERE ALERT INFO
MemTotal: 8254672 kB
MemFree: 4255408 kB
LowTotal: 727120 kB
LowFree: 72392 kB
Conditions:
CSCtq62339 is only being encountered if the following conditions are true:
Switch is running a release between 5.1(1) to 5.1(3).
>>>>=====
On these releases, the bug will be exposed
irrespective any feature enabled/disabled.
There is no precondition for this.
<<<<<====
Memory alert log shows only a snapshot of kernel memory *when* the alert threshold (85,90,95%) is crossed. Historical information can be misleading and needs to be understood clearly.
To calculate the CURRENT kernel memory, use the following procedure:
N7K# show system internal kernel memory usage | in Low
Low memory condition is logged when the following formula is at/above the logging threshold:
(LowTotal - LowFree) ?? LowTotal x 100
Ex: (727120 - 72392 ) ?? 727120 x 100 = 90% (threshold reached due to utilization in low region)
Low memory condition has been seen after approximately 3 months of supervisor uptime.
Workaround(s):
Reload of the active supervisor will clear the issue in a setup with two supervisor cards.
Reload of the switch will clear the issue in a setup with a single supervisor.
Software upgrade to fixed release, 5.1(4) or 5.2(1) or later.
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and determined it 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
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 5.1(1), 5.1(2), 5.2(1) |
|
Known Fixed Releases: | 5.1(10.4)S0, 5.1(4)S3, 5.2(1)S36, 5.2(1.43)S0 |
|
|
| |
| |
Bug Id: | CSCte53614 |
Title: | Memory leak in MTS |
|
Description: | Symptom:
A Nexus 7K or MDS running 4.2.x may run out of memory due to a memory leak in
the MTS module under specific conditions. A continuous memory leak can
eventually lead to the active Supervisor crash and a switchover will happen.
This defect does not affect the standby SUP (if the system does have one).
This leak can be confirmed by CLI command "show system internal kernel
malloc-stats".
On the last column of 'klm_mts' entry, the number will be very large (more than
100,000) and increase through time.
Example:
Nexus-7K# show system internal kernel malloc-stats
Module kmalloc kcalloc kfree diff
...
klm_mts 860524980 00000000 845560260 14964720
...
Condition:
When the following CLI commands are performed, a 32-byte memory block will be leaked:
show cdp global
show cdp interface <>
show cdp all
show cdp entry
show cdp traffic <>
Workaround:
1. The preferred workaround is to stop above mentioned SNMP walk,
query, and CLI commands.
2. A manual switchover of the sup can avoid ungraceful active
SUP failure due to this bug. The manual switch should be
preformed when the following condition is met:
The output of "show system internal kernel meminfo | inc LowFree"
is less than 200MB
3. Review upgrade options.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 4.2(2) |
|
Known Fixed Releases: | 4.2(1)N1(1), 4.2(4), 4.2(4.14), 4.2(5), 7.0(1)ZD(0.3), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuo15015 |
Title: | urib process crash on N7k |
|
Description: | Symptom:
A N7k running 6.2(2a) crashed on the urib process
Conditions:
This is a corner case. With frequent binding and unbinding of dynamic saps during lots of parallel CLI command processing, q handle management may cause the system subject to this bug.
Workaround:
None. But reducing the number of parallel CLI commands being processed by an application may reduce the chance of this bug.
Further Problem Description:
Impact: Process can crash and will be re-started by HA.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 6.2(2a), 7.1(0)D1(0.179) |
|
Known Fixed Releases: | 6.0(2)A6(0.78), 6.0(2)A6(1), 6.0(2)U6(0.78), 6.0(2)U6(1), 6.1(2)I3(2.19), 6.1(2)I3(3), 6.2(10), 6.2(10)CM(0.10), 6.2(10)CM(0.9), 6.2(8)KR(0.8) |
|
|
| |
| |
Bug Id: | CSCuu33340 |
Title: | Param-list is not cleaned up when the vrf are gone |
|
Description: | Symptom:
param-list entries still showing in "show run" even when all profiles have been un-applied
Conditions:
Auto-Configuration has been used to apply profiles and profiles have subsequently been un-applied (either manually or due to host aging).
Workaround:
User can remove param-list entries manually by doing "no param-list ..."
Further Problem Description:
The param-list entries do not cause a problem with subsequent profile applies.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.484), 7.2(0)VZD(0.33) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut30001 |
Title: | Camden NAT: SPM throws error on unconfig of nat from an intf |
|
Description: | Symptom:
On N9K switch, deleting an NAT INSIDE/OUTSIDE policy makes SPM generat an error: PPF Library: Invalid argument. The error is caused by SPM deleting ststs of a filter node.
I think this bug will be hit on almost all N9K camden switches.
Conditions:
deleting an NAT INSIDE policy on a N9K switch
Workaround:
Do not delete that NAT policy
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 7.2(0.1)VB(0.1) |
|
Known Fixed Releases: | 7.0(3)I2(0.134), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCup55118 |
Title: | ORIB buffer exhaustion on IGMP join/leave |
|
Description: | Symptom:
ORIB buffer exhaustion when we receive continuous IGMP join/leave
show ip igmp snooping internal ribs
IGMP Snooping internal RIB information
RIB name: M2RIB (type 0), ready: Yes No , xid 0x1f6cd
Max. outstanding buffers: 4
Current outstanding buffers: 0
Max. OMF entries per buffer: 400
Max. OMF route entries per buffer: 50
Max. route entries per buffer: 400
Fabricpath redist instance: 1
Used buffer queue count: 0
Free buffer queue count: 10
Buffer: 0x0x98650ac, type: none, xid: 0x0, count: 0
Buffer: 0x0x9869f04, type: none, xid: 0x0, count: 0
Buffer: 0x0x986ed5c, type: none, xid: 0x0, count: 0
Buffer: 0x0x9873bb4, type: none, xid: 0x0, count: 0
Buffer: 0x0x985174c, type: none, xid: 0x0, count: 0
Buffer: 0x0x984c8f4, type: none, xid: 0x0, count: 0
Buffer: 0x0x9847a9c, type: none, xid: 0x0, count: 0
Buffer: 0x0x98565a4, type: none, xid: 0x0, count: 0
Buffer: 0x0x985b3fc, type: none, xid: 0x0, count: 0
Buffer: 0x0x9860254, type: none, xid: 0x0, count: 0
TXLIST member version: 0
RIB name: ORIB (type 1), ready: Yes No , xid 0x10009
Used buffer queue count: 10
Buffer: 0x0x97ff7ac, type: route, xid: 0x10000, count: 1
Buffer: 0x0x9804604, type: route, xid: 0x10001, count: 1
Buffer: 0x0x980945c, type: route, xid: 0x10002, count: 1
Buffer: 0x0x980e2b4, type: route, xid: 0x10003, count: 1
Buffer: 0x0x981310c, type: route, xid: 0x10004, count: 1
Buffer: 0x0x97e6ff4, type: route, xid: 0x10005, count: 1
Buffer: 0x0x97ebe4c, type: route, xid: 0x10006, count: 1
Buffer: 0x0x97f0ca4, type: route, xid: 0x10007, count: 1
Buffer: 0x0x97f5afc, type: route, xid: 0x10008, count: 1
Buffer: 0x0x97fa954, type: route, xid: 0x10009, count: 1
Free buffer queue count: 0
TXLIST member version: 69545
Conditions:
this issue is seen in OTV environment
Workaround:
restart igmp process
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 5.2(1), 6.1(4), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S32, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.189), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)N1(0.240), 7.1(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCus15529 |
Title: | OTV trunk intf err-disabled due to "IFTMC PD commit db search failed" |
|
Description: | Symptom:
Interface getting error disabled on changing native vlan
Conditions:
It happens in a OTV enabled VDC with a trunk port carrying OTV extended vlans.
Workaround:
shut/no shut of interface
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12)S6 |
|
Known Fixed Releases: | 7.1(0)AV(0.38), 7.1(0)PDB(0.301), 7.2(0)D1(0.387), 7.2(0)D1(1), 7.2(0)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCuv30648 |
Title: | STP cores while configure VPC setup at stathashe_get_another_entry |
|
Description: | Symptom:
STP cores while configure VPC setup at stathashe_get_another_entry ,
STP core seen while configuring VPC setup ,
Conditions:
basic wccp configuration , No entry for SPM policy programming after wccp configuration on F2e LC
Workaround:
STP cores while configure VPC setup at stathashe_get_another_entry ,
STP core seen while configuring VPC setup ,
Further Problem Description:
STP cores while configure VPC setup at stathashe_get_another_entry ,
STP core seen while configuring VPC setup ,
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.78) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus68892 |
Title: | N7K: assess GHOST vulnerability in glibc (CVE-2015-0235) |
|
Description: | Symptom:
On January 27, 2015, a buffer overflow vulnerability in the GNU C library (glibc) was publicly announced. This vulnerability is related to the various gethostbyname functions included in glibc and affect applications that call these functions. This vulnerability may allow an attacker to obtain sensitive information from an exploited system or, in some instances, perform remote code execution with the privileges of the application being exploited. This vulnerability is documented in CVE-2015-0235.
A Cisco Security Advisory has been published to document this vulnerability at:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150128-ghost
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent.
Workaround:
Not available.
Further Problem Description:
A heap-based buffer overflow in glibc's __nss_hostname_digits_dots() function, which is used by the gethostbyname* glibc function calls.
All previously released versionsand NX-OS software are affected. The fix will be delivered for currently supported releases as follows:
NX-OS 7.0 release - is scheduled to be available in May 2015
NX-OS 6.2 release - first fixed release is 6.2(12) which is available on CCO
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/7.8
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C/CDP:ND/TD:ND/CR:ND/IR:ND/AR:ND
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 4.2(8), 5.2(9), 6.1(5), 6.2(10) |
|
Known Fixed Releases: | 6.2(12), 6.2(12)S32, 6.2(12.3)S0, 6.2(12.4)S0, 6.2(13.1)S0, 7.2(0)D1(0.410), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.347) |
|
|
| |
| |
Bug Id: | CSCut17447 |
Title: | SPAN dest port load balancing doesn't work with M2 as span src |
|
Description: | Symptom:
If SPAN source is on M2 module in the RX direction, then load balancing on SPAN destination port-channel does not work.
Hostname(config-monitor)# sh port-channel traffic interface po X
NOTE: Clear the port-channel member counters to get accurate statistics
ChanId Port Rx-Ucst Tx-Ucst Rx-Mcst Tx-Mcst Rx-Bcst Tx-Bcst
------ --------- ------- ------- ------- ------- ------- -------
19 Eth8/18 100.00% 65.15% 40.00% 100.00% 0.0% 0.0%
19 Eth8/19 0.0% 34.84% 59.99% 0.0% 0.0% 0.0%
Hostname(config-monitor)#
Conditions:
SPAN source is on M2 module and SPAN direction in RX only
This problem is seen on 6.2 code when ISSU was performed from 6.1 code.
Workaround:
This problem is not seen when N7K was upgraded to code 6.2 code traditionally or N7K is reloaded after ISSU to 6.2
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu38313 |
Title: | ETHPORT-2-IF_SEQ_ERROR: Error ("sequence timeout") |
|
Description: | Symptom:
ETHPORT-2-IF_SEQ_ERROR: Error ("sequence timeout") seen on syslog
Conditions:
On Scale Setup - with 384 fabric path bfd sessions & 1616 FP bfd sessions on L3 SVI. While adding/removing the FP members from Vlan
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus78697 |
Title: | N7K wrong source-interface selected for IPv6 logging after device reload |
|
Description: | Symptom:
logging source-interface seems to be non-working with v6 syslog server on N7K after device reload even the loggingsource-interface pointing to the loopback0 interface
Conditions:
After device reload
Workaround:
reapply logging source-interface loopback0
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 6.1(5), 6.2(10) |
|
Known Fixed Releases: | 6.2(13.4)S0, 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.443), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)N1(1), 7.2(0)PDB(0.379), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCug77418 |
Title: | SUP goes to failure state after starting traffic in vpc/vpls scale setup |
|
Description: | Symptom:
supervisor on N7k platform may crash with the following reason in 'show module internal exceptionlog' command
System Errorcode : 0x410b003a Octopus internal error
Error Type : FATAL error
PhyPortLayer : Supervisor Inband
Conditions:
The issue happens because Sup Metro receives packets (FF) with ccc bit set to 0x2 (L3 Multicast Rewrite).
Workaround:
Further Problem Description:
To determine if we are hitting this bug, we need to match 2 conditions:
first, from the exception log we need to see
"System Errorcode : 0x410b003a Octopus internal error"
"PhyPortLayer : Supervisor Inband"
second, in the output of `show hardware internal statistics device rewrite all` the following two counter should be non-zero
98 Multicast L3 PR replication pkt cnt 0000000000000348 - I1
130 Invalid MET entry cnt 0000000000000348 - I1
if we match both condition above, we are hitting this bug
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 6.1(3), 6.2(1.33)S2, 6.2(1.93)S3 |
|
Known Fixed Releases: | 6.2(1.103)S7, 6.2(1.106)S3, 6.2(1.110)S0, 6.2(2), 7.0(0)ZD(0.53), 7.0(0)ZD(0.55) |
|
|
| |
| |
Bug Id: | CSCuu60496 |
Title: | NVT: mroute stuck in pending after sso |
|
Description: | Symptom:
MRIB routes seem to be in pending state. "show ip mroute" will show routes with pending flag.
Conditions:
when a "pim restart" command is issued, in rare occasions, it is possible that PIM does not a proper mrib_deregister() and when it restarts, does mrib_register instead of mrib_reregister. This makes PIM a sort of invalid client of MRIB and MRIB does not send any updates to PIM and also postpones sending any update to hardware.
Workaround:
The workaround for this issue is "restart pim" command itself. This command will restart and MRIB should see PIM as a valid client. It is possible that under various scenarios, this workaround might have to be done multiple times.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo81646 |
Title: | N77-F348XP-23 port 41-48 link remain up even cable disconnected |
|
Description: | Symptom:
port 41-48 link remain up even cable disconnected or partner device is admin down
Conditions:
1G Optics or 1G copper are used on N77-F348XP-23 port 41-48
Workaround:
there is no work around
upgrade to fixed version
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 6.2(10)FM(0.27) |
|
Known Fixed Releases: | 6.2(10), 6.2(8)E5, 6.2(8.12)S0 |
|
|
| |
| |
Bug Id: | CSCur64055 |
Title: | ISIS cores when Lookup mode change with static MAC entry |
|
Description: | This bug affects MACs redistributed into FP ISIS from M2RIB
Symptom:
When lookup mode is changed from IP to MAC
Conditions:
ISIS crashes and restarts
Workaround:
the default lookup mode is IP so if we use it and don't redistribute MAC routes we don't see the crash. Avoid the configuration of static MAC addresses, and the use of "layer-2 multicast lookup mac".
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 6.2(10)S102 |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.15), 6.2(8a)E3, 7.2(0)D1(1), 7.2(0)ZD(0.82) |
|
|
| |
| |
Bug Id: | CSCuj45281 |
Title: | Crafted LLDP packet causes an interface to go error-disable |
|
Description: | Symptom:
A vulnerability in the Link Layer Discovery Protocol (LLDP) code of Cisco NX-OS Software could allow an unauthenticated, adjacent attacker to cause the switch port on which the packet is received to stop forwarding traffic.
The vulnerability is due to an error in processing a malformed LLDP packet. An attacker could exploit this vulnerability by sending a specially crafted, malformed LLDP packet to an interface enabled for LLDP packet processing. Other ports on the switch are not affected.
Conditions:
LLDP is enabled on the interface on which the malformed packet is received.
Workaround:
There are no workarounds
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 3.3/3.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:U/RC:C
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
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud01394 |
Title: | N7K - F1 / F2 line card: Mac addresses out of sync across FEs |
|
Description: | Symptom:
Following a MAC Flap, the hardware MAC address table on a F1 or F2 modules will not have the same consistent entry across all the forwarding engines (FEs) when the vlan mode is CE and learning mode is non-conversational.
Conditions:
Issue is seen on F1 modules on 5.2(5).
Rapid mac move that happen between two FEs and there is a Flood to bd / flood to fabric miss in hardware
Workaround:
Clear the specific mac address
Fix is present from 5.2(9) onwards for F series cards.
Will this issue impact Nexus7009 running 6.1.3?
Yes. As Integrated-release says its fixed from 6.1.5 onwards for 6.1.x train and all future releases.
Is this issue F1 module specific??
No
Will N7K-F248XP-25E be impacted??
Yes. Fix is present from 6.1.5 onwards.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.2(4), 5.2(5) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S64, 5.2(9.113)S0, 5.2(9.114)S0, 6.1(4.3)S0, 6.1(5), 6.2(1.93), 6.2(2), 7.1(0)D1(0.14), 7.1(0)D1(0.15) |
|
|
| |
| |
Bug Id: | CSCuv26663 |
Title: | Static mac missing from M card for L3 BD in HW |
|
Description: | Symptom:
L3 interfaces can not resolve ARP. Packet may get flooded.
HW mac table on LC will not have static mac for L3 BD.
Conditions:
add , delete , add L3 subifs couple times in quick succession (either via script or copy paste on terminal)
Or
add/delete/add any fhrp
Workaround:
reload LC
Further Problem Description:
This is a timing issue and is not HW dependent issue.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8b) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCub73193 |
Title: | BGP routes stuck in delete state blocked by ulib flow control |
|
Description: | Symptom:
Under rare situation, BGP bestpath run may stall due to a bug
in the BGP-ULIB flow control logic. To confirm the problem, search
the 'show tech bgp' or 'show tech l3vpn' for:
Last xid sent to ULIB: 4294967295
Last xid received from ULIB: 65535
ULIB flow control blocks: 5 (currently blocked)
Conditions:
This can only happen to MPLS deployments where label allocation
is required (L3VPN, 6VPE, 6PE).
There is an integer wrap-around bug in the BGP-ULIB flow control
logic. If during the wrap-around period, ULIB is busy and slow to
respond, the BGP bestpath run will be blocked indefinitely.
This problem is very time sensitive and the window is very small.
It is not guaranteed to happen every time.
This is no specific trigger, as long as new labels are continuously allocated
from ULIB (new prefixes, label mode change, etc), it may hit the wrap-around
condition.
Workaround:
There's no workaround. To recover from the situation, perform 'restart bgp'.
A less disruptive recovery method is to use 'per-vrf' label mode by configuring
a dummy l3vpn vrf context. Example:
vrf context dummy
rd
router bgp <>
vrf dummy
address-family ipv4 unicast
label-allocation-mode per-vrf
This should unblock the BGP bestpath run. If not, try adding another dummy vrf (without removing the previous one). After BGP bestpath run had been unblocked, the dummy vrfs can be removed.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.2(5), 5.2(5)S19 |
|
Known Fixed Releases: | 5.2(7), 5.2(7)S3, 5.2(7.6)S0, 6.0(2)N2(1), 6.0(2)U1(1), 6.1(1.66)S0, 6.1(2), 6.1(2.27), 6.2(0.285), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCut36425 |
Title: | F3 in FP transit mode - All traffic drop due to ports in CE mode |
|
Description: | Symptom:
All traffic is dropped on whole LC for various reasons - CBL drop, MIM on edge port etc - depending on interface configuration.
Conditions:
Issue can only on VDC/device in FabricPath in transit mode "fabricpath mode transit"
After removing the port-channel from the VPC configuration, the configuration is not wiped out in the LC.
Later when the Port-channel is used for any non-VPC configuration traffic is dropped.
Workaround:
Option 1 : Reload affected module
Option 2: Delete port-channel after making it non-VPC and then add the port-channel.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(13.16)S0, 6.2(13.3)S0, 6.2(14)FB(0.20), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)D1(0.459), 7.2(0)D1(1), 7.2(0)PDB(0.382), 7.2(1)D1(0.27), 7.2(1)ZD(0.22) |
|
|
| |
| |
Bug Id: | CSCud03634 |
Title: | RIP keep advertising route even though original route source is down |
|
Description: | Symptom:
RIP keep advertising route even though the original advertising source is down.
Conditions:
The route is redistributed to RIP.
Original source (other Routing protocols or Connected link) is down.
or
RIP native route
Workaround:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N1(0.349) |
|
Known Fixed Releases: | 5.2(9.51)S0, 6.0(2)A1(1c), 6.0(2)N2(1), 6.0(2)U1(3), 6.1(4.1)S0, 6.1(5), 6.2(1.93), 6.2(2), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCul45644 |
Title: | vlan_mgr crashed if dynamic reserved vlan range conflicts with vtp vlan. |
|
Description: | Symptom:
When reserved vlan range is within the VTP vlan range (vlan 2-1001) and
this vtp switch receives a vtp message from the network carrying a user vlan that has been locally configured as reserved, the new vlan creation message to vlan_mgr causes a crash.
Conditions:
This bug is hit with VTP enabled and reserved vlan range falls under VTP vlan range.
Example:
1. vdc1 and vdc2 have two trunks links between them.
2. vdc1 is vtp mode server, vdc2 is vtp client or server mode.
3. vdc2 has a reserved vlan range 100-227 configured.
ex: switch(config)>system vlan 100 reserve.
4. vdc1 creates vlan 100.
5. when vdc2 receives vtp add vlan message, vlan_mgr crashes.
Workaround:
Disable VTP or do not move the reserved vlan range into the VTP vlan range.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 6.2(5.52) |
|
Known Fixed Releases: | 6.2(6), 6.2(6)S2, 6.2(6.13)S0 |
|
|
| |
| |
Bug Id: | CSCuu73828 |
Title: | ipfib crash upon ISSU from 6.2.10 to GBR |
|
Description: | Symptom:
IPFIB crash on ISSU.
Conditions:
sh ipv6 route 14:211:1::
14:211:1::/64, ubest/mbest: 2/0, attached
*via 14:211:1::1, Vlan964, [0/0], 15:38:20, direct,
*via 14:211:1::8, Vlan964, [0/0], 06:10:04, direct,
When there is a direct and attached route with an ECMP of PATHs, IPFIB process will crash during ISSU(recovery).
This is because we do NOT expect a Direct route with an ECMP of PATHs.
Also we can see that clearing the route does not add the ECMP again, in which case we should NOT see the crash.
n7k-fex1-f3# sh ipv6 route 14:211:1::
14:211:1::/64, ubest/mbest: 2/0, attached
*via 14:211:1::1, Vlan964, [0/0], 16:13:11, direct,
*via 14:211:1::8, Vlan964, [0/0], 06:44:55, direct,
n7k-fex1-f3# clear ipv6 route 14:211:1::/64
Clearing 14:211:1::/64
n7k-fex1-f3# sh ipv6 route 14:211:1::
14:211:1::/64, ubest/mbest: 1/0, attached
*via 14:211:1::1, Vlan964, [0/0], 00:00:07, direct,
n7k-fex1-f3#
Workaround:
if we notice any Direct route with an ECMP of paths we can clear the route, which will fix the # of paths. And then if we do the ISSU, we should NOT see IPFIB crash.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.27), 7.2(1)ZD(0.22) |
|
|
| |
| |
Bug Id: | CSCup89391 |
Title: | SNMP process crash |
|
Description: | Symptom:
SNMP crash causing device reload
Conditions:
N/A
Workaround:
- use SNMPv2 instead SNMPv3
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.2(8b), 6.2(8) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud10012 |
Title: | Unexpected reload of nexus 7000 due to res_mgr hap reset |
|
Description: | Symptoms
A nexus 7000 may unexpectedly reload due to a res_mgr hap reset.
The logs of the switch will show several cores for the res_mgr process prior to
the hap reset:
%SYSMGR-2-SERVICE_CRASHED: Service "res_mgr" (PID 4055) hasn't caught signal 11
(core will be saved).
Conditions
Steps to recreate
(1) Create a large VLAN range, for eg. 1000-2000
(2) Delete VLANs in between such as "no VLAN 1005" followed by "no VLAN 1010" and so forth.
If you show the list of VLANs in the format "1000-1004,1006-1009,............" there are 19 characters to show the string "1000-1004,1006-1009" alone (1 for 1, 1 for 0, 1 for 0, 1 for 0, 1 for -, 1 for 1, 1 for 0, 1 for 0, 1 for 0, 1 for 4, 1 for ,, 1 for 1 and so forth). If you have too many VLAN or VRF ranges such that the representation in a string in the fashion above takes more than 512 characters, the problem will happen.
(3) For the problem to happen, after (1) and (2), you have to issue "show vdc resources".
Workaround
None known at this time.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S20, 5.2(9.38)S0, 6.1(3), 6.1(3)S21, 6.1(3.31)S0, 6.2(1.93), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCum05295 |
Title: | BGP multipath entry in uRIB does not get updated after attribute change |
|
Description: | Symptom:
There are two symptoms that can be seen for this bug.
1. The following error message can be seen in syslog and IGP redistributing BGP routes may fail.
2013 Dec 13 01:21:58 PTAINTS410 %OSPF-3-RPM_LIB_API_FAILED: bgp_lookup_ext_attr() - failed in rpm_acquire_bgp_shmem_lock()
2. A route with a stale metric in the routing table exists
`DC1-CORE-3# sho ip bgp 10.10.63.0
BGP routing table information for VRF default, address family IPv4 Unicast
BGP routing table entry for 10.10.63.0/25, version 127677
Paths: (6 available, best #1)
Flags: (0x00001a) on xmit-list, is in urib, is best urib route
Multipath: eBGP iBGP
Path type: internal, path is valid, received and used, not best reason: Router Id, multipath
AS-Path: NONE, path sourced internal to AS
1.1.2.3 (metric 101) from 1.1.2.3 (1.1.2.3)
Origin IGP, MED 409, localpref 100, weight 0 <====== MED 409 should match routing table
DC1-CORE-3# sho ip route 10.10.63.0
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
10.10.63.0/25, ubest/mbest: 5/0
*via 1.1.2.2, [200/409], 00:10:12, bgp-65001, internal, tag 65001
*via 1.1.2.5, [200/409], 00:43:22, bgp-65001, internal, tag 65001
*via 1.1.2.6, [200/409], 00:43:22, bgp-65001, internal, tag 65001
*via 1.1.2.7, [200/409], 00:43:22, bgp-65001, internal, tag 65001
*via 1.1.2.8, [200/409], 00:43:22, bgp-65001, internal, tag 65001
via 1.1.2.3, [200/65940], 00:15:17, bgp-65001, internal, tag 65001 <<======= OLD MED 409 not updated
Conditions:
1. IGP (e.g., OSPF) redistributes BGP routes.
2. The redistribution uses route-map to evaluate community associated with the routes.
3. Maximum-paths command is configured.
4. BGP receives paths with only attribute (e.g., AS-PATH,MED) change.
Workaround:
A few possible workarounds:
1. Post-fault (impact low->high): clear ip route , clear ip bgp and restart BGP/IGP process.
2. Do not configure multi-paths (maximum-paths command).
3. Do not use redistribution route-map to match community/other BGP attributes.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 6.1(1) |
|
Known Fixed Releases: | 6.1(4.112)S0, 6.1(5), 6.2(0)HS(0.10), 6.2(7.7)S0, 6.2(8), 6.2(8)CM(0.2), 6.2(9)FM(0.37), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)ZD(1.18) |
|
|
| |
| |
Bug Id: | CSCue95703 |
Title: | Syslog needed when OSPFv3's neigh interface ID changes due to L2 flood |
|
Description: | Symptom:
OSPFv2 / OSPFv3 session in EXCHANGE state that causes unexpected flaps.
Conditions:
Configure OSPFv2 and OSPFv3 on multiple links going through a layer-2 switch.
Workaround:
None.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 6.2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu45553 |
Title: | bfd crash seen with bfd_mts_flush_all_bfdc_msgs decodes |
|
Description: | Symptom:
BFD core seen
Conditions:
During copy config to run config
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu71685 |
Title: | N7k-Fex: Ethpm timed out on port sec with sticky config during bringup |
|
Description: | Symptom:
When member ports of port channels are configured with stick mac and during reload port security is trying to restore the stick mac of all ports causing delay in sending the response to ethpm resulting the ports and port channels to be in down state.
Conditions:
Workaround:
The work around is to un-configure the sticky mac as dynamic Mac learning is highly preferred than sticky. Removing the sticky mac configuration will resolve the sequence timing out issue.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv42487 |
Title: | show tech-support fcoe needs to contain all pertinent FC information |
|
Description: | Symptom:
Enhance show tech-support fcoe so that it includes all FC pertinent information. This should be similar to the MDS show tech-support details
Conditions:
Applicable to the Nexus 7000 switch in the FCoE storage VDC.
Workaround:
Use individual show tech-support commands. For example:
show tech-support zone
show tech-support fcns
show tech-support fcdomain
show tech-support port
etc...
Further Problem Description:
None.
Resolution Summary:
To be completed once resolved.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv43297 |
Title: | Breakout not working in M3 |
|
Description: | Symptom:
Logs attached
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 7.0(0)HSK(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv05083 |
Title: | Vlan learnt SGT mappings not downloaded to HW after module comes online |
|
Description: | Symptom:
On a nexus 7000 series switches, IP to DGT mappings, may not be honored for vlan learnt SGT mappings following a supervisor switchover and a module reload.
Conditions:
Workaround:
clear ip arp x.x.x.x force
will allow the switch to correct the IP-SGT binding .
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur07245 |
Title: | Nexus switch may see repeated crashes of ntpd process |
|
Description: | Symptom:
NTP process may crash repeatedly on a Nexus switch.
Nexus7010# sh core
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
1 5 1 ntpd 19361 2015-01-31 05:18:22
1 5 1 ntpd 19348 2015-01-31 05:18:22
1 5 1 ntpd 19096 2015-01-31 05:18:22
1 5 1 ntpd 21817 2015-01-31 05:30:25
1 5 1 ntpd 21201 2015-01-31 05:31:20
1 5 1 ntpd 21196 2015-01-31 05:31:20
1 5 1 ntpd 21188 2015-01-31 05:31:20
1 5 1 ntpd 21208 2015-01-31 05:31:21
In some cases the cores may not be properly bundled and will pile up in the /var/sysmgr/tmp_logs directory. This may result in messages similar to the following:
2015 Mar 28 00:34:06.644 Switch %SYSMGR-3-VAR_SYSMGR_FULL: System Manager file storage usage is unexpectedly high at 100%. This may impact system functions.
2015 Mar 28 00:40:29.912 Switch %SYSMGR-2-CORE_SAVE_FAILED: zip_copy_file_to_logflash: PID 24109 with message Failed to copy 0x1201_ntpd_core.30892 to logflash. Error file
error (srcerr 0x0 dsterr 0x807b001c) .
2015 Mar 28 00:40:30.057 Switch %SYSMGR-2-CORE_SAVE_FAILED: zip_copy_file_to_logflash: PID 24109 with message Failed to copy 0x1201_ntpd_core.30914 to logflash. Error file
error (srcerr 0x0 dsterr 0x807b001c) .
2015 Mar 28 00:40:30.463 Switch %SYSMGR-3-CORE_OP_FAILED: Core operation failed: core_client_run_system_cmd: Command: /isan/bin/sysmgr_logmgr /var/sysmgr/tmp_logs 0 1>> /var/sysmgr/core_handling.log failed wi
Conditions:
This has been observed on Nexus 5000, 6000, and 7000 series switches.
It is more likely to occur if the device is being polled via IPv6 NTP requests. However, this also affects IPv4-only configurations.
It may also be more likely to occur if an unreachable NTP peer is configured.
Workaround:
If either of the above two conditions are present in the configuration (IPv6 NTP polling, or an unreachable NTP peer) then removing these may make the crash less likely to occur.
However, the only guaranteed workaround would be to disable the NTP feature completely (remove all NTP configuration from the affected switch).
Further Problem Description:
This problem occurs due to memory corruption in a receive buffer in memory which is used by NTP. NTP will crash repeatedly after the corruption occurs.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.25), 7.0(7)ZN(0.108), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(1)N1(0.495), 7.1(1)N1(1), 7.1(1)ZN(0.48), 7.2(0)AB(9) |
|
|
| |
| |
Bug Id: | CSCtz13307 |
Title: | kgdb on udld process while peer-link shut no shut continuously |
|
Description: | Symptom:
A Nexus 5500 switch running NX-OS 5.1(3)N1(1) might reload with kernel
panic.
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 543702 usecs after Wed Feb 1 03:27:24 2012
Reason: Kernel Panic
Service:
Version: 5.1(3)N1(1)
Conditions:
Observed on Nexus5K and Nexus7k as well.
Workaround(s):
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: | 5.1(3)N2(1a), 5.2(4.83)S0, 6.0(4)S1, 6.1(0.280)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuo76751 |
Title: | Port asic in shared mode does not set Don't_fwd and Don't_learn bit |
|
Description: | Symptom:
Symptom 1: Port-channel member interfaces go into an LACP suspended state b/c because they stop sending LACP PDUs.
Symptom 2: Ports may stop learning mac addresses and stop passing traffic
Symptom 3: Ports may stop learning mac addresses but still flood traffic
Conditions:
Symptom 1 & 2 can be seen when a span destination is configured on a port M132 port in shared mode. Other ports in the port-group will set the DL (Don't Learn) and DF (Don't Forward) bit set to ON.
N7K# slot 1 sho hard int mac port 26 state | egrep -i "dont"
dont_forward: ***On***, dont_learn: ***On***
Symptom 3 is seen when the peer-link is on a shared-mode M132 port. MAC learning is disabled on the peer-link by default. Configuring a peer-link member interface on a shared-mode M132 port will disable MAC learning on the other three ports in the port-group.
N7K# slot 1 sho hard int mac port 26 state | egrep -i "dont"
dont_forward: Off, dont_learn: ***On***
These conditions may be triggered by reloading a VDC or flapping an interface (the VDC reload results in a link flap, the link flap triggers the error condition), though it has been seen when no link flap could be confirmed. When the VDC reload is complete the links in the port channel remain in the suspended state since LACP PDUs are not forwarded.
Workaround:
Symptom 1 & 2:
To restore service:
Remove the SPAN and then shut/no shut ports in the port-group
To configure a SPAN destination on a port in shared-mode, enable ingress learning:
switchport monitor ingress learning
Symptom 3:
Do not put the Peer-link member interfaces on an M132 port in shared mode. This is against best-practice and is documented here:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/interfaces/configuration/guide/if_cli/if_vPC.html#pgfId-1803465
Further Problem Description:
Don't_fwd and Don't_learn bits are set only for SPAN configuration and VPC peer-links to disable mac learning.This is a day one issue in all codes prior to 6210. Only M132 and M132-XL line cards are affected by this bug.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.2(8), 6.2(8)S25 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S35, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.232), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.169) |
|
|
| |
| |
Bug Id: | CSCul33530 |
Title: | Apex10: FCOE license is getting installed after reload |
|
Description: | Symptom:
Nexus 7000 shows F2 FCOE license installed even if it was not installed
Example
7710-1# sh lic usa
Feature Ins Lic Status Expiry Date Comments
Count
--------------------------------------------------------------------------------
MPLS_PKG No - Unused -
STORAGE-ENT No - Unused -
VDC_LICENSES Yes 4 In use Never -
FCOE-N7K-F248XP Yes 4 Unused Never 4 license(s) missing
ENHANCED_LAYER2_PKG No - Unused -
TRANSPORT_SERVICES_PKG Yes - Unused Never -
LAN_ENTERPRISE_SERVICES_PKG Yes - Unused Never -
--------------------------------------------------------------------------------
**** WARNING: License file(s) missing. ****
7710-1#
If you do "show file [license file name]" command you will see FCOE license was not installed.
It has been also seen that even if F2 line card in not installed in the system this error is seen.
Conditions:
TRANSPORT_SERVICES_PKG license installed in the system
Workaround:
"clear license sprom" command will clear the problem but it will re-appear after reload
Further Problem Description:
This happens because of an error in the license specfile. Because of overlapping bit positions FCOE is falsely turned on. The license spec file has been fixed. With these specfile after doing "clear license sprom" the problem should not happen.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.2(5.45)S3 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S77, 6.2(10.16)S0, 6.2(10.502)S0, 6.2(11)FM(0.26), 7.1(0)D1(0.278), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCtt41698 |
Title: | NXOS subinf MTU inconsistency |
|
Description: | Symptom:
When changing MTU on main interface, subinterface inherits this MTU as per the
"show interface ethernet x/y.z" command. Although, internally, MTU for subinterface
is still set to default.
Conditions:
Subinterface configuration.
Workaround:
Explicitly configure the non-default MTU on both main and subinterface.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.2(1), 6.0(1) |
|
Known Fixed Releases: | 6.1(0.184)S10, 6.1(0.197)S0, 6.2(0.228)S0, 7.2(0)VZN(0.30) |
|
|
| |
| |
Bug Id: | CSCut47891 |
Title: | NVT: Missing (S,G) between MSDP peers, when there are 4 spine with MSDP |
|
Description: | Symptom:
(S,G) entries are not in between MSDP peers
Conditions:
Four Spine devices configured as MSDP peers
Workaround:
no workaround
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv40883 |
Title: | F3 unexpected reload after span session config |
|
Description: | Symptom:
After enable a span session for a Port-channel source in vPC with N77-F348XP-23 physical port in module 1 and destination port in module 6 (both modules N77-F348XP-23) a core crash is created for both modules. they are restored after reload crash reload.
Conditions:
I saw this problem by the very first time during a customer network troubleshooting.
I reproduced problem on CALO with the next conditions:
HW:
1 x N77-SUP2E
2 x N77-F348XP-23
1 x N77-C7706-FAB-2
1 x N77-C7709
2 VDCs were created , 1 for SPINE Fabric Path VDC 1 for LEAF Fabric Path VDC
Problem occurs on LEAF VDC just after we do 'no shut' under the monitor session config mode
problem was reproduced on 6.2(8a) and 6.2(10)
Workaround:
Further Problem Description:
Cores from 6.2(10)
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437208662_0x102_fln_fwd_usd_log.1178.tar.gz
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437208661_0x802_fln_fwd_usd_log.1178.tar.gz
Cores from 6.2(8a)
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437203676_0x102_fln_fwd_usd_log.1160.tar.gz
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437203675_0x802_fln_fwd_usd_log.1160.tar.gz
|
| Severity: error
| lcfln_n77 - Nexus 7700 platform running 6.2(10)S102 experienced a crash
| at 2015-07-18 08:37:42.
| The decoded stack traces are:
| 0x0ff4a4b0 usd_sse_process_msg
| 0x0ff4a4b0 usd_sse_process_msg ---> usd_sse.c:826
| 0x100673e8 fln_fwd_sse_hdlr ---> fln_fwd_services.c:9067
| 0x0ff5bf48 usd_handle_event ---> usdw_main.c:344
| 0x0ff5c4cc usd_loop ---> usdw_main.c:466
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus72364 |
Title: | N7K BFD brings down additional BFD peers - bfd optimize subinterface |
|
Description: | Symptom:
N7K BFD brings down additional BFD peers
When shutting one of the links, BFD session on another link also flaps. Both are sub-interfaces with "bfd optimize subinterface" feature enabled.
Conditions:
sub-interfaces with "bfd optimize subinterface" feature enabled.
Code- 6.2(8a) and will be seen on versions greater than 6.2.8 if config is saved in 6.2.8 and reloaded with upgraded images (like 6.2.10/12 etc)
Mod 9 - N7K-M224XP-23L
Mod 3 - N7K-F248XP-25E
Workaround:
After that unexpected flap - BFD re-establishes the session.
Work Around in 6.2.10 or later is to remove "bfd optimize sub-interface" config from interfaces and reapply them.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a) |
|
Known Fixed Releases: | 6.2(13.11)S0 |
|
|
| |
| |
Bug Id: | CSCun93402 |
Title: | PIM process leaking memory |
|
Description: | Symptom:
A Cisco Nexus switch may see a memory leak in the PIM process. The following command can be used to examine the memory being used by the PIM process:
show ip pim internal mem-stats detail
A sign of this leak is to see the PIM_MEM_RPF_SOURCE_IPC allocations growing without bound.
Conditions:
The current conditions to trigger the leak are unknown at this current time.
Workaround:
There is no workaround at this time. If the process in question consumes all of the allowed memory pim functions and commands may cease to work. If the process does not crash TAC can kill the process manually which will allow the process to restart and become operational.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.0(2)N3(0.111), 6.0(2)N3(1), 6.2(0)HS(0.10), 6.2(8), 6.2(8)S10, 6.2(8.5), 7.0(0)BNZ(0.23), 7.0(0)KM(0.64), 7.0(1)ZD(0.267), 7.0(1)ZN(0.581) |
|
|
| |
| |
Bug Id: | CSCuu10841 |
Title: | NXOS RPM crash due to the CLI "show ip prefix-list | xml" |
|
Description: | Symptom:
%SYSMGR-2-SERVICE_CRASHED: Service "rpm" (PID 4664) hasn't caught signal 11 (core will be saved).
Conditions:
In NXOS code 6.2.(12), running CLI "show ip prefix-list | xml" will cause RPM crash in case the prefix-list is not existing.
Workaround:
TBD
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E6, 6.2(13.3)S0, 6.2(14)FB(0.57) |
|
|
| |
| |
Bug Id: | CSCuu72468 |
Title: | UDLD-4-UDLD_SFP_TYPE_CHANGED: User changed SFP type from fiber to copper |
|
Description: | Symptom:
Switch may report below message when interface comes up although no changes are made:
%UDLD-4-UDLD_SFP_TYPE_CHANGED: User changed SFP type on Ethernet7/6 from fiber to copper, default udld port configuration was applied, 'copy running-config startup-config' recommended
Issue seen at least on CFP and CPAK transceivers, includes fix for 10Gbase-CX in X2 form-factor
Conditions:
Linkflap seems to trigger this message.
Workaround:
No known workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(14)FB(0.78) |
|
Known Fixed Releases: | 6.2(13.4)S0, 7.2(1)D1(0.14), 7.2(1)ZD(0.10) |
|
|
| |
| |
Bug Id: | CSCuo28456 |
Title: | N7K: ospf select wrong next-hop when redistribute route in NSSA area |
|
Description: | Symptom:
External routes in OSPF are installed over a NSSA area (instead of backbone area).
Conditions:
In case, there is reachability of OSPF external prefixes in both NSSA area and the backbone area, OSPF will install routes over those prefixes over the NSSA area.
Example topology:
area 0
N7K-1-----------N7k-2--lo1
(ABR) (ABR/ASBR)
| |
| area 1 |
| nssa |
| |
4948-1----------4948-2
The problem only occurs if one of the links between the ABRs is in the backbone
area and another is in a NSSA area. Only releases 6.2.x/7.0.x are affected by this, and prior releases are unaffected.
Workaround:
There are the following workarounds for this bug:
(1) Configure a lower-cost, normal non-backbone area adjacency between the 2 ABRs.
(2) Configure the link between the 2 ABRs as P2P, and add a multi-area link.
For example, in the topology below, the link between the 2 N7K ABRs is P2P and both in area0, and multi-area 10 at the same time.
Multi-area 10
--------------------
| area 0 |
N7K-1-----------N7k-2--lo1
(ABR) (ABR/ASBR)
| |
| area 1 |
| nssa |
| |
4948-1----------4948-2
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.2(2a) |
|
Known Fixed Releases: | 6.1(2)I3(1.22), 6.1(2)I3(2), 6.2(10), 6.2(10)CM(0.28), 6.2(8)TS(0.28), 6.2(9.3)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.191), 7.1(0)FC(0.2) |
|
|
| |
| |
Bug Id: | CSCuv44868 |
Title: | L2FMC is not in the card config of M3 VMM bind/unbind |
|
Description: | Symptom:
VDC pointer not cleared after vdc reload from mtm db
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 7.0(0)HSK(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur32209 |
Title: | LDP should not remove/free entries while walking the xos radix tree |
|
Description: | Symptom:
LDP can encounter memory corruption or process crash.
Conditions:
Because of the nature of the bug, the problem can happen at any point, unexpectedly.
Workaround:
No workarounds.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 7.1(0)ZD(0.341) |
|
Known Fixed Releases: | 6.2(10)E5, 6.2(13.3)S0, 6.2(14)FB(0.65), 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.119), 7.1(0)AV(0.38), 7.1(0)ES(0.7), 7.1(0)EV(0.125) |
|
|
| |
| |
Bug Id: | CSCus42713 |
Title: | 2014 and 2015 OpenSSL Vulnerabilities |
|
Description: | Symptom:Cisco NX-OS (Covering Nexus 5K, N6K and N7K and Cisco MDS) includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE)
IDs:
CVE-2014-3569, CVE-2014-3570, CVE-2014-3571, CVE-2014-3572, CVE-2014-8275,
CVE-2015-0204, CVE-2015-0205, CVE-2015-0206
This bug has been opened to address the potential impact on this product.
Conditions:This device has a vulnerable version of OpenSSL, this bug is being used to update the OpenSSL package used on the product.
Product doesn't support DTLS so is not affected by either:
CVE-2014-3571
CVE-2015-0206
The LDAP SSL authentication feature may be configured to use OpenSSL. This feature is disabled by default. Hence, this vulnerability only exists if the LDAP SSL Authentication feature is enabled.
Workaround:1. Nexus 5000 (N5K) : The following features can use SSL and would need to
be disabled.
a) Avoid any "fabric database" configuration with keyword "enable-ssl".
For example:
fabric database type network
server protocol ldap ip 172.29.21.2 enable-ssl
b) Make sure the 'secure LDAP' option is unchecked when defining POAP
template on DCNM.
c) Do not use Cisco's One Platform Kit (OnePK) with the transport type tls
..." open.
d) Remove the VM Tracker Configuration.
2. Nexus 7000 (N7K) : The LDAP feature uses Open SSL. To disable the LDAP
SSL Authentication feature. LDAP can be disabled or used without SSL
Authentication.
More Info: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.6
http://tools.cisco.com/security/center/cvssCalculator.x?version=2.0&vector=AV:N/AC:M/Au:N/C:P/I:N/A:N/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 Ciscos security vulnerability policy can be
found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.2(8f), 6.2(10), 6.2(11), 6.2(7), 6.2(8)S3, 6.2(8a), 7.2(0)VX(0.9), 7.2(0.1)PR(0.1), 7.3(0.9), 9.9(0)XS(0.1) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.52), 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.504), 7.2(0)D1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCus56648 |
Title: | EIGRP crash in ipigrp2_get_tmap_distance |
|
Description: | Symptom:
EIGRP crash in ipigrp2_get_tmap_distance
Conditions:
Crash is seen with table map if redistributed route is learnt when the corresponding dndb is active
Workaround:
Unconfigure table-map
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 7.1(0)IB(103) |
|
Known Fixed Releases: | 6.2(13.12)S0, 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)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) |
|
|
| |
| |
Bug Id: | CSCuu16775 |
Title: | NVE config is missing after doing ISSU from 7.1(1)N(1a) to 7.2 |
|
Description: | Symptom:
VXLAN traffic will get dropped due to missing Network virtualization interface (interface nve) configuration.
Conditions:
Vxlan feature configured on Nexus OS version 7.1.x and upgrading from this version to Nexus OS version 7.2.
Workaround:
Copy the saved running-configuration to switch's running configuration using the command "copy running-config". This will restore the missing configuration related to nve interfaces. Since other parts of configuration already existed prior to the operation of copying save file to running-config, certain warnings will be displayed. These warnings can be ignored.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.191) |
|
Known Fixed Releases: | 7.2(1)N1(0.263), 7.2(1)N1(1), 7.2(1)ZN(0.27) |
|
|
| |
| |
Bug Id: | CSCue02901 |
Title: | Logging server shows unreachable, syslog not delivered |
|
Description: | Symptom:
show logging server output shows the following text for a logging server:
'This server is temporarily unreachable'
While ping to the same server IP / hostname is successful.
Conditions:
Workaround:
Run following commands:
DC1-4(config)# no logging server 172.28.92.10 7 use-vrf management facility local6
DC1-4(config)# logging server 172.28.92.10 7 facility local6
DC1-4(config)# logging source-interface loopback 0
Configuring logging source-interface will open UDP/syslog socket(514).
DC1-4(config)# logging server 172.28.92.10 7 use-vrf management facility local6
DC1-4(config)# no logging source-interface loopback 0
UDP/syslog socket(514) is being closed.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.2(7), 6.1(2) |
|
Known Fixed Releases: | 6.0(2)U2(2.29), 6.0(2)U2(3), 6.0(2)U3(0.617), 6.0(2)U3(1), 6.0(2)U4(0.60), 6.0(2)U4(1), 6.2(5)BF(0.24), 6.2(5.42)S0, 6.2(6) |
|
|
| |
| |
Bug Id: | CSCuo85450 |
Title: | Nexus 5K/6000 crash with arp hap reset |
|
Description: | Symptom:
A Nexus 5K/6000 switch might reload with following hap reset:
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 141764 usecs after Wed May 14 03:21:41 2014
Reason: Reset triggered due to HA policy of Reset
Service: arp hap reset
Version: 7.0(1)N1(1)
Conditions:
Gratuitious ARP storms are suspected as the trigger for this issue.
Workaround:
Identify source of ARP storm and stop it.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(2) |
|
Known Fixed Releases: | 6.0(2)A5(0.943), 6.0(2)A5(1), 6.0(2)U5(0.943), 6.0(2)U5(1), 6.2(10), 6.2(10)S40, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(1)ZD(0.248) |
|
|
| |
| |
Bug Id: | CSCuq22831 |
Title: | Crash in snmpd process due to heartbeat failure after netstack hogs CPU |
|
Description: | Symptom:
The snmpd process crashed multiple times triggering a HAP-Reset:
----- reset reason for Supervisor-module 5 (from Supervisor in slot 5) ---
1) At 885418 usecs after Fri Jul 25 08:21:03 2014
Reason: Reset triggered due to HA policy of Reset
Service: Service "snmpd" in vdc 2 hap reset
Version: 6.1(3)
Conditions:
This occurs while polling interface counter statistics via SNMP.
Workaround:
Slowing down the interval of SNMP polling should help reduce the odds of hitting the issue. Disabling SNMP altogether should prevent the issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | 6.1(2)I3(2.39), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 6.1(5)E1, 6.2(10), 6.2(10)S48, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(3)I1(0.248) |
|
|
| |
| |
Bug Id: | CSCuj57803 |
Title: | dcos-telnetd process crash |
|
Description: | Symptom:
A device running NXOS may see the dcos-telnetd process crash
Conditions:
This is seen running large commands, like show tech.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.0(2)N3(0.340), 6.0(2)N3(0.89), 6.0(2)N3(1), 6.2(5)BF(0.27), 6.2(5.42)S0, 6.2(6), 7.0(0)ZN(0.60), 7.0(1)N1(0.135), 7.0(1)N1(1), 7.0(1)ZN(0.193) |
|
|
| |
| |
Bug Id: | CSCur77280 |
Title: | N6k m2rib missing interfaces from OIFL |
|
Description: | Symptom:
Multicast/broadcast packet drops on certain vlans.
Conditions:
After flapping several links or recreating fabricpath vlans in specific order.
Workaround:
Remove and add back vlan, trying to start from the spines and then going to the leafs.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.81) |
|
Known Fixed Releases: | 7.0(1)ZN(0.736), 7.0(6)N1(0.236), 7.0(6)N1(0.4), 7.0(6)N1(1) |
|
|
| |
| |
Bug Id: | CSCur08379 |
Title: | DOC: N7k Macsec is not supported on vPC/vPC+ in 5.x |
|
Description: | Symptom:
Documentation for Macsec support is wrong. Configuration guide for 5.x doesn't mention this limitation.
Conditions:
Macsec on vPC/vPC+ on Nexus 7k in 5.x
Workaround:
Use non vPC/vPC+ setup
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.3(2)S4 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu38580 |
Title: | 7.2.0.506.S2 UI - congestion on F2 LC after vdc reload |
|
Description: | Symptom:
Applicable to all F2 (Clipper/Clipper CR) based cards.
Congestion seen on ingress traffic on some/all of the ports. This is because, frames are stuck in the IB caused due to bad acos to ccos table.
To confirm if the issue is due to bad table, please compare the acos to ccos mapping in the below commands
show hardware internal qengine inst x vq acos_ccos_4cl/acos_ccos_8cl
compare it with the ccos mapping in
show hardware internal qengine inst x table fr_dcx4q_oq_ccos/fr_dcx8q_oq_ccos
if the acos to ccos mapping are different, then the Credit Loop logic will affected and frames will be stuck in the IB resulting in congestion on the ingress ports.
Conditions:
Do ISSU and then VDC reload (VDC containing ports from F2 LC).
This is because, the shadow memory in our Qengine driver was corrupted during ISSU and VDC reload causes a shadow refresh to the HW.
Workaround:
Workaround1(preferred as less traffic interrupt):
Copy the Applied network QoS Template:
1) find the applied tempalte
show policy-map system
Type network-qos policy-maps
============================
policy-map type network-qos default-nq-8e-policy template 8e
class type network-qos c-nq-8e
match cos 0-7
congestion-control tail-drop threshold burst-optimized
mtu 1500
2) Copy:
qos copy policy-map type network-qos default-nq-8e-policy prefix Copy_
3) Apply Ciopy to trigger reporgramming:
switch(config)# system qos
switch(config-sys-qos)# service-policy type network-qos Copy_nq-8e
4) Optional: Reapply back the previous template
switch(config)# system qos
switch(config-sys-qos)# service-policy type network-qos default-nq-8e-policy
Note: Applicable for any networkqos template. During Template Change traffic on All VDC which contain F cards will be disrupted for less than a Second
Workaround2: reload the LC after ISSU or
Workaround3: reload the LC after VDC reload
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.506) |
|
Known Fixed Releases: | 6.2(13.4)S0, 7.0(0)FFW(0.7), 7.0(0)HSK(0.474), 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)ZD(0.202), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCus71454 |
Title: | PVLAN VPC: peer-link flap causes primary legs in PVLAN host mode to flap |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.2(12)S29 |
|
Known Fixed Releases: | 6.2(13.18)S0 |
|
|
| |
| |
Bug Id: | CSCuv46246 |
Title: | various vpc crashes in core after linecard having peer-link crashed |
|
Description: | Symptom:
various vpc crashes in core after linecard having peer-link crashed/reload.
Conditions:
card having peerlink crashed.
Workaround:
N.A.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut68515 |
Title: | SSTE: multiple port-profile cores with 7.2(0)D1(0.456) on autoconfig |
|
Description: | $$IGNORE
Symptom:
port-profile crash & switch hap reset.
Conditions:
auto config
Workaround:
NA
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.456), 7.2(0)D1(0.490) |
|
Known Fixed Releases: | 7.0(0)FFW(0.7), 7.0(0)HSK(0.474), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)D1(0.499), 7.2(0)D1(0.506), 7.2(0)D1(0.509), 7.2(0)D1(1), 7.2(0)ZD(0.188), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCtz29341 |
Title: | N7k M1/F2 module ports stuck in init state and error disable |
|
Description: | Symptom:
Nexus 7000 using M1 or F2 series linecards may experience ports stuck in initializing state following a switch reload. After some time the port may go error disabled due to a sequence timeout. The following errors will be reported for the affected interfaces:
%ETHPORT-5-IF_SEQ_ERROR: Error ("sequence timeout") communicating with for opcode (RID_PORT: Ethernet2/48)
%ETHPORT-5-IF_DOWN_ERROR_DISABLED: Interface Ethernet2/48 is down (Error disabled. Reason:sequence timeout)
If the Peer Keep-alive is affected the Peer-link and VPCs will remain down.
Workaround:
A temporary workaround is reload the affected switch
--or--
Power off the impacted modules and fail over the supervisor. Once the failover is complete, power on the modules
A long term workaround to ensure the Peer Keep-Alive is not impacted is to move the Peer Keep-Alive over the management interface.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | 5.2(4.79)S0, 6.1(0.277)S0 |
|
|
| |
| |
Bug Id: | CSCuq46564 |
Title: | SSTE:LDP core observed after process restart LDP with 7.1(0)D1(0.232) |
|
Description: | Symptom:
LDP crashes due to heartbeat failure following a proc restart of LDP.
Conditions:
Happens when user does a proc restart of LDP.
Workaround:
No workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.232) |
|
Known Fixed Releases: | 6.2(10)E5, 6.2(13.3)S0, 6.2(14)FB(0.65), 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)OTT(0.45), 7.2(0)D1(0.417) |
|
|
| |
| |
Bug Id: | CSCum18198 |
Title: | restrictions for wccp redirect access-list and such other limitations |
|
Description: | Symptom:
restrictions for wccp redirect access-list and such other limitations
Conditions:
restrictions for wccp redirect access-list and such other limitations
Workaround:
restrictions for wccp redirect access-list and such other limitations
Further Problem Description:
restrictions for wccp redirect access-list and such other limitations
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.2(6)S9 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu34174 |
Title: | UIN-1::After switch reload macs are not in sync between VPC peers |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.506) |
|
Known Fixed Releases: | 7.3(0)PDB(0.15) |
|
|
| |
| |
Bug Id: | CSCuu08730 |
Title: | DAI: ARP Response dropped when the local vPC leg is down |
|
Description: | Symptom:
A nexus 7000 series switch in a vpc/vpc+ environment configured for dynamic arp inspection may drop arp replies targetted to itself under certain conditions
Conditions:
- The local vpc leg is down causing the arp reply to be sent to the peer and tunneled to the switch that sent the arp request.
- The vpc is trusted for dynamic arp inspection
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 7.2(0)N1(0.217) |
|
Known Fixed Releases: | 6.2(10)E3, 6.2(13.11)S0, 7.0(0)FFW(0.7), 7.0(0)HSK(0.474), 7.0(0)KM(0.138), 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)N1(1), 7.2(0)ZD(0.199), 7.2(0)ZN(0.218) |
|
|
| |
| |
Bug Id: | CSCuv42308 |
Title: | MST Disputes VPC peer-switch secondary peer sending cost of 250 |
|
Description: | Symptom:
STP/MST disputes downstream from vPC domain with peer-switch
Conditions:
vpc peer-switch configured, this was noticed with MST, unaware if it also affects PVST
Workaround:
Remove "peer-switch" from secondary peer sending incorrect root cost value and re-add peer-switch
Further Problem Description:
If this is encountered, please gather the following from both N7K's and engage TAC:
# show tech detail
# show tech vpc
# show tech stp
# show tech l2fm detail
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq34116 |
Title: | N7K-F248XT-25E interfaces fail PortLoopback test and fail to initialize |
|
Description: | Symptom:
Interfaces on an N7K-F248-XT-25E fail to initialize.
- Gaurdian is in stuck state.
- Shut / no shut of the interface does not help.
- Not easily reproducible.
- Once we reload the LC, issue goes away.
- So this is very rare and intermittent case.
Conditions:
N7K-F248-XT-25E running 6.2(x)
Workaround:
Reload the impacted line card
Further Problem Description:
The interface in question will fail the port loopback diagnostic test. However, if you were to check the exception log for the module you will see the following exception being raised for the interface:
n7k# sh module internal exceptionlog module 5
********* Exception info for module 5 ********
exception information --- exception instance 1 ----
Module Slot Number: 5
Device Id : 143
Device Name : Port-Client
Device Errorcode : 0xc8f0c269
Device ID : 143 (0x8f)
Device Instance : 12 (0x0c)
Dev Type (HW/SW) : 02 (0x02)
ErrNum (devInfo) : 105 (0x69)
System Errorcode : 0x42370069 GD link down
Error Type : Minor error
PhyPortLayer : Ethernet
Port(s) Affected : Ethernet5/13
Error Description : send_exp_info: Operational param config failed in port client linkup handler port: 12 error 0x42370069
DSAP : 0 (0x0)
UUID : 323 (0x143)
Time : Wed Jul 9 09:43:16 2014
(Ticks: 53BD5504 jiffies)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.2(2), 6.2(6), 6.2(6a), 6.2(6b), 6.2(8a) |
|
Known Fixed Releases: | 6.2(12)E6, 6.2(13.3)S0, 6.2(14)FB(0.28), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)D1(0.469), 7.2(0)D1(1), 7.2(0)PDB(0.394), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCup66750 |
Title: | BGP routes not advertised after "default address-family ipv4/6 unicast" |
|
Description: | Symptom:
Nexus 7k running with version 6.1.5 and 6.2.8 stops advertising the routes to neighboring peer as soon "default address-family ipv4/6 unicast" is issued under the neighbor statement.
router bgp xxxx
csw06d.lla1(config-router)# neighbor 10.46.177.47
csw06d.lla1(config-router-neighbor)# default address-family ipv6 unicast
csw06d.lla1(config-router-neighbor)# default address-family ipv4 unicast
end
Conditions:
Happens only when "default address-family ipv6 unicast" is issued under the neighbor statement for BGP.
Workaround:
Clear ip bgp soft * resolves the issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.1(5) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.39), 7.0(3)I2(0.406), 7.0(3)I2(1), 7.2(1)D1(0.29), 7.2(1)N1(0.264), 7.2(1)N1(1), 7.2(1)ZD(0.24), 7.2(1)ZN(0.28), 8.3(0)CV(0.72) |
|
|
| |
| |
Bug Id: | CSCuv42949 |
Title: | Nexus 7k Crashes due to "isis_otv-default" Process |
|
Description: | Symptom:
Nexus 7k crashed due to the "isis_otv-default" process multiple times in quick succession. If redundant supervisor engines are installed, both may crash within a short timeframe of one another, leading to a full chassis reset if the switch briefly has no ready active supervisor.
Conditions:
None known. May be caused by OTV depolarization feature, but uncertain at this point.
Workaround:
None known.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup13175 |
Title: | SSTE: LDP core while doing SSO and LC reload |
|
Description: | Symptom:
LDP process crashes during cleanup. This mostly happens during the clean-up stage, when user unconfigures LDP or interfaces used by LDP go down.
Conditions:
During cleanup, if two threads access/modify the same resource, LDP may crash.
Workaround:
There is no workaround for this fix.
Further Problem Description:
LDP uses cross-OS radix tree API which is not thread safe. Issue happens when one thread modifies the tree, while another is reading it, resulting in memory corruption and crash of LDP process.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.2(10)S82, 7.1(0)D1(0.151), 7.1(0)D1(0.188), 7.1(0)D1(0.196), 7.1(0)D1(0.228), 7.1(0)D1(0.240) |
|
Known Fixed Releases: | 6.2(10)E5, 6.2(13.3)S0, 6.2(14)FB(0.65), 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.251), 7.1(0)D1(0.262), 7.1(0)N1(0.313), 7.1(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuv42813 |
Title: | aclmgr crashes with unknown trigger |
|
Description: | Symptom:On ISSU upgrading from 6.2.8a to 6.2.12 S33 image with ACL config, it was noticed that multiple acl_mgr process crash and eventual vdc_reload.
Conditions:This happens when some of ACL config internal data structure which get stored in PSS is not ISSU proof. Due to this later release ACL_MGR process reads it resulting in non-interpreting correctly and crashes.
Workaround:Either loading 6.2.12 S33 directly or do "write erase" of startup-config followed ASCII replay to restore config.
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup96876 |
Title: | N7K FIB Entry Miss-programmed into wrong SPL Bank |
|
Description: | Symptom:
Traffic to a subset of hosts is punted to the CPU and either forwarded in software or dropped.
Conditions:
ISSU from 6.2(8) to 6.2(8a)
ISSU from older releases to 6.2(8) or 6.2(8a)
Problem specific to M1-XL or M2 (Does not apply to F2/F3)
Workaround:
Reload the affected linecard
Further Problem Description:
This occurs when the FIB entry is programmed in the wrong SPL bank. As a result, the longest prefix match is not hit and traffic is punted for an ARP glean.
For example, a host exists in a /24 subnet. Checking 'show ip route' to the host will show a /32 installed in the RIB. However, checking the longest prefix match in hardware will show the /24 route.
N7K-1# show system internal forwarding ipv4 route 172.22.31.173 module 7
Routes for table default/base
----+---------------------+----------+----------+------+-----------
Dev | Prefix | PfxIndex | AdjIndex | LIFB | LIF
----+---------------------+----------+----------+------+-----------
1 172.22.31.0/24 0x423e 0xa2cb 0 0x1ff8b <------hardware only finds the /24 entry
Note, the /32 entry is present in hardware but since it is programmed in the wrong bank it will always hit the /24 entry.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S55, 6.2(10)S56, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.258), 7.1(0)OTT(0.34), 7.1(0)PDB(0.196), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCut18721 |
Title: | gbr_422: urib core at urib_chlist_segv_handler |
|
Description: | Symptom:
urib crashes and since it is not restartable, the crash will result in reload of the switch in single SUP scenario or will result in SSO when dual SUP is present.
Conditions:
Inter VRF case where routes in one VRF are pointing to next hops in different VRF.
Workaround:
no workaround
Further Problem Description:
This issue mainly happens when routes are being flapped in large scale by BGP due to multiple restart or some other reasons or repeated execution of "clear ip route *".
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.422), 7.2(0)D1(0.444) |
|
Known Fixed Releases: | 6.2(10)E8, 6.2(12)E1, 6.2(13.3)S0, 6.2(14)FB(0.28), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)SIB(99.109), 7.1(2)N1(0.571), 7.1(2)ZD(0.22), 7.1(2)ZN(0.30) |
|
|
| |
| |
Bug Id: | CSCur32142 |
Title: | mcast traffic blackhole for upto 4min as assert cancel not sent by winne |
|
Description: | Symptom:
Multicast traffic blackhole for up to 4 minutes
Conditions:
If more than one router forwards traffic onto a LAN - in initial bootup phase or when 'ip multicast multipath' command is configured - PIM assert election happens and one router becomes the winner. This could be the non-PIM-DR having a PIM receiver. There may also be local IGMP receivers on this LAN.
Now, if the winner receives a PIM Prune message and no other PIM receivers exist on that LAN, the winner should send an assert cancel message, to conclude the election and let the PIM-DR on the LAN forward for local receivers.
Under certain circumstances, the winner does not always send out the assert cancel thereby causing traffic blackhole until the loser router ages out the winner's assert message. This could take up to 4 minutes.
Workaround:
clear ip mroute
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S102, 7.1(0)D1(0.324) |
|
Known Fixed Releases: | 6.2(13.5)S0, 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)D1(0.325), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283), 7.1(0)SIB(99.68), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup52842 |
Title: | bgp flapping with fd read error |
|
Description: | Symptom:
014 Jun 20 18:32:24.386535 bgp: 64896 [9115] (default) EVT: 172.23.96.107 peer connection retry timer expired
2014 Jun 20 18:32:24.386607 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Triggered active open for peer
2014 Jun 20 18:32:24.387329 bgp: 64896 [9115] (default) EVT: 172.23.96.107 went from Idle to Active (Active setup)
2014 Jun 20 18:32:24.388533 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Schedule wait for connect
2014 Jun 20 18:32:24.388563 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Wait (30 sec) for session setup response
2014 Jun 20 18:32:24.850982 bgp: 64896 [9115] (default) EVT: 172.23.96.107 connect to peer is successful
2014 Jun 20 18:32:24.851013 bgp: 64896 [9115] (default) EVT: 172.23.96.107 sending OPEN message to peer
2014 Jun 20 18:32:24.851060 bgp: 64896 [9115] (default) EVT: 172.23.96.107 went from Active to OpenSent (Active setup)
2014 Jun 20 18:32:24.851101 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Wait (30 sec) for session setup response
2014 Jun 20 18:32:24.851498 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Process OPEN message from peer
2014 Jun 20 18:32:24.851573 bgp: 64896 [9115] (default) EVT: 172.23.96.107 went from OpenSent to OpenConfirm (Active setup)
2014 Jun 20 18:32:24.851617 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Wait (30 sec) for session setup response
2014 Jun 20 18:32:24.852853 bgp: 64896 [9115] (default) EVT: 172.23.96.107 went from OpenConfirm to Established (Active setup)
2014 Jun 20 18:32:24.852898 bgp: 64896 [9115] (default) EVT: 172.23.96.107 cleaning up active peer setup, thread id 0x0
2014 Jun 20 18:32:24.852991 bgp: 64896 [9115] (default) EVT: 172.23.96.107 went from Idle to Established
2014 Jun 20 18:32:24.853018 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Scheduling peer 172.23.96.107 for soft refresh out
2014 Jun 20 18:32:25.867395 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] 172.23.96.107 [peer index 245]
2014 Jun 20 18:32:25.879017 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Adding peer 172.23.96.107 for update gen
2014 Jun 20 18:32:25.879032 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Insert marker dest 0xe1525d64 into xmitlist for 172.23.96.107 with 0 routes on new list and 10475 routes on Tx list
2014 Jun 20 18:32:26.652 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Mark AF update completion for peer 172.23.96.107 (sent prefixes: 4670)
2014 Jun 20 18:32:27.054140 bgp: 64896 [9115] (default) EVT: Read error from peer 172.23.96.107: Broken pipe
2014 Jun 20 18:32:27.054221 bgp: 64896 [9115] (default) EVT: Reset by us (fd read error) in session to 172.23.96.107, value 187, state was Established
2014 Jun 20 18:32:27.054242 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Stopping keepalive, hold timers, peer state Established
2014 Jun 20 18:32:27.054261 bgp: 64896 [9115] (default) EVT: peer:172.23.96.107, state: Established, peer GR STATE: none, AF GR state: none, saved flags: 0
2014 Jun 20 18:32:27.054275 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] 172.23.96.107 Close AF session, gr state none saved flags 0
2014 Jun 20 18:32:27.054290 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Requesting cleanup thread to delete/stale routes for peer 172.23.96.107, with index 245
2014 Jun 20 18:32:27.054303 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Requ
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 6.2(8)S33, 6.2(9), 7.1(0)D1(0.169) |
|
Known Fixed Releases: | 6.1(2)I3(2.42), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 6.2(10), 6.2(10)S18, 6.2(8)E9, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(3)I1(0.248) |
|
|
| |
| |
Bug Id: | CSCur00089 |
Title: | vdc-admin on N7K can break out of vsh-"chroot" using symbolic links |
|
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:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:P/I:P/A:N/E:F/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(13.4)S0, 6.2(14)FB(0.74), 7.2(1)D1(0.30), 7.2(1)ZD(0.25), 7.3(0)IB(0.17) |
|
|
| |
| |
Bug Id: | CSCuu82356 |
Title: | Evaluation of n7k-infra for OpenSSL June 2015 |
|
Description: | Symptom:
This product includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-1788
CVE-2015-1789
CVE-2015-1790
CVE-2015-1792
This bug has been opened to address the potential impact on this product.
Conditions:
NXOS uses OpenSSL 0.9.8 release and is vulnerable.
Workaround:
Nexus 7000 (N7K) : The LDAP feature uses Open SSL. To disable the LDAP
SSL Authentication feature. LDAP can be disabled or used without SSL
Authentication.
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
Please check IMPACT_ASSESSMENT attachment for more details.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUL-2015 |
|
Known Affected Releases: | 7.3(0)ZD(0.9) |
|
Known Fixed Releases: | 6.2(13.6)S0, 7.2(1)D1(0.17), 7.2(1)D1(0.22), 7.2(1)D1(0.23), 7.2(1)N1(0.248), 7.2(1)N1(0.255), 7.2(1)N1(1), 7.2(1)ZD(0.13), 7.2(1)ZD(0.17), 7.2(1)ZD(0.18) |
|
|
| |
| |
Bug Id: | CSCuv29391 |
Title: | SNMPD crash on n5k |
|
Description: | Symptom:
SNMPD crashes on N5K switches.
Conditions:
With..
Hardware: N5K-C5548UP-B-S32
Software: 7.1(0)N1(1b)
Workaround:
na
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.28), 7.2(1)N1(0.263), 7.2(1)N1(1), 7.2(1)ZD(0.23), 7.2(1)ZN(0.27) |
|
|
| |
| |
Bug Id: | CSCus76724 |
Title: | NVT-DC1:PVLAN traffic block-hole upon Primary VLAN remove/add |
|
Description: | Symptom:
On M1XL linecards, when some vlan config causes a private-vlan association to be non-operational , private-vlan trunk secondary port sees traffic loss. Similarly, when the trunk association is unconfigured and re-configured on private-vlan trunk-secondary port, the issue might be observed.
Conditions:
This issue is seen on M1XL linecards. Will not be seen with M1 and F-series line cards
Example config and trigger:
Config:
switch(config-if)# show running-config interface e3/3
!Command: show running-config interface Ethernet3/3
!Time: Wed Feb 4 00:38:51 2015
version 6.2(12)
interface Ethernet3/3
switchport
switchport mode private-vlan trunk secondary
switchport private-vlan association trunk 2 3
no shutdown
The issue will be seen after any of the following triggers
1. Delete and recreate of primary vlan
switch(config-if)# no vlan 2
switch(config)# vlan 2
switch(config-vlan)# private-vlan primary
switch(config-vlan)# private-vlan association 3
switch(config-vlan)# ex
2. Delete and recreate secondary vlan
switch(config-if)# no vlan 3
switch(config)# vlan 3
switch(config-vlan)# private-vlan isolated
switch(config-vlan)# ex
3. Delete and re-add trunk association on the port
switch(config)# int e3/3
switch(config-if)# no switchport private-vlan association trunk 2 3
switch(config-if)# switchport private-vlan association trunk 2 3
Workaround:
Workaround is to do a shut no-shut on the port or PC or VPC leg where the issue is observed
switch(config)# int e3/3
switch(config-if)# shutdown
switch(config-if)# no shutdown
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 6.2(12)S32 |
|
Known Fixed Releases: | 6.2(13.11)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.439), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.364), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCuc23279 |
Title: | SYSTEST:FCoE:core detected due to hwclock crash on standby sup |
|
Description: | Symptom:
Core detected due to hwclock crash on standby sup.
Conditions:
None
Workaround(s):
No impact reported.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 6.1(2), 6.1(2)S11, 6.1(2)S41, 6.1(4a)S14, 6.2(1.42), 6.2(1.59)S2, 6.2(1.59)S5, 6.2(1.69), 6.2(1.69)S5, 6.2(1.83)S5 |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(5.9)S0, 6.2(0.304), 6.2(1.72)S0, 6.2(1.84)S0, 6.2(2), 7.0(0.7), 7.1(0)D1(0.14) |
|
|
| |
| |
Bug Id: | CSCuv37216 |
Title: | Callhome messages via HTTP transport is not sent due to L3VM error |
|
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.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 7.3(0)SLN(0.28) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtw72949 |
Title: | Slow drain of udp sock mts buffers for some bulk requests in bridge-mib |
|
Description: | Symptom:
On nexus 7000 series switch, polling at a sustained rate certain objects from
bridge-mib may cause a relatively high cpu for snmpd for some time after polling and new requests to time out.
On pre 5.2 NX-OS versions, this polling may cause internal messages for inter
process communications to be queued and affect other services.
This problem is also observed on Nexus 5xxx switch running 5.2 release. The fix
for this issue is in 5.2(1)N1(4) release of the 5k and 6.0(2)N1(2a) and later releases.
Conditions:
A large amount of SNMP access to the device against BRIDGE-MIB
Workaround:
Reduce the amount of SNMP traffic to a acceptable level.
If using Orion or Solarwinds Network Management Server uncheck option
Topology: L2.
Further Problem Description:
Problem exists in 5.2(1-3), 6.0(x) and earlier releases on Nexus 7000 switch.
Fixes had been integrated in 5.2(4), 6.1(1), 6.2(2) and later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 5.1(4), 5.2(1), 6.2(0.1) |
|
Known Fixed Releases: | 5.2(1)N1(4), 5.2(4)S3, 5.2(4.10)S0, 5.2(4.4)S0, 6.0(2)N1(2a), 6.0(2)N2(1), 6.0(2)U3(0.599), 6.0(2)U3(1), 6.1(0.205)S0, 6.1(0.209)S0 |
|
|
| |
| |
Bug Id: | CSCuo73479 |
Title: | F348XP:1Gig interface remain up with copper SFP and cable pulled out |
|
Description: | Symptom:
Interface is remaining in "up/up" state when there is an SFP inserted into an F348XP line card running 6.2(8), even when the opposite end is admin down or the cable is removed from the SFP.
This was duplicated using an Avago??, GLC-T, and GE-T SFP.
Support for gig transceiver was introduced in 6.2.8
Conditions:
Issue seen for 1gig SFP on N77-F348XP-23 module.
Seen on 6.2.8
Issue seen when speed on interface is hardcoded to 1gig.
Workaround:
Admin down local interface.
configure speed auto on the interface.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.13), 6.2(8)E5, 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.12)S0, 6.2(9)FM(0.75) |
|
|
| |
| |
Bug Id: | CSCuu89065 |
Title: | Activating L2 netflow causes mac flap on F2 |
|
Description: | Symptom:
Activating L2 netflow causes mac flap on F2
Conditions:
Activating L2 netflow on F2 card
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv50202 |
Title: | PBR does not redirect traffic that comes from SNF configured interface |
|
Description: | Symptom:
PBR next-hop does not effect if traffic comes from L2 netflow configured interface.
Conditions:
Traffic must comes from L2 netflow configured interface.
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut17599 |
Title: | N7K-F248XT-25E: Periodic PortLoopback Failures for Unknown Reason |
|
Description: | Symptom:
PortLoopback test failure with failure reason 'Loopback test failed. Unable to analyze the reason for failure'
Conditions:
- Unused port
- N7K-F248XT-25E
Workaround:
1. If diagnostic test is error-disabled (DIAG TEST ERR DISABLE) due to this reason, you can reset the diagnostic by doing the following:
# diagnostic clear result module all
(config)# no diagnostic monitor module test 6
(config)# diagnostic monitor module test 6
# diagnostic start module test 6
2. If the Port loopback test is failing (DIAG TEST FAIL) even after resetting the condition, then see if you are hitting CSCuq34116. If yes, please the attachment - Workaround
3. If the fix of CSCuq34116 in step 2 is not helping recover, it is most likely a hw issue.
4. Reloading the module might recover the ports (Secure a maintenance window and reload the module)
Further Problem Description:
If this is not a CSCuq34116, then its very likely a hw issue. Recommend an RMA.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.1(5), 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut99084 |
Title: | Expecting egress queue mismatched on F2E card of Crossbow(6.2.10) |
|
Description: | Symptom:
When sending traffic with COS3 ( port trust COS , and no DSCP rewrite) or sending traffic with ip precedence 3
( have DSCP rewrite) , then issue show policy-map interface "F2E port" command.
Checking egress queue match , streams hit incorrect queue "8e-4q8q-out-q2". The correct queue for COS3 should be "8e-4q8q-out-q5".
Hardware and OS version: Crossbow N77XX (6.2.10) , F2E linecard.
Conditions:
When apply the following service-policy on F2E card of N77XX , and send traffic with COS 3 and IP precedence 3.
Class-map:
class-map type queuing match-any 8e-4q8q-in-q1
match cos 5-7
match dscp 40-63
class-map type queuing match-any 8e-4q8q-in-q-default
match cos 0-1
match dscp 0-8
class-map type queuing match-any 8e-4q8q-in-q3
match cos 3-4
match dscp 24-39
class-map type queuing match-any 8e-4q8q-in-q4
match cos 2
match dscp 9-23
class-map type queuing match-any 8e-4q8q-out-q1
match cos 5
class-map type queuing match-any 8e-4q8q-out-q2
match cos 7
class-map type queuing match-any 8e-4q8q-out-q3
match cos 6
class-map type queuing match-any 8e-4q8q-out-q4
match cos 4
class-map type queuing match-any 8e-4q8q-out-q5
match cos 3
class-map type queuing match-any 8e-4q8q-out-q6
match cos 2
class-map type queuing match-any 8e-4q8q-out-q7
match cos 1
class-map type queuing match-any 8e-4q8q-out-q-default
match cos 0
Policy-map:
policy-map type queuing NAC_TEST_IN8e-4q8q-in
class type queuing 8e-4q8q-in-q1
queue-limit percent 10
bandwidth percent 80
class type queuing 8e-4q8q-in-q-default
queue-limit percent 40
bandwidth remaining percent 35
class type queuing 8e-4q8q-in-q3
queue-limit percent 30
bandwidth remaining percent 45
class type queuing 8e-4q8q-in-q4
queue-limit percent 20
bandwidth remaining percent 20
policy-map type queuing NAC_Eg8e-4q8q-out
class type queuing 8e-4q8q-out-q1
priority level 1
shape average percent 50
class type queuing 8e-4q8q-out-q2
bandwidth remaining percent 1
class type queuing 8e-4q8q-out-q3
bandwidth remaining percent 25
class type queuing 8e-4q8q-out-q4
bandwidth remaining percent 15
class type queuing 8e-4q8q-out-q5
bandwidth remaining percent 10
class type queuing 8e-4q8q-out-q6
bandwidth remaining percent 10
class type queuing 8e-4q8q-out-q7
bandwidth remaining percent 4
class type queuing 8e-4q8q-out-q-default
bandwidth remaining percent 35
Workaround:
no workarounds
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu24710 |
Title: | ISSU failed 6.2(10) to 6.2(12) on a non-existing FEX |
|
Description: | Symptom:
ISSU from 6.2(10) to 6.2(12) failed on a no longer existing FEX 110.
This physical device - N2K [fex 110] - was reused in another vdc and had a new fex number there.
Module 10:
Upgrading bios/loader/bootrom.
Warning: please do not remove or power off the module at this time.
-- SUCCESS
FEX image downloading in progress.
-- SUCCESS
Non-disruptive upgrading.
Module 161 upgrade completed successfully.
Non-disruptive upgrading.
-- SUCCESS
Non-disruptive upgrading.
Module 110 upgrade failed. >>>>>>>>>>>>>>>module 110 is not existing.
Non-disruptive upgrading.
-- FAIL.
Conditions:
Fex was present in one vdc and then later was moved to another VDC with a different fex number.
Workaround:
TBD
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(0)D1(0.490) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.50), 7.1(0)AV(0.81), 7.2(0)D1(0.504), 7.2(0)VZD(0.26), 7.2(0)ZD(0.184), 7.2(1)PIB(0.14), 7.3(0)IB(0.19), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCtz10762 |
Title: | Core-client on fex module does not send MTS to default vdc |
|
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 TAC to manually copy the core files.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.1(0.249)S7, 6.2(1.121)S0, 6.2(1.83)S7, 6.2(7.23)S0, 7.1(0)D1(0.308), 7.1(0)D1(0.64) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut50838 |
Title: | M2 VLAN Translation Not Translating Non-Native VLAN BPDUs |
|
Description: | Symptom:
Ingress non local VLAN BPDUs are dropped as "igr ifc: total pkts dropped due to cbl? and egress BPDUs are not tagged with translated VLAN causing both devices to see them self as spanning-tree root for translated VLAN
Conditions:
When VLAN translation is configured on N7K-M224XP-23L
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(8a) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.65) |
|
|
| |
| |
Bug Id: | CSCur57243 |
Title: | F3: OTV not Encapsulating Unicast Traffic with ARP ND Cache Disabled |
|
Description: | Symptom:
Unicast traffic over OTV is black-holed
Conditions:
- F3 OTV
- 'no otv suppress-arp-nd' configured
Workaround:
Enable the 'otv suppress-arp-nd' feature
Further Problem Description:
Issue is seen after one of the following:
- Switch reload
- VDC reload
- System switchover
- Adding an extended vlan
- Issuing 'clear ip route' in the OTV VDC
- shut/not shut on overlay interface in OTV VDC
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.14), 7.1(0)AV(0.38), 7.1(0)D1(0.343), 7.1(0)OTT(0.47), 7.1(0)PDB(0.282), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuu86315 |
Title: | iscm cores for scale configs service flap |
|
Description: | Symptom:
iscm cores for scale configs service flap
Conditions:
iscm cores for scale configs service flap
Workaround:
iscm cores for scale configs service flap
Further Problem Description:
iscm cores for scale configs service flap
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.79), 7.2(0)D1(1), 7.2(0)D1(1.20) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv50831 |
Title: | Route Redistributed for Routes with Administrative Distance of 255. |
|
Description: | Symptom:
Routes with an AD of 255 are permitted for redistribution.
Conditions:
When using the [distance # # #] command for BGP to set summarized/local routes to an administrative distance of 255. The summary routes remain in the routing table, but marked with an AD of 255 from its default of 220 and also permitted to be redistributed into other protocols.
10.10.0.0/16, ubest/mbest: 1/0
*via Null0, [255/0], 00:00:11, bgp-65545, discard, tag 65012 ---------------->Route remained in routing table but AD did adjust to 255.
r12.7k-VDC3(config-router-af)#
####################################################################Redistributing BGP into OSPF############################
##Route shouldn't be redistributed as it is within the RIB with an AD of 255.
version 6.2(12)
feature ospf
router ospf 1
router-id 172.16.0.1
redistribute bgp 65545 route-map test ----------------------->Sending route to OSPF
ip prefix-list bgp seq 5 permit 0.0.0.0/0 le 32
route-map test permit 10
match ip address prefix-list bgp
r12.7k(config)# sho ip ospf database | b Ex
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 172.16.0.1 14 0x80000002 0xea3c 65005
10.10.0.0 172.16.0.1 14 0x80000002 0x50cd 65012 ---------->Summary is installed within OSPF database and advertised to OSPF peers. Which shouldn't happen as AD is 255
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 5.1(4), 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue79881 |
Title: | SNMP crashes on SNMP bulk get query |
|
Description: | Symptom:
The SNMP process may crash with the following messages displayed in the output of show logging log
%KERN-2-SYSTEM_MSG: mts_is_q_space_available_new():1416:Total mtsbuf size 10070872 for sap 28, exceeds limit 15 perc of 67108864 - kernel
%KERN-2-SYSTEM_MSG: mts_acquire_q_space() failing - no space in sap 28, uuid 26 send_opc 3176, pid 3616, proc_name sctpt_rx_thr - kernel
%KERN-2-SYSTEM_MSG: [sap 28][pid 4406][comm:snmpd] sap recovering failed and so Killed - kernel
%SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 4406) hasn't caught signal 6 (core will be saved).
Conditions:
This bug affects both Nexus 7000 and MDS switches. It has been observed when a monitoring device is using snmp-bulk-get requests on the entity-MIB for multiple FEX modules at one time, or if there is continuous polling from multiple polling stations on slow mibs.
Some examples of mibs that may be affected by contiuous snmp bulk walk are qos mib, entity mib, entity-fru mib, bridge mib.
Workaround:
A possible workaround is configuring the no snmp-server counter cache enable command. This command prevents SNMP bulk gets from getting cached via the use of MTS buffers. This will prevent the MTS buffers from getting consumed and resulting in a process crash. The result of the command is that the interface table might be slower to update the statistics (since caching is disabled).
Note: This workaround is only available on Nexus 7000 switches.
This defect is fixed in NX-OS releases 5.2.9, 6.1.4 (Nexus 7000), 5.2.8g (MDS), and 6.2.1 (Nexus 7000 and MDS).
Further Problem Description:
A possible way of verifying if you are affected by this bug is to issue the command show system internal mts buffers summary and check if notifications for sap 28 are increasing.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 5.2(7), 5.2(7)S20, 6.1(1.66)S0, 6.1(3), 6.1(4)S17, 6.2(0.294)S11, 6.2(0.294)S12, 6.2(1.23) |
|
Known Fixed Releases: | 5.2(1)N1(5), 5.2(8g), 5.2(8g)S11, 5.2(9), 5.2(9)S53, 5.2(9.98)S0, 6.0(2)N1(2a), 6.0(2)U1(1) |
|
|
| |
| |
Bug Id: | CSCuj70143 |
Title: | PPF out of sync between SUP and LCs |
|
Description: | Symptom:
The following error can be seen when applying ACL changes:
"Failed to complete Verification: Link exists" or
"Database Internal error"
Conditions:
Applying a large amount of config change.
Workaround:
Reload the module, or change the name of the ACL/object-group
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 5.2(9) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.8), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.96), 7.1(0)BNB(0.1), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)N1(0.153) |
|
|
| |
| |
Bug Id: | CSCtg90112 |
Title: | N7k Linecard is reset due to "Metro fatal interrupt in device 79" |
|
Description: | Symptom:Linecards, in Nexus 7000 systems
may be reset with the following messages.
Nexus 7000
%MODULE-2-MOD_DIAG_FAIL: Module reported failure on ports 8/2-8/2
(Ethernet) due to Metro fatal
interrupt in device 79 (device error 0xc4f00202)
Conditions:This issue can occur when an n7k linecard is responsible for
SPAN and multiple packet replication of the same packets.
1) Overlapping SPAN sessions can increase the chance of running into the issue
as shown below.
- Overlapping source vlan/interface, configured in tx or both directions, in 2
separate SPAN sessions.
Example:
monitor session 1 source vlan 11 - 20
monitor session 2 source vlan 11 - 20 (or any vlans that are in the session 1)
2) High # of OIFs for a specific multicast group with SPAN configured for any
of these OIFs. This has been observed with approx 60+ OIFs.
To determine if a linecard is susceptible, use the following commands.
Nexus7000# attach mod 2
module-2# sh hardware internal version
-------------------------------------------------
Name InstanceNum Version
-------------------------------------------------
Octopus 1 0.4
Octopus 2 0.4
Sotra 1 186.3
Sotra 2 186.3
Metropolis 1 0.3 <<<<<< version is irrelevent
Metropolis 2 0.3
Metropolis 3 0.3
Metropolis 4 0.3
Workaround:The only true workaround if you are hitting the described conditions, is to not have tx SPAN of multicast. You can do this by only using the "rx" option for the span source, or you can use the multicast best-effort command which disables tx span for mcast.
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/system_management/configuration/guide/sm_nx_os_cg/sm_14span.html#pgfId-1309359
You may decrease the chances of running into the issue (if you're hitting the scenario with 2 SPAN sessions) via the following
respectively:
- Do not use overlapping SPAN sessions
or
- Use Virtual SPAN session
http://www.cisco.com/en/US/partner/docs/switches/datacenter/sw/4_2/nx-os/system_management/configuration/guide/sm_14span.html#wp1214731
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu54461 |
Title: | Traffic loss seen after BGP Autodiscovery triggers |
|
Description: | Symptom:
In VPLS BGP auto-discovery, if L2VPN changes the route-target configs for a VFI, the config changes may not be reflected in outgoing routes until a route refresh is done in BGP.
Conditions:
Changing route-target configs like in the following condition.
l2vpn vfi context test7
vpn id 7
autodiscovery bgp signaling ldp
route-target import 1.2.3.4:7 <<<<<<
route-target export 1.2.3.4:7 <<<<<<
no auto-route-target <<<<<<
Workaround:
Route-target changes are typically done across the network, not just limited to one router. So, it is cautious to do a "clear bgp l2vpn vpls * soft" in routers that will see its effect percolate across the whole network, after all config changes are completed.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc94570 |
Title: | N7k: Fabricpath traffic loss for unicast flooded traffic |
|
Description: | Symptom:
Unidirectional North-South traffic does not flow through VPC+ ports in F2 modules
Conditions:
When the core ports and vpc+ edge ports are part of the same F2 ASIC instance, the unknown unicast flood may be incorrectly pruned and not make it out of the vpc+ ports
Workaround(s):
Locate the vpc+ ports in a separate ASIC instance than the core ports.
The ports and the corresponding ASIC instances in a F2 card are as follows
--------------------
ASIC | ports
---------+---------
1 : 1-4
2 : 5-8
3 : 9-12
4 : 13-16
5 : 17-20
6 : 21-24
7 : 25-28
8 : 29-32
9 : 33-36
10 : 37-40
11 : 41-44
12 : 45-48
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.1(2), 6.2(5.27)S0 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut26755 |
Title: | L3 SVI BFD ACL remove failed on reload of F2 module |
|
Description: | This issue may be exposed to customer.
Symptom:
Reloading of F3 module followed by F2 module reload; brings the fabricpath bfd sessions on l3 svi to down state, due to ACL install failed on F3 modules.
Conditions:
Configure IPv4/IPv6 Fabricpath BFD sessions on L3 SVI with fabricpath member ports on F3 and F2E modules. With this configuration - issue occurs in the following conditions,
* Reload the F3 module where BFD was hosted. Once the F3 goes down, BFD session is moved to F2 LC. Once the F3 is back online, BFD sessions moves back to F3.
* Now reload the module F2. Upon reloading the F2 module ACL entries on F3 module are getting deleted and never creates back, as a result fabricpath bfd sessions will never come up again.
Workaround:
Reload the F3 module again to bring up the fabricpath bfd sessions on l3 SVI.
(or)
Reload the F2 module after sometime once the F3 is UP.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 7.2(0)ZD(0.106) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu13344 |
Title: | Rackspace - pixmc crash and M2 LC - communication failure |
|
Description: | Symptom:
During the HA switch over of the supervisors, the neighbor switch crashed with pixmc core.
Conditions:
have a M2 LC and more than 128 interfaces within a BD LTL.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(12)E5, 6.2(13.3)S0, 6.2(14)FB(0.46), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.496), 7.2(0)D1(1), 7.2(0)ZD(0.178), 7.3(0)IB(0.19) |
|
|
| |
| |
Bug Id: | CSCut49944 |
Title: | sw reload would put range of private-vlan are STP blocked state |
|
Description: | Symptom:
sw reload its observed that range of private-vlan are STP blocked state
Conditions:
sw reload its observed that range of private-vlan are STP blocked state
Workaround:
workaround : realod of LC
Further Problem Description:
sw reload its observed that range of private-vlan are STP blocked state
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.72), 7.2(0)D1(0.444) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(13.4)S0, 6.2(14)FB(0.65), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.504), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.184) |
|
|
| |
| |
Bug Id: | CSCut34478 |
Title: | unicast route for the NVE peer loopback IP is missing on some ASIC inst |
|
Description: | Symptom:
This issue is specific to Vxlan - Flood and Learn. When the peer LC goes down and it is the only core facing LC on the peer switch, the peer route is not programmed properly on all the instances and hence the traffic fails.
Conditions:
This issue is specific to Vxlan - Flood and Learn.
The peer route must be programmed on the VDC instances. This is achieved through the following two updates -
a. URIB route update for programming the route on core vrf instances.
b. NVE Manager peer add updates for programming the route on the VDC instances.
This issue is observed when the peer LC goes down and it is the only core facing LC on the peer switch. In such a scenario, when OSPF timeouts, URIB triggers an unlearn for the peer route.
However, the MAC Table timeout is longer than the OSPF timeout. Hence, the MAC table still has the Remote host MAC entry - thus the NVE peer is still seen in NVE Manager.
When the peer LC is up again, OSPF sends an update for the peer route. However, NVE manager doesn't resend the peer route update since it already has the peer update. As a result, we end up with the peer route programmed only on the URIB notified VRF instances and not the other instances in the VDC.
Workaround:
clear ip route vrf all
shut / no shut on the nve interface.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.424) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu88922 |
Title: | partial configuration applied after configuring fabric-control on pvlan |
|
Description: | Symptom:
Trying to configure/unconfigure a vlan as fabric-control which is initially configured as a private-vlan irrespective of primary or isolated or community. Such a config is not supported and ideally vlan_mgr needs to log an error or warning on the console. If such a config is applied then pixm_vl crashes.
Conditions:
vlan need to be private vlan and configure it as fabric-control and then again remove fabric-control.
vlan 10
fabric-control
exit
vlan 10
no fabric-control
exit
Workaround:
N/A
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
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) |
|
|
| |
| |
Bug Id: | CSCut75759 |
Title: | ACL change fail "hardware resource allocation failure" |
|
Description: | Symptom:
unable to modify/remove ACL from SVI. getting the following error: "ERROR: Module 1 returned status: hardware resource allocation failure"
Conditions:
Issue is seen when modification is done to ACL attached to SVI. This is due to memory leak in policer being allocated by qos. With each modification to ACL number of policer in QOS keeps on increasing. It reaches a point where there are not sufficient quantity of policers free and error is generated.
Workaround:
Remove the QOS policy from VLAN config, this results in deallocation of all allocated policers for that vlan.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.42), 7.2(0)BA(0.25), 7.2(0)D1(0.495), 7.2(0)D1(1), 7.2(0)ZD(0.177), 7.3(0)IB(0.19), 7.3(0)RTG(0.17), 7.3(0)SL(0.73) |
|
|
| |
| |
Bug Id: | CSCuu10618 |
Title: | Traffic loss on some vlans after line card reload |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471), 7.2(0)D1(0.475) |
|
Known Fixed Releases: | 15.5(1)S2.7, 15.5(2.20)T, 15.5(2.21)S0.12, 15.5(2.21)S0.5, 15.6(0.2)S, 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25) |
|
|
| |
| |
Bug Id: | CSCuu05012 |
Title: | Post ISSU : EXP based classification is not working |
|
Description: | Symptom:
Before fixing the issue ISSU from 6.2.x to 7.2, qos was not working properly.
Conditions:
The hardware initialization is modified in 7.2 and if did ISSU from 6.2.x to 7.2 with flanker card, hardware is with still old 6.2.x programming and in some qos cases may not work properly in 7.2, since ISSU do not touch the hardware.
To fix this qos tables are reprogrammed at the time of ISSU when moved to 7.2.
Workaround:
Reload LC.
Further Problem Description:
There may be some packet drops while doing ISSU from 6.2.x to 7.2 till qos tables get reprogrammed in the hardware.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | 7.2(0)BA(0.25), 7.2(0)D1(0.496), 7.2(0)D1(1), 7.2(0)ZD(0.178), 7.3(0)IB(0.19), 7.3(0)RTG(0.17), 7.3(0)SL(0.73) |
|
|
| |
| |
Bug Id: | CSCuv29907 |
Title: | N7K supervisor reload due to 'monitor' service crash |
|
Description: | Symptom:
Supervisor reload or VDC restart may occur due to a crash in the 'monitor' service. Service crashes with names such as 'm5on' may also be observed.
2015 Jul 7 10:03:29.557 N7K %$ VDC-5 %$ %SYSMGR-2-SERVICE_CRASHED: Service "monitor" (PID 5207) hasn't caught signal 11 (core will be saved).
2015 Jul 7 10:03:31.445 N7K %$ VDC-5 %$ %SYSMGR-2-SERVICE_CRASHED: Service "monitor" (PID 9567) hasn't caught signal 6 (core will be saved).
2015 Jul 7 10:03:10 N7K %SYSMGR-2-LAST_CORE_BASIC_TRACE: : PID 13032 with message m5on(non-sysmgr) crashed, core will be saved .
----- reset reason for module 6 (from Supervisor in slot 6) ---
1) At 158164 usecs after Tue Jul 7 10:13:15 2015
Reason: Reset triggered due to HA policy of Reset
Service: Service "monitor" in vdc 5 hap reset
Version: 6.2(10)
Conditions:
This was observed on a Nexus 7000 running 6.2(10).
Exact conditions are unknown. It is suspected that the affected code path can be invoked either via 'show' commands or via SNMP polling, but the exact commands or OIDs are currently not known.
This will be updated with additional information as the investigation into this issue progresses.
Workaround:
Do not run the SNMP SPAN MIB Query.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur12364 |
Title: | N5K:ISSU fails 5.1(3)Nx(x)/5.2(1)N1(x) -> 6.0(2)Nx(x)/5.2 -> 7.0(x)N1(1) |
|
Description: | Symptom:
When performing ISSU with this path: 5.1(3)N1(1) / 5.1(3)N1(1a) => 6.0(2)N2(5) => 7.0(3)N1(1)
This issue is hit with ISSU upgrade path of 5.1.x->5.2.x->7.x as well. Not necessary that 6.0 should be interim.
We can see that 1st step is fine. But when switch is rebooted on the second step for upgrade 6.0(2)N2(5) => 7.0(3)N1(1) switch is crashing at boot at URIB process.
And this error is shown:
show install all status
This is the log of last installation.
Need to perform cleanup of failed upgrade.
Install has failed. Return code 0x40930039 (aborting due to failed upgrade).
Conditions:
Issue seen with these conditions:
- N5K VPC pair with AA FEX
- perform ISSU: 5.1(3)N1(1) -> 6.0(2)N2(5) -> 7.0(3)N1(1) or 5.1.x->5.2.x->7.x (without reload between after intermediate upgrade)
Workaround:
Issue is not seen when N5K pair booted 6.0(2)N2(5) and configured from clear config.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.1(3)N1(1a), 6.0(2)N2(5), 7.0(3)N1(0.125) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.0(3)I2(0.489), 7.0(3)I2(1), 7.0(6)N1(0.276), 7.0(6)N1(1b), 7.0(7)ZN(0.112), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.1(2)N1(0.549), 7.1(2)ZD(0.6) |
|
|
| |
| |
Bug Id: | CSCuu09005 |
Title: | vinci prefixes on BL node not sent to local FP neighbors-trig sys reload |
|
Description: | Symptom:
In a Vinci BL-DCI topology, after box reload, BL may not be advertise fabric external BGP route to fabric internal BGP peer.
Conditions:
1. Border Leaf is reloaded.
2. More specific fabric external route is received before less specific fabric internal route.
Workaround:
clear bgp vpnv4 unicast * soft out on the Border Leaf.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu49365 |
Title: | Wrong set of bd's are sent in TMC when no bridge-domain is done |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.512), 7.2(0)D1(1), 7.3(0)D1(0.34) |
|
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) |
|
|
| |
| |
Bug Id: | CSCue11653 |
Title: | LC Reset due to LM_INT_CL1_TCAM_B_PARITY_ERR or LM_INT_L3_TCAM_PARITY |
|
Description: | Symptom
All the below three symptoms should be seen.
1. SYSMGR-SLOT8-2-SERVICE_CRASHED: Service "lamira_usd" (PID 1944) hasn't caught signal 6 (core will be saved).
2. In "show logging onboard mod 2 exception-log"
----------------------------
Module: 2
----------------------------
Exception Log Record : Mon Mar 4 11:25:32 2013 (602696 us)
Device Id : 81
Device Name : Lamira
Device Error Code : c5101210(H)
Device Error Type : ERR_TYPE_HW
Device Error Name : NULL
Device Instance : 1 <----- this should be 1
Sys Error : Generic failure
Errtype : INFORMATIONAL
PhyPortLayer : Ethernet
Port(s) Affected :
Error Description : LM_INT_CL1_TCAM_B_PARITY_ERR <---------!
DSAP : 211
UUID : 382
Time : Mon Mar 4 11:25:32 2013
(602696 usecs 513484AC(H) jiffies)
or
----------------------------
Module: 2
----------------------------
Exception Log Record : Mon Mar 4 11:25:32 2013 (602696 us)
Device Id : 81
Device Name : Lamira
Device Error Code : c5101210(H)
Device Error Type : ERR_TYPE_HW
Device Error Name : NULL
Device Instance : 1 <---------- this should be '1'
Sys Error : Generic failure
Errtype : INFORMATIONAL
PhyPortLayer : Ethernet
Port(s) Affected :
Error Description :LM_INT_L3_TCAM_PARITY <---------!
DSAP : 211
UUID : 382
Time : Mon Mar 4 11:25:32 2013
(602696 usecs 513484AC(H) jiffies)
3. Attach to linecard, and check this.
show logging onboard internal lamira
You will see something like this below.
ACLQOS: STAT Register Scan - No Correctable Error Found
or
IPFIB: STAT Register Scan - No Correctable Error Found
If all the above are seen the issue is that software reset the linecard due to an error in handling parity interrupt.
Symptom:
Conditions:
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.1(5), 6.0(4), 6.1(2) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S59, 5.2(9)S60, 5.2(9)S66, 5.2(9.107)S0, 5.2(9.115)S0, 5.2(91.1)S0, 6.1(4), 6.1(4)S3, 6.1(4)S5 |
|
|
| |
| |
Bug Id: | CSCtz59702 |
Title: | N7k - Memory leak due to wccp |
|
Description: | Symptom:
WCCP process crashes and creates a core file running on Nexus 7k.
Conditions:
WCCP must be configured with http/https traffic.
Workaround:
Unknown
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.1(5) |
|
Known Fixed Releases: | 5.2(3a)E2, 5.2(7), 5.2(7)E1.1, 5.2(7)S6, 5.2(7.11)S0, 6.1(1.66)S0, 6.1(2), 6.1(2.27), 6.2(0.285), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCup19405 |
Title: | targeted ldp session fails when frr is in use |
|
Description: | Symptom:
Targeted ldp session is up when the primary tunnel is up, but goes down when frr goes active.
Conditions:
"In the scenarios where the MPLS core interface is a SVI or a sub-interface, packets coming in with two or more NULL labels and bound to the Supervisor card will be dropped"
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.151), 7.2(0)D1(0.456) |
|
Known Fixed Releases: | 7.1(0)AV(0.81), 7.2(0)BA(0.25), 7.2(0)D1(0.475), 7.2(0)D1(0.507), 7.2(0)D1(0.510), 7.2(0)ZD(0.186), 7.2(0)ZD(0.190), 7.2(1)D1(0.20), 7.2(1)PIB(0.14), 7.2(1)ZD(0.16) |
|
|
| |
| |
Bug Id: | CSCus22805 |
Title: | N7K-SUP2/E: Compact Flash Failure or Unable to Save Configuration |
|
Description: | Symptom:The following symptoms have been seen:
- Compact flash diagnostic failure
- Unable to perform a 'copy run start'
To display the current status of the RAID devices, please run the following commands:
switch# show system internal raid | grep -A 1 "Current RAID status info"
Current RAID status info:
RAID data from CMOS = 0xa5 0xf0
Where x is the standby supervisor slot number:
switch# slot x show system internal raid | grep -A 1 "Current RAID status info"
Current RAID status info:
RAID data from CMOS = 0xa5 0xd2
Last number in the RAID data indicate the number of disks failed:
0xf0 ==>> No failures reported
0xe1 ==>> Primary flash failed
0xd2 ==>> Alternate (or mirror) flash failed
0xc3 ==>> Both primary and alternate failed
Conditions:- N7K-SUP2 or N7K-SUP2E
- N77k-SUP2 and N77K-SUP2E are NOT effected
- Several months or years of uptime
Workaround:While system can operate with only one flash device, its highly recommended to recover and add the removed flash back into RAID configuration. Second flash device can also get into this condition over time triggering the read-only mode.
Flash Recovery Tool:
n7000-s2-flash-recovery-tool.10.0.2.tar.gz is available to be downloaded from Cisco support site. This works as a custom plug-in that can be run using the 'load' CLI.
- To run the tool, download and copy it to bootflash/volatile/slot0.
extract it
#tar extract bootflash:n7000-s2-flash-recovery-tool.10.0.2.tar.gz
run with the load command
#load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
- Tool automatically fixes any single flash errors when present.
- If a standby available, it will copy itself to standby and run there.
- No side effects if there are no errors reported at the time.
- Tool will not attempt dual flash recovery either on active or standby.
Single flash failure on active or standby:
Systems running with single flash failure can be repaired while in service using the flash recovery tool.
Dual flash failure on the standby:
This is a recoverable situation by reloading the standby and making sure that the flashes are healthy once it comes back online. Flash recovery tool should be run after reload to put both flashes back into service.
Dual flash failures on Active:
This is not a recoverable situation, unless there is at least one working flash on the standby. Otherwise, switch need to be reloaded during next maintenance window. If the standby is healthy a switchover can be attempted and then recover the old active. Latest running configurations need to be saved external to the switch to be restored after reload. Flash recovery tool should be run after reload to make sure flashes back into service.
Additional verification steps and further information can be found in the Read Me file with the recovery tool.
More Info:Fix is available in 6.2(14), 7.2(x), and later.
Each Nexus 7000 Supervisor board are equipped with 2 identical eUSB flash devices in a RAID1 mirror configuration. Called primary and mirror, they together provide for non-volatile repositories for storing boot images, startup configuration and other persistent application data.
Over years in service, one of these devices may get disconnected from the USB bus. This causes the RAID software to drop the affected device to be removed from its configuration. System still can function normally with the remaining working device.
However, if the second device also experiences similar issue and drops out of the RAID array, boot flash devices will re-mounted as read-only preventing configuration copying. Even though there is no operational impact on systems running in this state, a reload of the affected supervisor is needed to recover f
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.1(5a), 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.26), 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)IB(122), 7.2(0)AB(9), 7.2(0)BA(0.12), 7.2(0)D1(0.456), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCut08818 |
Title: | SNMPD crashes with role with only deny OIDs |
|
Description: | Symptom:
If the SNMP community name is associated with a role which has only a deny OID will cause SMNP to unexpectedly write out a core file when polled with a SNMP bulk request. If multiple SNMP crashes occur then the SUP will switchover and the SNMP configuration will be lost.
Conditions:
The N7K is configured with SNMP and a role which only denies OIDs.
Workaround:
For the configured role add in a permit OID.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(8a), 6.2(9a) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.63), 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.1(2)N1(0.548), 7.1(2)ZD(0.6), 7.1(2)ZN(0.7), 7.2(0)BA(0.25), 7.2(0)D1(0.492) |
|
|
| |
| |
Bug Id: | CSCut13349 |
Title: | EIGRP hap reset seen on primary vpc+ switch with Janjuc build 111 |
|
Description: | Symptom:
This issue is seen on L3 over Fabricpath testbed. N64P switches are vpc+ peers. P2 is primary and P1 is secondary.
Fwm reset happened on P1 (vpc secondary) and switch went for a reload. All the L3 protocols between P1 and P2 went down. Around 3 minutes later primary vpc switch (P2) went down due to eigrp hap reset.
No triggers executed this time. Switch was left idle with traffic on for around 12 hours. Then the fwm crash was seen on secondary switch and few minutes later eigrp hap reset was seen on primary vpc+ switch.
Conditions:
Eigrp hap reset seen
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.409), 7.2(0)N1(0.111) |
|
Known Fixed Releases: | 7.0(0)FFW(0.7), 7.0(0)HSK(0.474), 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)N1(0.213), 7.2(0)N1(1), 7.2(0)ZD(0.194), 7.2(0)ZN(0.213), 7.2(1)PIB(0.14), 7.3(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCut67131 |
Title: | ACL_Deny misprogrammed on F1 when creating a new VDC |
|
Description: | Symptom:
When creating a new VDC,
Broadcast packets may loop from one VPC member, across the peer link, and out the other VPC member.
Conditions:
Only seen on a Nexus 7000 switch using F1 Linecards running 6.2
Workaround:
To recover from this state after shut/no shut the VPC member on the F1 modules which is looping the broadcast.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur17440 |
Title: | snmpwalk on cpmCPUTotalTable(1.3.6.1.4.1.9.9.109.1.1.1) failing |
|
Description: | Symptom:
On nexus 5500/6000 series switches, snmpwalk on 1.3.6.1.4.1.9.9.109.1.1.1( cpmCPUTotalTable) does not return the expected objects.
Conditions:
This is seen with 7.1 train, the issue does not exist with previous trains such as 7.0
Workaround:
An snmpget to the object will work, for instance to 1.3.6.1.4.1.9.9.109.1.1.1.1.8.1 for cpmCPUTotal5minRev
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.1(1)N1(0.8) |
|
Known Fixed Releases: | 7.3(0)BZN(0.7), 7.3(0)D1(0.33), 7.3(0)DHB(0.2), 7.3(0)OTT(0.8), 7.3(0)PDB(0.15), 7.3(0)RTG(0.39), 7.3(0)ZD(0.50), 7.3(0)ZN(0.55) |
|
|
| |
| |
Bug Id: | CSCuu29773 |
Title: | Crash in the pim process after exceeding 32K multicast routes |
|
Description: | Symptom:
Multiple pim process crashes seen resulting in a hap-reset that restarts the system
Conditions:
This issue occurs after exceeding the limit of 32K multicast routes and PIM assert message for a new S,G arrives.
show ip mroute detail vrf all`
IP Multicast Routing Table for VRF "default"
Total number of routes: 44037
Total number of (*,G) routes: 141
Total number of (S,G) routes: 43895
Total number of (*,G-prefix) routes: 1
Also saw many SLAB memory errors which could potentially be the result of a memory leak:
2015 May 6 18:11:09 CVC-1-1761C-BR-0-2 %PIM-3-SLAB_ALLOC: pim [15748] Slab alloc of type pim_routetype failed in pim_build_pim_ro
ute()
2015 May 6 18:11:09 CVC-1-1761C-BR-0-2 %PIM-3-CREATE_ROUTE: pim [15748] Couldn't create PIM route for (141.214.83.211/32, 239.255
.255.253/32) in join notification
2015 May 6 18:11:19 CVC-1-1761C-BR-0-2 %PIM-4-SYSLOG_SL_MSG_WARNING: PIM-3-SLAB_ALLOC: message repeated 1349 times in last 7710408
sec
2015 May 6 18:11:19 CVC-1-1761C-BR-0-2 %PIM-3-SLAB_ALLOC: pim [15748] Slab alloc of type pim_routetype failed in pim_build_pim_ro
ute()
2015 May 6 18:11:29 CVC-1-1761C-BR-0-2 %PIM-4-SYSLOG_SL_MSG_WARNING: SYSLOG-4-SL_MSG_WARNING: message repeated 1 times in last 7710
418 sec
2015 May 6 18:11:30 CVC-1-1761C-BR-0-2 %PIM-3-SLAB_ALLOC: pim [15748] Slab alloc of type pim_routetype failed in pim_build_pim_ro
Workaround:
Reduce the total mulitciast routes to less than 32K
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.58), 7.0(0)FFW(0.7), 7.0(0)HSK(0.474), 7.0(0)KM(0.138), 7.1(2)N1(0.574), 7.1(2)ZD(0.23), 7.1(2)ZN(0.35), 7.2(0)D1(1), 7.2(0)D1(1.1) |
|
|
| |
| |
Bug Id: | CSCuu58892 |
Title: | Traffic loss observed after changing VPLS-id |
|
Description: | Symptom:
After changing the VPLS-id, Traffic loss is being observed over the PW's.
Conditions:
# Change VPLS-ID on PE-a
# Change VPLS-ID on PE-b & PE-c
# Revert VPLS-ID to default on all Pes
Workaround:
clear l2vpn service
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus98916 |
Title: | BGP Vinci: For 0.0.0.0/0, BGP installs non-best/multi paths in URIB |
|
Description: | Symptom:
In a vinci setup, customer is not able to chose one out of two Border Leaf because URIB is doing ECMP for both paths learnt via BGP.
Conditions:
1. Two paths in BGP vrf table for 0.0.0.0/0 from two Border Leaf.
2. First path is marked as best-path.
3. Second path is not marked as multi-path or best-path
4. BGP installs both paths in URIB vrf table.
5. URIB sees both paths having exact same metrics and interprets ECMP.
Workaround:
Config can be reworked in a way that the Leaf only receives one path via BGP.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.1(1)N1(0.481), 7.1(1)N1(1), 7.1(1)ZD(0.18), 7.1(1)ZN(0.33), 7.2(0)BA(0.25), 7.2(0)D1(0.487), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuu27816 |
Title: | IPv6 prefixes of OSPFv3 interfaces not present in intra-area-prefix LSA |
|
Description: | Symptom:
IPv6 prefixes of interfaces part of OSPFv3 not present in intra-area-prefix LSA.
Conditions:
Interfaces without adjacency can run into this problem after interface flap or VDC reload
Workaround:
Use "redistribute direct" instead of configuring the interfaces in OSPFv3 if possible.
Further Problem Description:
Recovery is via clear ospfv3 neighbors.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.499) |
|
Known Fixed Releases: | 7.0(0)FFW(0.7), 7.0(0)HSK(0.474), 7.0(0)KM(0.138), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)D1(0.511), 7.2(0)D1(1), 7.2(0)N1(0.209), 7.2(0)N1(1), 7.2(0)ZD(0.191) |
|
|
| |
| |
Bug Id: | CSCuo80937 |
Title: | Nexus 7000 Stuck Sending TCNs Every 2 Seconds |
|
Description: | Symptom:
If there is any TC after upgrade to 6.2.(6), 6.2.(6a) or 6.2.(8), then after approximately 90 days of active supervisor uptime, STP TC BPDUs are sent out every 2 seconds for a long period of time.
Conditions:
Nexus 7000 or 7700 running 6.2(6), 6.2.(6a), or 6.2(8).
Workaround:
In order to circumvent this issue until an upgrade to fixed code can be performed,
execute the appropriate workaround depending on whether you have a dual-supervisor or single-supervisor
configuration before each 90 days of Active supervisor uptime.
For dual-supervisor setups:
1. Reload the standby supervisor using cli "reload module x" where x is standby supervisor slot number.
2. Use the 'show module' command to confirm that the standby supervisor is up and in the ha-standby mode.
3. Use the 'system switchover' command to switch to the standby supervisor.
For single-supervisor setups:
1. Upgrade to 6.2.6b or 6.2.8a, depending on your business requirements.
2. Reload the switch.
Further Problem Description:
Active Supervisor Uptime can be found from "show system uptime":
N7K-7009-3# show system uptime
System start time: Fri Oct 25 09:40:58 2013
System uptime: 236 days, 8 hours, 56 minutes, 59 seconds
Kernel uptime: 110 days, 23 hours, 7 minutes, 49 seconds
Active supervisor uptime: 110 days, 23 hours, 2 minutes, 23 seconds <<<<<<<<<<<
-----------------
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.2(10)E1, 6.2(6) |
|
Known Fixed Releases: | 6.1(2)I3(1), 6.2(10), 6.2(10)S5, 6.2(10.5), 6.2(6)E2, 6.2(6b), 6.2(6b)S1, 6.2(8)E1, 6.2(8)E2, 6.2(8)E5 |
|
|
| |
| |
Bug Id: | CSCuu59073 |
Title: | UIN-1::Seeing ifmgr core @ ethpm_get_max_port_speed |
|
Description: |
Symptom:
User triggered command for sub-interface causing ifmgr core
Conditions:
Using invalid data for the sub-interface with uninitialized value.
Workaround:
None
Further Problem Description:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)ZD(0.209), 7.2(1)PIB(0.14), 7.3(0)SL(0.73) |
|
|
| |
| |
Bug Id: | CSCuu59408 |
Title: | Gibraltor:post ISSU, reload F2 -fex uplink results in DCBX ACK lost |
|
Description: | Symptom:
On Nexus 7018 switch with software 7.2.0 release, where Fabric Extender N2232PP uplink is connected to the only one F2 Module ports and the host interface connected to the physical host UCS is shared with the storage virtual device (VDC).
If reload of F2 module is performed post module up the host interface connected to the UCS host will see that DCBX PDU ACK gets lost.
Conditions:
Nexus 7000 series switch F2 only one module having uplink of fabric extender FEX N2232PP and host interface of FEX is shared with the storage VDC.
Workaround:
To resolve the issue, in the owner virtual device ( vdc) of nexus 7018 switch ,flap the host interface (HIF) port of Fabric extender FEX, So that the DCBX exchange will get reinitialized.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1), 7.3(0)D1(0.54) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus97711 |
Title: | Unable to delete files from /tmp directory using filesys delete |
|
Description: | Symptom:
Can not delete files from /tmp/var directory on Line cards using filesys delete cli
Conditions:
n/a
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.37), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.492), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.174), 7.3(0)IB(0.19) |
|
|
| |
| |
Bug Id: | CSCup20959 |
Title: | M2 linecard reset due to EOBC heartbeat failure |
|
Description: | Symptom:A M2 linecard may be reset by the supervisor due to EOBC heartbeat being missed by the linecard
Conditions:NXOS versions prior to 6.2(10)
Workaround:None
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.1(4), 6.2(6), 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S84, 6.2(10.16)S0, 6.2(8)E10, 7.1(0)AV(0.38), 7.1(0)D1(0.306), 7.1(0)EV(0.116), 7.1(0)OTT(0.45), 7.1(0)PDB(0.241), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCut72659 |
Title: | SSH connection failure with 'no matching cipher found ' syslog |
|
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#
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
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)S15, 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.487), 7.2(0)D1(0.489) |
|
|
| |
| |
Bug Id: | CSCut17793 |
Title: | SSTE:Traffic loss observed after flapp mpls interf with 7.2(0)D1(0.422) |
|
Description: | Symptom:
Few VPLS PWs are down
Conditions:
Flap MPLS interface used by PWs
Workaround:
clear l2vpn service all
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.422), 7.2(0)D1(0.484) |
|
Known Fixed Releases: | 15.5(1)S2.7, 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.503), 7.2(0)D1(1), 7.2(0)N1(0.196), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuv48908 |
Title: | N6K IGMP v3 snooping hap reset |
|
Description: | Symptom:
Nexus 6000 may crash due to igmp snooping.
%SYSMGR-2-SERVICE_CRASHED: Service "igmp" (PID XXXX) hasn't caught signal 11 (core will be saved).
%SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "igmp" in vdc 1 has had a hap failure
Conditions:
Infrastructure has ip IGMP version 3 configured. This crash is seen due to incorrect handling of very large IGMPv3 Group-and-Source-Specific Query by the Nexus. Usually seen with a malformed packet with a large number of source address which could be bogus.
Workaround:
Find the source of the large IGMP Group-and-Source-Specific Query packet and stop it if it is malformed packet. Using IGMPv2 everywhere will be a workaround.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur21785 |
Title: | N7K - M1/M2 Egress Queuing behavior post 6.2(x) for control plane packet |
|
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) 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:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu53575 |
Title: | sh vlan id 1 shows incorrect ports after doing ASCII replay twice |
|
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:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo13444 |
Title: | IP Packets are dropped at LC when one sub interface is deleted |
|
Description: | Symptom:
Traffic breaks for all sub-interfaces under a parent interface when we remove a sub-interface under that parent interface.
Conditions:
Sub-interfaces configured on F2 linecard
Workaround:
shut/no shut another configured sub-interface
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.85), 7.1(0)ZD(0.193) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.19), 6.2(8)TS(0.28), 6.2(9.1)S0, 7.1(0)D1(0.153), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)ZD(0.204), 7.1(1)SP(0.4), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCud91672 |
Title: | Nexus7000: DEV_LOCAL_SAC_ASIC (device error 0xc910026d) [Sup2+M2] |
|
Description: | Symptom:
Nexus7000 module reports:
%MODULE-4-MOD_WARNING: Module (Serial number: ) reported warning on ports
due to SAC sync lost in device DEV_LOCAL_SAC_ASIC (device error 0xc910026d)
Conditions:
Issue is seen only with M2 modules in Nexus7000 with SUP1 or SUP2 engines running 6.x releases
Workaround:
None
Issue is fixed in 6.1(4) and 6.2(2) or later releases.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.1(3)S32 |
|
Known Fixed Releases: | 5.2(9.95)S0, 6.1(4), 6.1(4)S3, 6.1(4.25)S0, 6.2(1.41)S0, 6.2(1.93), 6.2(2), 7.0(0.6) |
|
|
| |
| |
Bug Id: | CSCuq25337 |
Title: | Broadcast & multicast fail after multiple ISSU, no port select for LTL |
|
Description: | Symptom:Broadcast / multicast traffic may not egress out port channel members and/or physical ports.
pixm pss has duplicate entries for BD LTLs after multiple ISSU
slot 4 show hardware intern ltl start-index 0x802b end-index 0x802b egress-port 6
----------------------------------------------------------------
|fp ports|inst| ltl | rbh| vqi |mi(v5)|mi(v4)|drop|eg ports|
|--------------------------------------------------------------|
| 5- 8 | 1| 802b| 0| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 1| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 2| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 3| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 4| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 5| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 6| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 7| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 8| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 9| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 10| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 11| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 12| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 13| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 14| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 15| | c9| ca| 0|no port selects
Conditions:Multiple ISSUs causing incorrect setting of the port bitmaps due to pss key corruption.
For example, lets take a 2 ISSUs case from 6.2.8 to 6.2.8a to 6.2.10
- Switch loaded with 6.2.8 image.
- On a BD ltl operation if any, upon updation of the pss entry in the pss file, there is a mismatch between the pixmc internal data structure and the pss entry.
- After ISSU from 6.2.8 to 6.2.8a, the restoration of BD LTL is done based on the mismatched state. This results in inconsistency between pixmc internal sw state and its pss file only without affected the hardware programming.
- Now, any BD ltl operation on the above affected BD LTL will result in creation of a duplicate key in the pss file.
- Another ISSU from 6.2.8a to 6.2.10 will result in restoration of an invalid PSS entry (because of duplicate pss key) which has stale port bitmaps set for that BD LTL.
Workaround:Bounce the port channel members which do not have the port selects set properly to cause reprogramming of the affected BD LTL due to the port-channel membership change.
OR
Flap the affected vlan to cause reprogramming of the BD LTL with the right port selects.
OR
Resetting the affected module(s)
More Info:Double ISSU is a commonly seen condition. This issue can also be seen after an ISSU followed by M1-to-M2 replacement (which involves port-channels flap)
The fix for this is in 6.2(10). This means that:
a) ISSU from any prior release to 6.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.1(2), 6.2(10)S38, 6.2(2a), 6.2(6a), 6.2(8), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S45, 7.1(0)AV(0.38), 7.1(0)D1(0.267), 7.1(0)OTT(0.36), 7.1(0)PDB(0.206), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCus73066 |
Title: | M2 linecard reset due to EOBC heartbeat failure |
|
Description: | Symptom:
A M2 linecard may be reset by the supervisor due to EOBC heartbeat being missed by the linecard
Conditions:
Unknown
Workaround:
None
Further Problem Description:
The defect is similar to CSCup20959 which should be fixed in 6.2(10) code but still seen in 6.2(10)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.1(4), 6.2(10), 6.2(12), 6.2(6), 6.2(8) |
|
Known Fixed Releases: | 6.2(10)E5, 6.2(10)E8, 6.2(12)E2, 6.2(13.3)S0, 6.2(14)FB(0.14), 6.2(8)E10, 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)D1(0.469), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuu09287 |
Title: | SSTE: pixm critical message on 'no feature-set fabric' |
|
Description: | Symptom:
error message seen when no feature-set fabric is issued.
Conditions:
configure several feature sets and multiple VDCs.
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.484) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj16682 |
Title: | acl applied on mgmt interface only works when remove/apply after reload. |
|
Description: | Symptom:
acl applied on mgmt interfaces fail to act, after realod
Conditions:
Once the n7k is reloaded, acl applied on mgmt interface wont work,
checked for acl that blocks telnet to mgmt ip,
telnet seens to be sucessfull after realod, though acl was there to block tcp connections
Workaround:
remove and apply the acl on the mgmt interface after relaod.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.2(3), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S56, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.228), 7.1(0)EB(99.2), 7.1(0)NF(0.32), 7.1(0)OTT(0.27) |
|
|
| |
| |
Bug Id: | CSCui72592 |
Title: | N7k: F3 module reloads due to Kernel Panic |
|
Description: | N7K / F3 module may reload unexpectedly due to a kernel panic at 'InstructionTLBError47x'. The following symptoms will be observed:
(1) Syslogs will indicate the module was unresponsive, and was reset.
2014 Aug 21 20:20:08 NEXUS7K %MODULE-2-MOD_NOT_ALIVE: Module 2 not responding... resetting (Serial
number: XXXXXXXXXXX)
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-2-MOD_DETECT: Module 2 detected (Serial number XXXXXXXXXXX)
Module-Type 10/40 Gbps Ethernet Module Model N77-F324FQ-25
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-2-MOD_PWRUP: Module 2 powered up (Serial number XXXXXXXXXXX
)
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-5-MOD_STATUS: Module 2 current-status is MOD_STATUS_POWERED
_UP
2014 Aug 21 20:21:57 NEXUS7K %BIOS_DAEMON-SLOT2-5-BIOS_DAEMON_LC_PRI_BOOT: System booted from Pri
mary BIOS Flash
2014 Aug 21 20:24:03 NEXUS7K %VDC_MGR-5-VDC_STATE_CHANGE: vdc 1 state changed to updating
2014 Aug 21 20:24:03 NEXUS7K %VDC_MGR-5-VDC_STATE_CHANGE: vdc 1 state changed to active
2014 Aug 21 20:24:32 NEXUS7K %PLATFORM-5-MOD_STATUS: Module 2 current-status is MOD_STATUS_ONLINE/
OK
(2) The output of 'show logging onboard module internal reset-reason' will indicate that the reload reason was due to a kernel panic.
Reset Reason for this card:
Image Version : 6.2(8a)
Reset Reason (LCM): Line card not responding (60) at time Thu Aug 21 20:21:59 2014
Reset Reason (SW): Kernel Panic (19) at time Thu Aug 21 20:19:28 2014
Service (Additional Info): Kernel Panic
Reset Reason (HW): System reset by active sup (by writing to PMFPGA regs) (100) at time Thu Aug 2
1 20:21:59 2014
Last log in OBFL was written at time Thu Aug 21 19:32:39 2014
(3) The output of 'show logging onboard module stack-trace' will provide the kernel stack trace. The top function on this stack will be 'InstructionTLBError47x'. The running process and the rest of the stack are not relevant.
Example:
---------------------------------
Module: 2 stack-trace
---------------------------------
------------------ LOG 01 -------------------
Logging time: Thu Aug 21 20:19:28 2014
1408670368:500000000 process xxxxxxxx (1219), jiffies 0xb79c1f6
Machine Check in kernel mode : Process xxxxxxxxx (1219)
MCSR: 0x0 MCAR: 0x0 MCSSR0: 0xc040100c MCSSR1: 0x21000
STACK
CPU 1 Call Trace:
[]InstructionTLBError47x+0x6c/0xa8 <------------- HERE
Symptom:N7K / F3 module may reload unexpectedly due to a kernel panic at 'InstructionTLBError47x'. The following symptoms will be observed:
(1) Syslogs will indicate the module was unresponsive, and was reset.
2014 Aug 21 20:20:08 NEXUS7K %MODULE-2-MOD_NOT_ALIVE: Module 2 not responding... resetting (Serial
number: XXXXXXXXXXX)
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-2-MOD_DETECT: Module 2 detected (Serial number XXXXXXXXXXX)
Module-Type 10/40 Gbps Ethernet Module Model N77-F324FQ-25
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-2-MOD_PWRUP: Module 2 powered up (Serial number XXXXXXXXXXX
)
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-5-MOD_STATUS: Module 2 current-status is MOD_STATUS_POWERED
_UP
2014 Aug 21 20:21:57 NEXUS7K %BIOS_DAEMON-SLOT2-5-BIOS_DAEMON_LC_PRI_BOOT: System booted from Pri
mary BIOS Flash
2014 Aug 21 20:24:03 NEXUS7K %VDC_MGR-5-VDC_STATE_CHANGE: vdc 1 state changed to updating
2014 Aug 21 20:24:03 NEXUS7K %VDC_MGR-5-VDC_STATE_CHANGE: vdc 1 state changed to active
2014 Aug 21 20:24:32 NEXUS7K %PLATFORM-5-MOD_STATUS: Module 2 current-status is MOD_STATUS_ONLINE
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.2(5.41)S0, 6.2(5.41)S1, 6.2(5.41)S2, 6.2(5.41)S3, 6.2(5.7), 6.2(8a), 7.0(0.33)S0, 7.1(0)D1(0.169) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S32, 6.2(10)S9, 6.2(10.5), 6.2(6b)E2, 6.2(8)E4, 6.2(8)E5, 7.1(0)D1(0.232), 7.1(0)NF(0.32), 7.1(0)OTT(0.27) |
|
|
| |
| |
Bug Id: | CSCuv37478 |
Title: | Unable to clear SNMP intf counters for Input Discards in M2 |
|
Description: | Symptom:
clear snmp counter cmds has no effect on clearing "Input discard errors" counter on M2 cards. For other counters, this command works.
Conditions:
When Input Discards are incremented for an Ethernet interfaces of M2 line cards.
Workaround:
Reload the line card clears the snmp counters.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.2(13.8) |
|
Known Fixed Releases: | 6.2(14)S0 |
|
|
| |
| |
Bug Id: | CSCtz71765 |
Title: | NF configuration is retained when the config is not supported in HW |
|
Description: | Symptom:
Nexus 7000 switches have several restrictions in terms of hardware support for ACL based features being configured on the same L3 interface. For example Netflow and DHCP relay are not supported on the same interface at the same time.
The N7K may accept netflow configuration on the CLI and save it to the start-up configuration even though this configuration is not supported on the interface in question due to a conflict with some other ACL based feature. Upon reloading the N7K the start-up process discovers this problem and will suspend the VLAN interfaces in question. You may see errors like this:
2013 Sep 25 22:04:13 2JUA_SDS-7K-DATA ETHPORT-3-IF_ERROR_VLANS_SUSPENDED VLANs
2-999 on Interface port-channel610 are being suspended. (Reason: Tcam Allocatio
n Failure)
Conditions:
N7K with Netflow and other ACL based feature configured on the same interface. For example DHCP relay and ingress Netflow. Save config and reload the box. the bug has two parts:
1. It should reject the command
2. It should give you an error every time you configure it
r12.7k-VDC2(config-if)# no ip flow monitor standard-monitor input sampler nf-sampler r12.7k-VDC2(config-if)# ip access-group test1 in r12.7k-VDC2(config-if)# ip flow monitor standard-monitor input sampler nf-sampler Verify failed - Client 0x83000146, Reason: Tcam Allocation Failure, : RACL, Netflow Sampler (SVI), Interface: Vlan145 r12.7k-VDC2(config-if)# 2013 Sep 26 16:51:48 r12.7k-VDC2 %$ VDC-2 %$ %NFM-2-VERIFY_FAIL: Verify failed - Client 0x83000146, Reason: Tcam Allocation Failure, : RACL, Netflow Sampler (SVI), Interface: Vlan145
r12.7k-VDC2(config-if)# show run int vlan 145
!Command: show running-config interface Vlan145
!Time: Thu Sep 26 16:51:59 2013
version 6.1(4)
interface Vlan145
ip access-group test1 in
ip flow monitor standard-monitor input sampler nf-sampler
ip address 10.13.169.2/24
no shutdown
r12.7k-VDC2(config-if)# ip flow monitor standard-monitor input sampler nf-sampler r12.7k-VDC2(config-if)#
Workaround:
Remove the conflicting configuration before you save your config and reload the box.
Or you can try to upgrade to 6.2.2 and issue this command:
hardware access-list resource feature bank-mapping
The above command adds more flexibility in how various ACL based features are mapped to the 4 different TCAM banks. It doesn't make every feature combination work but it greatly reduces the amount of combinations that are not supported.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.2(7), 5.2(9)S50, 6.1(0.277), 6.1(2), 6.1(4.9), 6.2(10)S12, 6.2(10)S38, 6.2(2)S42, 6.2(2)S6, 6.2(5.38) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq39448 |
Title: | Nexus EIGRP crash when distribute list is configured under interface |
|
Description: | Symptom:
A Nexus 5000, 6000, or 7000 switch may reload unexpectedly due to an EIGRP process crash. Reset reason will look similar to the following:
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 306358 usecs after Wed Sep 3 04:32:21 2014
Reason: Reset triggered due to HA policy of Reset
Service: __inst_001__eigrp hap reset
Version: 7.0(2)N1(1)
Conditions:
This crash can be hit when a distribute-list is configured on a physical interface or SVI. It will occur when a new neighborship is formed on that interface.
Workaround:
No known workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.17), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(1)ZN(0.693), 7.0(3)DEV1(1), 7.0(3)DEV1(1.5), 7.0(3)I2(0.414), 7.0(3)I2(1), 7.0(6)N1(0.202) |
|
|
| |
| |
Bug Id: | CSCuv02037 |
Title: | L2 SVI to L3 Port to be driven by DSCP |
|
Description: | Symptom:In some cases, egress queuing behavior for F2E/F3 modules (both on Nexus 7000 & Nexus 7700) is incorrect - either the traffic selects the wrong egress queue, or the final COS of the traffic is not remarked, or both.
Conditions:Workaround:You can apply a 'type qos' policy on the ingress port(s) or VLAN(s) that explicitly copies dscp to dscp using a table-map.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.2(10)S102 |
|
Known Fixed Releases: | 6.2(12)E1, 6.2(13.7)S0 |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论