| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz92666 | Title: | Evaluation of nexus-3500 for NTP June 2016 |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
Cisco Nexus 3000 Series Switches includes a version of ntpd that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2016-4957, CVE-2016-4953, CVE-2016-4954, CVE-2016-4955, CVE-2016-4956
And disclosed in http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160603-ntpd
This product is affected by one or more of the listed CVE ids.
Conditions:
Device configured with NTP.
Cisco has reviewed and concluded that this product is affected by the following Common Vulnerability and Exposures (CVE) IDs:
* CVE-2016-4954 - Network Time Protocol Processing Spoofed Server Packets Vulnerability
* CVE-2016-4955 - Network Time Protocol Autokey Association Reset Vulnerability
This product is not affected by the following Common Vulnerability and Exposures (CVE) IDs:
* CVE-2016-4956: Network Time Protocol Broadcast Interleave Vulnerability
* CVE-2016-4953 - Network Time Protocol Bad Authentication Demobilizes Ephemeral Associations Vulnerability
* CVE-2016-4957 - Network Time Protocol CRYPTO_NAK DoS Vulnerability
Workaround:
Not available.
Further Problem Description:
Additional details about those vulnerabilities can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 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:
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 6.0(2)A8(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva15538 | Title: * | L3 flow punted to cpu due to L3MTU failure |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Flapping any SVI times would trigger flow is punted to CPU
Conditions:
SVI flapping or SVI down
Workaround:
keep all SVI active
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 6.0(2)A6(3) |
|
Known Fixed Releases: | 6.0(2)A6(7.274), 6.0(2)A6(7.276), 6.0(2)A6(8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva30223 | Title: | IMR: Cannot set non-default ports on NXAPI |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
Changing default http/https ports on NXAPI causes "Start of nginx process failed' error
Conditions:
Changing NXAPI default ports
Workaround:
use default 80/443 ports.
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 6.0(2)U6(5) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz07246 | Title: | N3500 // Orphan port stale adjacency for peer MAC black holing traffic |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Some traffic for particular VLANs failing destined to a vPC peers SVI IP when it is hashed into local device and should cross the peer-link to reach the peer.
Peers SVI MAC for affected VLAN will be pointing out an orphan port where it may have been previously learned.
"show ip arp detail" will show the old orphan port interface for the ARP entry instead of the peer-link where it should point:
N3K-1# show ip arp detail
Flags: * - Adjacencies learnt on non-active FHRP router
+ - Adjacencies synced via CFSoE
# - Adjacencies Throttled for Glean
IP ARP Table for context default
Total number of entries: 3
Address Age MAC Address Interface Physical Interface
10.51.16.252 00:01:05 6073.5c62.6781 Vlan151 Ethernet1/13
Conditions:
Issue was seen on ISSU when one of the vPC devices was coming back up, could also be seen on reload.
The peer SVI MAC is learned on a NON vpc peer-link interface (orphan port) BEFORE the peer-link itself comes up. This can happen during device bringup and broadcast ARPs from the peers SVI MAC is flooded downstream and makes it back up to this orphan port that populates the ARP entry.
After the peer-link comes back up, the adjacency entry stays pointed out of the old orphan port indefinitely and is not correctly re-learnt on the peer-link.
Workaround:
"clear mac address-table dynamic" for the peer SVI MAC is known to fix the issue by clearing the FWM entry for the MAC so it can no longer incorrectly re-learn on the orphan port and will cause it to be correctly learned on the peer-link.
Further Problem Description:
What we see happening is for a handful of VLANs for a peers SVI MAC, we learn on an orphan port before the vPC peer-link comes up, this occurred during ISSU and could also occur on a regular reload.
The peer-link then comes up, and when the ARP fully expires and no longer shows up in adjacency tables or the ARP table, the affected N3K sends a broadcast ARP that makes it across the peer-link to the peer N3K, who then sends the ARP response back across the peer-link. This causes the ARP entry to "populate" with the correct MAC, however it appears as if fwm/l2fm is sending a MAC Move notification to the AM process that causes it to switch the adjacency to the old orphan port where it was initially learned on instead of staying pointed at the peer link. This causes the black holed traffic and can cause a large outage when services such as DHCP Relay are used.
# show platform fwm info mac XXXX.XXXX.XXXX [VLAN ID]
The above command will show the MAC history for the peers SVI MAC and where we "hw learn" the MAC.
Taking the interface index and grepping for it with "show interface snmp-ifindex | grep 0xVALUE" will show the interface of where we learned the MAC when the peer-link was down and where the stale ARP entry points to.
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 6.0(2)A6(5), 6.0(2)A7(1) |
|
Known Fixed Releases: | 6.0(2)A6(7.264), 6.0(2)A6(8), 6.0(2)A8(0.10), 6.0(2)A8(0.8), 6.0(2)A8(0.9), 6.0(2)A8(1), 6.0(2)U6(6.264), 6.0(2)U6(7), 6.0(2)U8(0.10), 6.0(2)U8(0.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva08149 | Title: | N3172TQ-XL unable to sync without large variations in ptp offset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
N3172TQ-XL sees large swings in ptp sync offsets ranging from tens to thousands of nanoseconds.
Conditions:
N3172TQ-XL running 7.0(3)I4(1) to N3172PQ-XL running the same. Both boxes fully loaded with ports participating in ptp. PQ has Grand Master Clock.
Workaround:
None at this time.
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I4(1) |
|
Known Fixed Releases: * | 7.0(3)I4(1.80), 7.0(3)I4(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz94305 | Title: | Nexus3500 SSM routed multicast traffic dropped in HW due to RPF BD 0 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
SSM routed multicast traffic is dropped on a Nexus 3500 switch.
Conditions:
1. Checking PIM, MRIB and MFIB shows the multicast route for that particular group with valid OILs.
PIM: `show ip pim route `
MRIB: `show ip mroute `
MFIB: `show forwarding multicast route group `
2. Checking HW PD component table we can see that RPF BD is 0 for that particular group (you need to transform the group IP address from decimal to hexadecimal).
`show hardware internal libsdk mtc l3 route-mc-tbl all valid-only`
3. For the groups for which the Nexus 3500 is dropping the traffic it can be noticed that the PIM Join was received from the receivers side before the IGMP Report was received from the source side.
Check "uptime" value for the interface where the source is connected and for the interface used to reach the receivers using the command `show ip mroute `.
Workaround:
Issuing `no ip mroute all-owners ` solves the issue temporary, until the multicast source stops sending traffic.
Further Problem Description:
|
|
Last Modified: | 24-JUN-2016 |
|
Known Affected Releases: | 6.0(2)A7(2) |
|
Known Fixed Releases: * | 6.0(2)A6(7.274), 6.0(2)A6(8), 6.0(2)U6(6.274), 6.0(2)U6(7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz36820 | Title: | pfma hap reset after One fan missing or failed |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
pfma hap reset after one fan is missed for some reason. we can see :
%NOHMS-2-NOHMS_ENV_ERR_FAN_DOWN: System minor alarm on fans: One fan missing or failed
After this, pfma crashes:
%SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "pfma" in vdc 1 has had a hap failure
Conditions:
This is first seen on Platform : N3K-C3548P-10G with software : 6.0(2)A7(2)
Workaround:
Disable the following snmp trap:
no snmp-server enable traps entity entity_fan_status_change
Further Problem Description:
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.0(2)U8(0.367) |
|
Known Fixed Releases: * | 6.0(2)A6(7.264), 6.0(2)A6(8), 6.0(2)A9(0.392), 6.0(2)A9(1), 6.0(2)U6(6.264), 6.0(2)U6(7), 6.0(2)U9(0.392), 6.0(2)U9(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz44152 | Title: | Evaluation of nexus-3500 for NTP_April_2016 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco Nexus 3X00 Series Switches includes a version of ntpd that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2016-1551, CVE-2016-2516, CVE-2016-2517, CVE-2016-2518, CVE-2016-2519, CVE-2015-8138, CVE-2016-1550, CVE-2015-7704, CVE-2016-1547, CVE-2016-1548, CVE-2016-1549
And disclosed in http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160428-ntpd
This product is affected by one or more of the listed CVE ids.
Conditions:
Device configured with NTP.
Cisco has reviewed and concluded that this product is affected by the following Common Vulnerability and Exposures (CVE) IDs:
* CVE-2016-2518 - Network Time Protocol Crafted addpeer With hmode > 7 Causes Array Wraparound With MATCH_ASSOC
* CVE-2015-8138 - Network Time Protocol Zero Origin Timestamp Bypass
* CVE-2016-1550 - Network Time Protocol Improve NTP Security Against Buffer Comparison Timing Attacks
* CVE-2015-7704 - Network Time Protocol Original Fix For NTP Bug 2901 Broke Peer Associations
* CVE-2016-1548 - Network Time Protocol Interleave-pivot Denial Of Service Vulnerability
* CVE-2016-1549 - Network Time Protocol Sybil Vulnerability: Ephemeral Association Attack
This product is not affected by the following Common Vulnerability and Exposures (CVE) IDs:
* CVE-2016-1547 - Network Time Protocol CRYPTO-NAK Denial Of Service Vulnerability
* CVE-2016-2516: Network Time Protocol Duplicate IPs On Unconfig Directives Will Cause An Assertion Botch In ntpd
* CVE-2016-2519 - Network Time Protocol Remote ctl_getitem() Return Value Not Always Checked
* CVE-2016-2517: Network Time Protocol Remote Configuration Trustedkey/Requestkey/Controlkey Values Are Not Properly Validated
* CVE-2016-1551: Network Time Protocol Refclock Impersonation Vulnerability
Workaround:
Not available.
Further Problem Description:
Additional details about those vulnerabilities can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 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:
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.0(2)A8(0.383) |
|
Known Fixed Releases: * | 6.0(2)A9(0.395), 6.0(2)A9(0.396), 6.0(2)A9(1), 6.0(2)U9(0.395), 6.0(2)U9(0.396), 6.0(2)U9(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuj35899 | Title: | Error on snmpwalk: svi_counter_cache_fetch: destroying stale results |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N3000/3500 switches may report below errors:
%SNMPD-3-ERROR: SNMP log error : svi_counter_cache_fetch: destroying stale results for ifindex=0x9010001
Conditions:
snmpwalk on IF-MIB (1.3.6.1.2.1.2.2.1) generates the above error notification when NX-OS detects stale SVI counter entries.
Workaround:
No workaround. Above errors are cosmetic and notifying stale SVI counters were detected on SNMP poll and are being flushed. Software then polls the hardware to update the SVI counter cache.
Since NX-OS releases 6.0(2)U2(1) & 6.0(2)A3(1) issue has been resolved for N3k switches, now we do not print this notification as was deemed un-required.
6.0(2)A2(1) was available externally as 6.0(2)A3(1).
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)U2(1) |
|
Known Fixed Releases: | 6.0(2)A2(1), 6.0(2)U2(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj83903 | Title: | N3064 does not send CDP packets to N9K |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | PORT Up state handled but PORT Link up not.
Symptom:
Conditions:
Workaround:
Shut, No shut link can recover the state.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)U1(2) |
|
Known Fixed Releases: * | 6.0(2)U3(0.702), 7.1(0)N1(0.139), 7.1(0)N1(1), 7.1(0)ZN(0.257), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw08964 | Title: | OpenSSH: Evaluation of Multiple OpenSSH CVEs for NX-OS |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Cisco Nexus Operation System (NX-OS) includes a version of Open Secure Shell (OpenSSH)
software that is affected by the vulnerabilities identified by the following Common
Vulnerability and Exposures (CVE) IDs:
CVE-2015-5600, CVE-2015-6563, CVE-2015-6564 and CVE-2015-6565
This bug was opened to address the potential impact on this product.
Conditions:
Device with default configuration.
Workaround:
Not currently available.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at
http://cve.mitre.org/cve/cve.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5600
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6563
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6564
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6565
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.9/6.9:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:M/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C&version=2.0
CVE ID CVE-2015-5600, CVE-2015-6563, CVE-2015-6564, CVE-2015-6565 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: | 02-JUN-2016 |
|
Known Affected Releases: | 7.3(0)ZN(0.89) |
|
Known Fixed Releases: | 6.0(2)A7(0.282), 6.0(2)A7(1), 6.0(2)U6(5), 6.0(2)U7(0.282), 6.0(2)U7(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva04821 | Title: | Conditional default originate not working in couple of scenarios |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
v6 prefix is not withdrawn from the BGP peer even though U6RIB does not have the route.
Conditions:
Only when we have default-originate CLI on the v6 neighbor for v4 AF and v6 AF, and one of the following two scenarios for route-maps -
Scenario-1 : a route-map d1 for IPv6 and another route-map d2 for IPv4.
Scenario-2 : a single route-map d1 for both IPv4 and IPv6 match statements.
Also, both v4 and v6 static routes removed from the URIB/U6RIB simultaneously/same trigger.
Workaround:
soft out to peer resolves
clear bgp ipv6 unicast soft out.
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I4(1), 7.0(3)I4(2) |
|
Known Fixed Releases: * | 7.0(3)IED5(0), 7.0(3)IED5(0.142), 7.0(3)IPP4(2), 7.0(3)IPP4(2.59) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz96543 | Title: | QoS tcam increase when link flap and speed change |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
QoS tcam increase when link flap and speed change
Conditions:
link flap and speed change
Workaround:
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 7.0(3)I2(3) |
|
Known Fixed Releases: * | 7.0(3)I4(1.69), 7.0(3)I4(2), 7.0(3)IED5(0), 7.0(3)IED5(0.141), 7.0(3)IED5(0.145) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva10782 | Title: | N3K Tplus: Egress object Leak post ISSU |
|
Status: * | Open |
|
Severity: * | 3 Moderate |
Description: | Symptom:
Issue happens only after ISSU (N3K Tplus devices) and user will not be able to add any L3 interface further to the system after ISSU.
Conditions:
Issue seen for N3K Tplus devices in NXOS: version 7.0(3)I4(1).
Configuring of index zero for L3 egress interface table is causing the issue. It can be verified as below
switch(config)# bcm-shell mod 1
Warning: BCM shell access should be used with caution
Entering bcm shell on module 1
Available Unit Numbers: 0
bcm-shell.0>
bcm-shell.0> dump chg EGR_L3_INTF 0
EGR_L3_INTF.epipe0[0]:
Workaround:
Before doing ISSU with the above software make sure to re-set the vlan-id of index 0 as below.
bcm-shell.0> dump chg EGR_L3_INTF 0
EGR_L3_INTF.epipe0[0]:
bcm-shell.0>
bcm-shell.0> mod EGR_L3_INTF 0 1 VID=0
bcm-shell.0>
bcm-shell.0> dump chg EGR_L3_INTF 0
EGR_L3_INTF.epipe0[0]:
Further Problem Description:
The issue is specific to N3K Tplus devices and seen only in version 7.0(3)I4(1).
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 7.0(3)I4(1.42) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy67407 | Title: | %IPQOSMGR-5-QOSMGR_LC_STAT_SESSION_ERROR_MSG error logs |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | QOSMGR logs are continuously seen on N3K switch.
Symptom:
Logging log file is continuously getting log: %IPQOSMGR-5-QOSMGR_LC_STAT_SESSION_ERROR_MSG: Linecard 1 returned the following error for statistics session: Device Name:[0x3FF] Instance:[63] Error Type:[(null)] code:[255].
Conditions:
logging level ipqosmgr 7
Workaround:
Changing logging level ipqosmgr 4 is a temporary workaround.
Permanent workaround is to reload the switch.
Further Problem Description:
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I2(2a) |
|
Known Fixed Releases: | 7.0(3)I4(1.18), 7.0(3)I4(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva18028 | Title: | N3K: DOM report TX power N/A for SFP+ with CVR-QSFP-SFP10G adaptor |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Show interface transceiver details report N/A for Current and Tx Power with CVR-QSFP-SFP10G adaptor in QSA ports for N3K-C3172TQ-XL.
N3k# sh int Eth1/54/1 transceiver details | b Deta
SFP Detail Diagnostics Information (internal calibration)
----------------------------------------------------------------------------
Current Alarms Warnings
Measurement High Low High Low
----------------------------------------------------------------------------
Temperature 5.85 C -- 67.30 C 85.28 C 65.21 C 78.26 C
Voltage 0.07 V -- 1.36 V 1.23 V 2.20 V 1.30 V
Current N/A 12.19 mA 8.10 mA 0.00 mA 87.37 mA
Tx Power N/A 3.28 dBm 3.12 dBm 1.00 dBm 2.60 dBm
Rx Power -13.97 dBm - 5.02 dBm 0.00 dBm -2.49 dBm -6.36 dBm
Transmit Fault Count = 0
----------------------------------------------------------------------------
Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
Conditions:
SFP+ transceiver with DOM inserted with SFP+ to QSFP adaptor in QSA port.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.0(3)I2(2e) |
|
Known Fixed Releases: | 7.0(3)I4(1.78), 7.0(3)I4(1.81), 7.0(3)I4(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz90594 | Title: * | ARP request may be send for local IP address on Nexus 3500 |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
On a Nexus 3000, the following error may be observed:
%ARP-3-REQ_IP: arp [] Sending ARP request for local IP address on , request from pid:
Conditions:
The issue is observed when the nexus is configured with VRRP and has the same IP address configured as physical IP on the interface.
Under this condition, when a packet is send from the nexus 3500 to it's own VRRP address (eg. ping or through a control protocol), the error is observed.
Workaround:
The error is cosmetic in nature.
Using a different VRRP address than physical address prevents the issue.
The errors can also be hidden by configuring 'logging level arp 2', however there is a risk of other ARP messages not being shown.
Further Problem Description:
|
|
Last Modified: | 15-JUN-2016 |
|
Known Affected Releases: | 6.0(2)A7(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud95934 | Title: | N3K: High CPU utilization when sFlow is running |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
sflow process used to show high cpu utilization under some test conditions.
Conditions:
QI-01(config)# show sflow
sflow sampling-rate : 10000
sflow max-sampled-size : 128
sflow counter-poll-interval : 20
sflow max-datagram-size : 1400
sflow collector-ip : 173.39.18.168 , vrf : management
sflow collector-port : 6343
sflow agent-ip : 192.1.2.2
sflow data-source interface port-channel1
sflow data-source interface Ethernet1/1
sflow data-source interface Ethernet1/2
sflow data-source interface port-channel2
Workaround:
Further Problem Description:
sflow process used to show high cpu utilization with the particular configuration shown in "Conditions" above. The fix takes care of reducing the cpu overhead of this process by optimizing the codepath without changing the overall sflow design in NXOS.
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 5.0(3)U5(1) |
|
Known Fixed Releases: | 5.0(3)U5(1g), 6.0(2)U1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva06179 | Title: | Enhancement : NX-API coed execution |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Enhancement for the code to run completely, even when there are errors found in the code. Throw an error but execute the command completely
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
N/A
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I2(2d) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu78476 | Title: | pvlan host/promisocus config rejected on vpc Po |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
pvlan host and promisocus config rejected on vpc Po
Conditions:
Configure pvlan host mode or promiscuous mode on a vpc Port channel
Workaround:
Further Problem Description:
pvlan host and promisocus config rejected on vpc Po
Get the below error when configure pvan host/promiscous association
ERROR: Port-Channel 11 : requested config not allowed on Port-Channels
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I2(0.374) |
|
Known Fixed Releases: | |
|
|
| |
:
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论