| |
|
Alert Type: | Updated * |
Bug Id: | CSCux33013 | Title: * | N3500 crash with "mtc_usd hap reset". |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Device can crash with "mtc_usd hap reset" as interrupt for virtual-time rate shaping is triggered.
Conditions:
Suspicious control plane traffic is flooded to mgmt0 interface.
Workaround:
Potential Workarounds:
- disconnect mgmt0 interface.
- find the source of excessive PDUs that are flooded to mgmt0 interface.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A7(1) |
|
Known Fixed Releases: * | 6.0(2)A6(5.187), 6.0(2)A6(5.188), 6.0(2)A6(6), 6.0(2)A7(0.17), 6.0(2)A7(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux95105 | Title: | Evaluation of nexus-3500 for NTP_January_2016 |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco Nexus 3500 Series Switches includes a version of ntpd that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-7973, CVE-2015-7974, CVE-2015-7975, CVE-2015-7976, CVE-2015-7977, CVE-2015-7978, CVE-2015-7979, CVE-2015-8138, CVE-2015-8139, CVE-2015-8140, CVE-2015-8158
This product is affected by one of more of the listed CVE ids.
Conditions:
Device configured with NTP.
Device does not support Mode 6/7 or broadcast mode.
Affected by:
* CVE-2015-7974: Network Time Protocol Missing Trusted Key Check
* CVE-2015-8138: Network Time Protocol Zero Origin Timestamp Bypass
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: 6.4/5.3
http://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:L/Au:N/C:N/I:P/A:P/E:F/RL:OF/RC:C/CDP:N/TD:N/CR:L/IR:L/AR:L
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includ
|
|
Last Modified: | 01-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A7(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue51251 | Title: | calling onep_element_publish_appl_event() reloads the box |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U1(1) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(2.13)S, 15.3(2.15.1)XEB, 15.3(2.6)T |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCum51375 | Title: | ISSU was not successful due to failure to save sup run time state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Upgrade may fail with error code:
Nexus3k# show system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 473009 usecs after Tue XXX XX XX:XX:XX 20XX
Reason: Reset Requested due to Fatal System Error
Service: ISSU failure: 0x40930036
Conditions:
Attempting to ISSU from a 6.0(2)U2(X) release while "spanning-tree port type edge" and "spanning-tree port type network" are configured.
Workaround:
Remove all STP commands from interfaces before upgrading
Further Problem Description:
|
|
Last Modified: | 17-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U2(1) |
|
Known Fixed Releases: | 6.0(2)U3(0.564), 6.0(2)U3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03055 | Title: | Fast-Reload: IPv6 traffic convergence is greater than 30seconds |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
The IPv6 traffic down time is around 32 seconds, which is 2 seconds more than the targeted 30 second data plane downtime, during fast-reload.
Conditions:
This issue is seen with IPv6 traffic over BGP.
Workaround:
Further Problem Description:
|
|
Last Modified: | 04-FEB-2016 |
|
Known Affected Releases: | 7.0(3)I2(0.592) |
|
Known Fixed Releases: * | 7.0(3)F1(0.168), 7.0(3)I2(1.41), 7.0(3)I2(1.45), 7.0(3)I2(1.46), 7.0(3)I2(1.49), 7.0(3)I2(1.51), 7.0(3)I2(1.57), 7.0(3)I2(1.6), 7.0(3)I2(1.74), 7.0(3)I2(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui51551 | Title: | Unvalidated Pointers Could Result in Device Reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A vulnerability in the Open Network Environment Platform (ONEP) could allow an authenticated, remote attacker to cause a reload of the network
element.
The vulnerability is due to insufficient pointer validation of ONEP traffic processing. An attacker could exploit this vulnerability by sending a
crafted packet to the network element.
Conditions:
A network element configured for ONE-P processing.
Workaround:
Limit access to ONE-P process by using Control Plane Policing (CoPP) to define trusted sources and applications.
Further Problem Description:
You must be very careful about enabling the ONE-P feature on a network device. A non-secure implementation of ONE-P could provide the opportunity
for a malicious third party to gain control of a router or switch.
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.3/5.2:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:M/Au:S/C:N/I:N/A:C/E:F/RL:OF/RC:C&version=2.0
CVE ID 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-2013-5496
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 04-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U1(1), 6.0(2)U1(2) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(3)M1, 15.3(3)S0.8, 15.3(3)S1, 15.3(3)S2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud95800 | Title: | onep crashed when trying to run more than max onep session configured |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U1(1) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(1.14)PI22c, 15.3(2.2)T, 15.3(2.3.1)CG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux76626 | Title: | N3500 service not responding for multiple feature clis |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
'sh ip nat timeout' and
'sh ip nat max' commands might return "service not responding" message.
Conditions:
When lot of packets reaching cpu (sup) constantly, if following commands are executed in parallel.
"service not responding" message might be returned rather actual expected output.
Workaround:
Reduce the number of packets reaching CPU for translations, when cmd is executed.
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A7(1) |
|
Known Fixed Releases: * | 6.0(2)A6(5.236), 6.0(2)A6(6), 6.0(2)A7(1.35), 6.0(2)A7(2), 6.0(2)U7(1.35), 6.0(2)U7(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur38613 | Title: | link loss on n3k after Third-party switch switch is reloaded |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Link down on certain ports on 3132 when the third-party switch connected is reloaded
Conditions:
Connecting to Arista/ Arista 7050Q
Workaround:
Shut/unshut ports
Further Problem Description:
|
|
Last Modified: | 02-FEB-2016 |
|
Known Affected Releases: * | 6.0(2)U3(1.54), 6.0(2)U3(2), 6.0(2)U3(2.60), 6.0(2)U3(8), 6.0(2)U5(3), 6.0(2)U6(4) |
|
Known Fixed Releases: | 6.0(2)A3(4), 6.0(2)A4(1.28), 6.0(2)A4(2), 6.0(2)A5(0.983), 6.0(2)A5(0.985), 6.0(2)A5(1), 6.0(2)U3(5), 6.0(2)U4(1.28), 6.0(2)U4(2), 6.0(2)U5(0.983) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur39024 | Title: | Unable to remove multiple ipv6 nd prefixes configs from interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
"Unknown Prefix/Can not be deleted" error is seen when removing second prefix with the same length under interface.
example:
N3k(config-if)# no ipv6 nd prefix 2001:100:e102:10a0::/64 infinite infinite no-autoconfig
Unknown Prefix/Can not be deleted
Conditions:
Interface's configured with multiple IPv6 ND prefixes covering the same range configured under interface and the range isn't a configured prefix you may run into a condition where you are unable to remove the configuration.
Example config:
interface Vlan20
ipv6 address 2003:1000:705:3c::2/64
ipv6 nd prefix 2003:1000:705:3c::/64 infinite infinite no-autoconfig
ipv6 nd prefix 2003:1000:705:3c::2/64 infinite infinite no-autoconfig
ipv6 nd prefix 2001:100:e102:10a0::/64 infinite infinite no-autoconfig <<< please note no prefix if you remove this before the ::2 you will trigger this issue
ipv6 nd prefix 2001:100:e102:10a0::2/64 infinite infinite no-autoconfig
If you are hitting the issue you will notice the following input in "show ipv6 nd interface (interface id) prefix"
N3K(config)# show ipv6 nd interface vlan 20 prefix
ICMPv6 ND Interfaces for VRF "default"
List of IPv6 Prefix advertised on Vlan20 <<< the ipv6 nd prefix configuration is present but there is no prefix for that in the prefix list.
Prefix : 2003:1000:705:3c::/64
Enabled : Yes
Validlife time : infinite
Preferred lifetime : infinite
On-link : Yes
Off-link : No
Autonomous : No
Note this can also be seen if you change the ipv6 prefix on the interface before you remove the ipv6 np prefix configurations
Workaround:
1: Add the "ipv6 nd prefix " back into the configuration under the interface configuration then remove it again
example:
N3k(config-if)# ipv6 nd prefix 2001:100:102:10a0::/64 infinite infinite no-autoconfig
N3k(config-if)# no ipv6 nd prefix 2001:100:102:10a0::/64 infinite infinite no-autoconfig
2: configure a ipv6 secondary address in this range and remove the configuration
Further Problem Description:
|
|
Last Modified: | 02-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U2(1) |
|
Known Fixed Releases: | 6.0(2)A3(4.88), 6.0(2)A3(4.90), 6.0(2)A3(5), 6.0(2)A4(1.29), 6.0(2)A4(1.31), 6.0(2)A4(2), 6.0(2)U3(4.88), 6.0(2)U3(4.90), 6.0(2)U3(5), 6.0(2)U4(1.29) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux37352 | Title: | NAT-2-HW_PROG_FAILED:Hardware programming for NAT failed- 6.0(2)A7(1) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Below error seen after the nat-sampling timeout expires.
------
%AFM-3-AFM_VERIFY_FAIL: Access control (ACL) policy modification on interface Ethernet1/29 failed. Configuration changes required to restore functionality.
%NAT-2-HW_PROG_FAILED: Hardware programming for NAT failed:Verify failed in LC: policy parse error (3)
%AFM-3-AFM_VERIFY_FAIL: Access control (ACL) policy modification on interface Ethernet1/29 failed. Configuration changes required to restore functionality.
%NAT-2-HW_PROG_FAILED: Hardware programming for NAT failed:Verify failed in LC: policy parse error (3)
%AFM-3-AFM_VERIFY_FAIL: Access control (ACL) policy modification on interface Ethernet1/29 failed. Configuration changes required to restore functionality.
%NAT-2-HW_PROG_FAILED: Hardware programming for NAT failed:Verify failed in LC: policy parse error (3)
%NAT-2-HW_PROG_FAILED: Hardware programming for NAT failed:invalid id to spm(3)
----------
Conditions:
This would happen if tcp control packets were reaching out of RFC defined sessions order, like, below is the RFC defined order of TCP-control packet flow.
1. syn
2. syn-ack
3. data-pak
....
4. fin-pak
5. another-fin
Workaround:
Enforce the TCP sessions to follow RFC defined order of TCP-control packet flow.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A7(1) |
|
Known Fixed Releases: * | 6.0(2)A6(5.239), 6.0(2)A6(5.241), 6.0(2)A6(6), 6.0(2)A8(0.301), 6.0(2)A8(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu35333 | Title: | Should not shutdown system when there is PS or FAN direction mismatch |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Donot shutdown system due to fan/PS direction mismatch.
Print Sev1 syslogs every minute instead.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U3(7.103) |
|
Known Fixed Releases: * | 6.0(2)A6(3.82), 6.0(2)A6(3.83), 6.0(2)A6(4), 6.0(2)U6(1.82), 6.0(2)U6(1.83), 6.0(2)U6(2), 7.0(3)IDP3(1.138) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux79934 | Title: | DUBLIN_GLDN: Insufficient free entries in TCAM error found |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
When configuring large access-list on a switch port (> 1533 entries with the default TCAM carving of 1536 entries for the region) the error message:"ERROR: Sufficient free entries are not available in TCAM bank" is seen.
Conditions:
Configuring a large access-list on switch-port with greater than 1533 ACL entries with the default TCAM carving of 1536 entries for the region, the error message:"ERROR: Sufficient free entries are not available in TCAM bank" is seen.
Workaround:
In 7.0(3) releases, by default in ifacl tcam region 3 entries are reserved in the region hence can program 1533 entries in ifacl region with the default TCAM carving of 1536 entries for the ifacl region.
Need to reduce the size of the access-list to be <= (configured ifacl region size - 3 entries) for the access-list to be successfully programmed in the TCAM.
Further Problem Description:
|
|
Last Modified: | 08-FEB-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.245) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux22283 | Title: | Bootup time of N3KC30xx in dublin higher compared to N3KC31xx device |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Bootup time of the box is high
Conditions:
Applicable only for N3K-C30xx platforms.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 05-FEB-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.139) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq59586 | Title: | back space hits 73rd character will "blank" out all characters |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
when entering long CLI command that exceeded 73 characters, if back space was used, when back space hits the 73rd character, all characters then disappeared from the command line.
Conditions:
CLI command exceeds 72 characters long and back space bar was used
Workaround:
set the terminal width to a bigger number. By default terminal width is set at 72. This can the set to a maximum number of 511.
BLR-SCL-QI2-28# terminal width ?
<24-511> Number of characters on a screen line
BLR-SCL-QI2-28# terminal width 511
Further Problem Description:
|
|
Last Modified: | 04-FEB-2016 |
|
Known Affected Releases: | 5.0(3)U5(1h) |
|
Known Fixed Releases: * | 6.0(2)A6(0.74), 6.0(2)A6(1), 6.0(2)U6(0.74), 6.0(2)U6(1), 7.0(3)F1(0.168), 7.0(3)I2(1.66), 7.0(3)I2(2), 7.0(3)I3(0.128), 7.0(3)I3(1), 7.0(3)IDP3(1.12) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu74705 | Title: | After breakout, ports come in no shutdown mode (N9k breakout) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Breakout ports are in administratively enabled state after breakout or breakin. This is a behavior change from 7.0(3)I2(1) release on Nexus 3000 platforms.
Conditions:
After breakout of the ports into 4x10G mode or breakin of ports into 40G mode
Workaround:
None required. On upgrade from earlier releases, the configuration restored will take care of restoring the appropriate administrative state of the ports.
Further Problem Description:
|
|
Last Modified: | 04-FEB-2016 |
|
Known Affected Releases: | 7.0(3)I2(0.360) |
|
Known Fixed Releases: * | 7.0(3)I2(1.33), 7.0(3)I2(2), 7.0(3)I3(0.122), 7.0(3)I3(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf66434 | Title: | Onep error when trying to add an interface to the logical switch |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Adding an interface to a Logical switch fails and the interface is put in link-down state
Conditions:
Happens after the interface with an acl configured is attempted to be added to the LS. Even after the interface is removed and the acl cleaned up, the subsequent adds fail.
Workaround:
Don't add an interface with an acl configured to the LS.
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A1 |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(1.2.16)PI22, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(2.13)T, 15.3(2.14.1)PIB23 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue28842 | Title: | New onep Makefile targets for c-pl and java-pl |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U1(1) |
|
Known Fixed Releases: * | 15.1(1)ICA4.122, 15.2(1)IC273.5, 15.2(2.4.11)EA, 15.2(2.6.89)EA, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(1.14)PI22c, 15.3(2.2)T, 15.3(2.3.1)CG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx15209 | Title: | ipv4 ping fails for pkt size > 9170, when MTU configured on interface |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptoms
If 9216 is configured as L2 as well as L3 MTU in the system ( over SVI and physical interfaces respectively ), then ping of large size (65468) will not work between connected switches over the same SVI.
Conditions
This happens only when 9216 is configured as L3 and interface MTU.
Workaround
There is no workaround currently. Note that this is applicable for only large size pings. Regular pings work correctly.
|
|
Last Modified: | 02-FEB-2016 |
|
Known Affected Releases: | 5.0(3)U3(0.123) |
|
Known Fixed Releases: | 5.0(3)U3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun37796 | Title: | Nexus 3000 vPC: LACP timed out or failed on Hot-Standby Link |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
When connecting a hot-standby LACP connection through a vPC the following log messages are seen:
2014 Jan 28 16:55:13 USORDFDRL4SW1 ETHPORT-5-IF_ADMIN_UP Interface Ethernet1/49 is admin up .
2014 Jan 28 16:55:14 USORDFDRL4SW1 ETHPORT-5-SPEED Interface Ethernet1/49, operational speed changed to 1 Gbps
2014 Jan 28 16:55:14 USORDFDRL4SW1 ETHPORT-5-IF_DUPLEX Interface Ethernet1/49, operational duplex mode changed to Full
2014 Jan 28 16:55:14 USORDFDRL4SW1 ETHPORT-5-IF_RX_FLOW_CONTROL Interface Ethernet1/49, operational Receive Flow Control state changed to off
2014 Jan 28 16:55:14 USORDFDRL4SW1 ETHPORT-5-IF_TX_FLOW_CONTROL Interface Ethernet1/49, operational Transmit Flow Control state changed to off
2014 Jan 28 16:55:17 USORDFDRL4SW1 VSHD-5-VSHD_SYSLOG_CONFIG_I Configured from vty by admin on 10.255.255.161@pts/0
2014 Jan 28 16:57:14 USORDFDRL4SW1 ETH_PORT_CHANNEL-3-RSP_TIMEOUT Component MTS_SAP_LACP timed out on response to opcode:MTS_OPC_PCM_PROTOCOL_UP (for:Ethernet1/49)
2014 Jan 28 16:57:14 USORDFDRL4SW1 ETH_PORT_CHANNEL-3-LACP_ERROR LACP Misconfiguration on Ethernet1/49
2014 Jan 28 16:57:14 USORDFDRL4SW1 ETHPORT-5-IF_SEQ_ERROR Error ("LACP timed out or failed") communicating with MTS_SAP_ETH_PORT_CHANNEL_MGR for opcode MTS_OPC_ETHPM_PORT_BRINGUP (RID_PORT: Ethernet1/49) - Ethpm didn't receive a Link UP from the driver on time or had an internal error, check Port Client and Ethpm
2014 Jan 28 16:57:15 USORDFDRL4SW1 ETHPORT-5-IF_DOWN_ERROR_DISABLED Interface Ethernet1/49 is down (Error disabled. Reason:LACP timed out or failed)
Conditions:
A device running LACP in hot-standby mode connecting via vPC.
This issue has only been observed on the Nexus 3000 platform
Workaround:
Connect the device through a non-vPC link.
Further Problem Description:
|
|
Last Modified: | 02-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U2(1) |
|
Known Fixed Releases: | 6.0(2)U2(5.87), 6.0(2)U2(6), 6.0(2)U3(0.646), 6.0(2)U3(1), 6.0(2)U3(4), 6.0(2)U4(0.60), 6.0(2)U4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux56397 | Title: | "ntp authenticate" and related documentation inaccurate on Nexus 1000v |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
This is a documentation issue ntp authenticate does not enforce authentication, it enables it. There are interdependent commands which
must also be enable to create authenticated NTP sessions.
e.g.
ntp server ip-address key key-id
ntp peer ip-address key key-id
ntp passive
ntp broadcast client
ntp multicast client
Conditions:
Documentation bug
Workaround:
Not applicable or available.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via
normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 01-FEB-2016 |
|
Known Affected Releases: | 99.1(2.254)A |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux70434 | Title: | ARP resolution not working for IR peers in VPC setup in Specificscenario |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Automatic ARP resolution doesn't happen for IR peers in VPC setup in specifc scenario
Conditions:
Automatic ARP resolution doesn't happen for IR peers in VPC setup in specifc scenario.
Issue happens only in scenario of both VPC Peer reloads simultaneously.
Issue happens only in VPC config and Same Vlan is configured in MCT Peer-lnk and MCT leg.
ARP resolution happens with background L3 traffic (non-vxlan traffic).
Workaround:
Work-around is to learn IR Peers via L3 Routing protocols.
So that Control traffic from L3 Routing protocols resolves ARP.
Further Problem Description:
|
|
Last Modified: | 09-FEB-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.215) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv33390 | Title: | MSDP timers should match (S,G) state |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Currently in NX-OS, MSDP timers rely on the generation of Null-Registers on the RP to keep the SA state active. Even if the (S,G) expiry timer is increased and the source stops sending, the SA will eventually time out due to inactivity from the source as the Null-Registers will stop even though the (S,G) is still active.
Conditions:
This is the default behavior in NX-OS.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A4(3) |
|
Known Fixed Releases: * | 6.0(2)A6(6), 7.0(3)IBL3(1.52), 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)RTG(0.98), 7.3(0)SC(0.14), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux87710 | Title: | NX-OS 3500 Distributed reflective denial-of-service vulnerability NTP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A vulnerability in Network Time Protocol (NTP) package of Cisco NX-OS Software and Cisco Multilayer Director Switch (MDS) could allow an unauthenticated, remote attacker to
cause a Denial of Service (DoS) condition on an affected device.
The vulnerability is due to processing of MODE_PRIVATE (Mode 7) NTP control messages which have a large amplification vector. An attacker could exploit this vulnerability by
sending Mode 7 control requests to NTP servers and observing responses amplified up to 5500 times in size. An exploit could allow the attacker to cause a Denial of Service (DoS)
condition where the affected NTP server is forced to process and respond with large response data.
Conditions:
This is a day 1 issue and all versions of NX-OS and MDS with support for NTP are vulnerable.
Fixed Software:
This bug will apply to the Cisco Nexus 7000 (N7K), Cisco Nexus 6000 (N6K), Cisco Nexus 5000 (N5K)
and Cisco Multilayer Director Switch (MDS) and the fix is currently targeted for a release towards the end of
CY2015.
Cisco NX-OS Software and Cisco MDS switches are vulnerable to attacks utilizing Mode 7 NTP requests. Mode 7 requests can have amplification vector up to 5500.
To see if a device is configured with NTP, log into the device and issue the CLI command
''show running-config | include ntp''. If the output returns either of the following commands
listed then the device is vulnerable:
ntp master
ntp peer
ntp server
ntp broadcast client
ntp multicast client
For a Cisco MDS switch to confirm the NTP feature is disabled:
# show running-config | include ''no feature ntp
no feature ntp
Information about Cisco NX-OS and MDS Software release naming conventions is available in
''White Paper: Cisco IOS and NX-OS Software Reference Guide'' at the following link:
http://www.cisco.com/web/about/security/intelligence/ios-ref.html
Workaround:
There are no solid workarounds other than disabling NTP on the device via the ''no feature ntp'' command. The following mitigations have been identified for this vulnerability; only
packets destined for any configured IP address on the device can exploit this vulnerability. Transit traffic will not exploit this vulnerability.
Note: NTP peer authentication is not a workaround and is still a vulnerable configuration.
* NTP Access Group
Warning: Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the
sender's IP address, which may defeat access control lists (ACLs) that permit communication to these ports
from trusted IP addresses. Unicast Reverse Path Forwarding (Unicast RPF) should be considered to be used in conjunction to offer a better mitigation solution.
Additionally, ''serve-only'' keyword added to the NTP access-group will limit the exposure of the server to
only respond to valid queries.
Note: NTP Access Group groups are not supported by the Cisco MDS switch.
For additional information on NTP access control groups, consult the document titled ''Cisco Nexus 7000 Series NX-OS System Management Configuration Guide, Release 4.x'' at
the following link:
http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_2/nx-os/system_management/configuration/guide/sm_3ntp.html
* Infrastructure Access Control Lists
Warning: Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the
sender
|
|
Last Modified: | 29-FEB-2016 |
|
Known Affected Releases: | 7.3(0)ZN(0.98) |
|
Known Fixed Releases: * | 6.0(2)A6(5.240), 6.0(2)A6(5.241), 6.0(2)A6(6), 6.0(2)A7(1.44), 6.0(2)A7(1.45), 6.0(2)A7(1.46), 6.0(2)A7(2), 6.0(2)U6(6.240), 6.0(2)U6(6.241), 6.0(2)U6(7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu18724 | Title: | N3k MTS memory leak caused snmpd process to crashes multiple times |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
snmpd process crashes
2015 Apr 29 15:00:33.104 nttcom-tyo4 %$ VDC-1 %$ 29 15:00:32 %KERN-2-SYSTEM_MSG: [538326.904027] mts_is_q_space_available_haslock_old():2013: regular+fast mesg total = 46388, soft limit = 1024 - kernel
2015 Apr 29 15:00:33.106 nttcom-tyo4 %$ VDC-1 %$ 29 15:00:32 %KERN-2-SYSTEM_MSG: [538326.904034] mts_is_q_space_available_haslock_old(): NO SPACE - node=4, sap=27, uuid=26, pid=19086, sap_opt = 0x1, hdr_opt = 0x0, rq=46388(27966872), lq=0(0), pq=0(0), nq=0(0), sq=0(0), fast: rq=0, lq=0, pq=0, nq=0, sq=0 - kernel
2015 Apr 29 15:00:33.108 nttcom-tyo4 %$ VDC-1 %$ 29 15:00:32 %KERN-2-SYSTEM_MSG: [538326.904040] mts_print_longest_queue_state: opcode counts for first and last 50 messages in recv_q of sap 27: - kernel
2015 Apr 29 15:00:33.111 nttcom-tyo4 %$ VDC-1 %$ 29 15:00:32 %KERN-2-SYSTEM_MSG: [538326.904048] mts_print_msg_opcode_in_queue: opcode 2832 - 100 messages - kernel
2015 Apr 29 15:00:33.113 nttcom-tyo4 %$ VDC-1 %$ 29 15:00:32 %KERN-2-SYSTEM_MSG: [538326.904051] mts_do_msg_input() failing since no space available in 27 (src_sap = 27, opc = 325) - kernel
2015 Apr 29 15:00:52.241 nttcom-tyo4 %$ VDC-1 %$ 29 15:00:52 %KERN-2-SYSTEM_MSG: [538346.023794] [sap 27][pid 19086][comm:snmpd] QFULL drop notify posted - kernel
2015 Apr 29 15:00:52.244 nttcom-tyo4 %$ VDC-1 %$ 29 15:00:52 %KERN-2-SYSTEM_MSG: [538346.031952] [sap 27][pid 19086][comm:snmpd] sap recovering failed and so Killed - kernel
2015 Apr 29 15:00:53.034 nttcom-tyo4 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 19086) hasn't caught signal 6 (core will be saved).
2015 Apr 29 15:03:53.855 nttcom-tyo4 %$ VDC-1 %$ %SYSMGR-2-CORE_SAVE_FAILED: core_client_main: PID 24943 with message command /isan/bin/sysmgr_logmgr /var/sysmgr/tmp_logs 0 1>> /var/sysmgr/core_handling.log failed for srv , ret = 2 .
nttcom-tyo4#
Conditions:
normal operation
Workaround:
unknown at this point
Further Problem Description:
|
|
Last Modified: | 28-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U5(1) |
|
Known Fixed Releases: | 6.0(2)A6(5.222), 6.0(2)A6(6), 6.0(2)U6(5.222), 6.0(2)U6(6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux84200 | Title: | N3500 marker-Packet sent to wrong destination |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Marker packets are sent to wrong destination ip after changes to ERSPAN destination IP
Conditions:
This problem is seen after changing ERSPAN destination IP
Workaround:
Remove ERSPaN Configuration and reconfigure ERSPAN. In some condition reload is needed
Further Problem Description:
|
|
Last Modified: | 27-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A7(1) |
|
Known Fixed Releases: * | 6.0(2)A6(5.231), 6.0(2)A6(6), 6.0(2)A7(1.27), 6.0(2)A7(2), 6.0(2)U6(6.231), 6.0(2)U6(7), 6.0(2)U7(1.27), 6.0(2)U7(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw02037 | Title: | Cisco NX-OS Malformed ARP Header Vulnerability |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A vulnerability in Address Resolution Protocol (ARP) feature of the Cisco Nexus Operating System (NX-OS) could allow an
unauthenticated, adjacent attacker to cause a partial denial of service (DoS) condition due to the ARP process unexpectedly
restarting.
The vulnerability is due to improper input validation of the fields in the ARP packet header. An attacker could exploit this
vulnerability by sending a crafted ARP packet from an adjacent network to the affected device. An exploit could allow the
attacker to cause a partial DoS condition because the ARP process could unexpectedly restart when processing the
crafted ARP packet.
Conditions:
Device running with default configuration running an affected version of 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.1/5.8:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2015-6277 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 25-FEB-2016 |
|
Known Affected Releases: | 7.3(0)ZD(0.47) |
|
Known Fixed Releases: * | 6.0(2)A6(5.193), 6.0(2)A6(6), 6.0(2)A7(0.228), 6.0(2)A7(1), 6.0(2)U6(5.193), 6.0(2)U6(6), 6.0(2)U7(0.228), 6.0(2)U7(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy16810 | Title: | Port-channel Resilient hashing is broken after reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Port-Channel Resilient Hashing is not applied on copy running config to startup and reload.
Conditions:
Port-Channel Resilient Hashing is not applied on copy running config to startup and reload.
Port-channel Resilient Hashing is not applied only for existing Port-channels.
Newly created Port-channels are created with Resilient Hashing config.
Workaround:
Issue is seen on copy running config to startup and reload.
After reload, remove existing Port-channels and create again.
Then Port-channel are created with Resilient Hashing config.
Further Problem Description:
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.307) |
|
Known Fixed Releases: * | 7.0(3)IDP3(1.140), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy42097 | Title: | DOC: N3K aaa authentication login ascii-authentication documented poorly |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Documentation issue:
NX-OS aaa authentication login ascii-authentication documented poorly
N3K-1(config)# aaa authentication login ?
ascii-authentication Enable ascii authentication <<<<<<<
chap CHAP authentication for login
console Configure console methods
default Configure default methods
error-enable Enable display of error message on login failures
mschap MSCHAP authentication for login
mschapv2 MSCHAP V2 authentication for login
Under the NX-OS Command reference it says basically nothing:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/command/reference/5_0_3/security/3k_cmd_ref_sec/3k_cmd_ref_sec_cmds.html
It should include the following command, which is described in this N5K troubleshooting document
aaa authentication login ascii-authentication
In NX-OS, ASCII authentication is equivalent to PAP authentication. By default, both TACACS+ and RADIUS use CHAP. You can switch to PAP authentication with the aaa authentication login ascii-authentication command.
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/troubleshooting/guide/N5K_Troubleshooting_Guide/n5K_ts_sec.html#pgfId-1025879
In NX-OS, ASCII authentication is equivalent to PAP authentication. By default, both TACACS+ and RADIUS use CHAP. You can switch to PAP authentication with the aaa authentication login ascii-authentication command.
If you try to configure TACACS+ along with RADIUS, syslog messages similar toto the example, as shown in the example, appear during login.
Example:
2010 May 19 16:12:19 mars %$ VDC-1 %$ %RADIUS-2-RADIUS_NO_AUTHEN_INFO: ASCII authentication not supported
2010 May 19 16:12:19 mars %$ VDC-1 %$ %AUTHPRIV-3-SYSTEM_MSG: pam_aaa:Authentication failed for user oregon-regress from 10.193.128.5 - login[5698]
Conditions:
Workaround:
Further Problem Description:
Please update the documentation accordingly.
|
|
Last Modified: | 24-FEB-2016 |
|
Known Affected Releases: | 5.0(3)U5(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw58833 | Title: | 'sh platform afm event-history log' should be included in sh tech aclmgr |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
'show platform afm event-history log' is not included 'show tech aclmgr'
Conditions:
none
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A6(4.130) |
|
Known Fixed Releases: * | 6.0(2)A6(4.134), 6.0(2)A6(5), 6.0(2)A7(0.270), 6.0(2)A7(0.7), 6.0(2)A7(1), 6.0(2)A8(0.294), 6.0(2)A8(1), 6.0(2)U6(4.134), 6.0(2)U6(5), 6.0(2)U7(0.270) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux38031 | Title: | N3k :arp inspection statistics failing for ARP request packets |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
After configuring Dynamic Arp Inspection , the switch drops the invalid ARP request packets with target protocol address 0.0.0.0 as expected. But statistics for these drop packets are not shown in "show ip arp inspection statistics vlan.." CLI. These are reflected in "show ip arp statistics" CLI.
Conditions:
Configure and enable Dynamic ARP Inspection on vlan, sending invalid ARP request packets with target protocol address 0.0.0.0 switch drops the packets as expected but statistics are not shown in "show ip arp inspection statistics vlan.." CLI for the drop packets.
Workaround:
"show ip arp inspection stastics vlan.." CLI shows the DHCP binding validation fail drop statistics. The drop statistics for ARP packet sanity checks are reflected in "show ip arp statistics" CLI output. Hence need to check "show ip arp statistics" CLI along with "show ip arp inspection statistics" for the complete ARP validation statistics.
Further Problem Description:
|
|
Last Modified: | 10-FEB-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.162) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux64044 | Title: | ping dup message when apply "sla sender" feature in 7.0(3)I2(2) |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Dup message from mPBR interface
STLD1-630-01.05-N3K-RU37(config-if)# ping x.1.1.2 count 100
PING x.1.1.2 (30.1.1.2): 56 data bytes
64 bytes from x1.1.2: icmp_seq=0 ttl=254 time=1.652 ms
64 bytes from x.1.1.2: icmp_seq=0 ttl=252 time=2.233 ms (DUP!)
64 bytes from x.1.1.2: icmp_seq=0 ttl=250 time=2.267 ms (DUP!)
Conditions:
N3k(RU33) N3k(7.x version) RU37
Port 1/1 ? Port 1/1 <<<< SVI port for vlan 100,200
Port 1/22 ? Port 1/22 <<<< L3 interface for testing ping.
Configuration:
STLD1-630-01.05-N3K-RU33
interface Ethernet1/22
description ## in ##
no switchport
ip address x.1.1.2/30
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
int vlan100
ip address x.1.1.136/28
int vlan200
ip address x.1.1.36/28
STLD1-630-01.05-N3K-RU37
Feature pbr
Feature sla sender <<<<<<< this feature with configuration on the SVI or L3 interface
ip access-list 131
statistics per-entry
10 permit ip any 0.0.0.0 255.255.255.254
ip access-list 132
statistics per-entry
10 permit ip any 0.0.0.1 255.255.255.254
int vlan 100
ip address x.1.1.137/28
int vlan 200
ip address x.1.1.37/28
interface Ethernet1/22
description ## OUT ##
no switchport
ip address x.1.1.1/30
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip policy route-map CB-OUT
route-map CB-OUT permit 131
match ip address 131
set ip next-hop verify-availability x.1.1.136 track 4
set ip next-hop verify-availability x.1.1.36 track 3
set ip next-hop verify-availability x.1.1.133 track 2
set ip next-hop verify-availability x.1.1.33 track 1
route-map CB-OUT permit 132
match ip address 132
set ip next-hop verify-availability x.1.1.33 track 1
set ip next-hop verify-availability x.1.1.133 track 2
set ip next-hop verify-availability x.1.1.36 track 3
set ip next-hop verify-availability x.1.1.136 track 4
track 1 ip sla 1 reachability
track 2 ip sla 2 reachability
track 3 ip sla 3 reachability
track 4 ip sla 4 reachability
ip sla 1
icmp-echo x.1.1.33
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo x.1.1.133
frequency 5
ip sla schedule 2 life forever start-time now
ip sla 3
icmp-echo x.1.1.36
frequency 5
ip sla schedule 3 life forever start-time now
ip sla 4
icmp-echo x.1.1.136
frequency 5
ip sla schedule 4 life forever start-time now
ip sla logging traps
Workaround:
ACL to apply SVI or port based.
Further Problem Description:
Additional info:
When debug on (debug ip icmp)
ICMP_ECHO in without ping tet.
2015 Dec 21 07:03:52.349876 netstack: [5027] (default) Send packet (mbuf_prty 0): s=x.1.1.37, d=x.1.1.33, proto=1 (icmp), ICMP_ECHO, tos/dscp=0x0/0x0, ip_len=56, id=0000, ttl=255 STLD1-630-01.05-N3K-RU37#
STLD1-630-01.05-N3K-RU37# und2015 Dec 21 07:03:52.688331 netstack: [5027] (default) Send packet (mbuf_prty 0): s=x.1.1.137, d=x.1.1.133, proto=1 (icmp), ICMP_ECHO, tos/dscp=0x0/0x0, ip_len=56, id=0000, ttl=255
2015 Dec 21 07:03:53.007372 netstack: [5027] (default) Send packet (mbuf_prty 0): s=x.1.1.37, d=x.1.1.36, proto=1 (icmp), ICMP_ECHO, tos/dscp=0x0/0x0, ip_len=56, id=0000, ttl=255
2015 Dec 21 07:03:53.008777 netstack: [5027] (default) Rcvd packet on Vlan200 (mbuf_prty 0): s=x.1.1.36, d=x.1.1.37, proto=1 (icmp), ICMP_ECHOREPLY, tos/dscp=0x0/0x0, ip_len=56, id=bb21, ttl=254
2015 Dec 21 07:03:53.338276 netstack: [5027] (def
|
|
Last Modified: | 16-FEB-2016 |
|
Known Affected Releases: | 7.0(3)I2(2.9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux57023 | Title: | QZ2: high latency due to incorrect port speed detection by ipqos |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
QZ2: high latency due to incorrect port speed detection by ipqos
Conditions:
When the link operational speed changes during Auto neg
Workaround:
shut down and un shut the port in question
Further Problem Description:
|
|
Last Modified: | 18-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U5(1) |
|
Known Fixed Releases: * | 6.0(2)U6(6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy38631 | Title: | N3K BGP backup path is unexpectedly used to forward traffic |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
BGP backup path may be installed into RIB for forwarding, causing routing loop.
Conditions:
BGP is running followin feature:
bestpath as-path multipath-relax
maximum-paths 4
additional-paths install backup
Workaround:
Remove " additional-paths install backup"
Further Problem Description:
|
|
Last Modified: | 23-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A4(5) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy37616 | Title: | Getting password prompt even when entering password in copy ftp command |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
Getting password prompt even when entering password in copy ftp command
switch# copy bootflash:ABM.txt ftp://calosj:33@172.16.53.46 vrf management
Password:
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A7(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy37438 | Title: | clock protocol ptp required for ptp operation on N3548 |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
clock protocol ptp" to be moved to mandatory section from optional, as correction deviations is seen when not applied.
Conditions:
Optional Configuration
switch(config)# clock protocol ptp
This command configures the switch to use PTP to update the system calendar. This configuration keeps the clock of the switch synchronized with PTP. Not enabling this command won't prevent the switch from propagating the PTP clock on its master ports. However, the time source will be the Nexus local clock.
to be moved to Mandatory section..
Workaround:
Further Problem Description:
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A7(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr21126 | Title: | ACL Drops should not show up as input discards |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: | On a nexus 3000 series switch packets which are dropped via an ACL or other means are displayed as input discards. This enhancement is to suppress those drops and drop them silently in the same fashion as all other platforms.
|
|
Last Modified: | 04-FEB-2016 |
|
Known Affected Releases: * | 5.0(3)U1(1), 6.0(2)U3(5.94) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue88599 | Title: | Cleanup mgmt-policy funct and lockdown iptables to be more restrictive |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
This is a modification on the product to adopt new secure code best practices to enhance the security posture and resiliency of the product.
Conditions:
Device configured with default configuration.
Workaround:
Not applicable or available.
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 0/0:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:N/C:N/I:N/A:N/E:U/RL:U/RC:C&version=2.0
No CVE ID has been assigned to this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
Further Problem Description:
|
|
Last Modified: | 09-FEB-2016 |
|
Known Affected Releases: | 5.0(3)U3(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq00245 | Title: | Syntax error not given on "copy file start" with systax errors |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
No error is given specifying that a syntax error occurred when the configuration is applied.
Conditions:
When performing a "copy file start" and reload with a configuration file with syntax errors.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 05-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U3(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux06643 | Title: | N3K : Support for bud mode & dually connected hypervisors under vPC VTEP |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Multicast receivers located downstream of a nexus-3000 VxLAN L2 gateway, interested in traffic on VxLAN multicast group does not receive multicast traffic.
Conditions:
- If there is a multicast receiver connected downstream of a nexus-3000 operating as a VxLAN L2 gateway
- If the multicast receiver is interested in receiving multicast traffic for a group mapped to VN segment on the VxLAN L2 gateway
The receiver will not receive this traffic as the IPMC traffic received by nexus-3000 VxLAN L2 gateway will be terminated and decapsulated and not IPMC forwarded to any downstream receivers.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 04-FEB-2016 |
|
Known Affected Releases: | 7.1(0)I3(0.1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.124), 7.0(3)I3(0.132), 7.0(3)I3(0.136), 7.0(3)I3(1), 7.0(3)IAB3(0.2), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy12945 | Title: | only 200 dynamic nat entries created with single burst of 1000 packets |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
We are observing an issue where only 200+ of dynamic nat entries get created with single burst of 1000 packets sent to CPU from hardware within a Second.
Conditions:
NAT tries to program TCAM with more entries than TCAM can accomodate then all these entries programming on TCAM will be rejected then no flow entries will get created.
Assume TCAM can accomodate 1024 flow entries then we program 24 flow entries then TCAM can still accomodate 1000 entries. Now if we try to program 1001 entries in bulk then all 1001 entries programming will fail although 1000 entries we can program into TCAM. This is very corner case.
Workaround:
No Work Around and We don't see any real functional impact also.
Further Problem Description:
|
|
Last Modified: | 20-FEB-2016 |
|
Known Affected Releases: | 6.0(2)A7(1.41) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus94177 | Title: | N3k request to modify input discards counter in show interface |
|
Status: * | Other |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
Currently on the Nexus 3000 packets discarded during the normal operation of
the switch (acl drop, dejavu check, etc) are included in the "input discard"
counter in "show interface". This is inconsistent with other Cisco platforms
which only include buffer drops and/or aggregate errors (CRC, underruns, etc)
in this counter.
SHZT-TGJY-AS3048-25# show hardware internal interface indiscard-stats front-port 50
+-----------------------------------------+-----------------+----------------+-------------------------------------+
| Counter Description | Count | Last Increment | Last Increment Time |
+-----------------------------------------+-----------------+----------------+-------------------------------------+
IPv4 Discards 0 0
STP Discards 93830 3 02-12-2015 15:24:31.266093
Policy Discards 0 0
ACL Drops 0 0
Receive Drops 121368 3 02-12-2015 15:24:31.266093
Vlan Discards 27545 15 02-11-2015 18:07:23.394007
+-----------------------------------------+-----------------+----------------+-------------------------------------+
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 03-FEB-2016 |
|
Known Affected Releases: | 6.0(2)U3(5.94) |
|
Known Fixed Releases: | |
|
|
| |
:
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论