| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv91905 | Title: | N9k / ipfib crash may occur on primary vPC if secondary is reloaded |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
N9k configured as primary vPC reloads after reporting in the log:
%IPFIB-2-FIB_HW_ECMP_ADJ_CREATE_FAILURE: ECMP hardware programming failed.
last message repeated 2 times
%SYSMGR-2-SERVICE_CRASHED: Service "ipfib" (PID 7728) hasn't caught signal 11 (core will be saved).
%VPC-2-PEER_KEEP_ALIVE_RECV_FAIL: In domain 81, VPC peer keep-alive receive has failed
Conditions:
N9k configured as the secondary vPC peer is reloaded.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.559) |
|
Known Fixed Releases: * | 7.0(3)I2(0.586), 7.0(3)I2(0.592), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.37), 7.0(3)IVI2(1), 7.0(3)IVI2(1.3), 8.3(0)CV(0.248) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv46792 | Title: | N9K - Loops DHCP Packet on Spanning-tree Blocked Port |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
A vulnerability in the Spanning Tree Protocol (STP) handling of Dynamic Host
Configuration Protocol (DHCP) packets in the Cisco Nexus 9000 (N9K) Series Switch
software could allow an unauthenticated, adjacent attacker to cause a partial
denial of service (DoS) condition due to high CPU. The high CPU is due to a the
DHCP packet looping on the STP blocked port.
The vulnerability is due to a DHCP broadcast packet being forwarded out a STP port
in the state ''Alternate Blocking State''. An attacker could exploit this vulnerability
by flooding DHCP broadcast packets to the affected device. An exploit could allow the
attacker to cause the CPU utilization of the device to be abnormally high due to the
DHCP broadcasts being mis-handled and incorrectly looped on the STP blocked port.
Conditions:
The N9K configured as DHCP Relay agent with a link in STP ''Alternate Blocking State''.
Workaround:
The user can shutdown down the STP which is in ''Alternate Blocking State'' or prune the
VLAN which the loop is occurring in from this interface
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 3.3/2.7:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C&version=2.0
No CVE ID has been assigned to this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I3(2), 6.1(2)I3(4b), 7.0(3)I1(0.206), 7.0(3)I1(2) |
|
Known Fixed Releases: * | 6.1(2)I3(4.10), 6.1(2)I3(4.12), 6.1(2)I3(5), 7.0(3)I1(2.7), 7.0(3)I1(3), 7.0(3)I2(0.568), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw61081 | Title: | Migration of uSeg EPG VM failed |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Live migration of a VM initiated from SCVMM might fail, if there is a compliance check failure on the VM Network
Conditions:
VM network is showing compliance check failure at SCVMM
Workaround:
Perform the live migration using HyperV Cluster manager, or deploy Microsoft UR9 release.
Further Problem Description:
This issue is planned to be addressed in Microsoft UR9 release. A modified Microsoft ACI agent package will be released to support the Microsoft UR9 release expected in Q1'2016.
|
|
Last Modified: | 11-DEC-2015 |
|
Known Affected Releases: | 1.2(0.139k) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv94180 | Title: | N9KEVPN VTEP Unknown Punt Reason |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
UDP / TFTP packet punted to CPU for unknown reason.
Conditions:
- Seen on a N9K running 7.0(3)I1(2)
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 12-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I2(0.593), 7.0(3)I2(0.598), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1.37), 8.3(0)CV(0.248) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw46401 | Title: | N9k NTP monlist vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms:
Cisco Nexus 9000 Series Switches includes a version of Network Time Protocol (NTP)
that is affected by the vulnerabilities identified by the following Common
Vulnerability and Exposures (CVE) IDs:
CVE-2013-5211
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
and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5211.
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 5/5:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:H/RL:U/RC:C&version=2.0
CVE ID CVE-2013-5211 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: | 12-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1.21) |
|
Known Fixed Releases: * | 6.1(2)I3(5a), 7.0(3)I2(1.39), 7.0(3)I2(2), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2), 8.3(0)CV(0.248) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux52825 | Title: | one of the vPC vtep peers fails to respond to IPv6 NS packets from host |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:IPv6 NS packets from host are dropped by VTEP on some SVIs. ND packets to not get send via inband to the switch CPU, and gateway resolution to fail. A ethanalyzer capture will show ND packet not received by CPU.
Conditions:Vlan/SVI class id should be set to 0xc0 when SVI is up. However, when performing negative test cases, and other reload/upgrade test cases with ARP suppression enabled, it has been observed some SVIs may not have this set correctly.
Workaround:Shut/no-shut of the SVI interface will recover from this condition.
Also, this issue is not seen when ARP suppression is disabled to begin with.
|
|
Last Modified: | 18-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(2a) |
|
Known Fixed Releases: * | 7.0(3)I2(2a), 7.0(3)I3(0.194), 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux19425 | Title: | sh install all impact nxos causes all EVPN VNI down with VLAN/BD is down |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
sh install all impact nxos causes all EVPN VNI down with VLAN/BD is down
Conditions:
affects all N9K platforms running EVPN VNI
Workaround:
shut and no shut all l2/l3 VNI SVI
Further Problem Description:
|
|
Last Modified: | 18-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1), 7.0(3)I2(2) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I2(2.32), 7.0(3)I2(2a), 7.0(3)I2(3), command, convert_version.pl:, found, not |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux52950 | Title: | ipv6 NS failing for vip gateway resolution from host thru lacp vpc-po |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
1. Vpc-vtep, with pkts landing on lacp-po
2. The lacp-po having more than one members, with flows hashing non-FOP of the po gets impacted
3. If we shut that member, forcing all to hash onto FOP, they get resolved or work fine
4. No-shut the member to bring it back results in the same issue, for flows hashing back to that member
5. Flapping the lacp-vpc-po on the landing vpc-peer side help recover and works fine
6. So we tried to convert the lacp-po to static po and we did not see the issue. Verified across reloads too.
7. When the NS resolution fails, we see pkts coming in with 0::0 srp address which we cannot answer why.
8. We also reloaded the fanout N5K to avoid it being the cause.
Continuing to look further to figure out the cause as we do not have exact cause yet..
Thanks,
Hema.
Conditions:
The issue is after the trigger of reloading both the vpcs together, NS resolution from the host for the VIP fails. This is because, host first sends out NS for its own ipv6 to figure out if its a duplicate address. The ipmc index has one entry with encap_id -1, which is causing this NS request to come back to the host and it declares duplicate address and host doesn't send the NS for the gw.
Workaround:
* Flap admin shut/noshut the vpc-lacp-po, thru which the v6 NS fails. It can be one or multiple po's depending on where the flows land and fail.
Further Problem Description:
|
|
Last Modified: | 18-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(2a) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I2(2.32), 7.0(3)I2(2a), 7.0(3)I2(3), 7.0(3)I3(0.194), 7.0(3)I3(1), command, convert_version.pl:, found, not |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux57168 | Title: | SSTE: After shut and no shut for nve int, BGP EVPN routes are gone |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
On a VTEP node 9396PX running Dublin 188 image, after shut and no shut for nve interface, BGP EVPN routes are gone, and then not re-learned.
Conditions:
After shut and no shut for nve interface.
Workaround:
clear bgp all x.x.x.x soft in
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.195), 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux62371 | Title: | SSTE: [N9504]multiple nginx cores on install upg nxos <> non-disruptive |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
multiple nginx cores
Conditions:
install upg nxos <> non-disruptive
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 20-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.197) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux62381 | Title: | SSTE: snmpd cores on SNMP walks with VXLAN OIDs+config loss |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
snmpd cores
Conditions:
SNMP Walks
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.197) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux07377 | Title: | VxLAN encap packets carry inner dot1q tag for NS access ports |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Packet loss for VxLAN encapsulated packets received on the NVE and destined for an end hosts connected to 40G uplink port.
Conditions:
VxLAN encapsulated packets are being dropped on the destination North Star ASIC, 40G uplink port when received over the Network Virtualized Edge (NVE) interface. This only happens when the 40G uplink interface is configured as an classical 802.1Q trunk interface.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 22-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1), 7.0(3)I2(2), 7.0(3)IMK2(1.125) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I2(2.16), 7.0(3)I2(2a), 7.0(3)I3(0.170), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)IMK2(1), 7.0(3)IMK2(1.133), command |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux25491 | Title: | SSTE: On 9396PX VTEP Node, VXLAN Local MACs are missing |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
With Dublin 140 image, on 9396PX VTEP Node, local MACs are missing after shut and no shut on a physical interface.
Conditions:
It happens after shut and no shut on a physical interface.
Workaround:
Clear MAC address table
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.164), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux36201 | Title: | SSTE: "hardware qos ns-buffer-profile burst" Service not responding |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
"hardware qos ns-buffer-profile burst" Service not responding
Conditions:
wr er + reload + config apply
Workaround:
NA
Further Problem Description:
CLI config IPC message was not handled correctly.
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.158) |
|
Known Fixed Releases: * | 7.0(3)I3(0.173), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw57140 | Title: | vtpVlanTable populates partial values with wrong vlanId. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
vtpVlanTable populates only one entry for vlan 1 with incorrect vlanId.
Conditions:
Mibwalk vtpVlanTable.
Workaround:
Use the command "show vlan" to retrieve equivalent information from CLI.
Further Problem Description:
The issue exists in NXOS software release 7.0(3)I2(1),7.0(3)IX1(1).
The fix exists in 7.0(3)I2(2), 7.0(3)IX1(2) and all the later releases.
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.1(0)I3(0.44) |
|
Known Fixed Releases: * | <7.1(0)I>, 7.0(3)I2(1.33), 7.0(3)I2(2), 7.0(3)IX1(1.256), 7.0(3)IX1(2), 7.1(0)I3(0.52), 7.1(0)I3(1), 8.3(0)CV(0.248), 8.3(0)KMS(0.31), Bad |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv69713 | Title: | Cisco NX-OS IGMP Malformed Packet DoS Vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A vulnerability in the Internet Group Management Protocol (IGMP) Version 3 (IGMPv3) input
packet processing of the Nexus Operating System (NX-OS) could allow an unauthenticated,
adjacent attacker to cause the IGMP process to restart due to a malformed IGMP packet.
This can cause a denial of service (DoS) condition on the device.
The vulnerability is due to improper input validation when ensuring that the memory allocated
is large enough for the number of included sources in the IGMPv3 packet. An attacker could
exploit this vulnerability by sending a crafted IGMPv3 packet to the device. An exploit could
allow the attacker to cause the IGMP process to restart due to a buffer overflow which causes
the DoS condition. If the malformed IGMPv3 packet is continuously sent the device the DoS
condition will remain and the device is unavailable.
Conditions:
IGMP Version 3 snooping is configured on one or more Virtual Local Area Networks (VLANs).
Workaround:
The IGMP Version 3 snooping configuration has to be removed.
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:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2015-4324 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: | 23-DEC-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.81) |
|
Known Fixed Releases: * | 7.0(3)I2(0.546), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw65317 | Title: | Nexus 9k memory leak when running SNMP |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | A nexus 9k will leak memory when running SNMP OID MIB walk on IFMIB, leading to an eventually reload due to a kernel panic. A kernel core will not be written. The following logs will be shown:
2015 Sep 29 20:17:06 Core-199-B %$ VDC-1 %$ %PLATFORM-2-MEMORY_ALERT: Memory Status Alert : CRITICAL. Usage 91% of Available Memory
2015 Sep 29 20:17:15 Core-199-B %$ VDC-1 %$ %PLATFORM-2-MEMORY_ALERT_RECOVERED: Memory Status Alert : CRITICAL ALERT RECOVERED
2015 Sep 29 20:17:16 Core-199-B %$ VDC-1 %$ %PLATFORM-2-MEMORY_ALERT: Memory Status Alert : SEVERE. Usage 91% of Available Memory
2015 Sep 29 23:17:07 Core-199-B %$ VDC-1 %$ %PLATFORM-2-MEMORY_ALERT: Memory Status Alert : CRITICAL. Usage 91% of Available Memory
2015 Oct 1 04:11:04 Core-199-B %$ VDC-1 %$ Oct 1 04:11:04 %KERN-0-SYSTEM_MSG: [982247.800000] [1443690664] Kernel panic - not syncing: Out of memory: system-wide panic_on_oom is enabled - kernel
2015 Oct 1 04:11:04 Core-199-B %$ VDC-1 %$ Oct 1 04:11:04 %KERN-0-SYSTEM_MSG: [982247.800001] [1443690664] - kernel
2015 Oct 1 04:11:10 Core-199-B %$ VDC-1 %$ Oct 1 04:11:09 %KERN-0-SYSTEM_MSG: [982249.398446] [1443690665] Dumping interrupt statistics ? kernel
Symptom:
A nexus 9k will leak memory when running SNMP OID MIB walk on IFMIB, leading to an eventually reload due to a kernel panic. A kernel core will not be written. The following logs will be shown:
2015 Sep 29 20:17:06 N9K-1 %$ VDC-1 %$ %PLATFORM-2-MEMORY_ALERT: Memory Status Alert : CRITICAL. Usage 91% of Available Memory
2015 Sep 29 20:17:15 N9K-1 %$ VDC-1 %$ %PLATFORM-2-MEMORY_ALERT_RECOVERED: Memory Status Alert : CRITICAL ALERT RECOVERED
2015 Sep 29 20:17:16 N9K-1 %$ VDC-1 %$ %PLATFORM-2-MEMORY_ALERT: Memory Status Alert : SEVERE. Usage 91% of Available Memory
2015 Sep 29 23:17:07 N9K-1 %$ VDC-1 %$ %PLATFORM-2-MEMORY_ALERT: Memory Status Alert : CRITICAL. Usage 91% of Available Memory
2015 Oct 1 04:11:04 N9K-1 %$ VDC-1 %$ Oct 1 04:11:04 %KERN-0-SYSTEM_MSG: [982247.800000] [1443690664] Kernel panic - not syncing: Out of memory: system-wide panic_on_oom is enabled - kernel
2015 Oct 1 04:11:04 N9K-1 %$ VDC-1 %$ Oct 1 04:11:04 %KERN-0-SYSTEM_MSG: [982247.800001] [1443690664] - kernel
2015 Oct 1 04:11:10 N9K-1 %$ VDC-1 %$ Oct 1 04:11:09 %KERN-0-SYSTEM_MSG: [982249.398446] [1443690665] Dumping interrupt statistics ? kernel
Conditions:
SNMP is enabled and MIB walk for IFMIB is done frequently. The extent of the leak depends on how frequently IFMIB is being polled.
Workaround:
Disable SNMP on the switch
no snmp-server protocol enable
or you can disable just polling of IFMIB, but continue with other SNMP functions (like SNMP traps)
and do not execute any bash CLIs. To be safe bash access can also be disabled using:
no feature bash (if feature bash is enabled)
Further Problem Description:
Fix for this is present in 7.0(3)I2(1a). Both N9K and Nexus 3K running 7.0(3)I2(1) are affected.
Only this specific release 7.0(3)I2(1) is affected. No other release prior to this version or after, is affected.
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.52), 7.0(3)I2(1a), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw44272 | Title: | POAP-2-POAP_FAILURE: POAP Powerup Phase timedout |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
POAP on 9312x switches fail with below syslog message:
POAP-2-POAP_FAILURE: POAP Powerup Phase timedout
Conditions:
POAP DHCP discover phase never kicks in as we never see this syslog
OAP-2-POAP_DHCP_DISCOVER_START: POAP DHCP Discover phase started
Issue is not seen with 7.0(3)I2(1). Issue seen only with 7.0(3)I1(2)/7.0(3)I1(3) so far.
Workaround:
still unknown/investigating
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(3) |
|
Known Fixed Releases: * | <7.1(0)I>, .0(3)I1(3b, .0(3)I1(3b(3b.1), .0(3)I1(3b(3b.2), 7.0(3)I1(3b), 7.0(3)I2(1.27), 7.0(3)I2(2), 7.1(0)I3(0.41), 7.1(0)I3(1), 8.3(0)CV(0.248) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun34482 | Title: | Xbar needs to be down if a higig link goes down/recovers multiple times |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:Fabric Module or Linecard Module Internal link flaps can cause
- traffic drops during the time the link is down.
- excessive and frequent internal link flaps can cause additional processing overhead on xbar manager and cause problem getting the Line cards in other slots to come online in rare scenarios.
Fix is, as part of a default EEM policy, bring down Fabric module if a link flaps exceed link_flap threshold in any specified time interval. Also provide capability to modify linkflap threshold interval and policy action.
Conditions:It is a very rare excessive error handling condition for the case in case there is a bad internal link on the Fabric Module.
Workaround:More Info:Following are the messages logged when the issue happens.
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I1(1) |
|
Known Fixed Releases: * | 6.1(2)I3(5a), 7.0(3)I2(1.36), 7.0(3)I2(1.71), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw47106 | Title: | aclqos crashed @ aclqos_get_port_speed |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
aclqos crashed repeatedly. might trigger shut down the line card N9K-X9408PC-CFP2
Conditions:
issue was initially observed during normal operation without admin interfering. subsequently happened multiple times when tried replacement the CFP2 card with new card.
Workaround:
block snmp from polling ciscoSwitchQosMIB/csqIfQosGroupInfoTable
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(3), 7.0(3)I2(1) |
|
Known Fixed Releases: * | <7.1(0)I>, 7.0(3)I1(3b), 7.0(3)I2(1.29), 7.0(3)I2(2), 7.1(0)I3(0.47), 7.1(0)I3(0.59), 7.1(0)I3(1), 8.3(0)CV(0.248), 8.3(0)KMS(0.31), Bad |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw40773 | Title: | Copy R S failed due to "eth_port_channel" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
copy r s failing on nexus 9508.
switch# copy r s
[########################################] 98% Configuration update aborted: timed out
Following errors seen in logs:
2015 Sep 22 20:37:44 MDFLD-MVD1 %SYSMGR-2-CFGWRITE_ABORTED_CONFELEMENT_RETRIES: Copy R S failed as config-failure retries are ongoing. Type "show nxapi retries" for checking the ongoing retries.
2015 Sep 22 20:37:44 MDFLD-MVD1 %SYSMGR-3-CFGWRITE_SRVFAILED: Service "confelem" failed to store its configuration (error-id 0x00000079).
2015 Sep 22 20:38:14 MDFLD-MVD1 %SYSMGR-3-BASIC_TRACE: process_show_running_req: PID 11354 with message rvcd on vdc 1 .
2015 Sep 22 20:38:14 MDFLD-MVD1 %SYSMGR-3-BASIC_TRACE: process_show_running_req: PID 11354 with message last vdc = 1 .
2015 Sep 22 20:38:14 MDFLD-MVD1 %SYSMGR-2-CFGWRITE_USER_ABORT: Configuration copy aborted by the user.
2015 Sep 22 20:38:44 MDFLD-MVD1 %SYSMGR-3-CFGWRITE_SRVFAILED: Service "ethpm" failed to store its configuration (error-id 0x0000007C).
2015 Sep 22 20:42:44 MDFLD-MVD1 %SYSMGR-3-CFGWRITE_SRVTIMEOUT: Service "eth_port_channel" failed to store its configuration in the timeout period
2015 Sep 22 20:42:44 MDFLD-MVD1 %SYSMGR-2-CFGWRITE_ABORTED: Configuration copy aborted.
2015 Sep 22 20:42:45 MDFLD-MVD1 %SYSMGR-3-CFGWRITE_FAILED: Configuration copy failed (error-id 0x401E0045).
Conditions:
configuring switchport on an L3 port-channel with sub-interfaces
Workaround:
1) to recover, we need to reload the box
2) to avoid hitting the bug, please do not change the L3 port-channel to switchport with sub-interfaces configured. If needed, delete sub-interfaces first and then change it.
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.21), 7.0(3)I2(1a), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw30453 | Title: | L3 interface attributes lost after upgrade to Camden |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When switch is upgraded from Bronte+ to Camden, layer 3 configs are lost at the interface level, including ip address, PIM configuration, and ISIS configuration.
Conditions:
When customer performs ISSU from 7.0.3.I1.3a to 7.0.3.I2.1, and has layer3 configuration on interfaces.
Workaround:
Performing a reload ASCII with new image boot variable may prevent this behavior.
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.24), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw13560 | Title: | Cisco Nexus 9000 (N9K) Series Switch Reserved VLAN Tag Vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A vulnerability in the handling of incoming Layer 2 (L2) packets tagged with a reserved VLAN number from the
Cisco Nexus 9000 (N9K) Series Switch could allow an unauthenticated, adjacent attacker to cause a partial denial
of service (DoS) condition due to increased CPU and possible control plan instability. In addition L2 packets which
should be dropped by the switch can be incorrectly forwarded on the connected interfaces.
The vulnerability is due to lack of input validation of the VLAN number in the L2 packet. An attacker could exploit this
vulnerability by sending a crafted L2 packet tagged with a N9K reserved VLAN number. An exploit could allow the
attacker to cause a partial DoS condition due to increased CPU and possible control plan instability. In addition this
packet should be dropped by the N9K and instead can be forwarded on the attached networks.
Conditions:
Device running with default configuration running an affected version of software.
Workaround:
The reserved VLAN range can be changed to not conflict with the incoming traffic.
To review the current reserved VLAN range and reconfigure the follow commands are used:
> show vlan internal usage
> system vlan #### reserve
> copy running-config startup-config
> reload
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 4.8/4.6:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:P/I:N/A:P/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2015-6295 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: | 23-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I3(4), 7.0(3)I1(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.22), 7.0(3)I2(1.29), 7.0(3)I2(1.43), 7.0(3)I2(2), 7.0(3)IX1(1.242), 7.0(3)IX1(1.244), 7.0(3)IX1(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw20223 | Title: | [Camden][N9K] Flows fail to install if port-channel used as output port |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When user tries to install a flow low installation fail if the monitor device is connected to port channel that consists of 40G interface ports
Conditions:
For NDB 2.2 when connected to a Openflow device of N9K platform of Camden image
Workaround:
Wait for Camden MR1 release and update the N9K device the image with Camden MR1
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.16), 7.0(3)I2(2), 7.1(0)I3(0.48), 7.1(0)I3(1), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw07942 | Title: | Bud Node: Mcast encap packets duplicated with VPC leg down scenarios |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Duplicate VxLAN encapsulated packets are received on certain ports
Conditions:
When an IGMP join is present on a local vPC or orphan port from a VTEP, duplicate packets will be sent when a native frame is received and encapsulated with a multicast VxLAN header.
This behavior is observed for vPC ports with remote leg down, or for orphan ports when the native frame is received on the vPC peer switch.
Workaround:
There is no workaround
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.598) |
|
Known Fixed Releases: * | .0(3)I1(3b, .0(3)I1(3b(3b.1), 7.0(3)I1(3a), 7.0(3)I1(3b), 7.0(3)I2(0.601), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.37), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux37668 | Title: | PTP multicast packets are not being leaked to the CPU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
PTP multicast traffic in a routed N9k environment is not creating multicast state, no (s,g) is created
Conditions:
N9K is not configured for PTP and is only being used to be multicast router for PTP multicast stream
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 27-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(2), 7.0(3)I3(0.165) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.193), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), command, convert_version.pl:, found, not |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux69872 | Title: | Copy run start fails due to /var/sysmgr/ folder being full |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Copy run start fails due to /var/sysmgr folder being 100%. /var/sysmgr/ folder was full due to uncollect debug files. If the system fails to zip the core file, it should delete the uncollect file to avoid this issue.
ucf-mdf1-rtr-9(standby)# show system internal flash
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2097152 791520 1305632 38% /
proc 0 0 0 - /proc
sysfs 0 0 0 - /sys
none 40960 1388 39572 4% /nxos/tmp
none 3670016 3670016 0 100% /var/sysmgr
Conditions:
Workaround:
Delete the file manually.
ucf-mdf1-rtr-9(standby)# run bash
bash-4.2$ du /var/sysmgr/tmp_logs
3669840 /var/sysmgr/tmp_logs
bash-4.2$ cd /var/sysmgr/tmp_logs
bash-4.2$ ls
0x1c01_nginx-7259_uncollect stripcl_20151114_053544_8574_init.log
bash-4.2$ sudo su -
root@ucf-mdf1-rtr-9#pwd
/root
root@ucf-mdf1-rtr-9#cd /var/sysmgr/tmp_logs
root@ucf-mdf1-rtr-9#ls
0x1c01_nginx-7259_uncollect stripcl_20151114_053544_8574_init.log
if_index_log.7425
root@ucf-mdf1-rtr-9#rm 0x1c01_nginx-7259_uncollect
Further Problem Description:
|
|
Last Modified: | 29-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux44648 | Title: | Arp reply not sent when received on LACP port-channel in (I) mode |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
N9K does not respond to ARP request for its IP if the ARP request comes in on a port which is in LACP (I) state.
Conditions:
ARP request must come in on individual port which is configured as lacp port-channel
Workaround:
none
delayed lacp can help
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I2(2.32), 7.0(3)I2(2a), 7.0(3)I2(3), 7.0(3)I3(0.193), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.62), 7.0(3)IDP3(2), command |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw87620 | Title: | N9K Kernel Panic watchdog timeout - issue seen on CPU2 |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 9k switch may experience a kernel panic due to a high volume of interrupt events, and the device is overwhelmed with processing interrupts.
Conditions:
High amount of interrupts are being sent to one of the switch's CPUs.
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(1a) |
|
Known Fixed Releases: * | 7.0(3)I2(1.83), 7.0(3)I2(2), 7.0(3)I3(0.205), 7.0(3)I3(1), 7.0(3)IDP3(1.62), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux43453 | Title: | SSTE: On VTEP N9396PX Node, vPC Active VLANs are incorrect |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On N9396PX, after the upgrade from Dublin 165 image to Dublin 170 image for vPC pair that are two N9396PX, or after the reload of the vPC pair, vPC Active VLANs are incorrect.
Conditions:
After the upgrade or reload of vPC pair that are two N9396PX.
Workaround:
Shut and no shut under vPC domain.
Further Problem Description:
|
|
Last Modified: | 01-JAN-2016 |
|
Known Affected Releases: | 7.0(3)I3(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.223), 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw82627 | Title: | after multiple fail issu/impact check, free space error thrown |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Unable to upgrade code on Nexus 9000 using "install all" command.
The following error will be seen
Pre-upgrade check failed. Return code 0x40930062 (free space in the filesystem is below threshold)
Check "show system internal flash"
/var/tmp/volatile utilization will exceed 70%
Conditions:
Seen when
show install all impact check is done
Workaround:
(1) Check and see if tmp directory is over 50% usage
Show system internal flash
none 307200 286972 306972 77% /var/volatile/tmp
(2) Enable feature bash to be able to get into the bash shell
9396-2-38B(config)# feature bash
9396-2-38B(config)# end
9396-2-38B# run bash
bash-4.2$
bash-4.2$ cd /var/volatile/tmp
bash-4.2$ ls -lSh
total 188M
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-np.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-np-cr.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-qc.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-qg.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-qi2.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-qi2-cr.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-qi2-cr-ivy.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-qi2-ivy.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-qi.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-qs.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-qz2.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 8 23:19 bios-x86n-qz.bin.gz
-rw-rw-rw- 1 root root 8.0M Nov 17 23:49 calgary.bin
-rw-rw-rw- 1 root root 8.0M Nov 17 23:49 keystone.bin
-rw-rw-rw- 1 root root 8.0M Nov 17 23:49 kirkwood.bin
-rw-rw-rw- 1 root root 8.0M Nov 17 23:49 nagano.bin
-rw-rw-rw- 1 root root 8.0M Nov 17 23:49 oslo.bin
-rw-rw-rw- 1 root root 8.0M Nov 17 23:49 placid.bin
-rw-rw-rw- 1 root root 8.0M Nov 17 23:49 redmond2.bin
-rw-rw-rw- 1 root root 8.0M Nov 17 23:49 sapporo.bin
-rw-rw-rw- 1 root root 8.0M Nov 17 23:49 sochi.bin
-rw-rw-rw- 1 root root 8.0M Nov 17 23:49 sqvly.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 alta.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 apache.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 blackcomb.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 chicopee.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 cypress.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 honeycomb.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 moena.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 mtrose.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 seymour.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 shasta.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 sierra.bin
-rw-rw-rw- 1 root root 929K Nov 17 23:49 sunridge.bin
Remove these files
bash-4.2$ rm bios*
bash-4.2$ rm *.bin
Please do not delete any other files. Only files in TMP folder is ok to delete.
Call TAC if you see other directory full.
bash-4.2$ exit
Further Problem Description:
|
|
Last Modified: | 09-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(2), 7.0(3)I3(0.123), 7.0(3)I3(0.143), 7.0(3)I3(0.76) |
|
Known Fixed Releases: | 7.0(3)I3(0.171), 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux22173 | Title: | NVRAM Error causing system crash |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When the nvram is getting corrupted repeatedly - due to bad nvram battery etc. The nvram driver gets into a deadlock. This is very rare.
Conditions:
The CMOS/NVRAM battery was in a bad state. Essentially bad hardware
Workaround:
Replace the CMOS battery or replace the hardware.
Further Problem Description:
|
|
Last Modified: | 11-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.182), 7.0(3)I3(1), command, convert_version.pl:, found, not |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux11108 | Title: | Bidir BSR RP prefix grp change failed to propagate through the network |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
BSR RP to grp-range mappings are out-of sync in network.
Conditions:
change in BSR PR prefix list.
Workaround:
Remove RP config on RP-candidate and re-apply.
Further Problem Description:
|
|
Last Modified: | 03-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.123) |
|
Known Fixed Releases: | 7.0(3)I3(0.153), 7.0(3)I3(1), 7.0(3)IDP3(1.24), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv72655 | Title: | ACI: Leaf drops udp destination port 48879 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
udp packet to port 48879 is discarded at leaf's ingress port
Conditions:
version 1.1(1j)
ingress traffic is tagged(for untagged traffic , this issue doesn't happen
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 04-DEC-2015 |
|
Known Affected Releases: | 11.1(1j) |
|
Known Fixed Releases: | 11.1(2.287), 11.2(0.45), 11.2(0.46) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux41281 | Title: | APIC configured with 2 NTP servers w/ 1 prefer does not sync to either |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
An APIC configured with 2 NTP servers where 1 NTP server is preferred does not sync with either NTP server.
Conditions:
Version 1.1(4e)
Workaround:
configure an odd number of NTP servers (1 or 3 or more).
you should configure one, three, or four or more NTP servers. All NTP servers return the time together with an estimate of the current error. When using multiple time servers, NTP also wants these servers to agree on some time, meaning there must be one error interval where the correct time must be. When there are just two NTP servers, there might be an issue if both sources do not fall into the small common range because the NTP client will be unable to determine which source is more correct.
Further Problem Description:
When the fabric switches are presented with 2 NTP servers where each NTP server is more than 1 second different from the system clock, the switch will not sync with either NTP server even if one of the NTP servers is preferred. This is because the preferred concept only comes into consideration when the switch is presented with 2 NTP servers that fall with the dispersion range and must choose one of them to sync with. When both NTP servers are outside a dispersion range resulting in incrementing bad dispersion, the switch will not select either of them to sync with.
|
|
Last Modified: | 04-DEC-2015 |
|
Known Affected Releases: | 11.1(4e) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux43284 | Title: | Properties removed during profile create/edit are still applied anyway |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Properties that the user did not intend to include become part of the profile
Conditions:
When creating or editing a profile, if the user adds and then removes a property, that property will still be applied to the profile
Workaround:
Edit the profile again and remove the property
Further Problem Description:
|
|
Last Modified: | 08-DEC-2015 |
|
Known Affected Releases: | 1.0(0.513) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux42988 | Title: | Disabling a port channel shows an incorrect explanation for its state |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
A port channel disabled by user shows as explanation for being inactive "No active member in the port-channel".
Conditions:
A port channel has been disabled by the user.
Workaround:
No workaround. Cosmetic issue.
Further Problem Description:
|
|
Last Modified: | 08-DEC-2015 |
|
Known Affected Releases: | 1.0(0.618) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux46855 | Title: | vpc ext-svi: del/add vrf cfg from a leaf also need switchport cfg on vpc |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Deleting and adding vrf on a Leaf may not deploy ext-svi on vpc.
Conditions:
1) SVI over VPC deployed on nodes A and B
2) Suppose, VRF on node A is removed using "no vrf context ..." command
3) This ends up cleaning up VPC + SVI interfaces from Node B for that tenant+VRF
4) However, the L2 VPC interface still holds the SVI information on node A. But without Node B (that got deleted in #3 above), there will be no ext-svi deployment over VPC
5) Even if the VRF is added back on node A and the SVI interface re-created, there will be no ext-svi deployment over VPC.
Workaround:
The only way to get back ext-svi deployment is to re-associate SVI to L2 VPC interface using "switchport { trunk allowed | native allowed | access } vlan tenant external-svi"
Further Problem Description:
|
|
Last Modified: | 09-DEC-2015 |
|
Known Affected Releases: | 1.2(1c) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw65466 | Title: | ACI: inappropriate I/Fs on APIC GUI Tenants>EPG>Operational>Client EP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Unnecessary interfaces show up on Interface section under APIC GUI Tenants > EPG > Operational tab > Client End-Points.
Node-102/tunnel12(learned)
Node-101-102/vPC1(vmm)
Node-101-102/TEMP_vPC1(vmm) <---- I/F not connected to vmm domain devices
Node-101-102/TEMP_vPC2(vmm) <---- I/F not connected to vmm domain devices
Node-101-102/TEMP_PC1(vmm) <---- I/F not connected to vmm domain devices
Node-101-102/TEMP_PC2(vmm) <---- I/F not connected to vmm domain devices
Conditions:
This happens for endpoints with opflex such as AVS or Openstack with opflex.
These unnecessary interfaces are the one included in the same AEP associated to VMM domain, however not connected to vmm domain devices with that end-point.
These interfaces are only PC or vPC. This didn't somehow happen on individual ports.
They show up on GUI even if they are not UP.
Workaround:
No functional impacts have been observed. This impacts only for ease of operations.
Please remove unnecessary I/Fs from AEP for VMM domain with opflex.
Further Problem Description:
|
|
Last Modified: | 09-DEC-2015 |
|
Known Affected Releases: | 1.1(2h), 1.1(3f), 1.2(0.139k) |
|
Known Fixed Releases: * | 1.2(0.239a), 1.2(1i) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv29468 | Title: | Need a way to collect more information on PHY issues during linkscan |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Enhancement request for better event logging of PHY level issues in SDK event history
Conditions:
This is an enhancement to show mdio log which will show the mdio registers that are being accessed by the PHY driver to debug any problem with the PHY>
Workaround:
Enhancement.
Further Problem Description:
Enhancement.
|
|
Last Modified: | 11-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I3(4b) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.161), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), command, convert_version.pl:, found, not |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux42547 | Title: | adding first prefix in route-map overrites import-security flag |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
For a external-l3 (l3extOut object) configuration created through API(say out1) and if that l3extOut has a external-l3 epg (say out1:p1 where out1 is the l3extOut and p1 is the external-l3 epg), on creating a prefix-list with the same name through CLI (prefix-list p1 in route-map out1_out), the external-l3 epg (out1:p1) gets deleted.
Conditions:
1. There is an API created l3out.
2. This l3out has an l3extInstP that has all its subnets with scope set to 'import-security'.
3. A prefix-list with a prefix that is same as one of l3extInstP's subnets is added to the route-map _{in|out|shared}.
Workaround:
The prefix that got deleted from prefix EPG after prefix-list addition can be manually added back to the external-l3 EPG.
Further Problem Description:
|
|
Last Modified: | 10-DEC-2015 |
|
Known Affected Releases: | 1.2(1c) |
|
Known Fixed Releases: * | 1.2(1.79a), 1.2(1.81) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux27456 | Title: | should be able to reset bgp password from simple gui |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
no way to reset bgp password
Conditions:
no way to reset bgp password
Workaround:
Further Problem Description:
no way to reset bgp password
|
|
Last Modified: | 11-DEC-2015 |
|
Known Affected Releases: | 1.2(0.270b) |
|
Known Fixed Releases: * | 1.2(0.280), 1.2(1.74), 1.2(1i) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw31368 | Title: | N9K: shut down for PC memeber interfaces not working |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Not able to shut down physical interfaces part of port-channel
Conditions:
NX-OS upgrade to 7.0(3)I2(1)
Workaround:
Configure "switchport" (or "no switchport" - depending on what the correct layer of the PC interface should be) under PC interface, then member physical interface can be shut down.
Also, please check the output of "show running-config po all" and get the value of MTU configured on the PC.
Configure that also on the PC.
Further Problem Description:
|
|
Last Modified: | 12-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.19), 7.0(3)I2(1a), 7.0(3)I2(2), 8.3(0)CV(0.248) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw12835 | Title: | Unable to delete username with privilege feature enabled |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Cannot delete username.
Conditions:
When feature privilege is enabled, unable to delete the username.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 12-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.41), 7.0(3)I2(2), 8.3(0)CV(0.248) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux43098 | Title: | ACI : LACP/BGP or other control plane protocols should be prioritized |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
High CPU on Leaf caused loss of LACP PDUs
Conditions:
Workaround:
Ensure EP configuration, teaming configuration is in-line with switch config.
Further Problem Description:
|
|
Last Modified: | 12-DEC-2015 |
|
Known Affected Releases: | 11.0(4k) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw77598 | Title: | show install packages crashes VSH |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
VSH cores when 'show install package' cli is executed.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 12-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.52), 7.0(3)I2(2), 8.3(0)CV(0.248) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux52183 | Title: | after failed issu/impact check, run out of free space /var/volatile/tmp |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
sys03-eor1(config)# install all nxos bootflash:nxos.7.0.3.I2.2a.bin parallel
Installer will perform compatibility check first. Please wait.
Installer is forced disruptive
Verifying image bootflash:/nxos.7.0.3.I2.2a.bin for boot variable "nxos".
[####################] 100% -- SUCCESS
....
Do you want to continue with the installation (y/n)? [n]
sys03-eor1(config)# 2015 Dec 11 12:16:48 sys03-eor1 %$ VDC-1 %$ %VMAN-2-ACTIVATION_STATE: Successfully activated virtual service 'guestshell+'
sys03-eor1(config)#
sys03-eor1(config)#
sys03-eor1(config)# show system inter flash | grep volatile
none 51200 4768 46432 10% /var/volatile/log
none 307200 222300 84900 73% /var/volatile/tmp
none 614400 0 614400 0% /volatile
sys03-eor1(config)#
sys03-eor1(config)# install all nxos bootflash:nxos.7.0.3.I2.2a.bin parallel
Installer will perform compatibility check first. Please wait.
Installer is forced disruptive
Pre-upgrade check failed. Return code 0x40930062 (free space in the filesystem is below threshold).
sys03-eor1(config)#
sys03-eor1(config)#
Conditions:
Hi Vishal/Ganesh/Linda,
This is the bug and is in V state. Linda has fixed it.
Can you confirm if this is same and if the below diff can help. As the diff shows handling or rmving files from /var/volatile/tmp in addition to /var/sysmgr that was existing before..
sysmgr_system_cmd("/bin/rm /var/volatile/tmp/bios-x86n*.bin.gz",
CSCuw82627 after multiple fail issu/impact check, free space error thrown
If this is a trivial point fix guess we can take it. Others pls let know otherwise..
Thanks,
Hema.
Diff shows
*************** static void cleanup_single_img_tmp()
*** 2344,2355 ****
ret = sysmgr_system_cmd("/bin/rm -rf /var/sysmgr/tmp/sys_img", NULL,
installer_info.dbg_log_fp, installer_info.log_fp);
if (ret != 0) {
DEBUG_PRINT("system(rm) failed: %d: pid %d\n", ret, getpid());
}
- }
void fsm_action_srv_installer_done(installer_state_t old_state)
{
syserr_t syserr;
--- 2344,2367 ----
ret = sysmgr_system_cmd("/bin/rm -rf /var/sysmgr/tmp/sys_img", NULL,
installer_info.dbg_log_fp, installer_info.log_fp);
if (ret != 0) {
DEBUG_PRINT("system(rm) failed: %d: pid %d\n", ret, getpid());
}
+ ret = sysmgr_system_cmd("/bin/rm /var/volatile/tmp/bios-x86n*.bin.gz", NULL,
+ installer_info.dbg_log_fp, installer_info.log_fp);
+ if (ret != 0) {
+ DEBUG_PRINT("system(rm bios-x86n) failed: %d: pid %d\n", ret, getpid());
+ }
+
+ ret = sysmgr_system_cmd("/bin/rm /var/volatile/tmp/*.bin", NULL,
+ installer_info.dbg_log_fp, installer_info.log_fp);
+ if (ret != 0) {
+ DEBUG_PRINT("system(rm bin) failed: %d: pid %d\n", ret, getpid());
+ }
+
+ }
void fsm_action_srv_installer_done(installer_state_t old_state)
{
syserr_t syserr;
From: Vishal Jain (vishalja)
Sent: Thursday, December 10, 2015 9:26 PM
To: Hema Subash (hsubash); Ganesh Narayanaswamy (ganesnar); Venkatesh Srinivasan (venksrin); Umesh Mahindra (umahindr); Alok Rathore (arathore); Natarajan ManthiraMoorthy (
|
|
Last Modified: | 14-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(2), 7.0(3)I2(2a), 7.0(3)I3(0.123), 7.0(3)I3(0.143), 7.0(3)I3(0.76) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux04368 | Title: | NIF ports missing in vlan flood table on switchover & fex reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Flooded/broadcast traffic may be dropped on some FEX interface after a sup switchover followed by a FEX reload.
Conditions:
After a sup switchover (or) a specific (ELTM) process crashes, and then FEX is reloaded,
some FEX NIFs may not have the flood table programmed properly.
Workaround:
Deleting/adding of the vlan can recover from the condition.
Further Problem Description:
|
|
Last Modified: | 15-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1.81) |
|
Known Fixed Releases: | 7.0(3)I2(1.88), 7.0(3)I2(2), 7.0(3)I2(2.22), 7.0(3)I2(2a), 7.0(3)I2(2x), 7.0(3)I2(3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw57032 | Title: | ifc-svc:deleting one AVI SE causes deleting shared LIFs of other SEs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
all vNIC of AVI service engine VMs are put into quarantine portgroup after one of SEs being removed in AVI controller.
Conditions:
one of several service engine VM is deleted from services.
Workaround:
Manually assign the right port-group back to those remaining service engine VMs.
Further Problem Description:
Debug log showing the deletion....
807||15-10-06 15:25:24.953+00:00||aaa||DBG4||co=doer:3:1:0x180000000038c5e4:1,dn=uni||Skip RBAC writeability checks because no props changed||../common/src/framework/./core/mo/Mo.cc||278
807||15-10-06 15:25:24.953+00:00||aaa||DBG4||co=doer:3:1:0x180000000038c5e4:1,dn=uni||Skip RBAC writeability checks because no props changed||../common/src/framework/./core/mo/Mo.cc||278
807||15-10-06 15:25:24.953+00:00||aaa||DBG4||co=doer:3:1:0x180000000038c5e4:1,dn=||Skip RBAC writeability checks because no props changed||../common/src/framework/./core/mo/Mo.cc||278
@
|
|
Last Modified: | 17-DEC-2015 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: * | 1.1(3.4), 1.2(0.155), 1.2(1.17), 1.2(1i), 2.0(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux55114 | Title: | SSTE: On VTEP N9396PX, remote VTEPs MACs are missing in H/W mac table |
|
Status: * | Other |
|
Severity: * | 3 Moderate |
Description: | Symptom:
On VTEP N9396PX running Dublin 184 image, some remote VTEPs MACs are missing in H/W mac table when 90K remote MACs are learned.
Conditions:
When 90K remote MACs are learned from remote 90 VTEPs.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux01970 | Title: | Duplicated IPv6 PKT when PING to vPC VTEP's loopback in VRF |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Duplicate ping6 reply is seen when pinging vPC vtep's loopback in VRF
Conditions:
ICMPv6 Echo is received on vPC VTEP and routed to vPC peer VTEP.
Workaround:
None
Further Problem Description:
Duplicated IPv6 PKT when PING to vPC VTEP's loopback in VRF
ICMPv6 request/reply coming from vxlan overlay, the packet is copied
twice to Sup.
|
|
Last Modified: | 18-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1a) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I2(2.32), 7.0(3)I2(2a), 7.0(3)I2(3), 7.0(3)I3(0.166), 7.0(3)I3(1), command, convert_version.pl:, found, not |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux18677 | Title: | Reset reason shows 'Unknown' on system reload after EPLD |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On system reload after EPLD upgrade Reset reason from 'show version' and 'show system reset-reason'
would show 'Unknown'. This is a cosmetic issue and will be fixed in later releases.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 18-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I3(4b), 7.0(3)I2(2) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I2(2.32), 7.0(3)I2(2a), 7.0(3)I2(3), 7.0(3)I3(0.145), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.11), 7.0(3)IDP3(1.19), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux61740 | Title: | Need better SW handling for NMI due to FPGA CRC Error |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Enhancement request to better handle FPGA CRC errors
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(3), 7.0(3)I2(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu26485 | Title: | router bgp <x> and no router bgp <x> causes CLI timeout |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | It eventually recoversafter this msg is seen:FEATURE-MGR-2-FM_FEATURE_OP_TIMEOUT_ERROR: feature bgp operation failed on response timeout from service: bgp with uuid (0x11b)2015 May 8 16:16:08 spine-1 clis[5549]: FM enable feature "bgp" error : (0x40aa0008 == operation timeout == T-0x1/F-0x0550/E-0x0008)
Symptom:
router bgp x
no router bgp x
may cause CLI to timeout
Conditions:
It eventually recovers
after this msg is seen:
FEATURE-MGR-2-FM_FEATURE_OP_TIMEOUT_ERROR: feature bgp operation failed on response timeout from service: bgp with uuid (0x11b)
2015 May 8 16:16:08 spine-1 clis[5549]: FM enable feature "bgp" error : (0x40aa0008 == operation timeout == T-0x1/F-0x0550/E-0x0008)
Workaround:
If user wants to cut-n-paste router bgp.. multiple times (not sure what the use case is here), pls use the following workaround of adding sleep.
router bgp 100
sleep 60
no router bgp 100
sleep 60
router bgp 100
sleep 60
etc...
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(1), 7.0(3)I1(1.233) |
|
Known Fixed Releases: * | 7.0(3)I1(1.243), 7.0(3)I1(2), 7.3(0)D1(0.187), 7.3(0)ZD(0.205) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux63394 | Title: | N9k-Evpn-Ping fails from BL in act/standby static route scenario |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
N9k1
|
N9k2???evpn???N9K4
\ /
3750
|
216.129.219.41 (loopback)
N9k2 and N9k4 are the Border Leaf (non-vpc) connected to CE(3750) in same vlan and both have a static route to 3750's loopback.
vrf context 11099
vni 40599
ip route 216.129.219.41/32 216.129.21.26
N9k2 link to 3750 is standby/suspended state and N9k4 is active.
Ping fails from N9k2 to the loopback of 3750 but works from N9k1(another leaf) transiting through it or from devices directly connected to N9k2.
Conditions:
N9k configured as Border leafs running 7.0(3)I2(2) code.
Workaround:
Use HMM tracking with static route or source the ping from device behind N9k2 or another leaf in fabric.
track 1 ip route 216.129.21.26/32 reachability hmm
vrf context 11099
vni 40599
ip route 216.129.219.41/32 216.129.21.26
Further Problem Description:
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.99) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCur38739 | Title: | Mismatch Between dhcp:Pool:freeIPs and DHCP Leases |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The dhcp:Pool:freeIPs property is reported as 0 (zero) even though there are less than 32 leases for IP addresses within the pool.
Conditions:
Workaround:
Unknown at this time.
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 1.0(1k) |
|
Known Fixed Releases: | 1.0(3.15), 1.1(1j) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux43024 | Title: | Configure vrf filter for fabrc SPAN source errors out in CLI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Configuration of VRF or context filter for SPAN-ing fabric ports via CLI is not successful.
Conditions:
None.
Workaround:
Configure either a BD-filter or configure the context filter via GUI or REST API.
Further Problem Description:
|
|
Last Modified: | 22-DEC-2015 |
|
Known Affected Releases: | 1.2(1e) |
|
Known Fixed Releases: * | 1.2(1.109), 1.2(1.84) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw53430 | Title: | XML/JSON o/p of show lldp dxbx interface shows wrong value |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
invalid value of tlv in XML/JSON output of show lldp dcbx interface
Conditions:
Take XML/ JSON output of show lldp dcbx interface
Workaround:
NA
Further Problem Description:
NA
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)IFD1(0.17) |
|
Known Fixed Releases: * | 7.0(3)I3(0.173), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw41065 | Title: | Redistribute static is interpreted as redistribute direct and vice versa |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Upon negate of ?redistribute static xxx?, CLIServer is mapping incorrectly to ?no redistribute direct xxx? command, and vice versa.
Conditions:
This problem/issue happens when both the redistribute 'static' and 'direct' are configured.
Workaround:
There is no workaround.
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.24), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw34696 | Title: | SNMPwalk - OID not incrementing for rip2IfStatAddress w/ multiple IP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Mibwalk rip2IfStatAddres, observed OID not incrementing, keep looping.
Conditions:
when HSRP or multiple IP's are configured under RIP enabled interface.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)IX1(1.229) |
|
Known Fixed Releases: * | 7.0(3)I2(1.19), 7.0(3)I2(2), 7.1(0)I3(0.19), 7.1(0)I3(1), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv02994 | Title: | cieIfUtilTable is always return 0, instead cli value. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
cieIfUtilTable still showing 0 values instead actual Packet Rate.
Problem exists in 6.1.2.I1.1.
Fix had been integrated into 7.0.(3).I2.1.
Conditions:
Always.
Workaround:
Use "show interface ..." CLI to get the equivalent information
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.418) |
|
Known Fixed Releases: * | 7.0(3)I2(0.491), 7.0(3)I2(0.500), 7.0(3)I2(0.524), 7.0(3)I2(0.527), 7.0(3)I2(0.577), 7.0(3)I2(0.579), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.15), 7.0(3)IMK2(1.65) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv88252 | Title: | Crash @ qosmgr_dce_print_cos2q_maps |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Nexus 9K crashes with ipqosmgr on running the command show class-map type queuing c-out-8q-q-default
Conditions:
When running the command show class-map type queuing c-out-8q-q-default
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(2), 7.0(3)IND2(1.64) |
|
Known Fixed Releases: * | 6.1(2)I3(4.25), 6.1(2)I3(5), 7.0(3)I1(2.21), 7.0(3)I1(3), 7.0(3)I2(0.576), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv32523 | Title: | syslogd hap reset when invoking /dev/log for syslogd through python |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Syslogd crashes when python script is invoked to log syslog
Conditions:
pyhton script is loaded on n9k and run to log syslog on the switch
Workaround:
modified python script to add date and timestamp before writing message to /dev/log for logging syslog. If message is passed in proper format, then syslog is getting logged on the console and syslogd doesn't crash
Further Problem Description:
Syslog expects message in a particular format and continues with the processing. Unformatted message was causing the crash.
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I2(0.565), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw50298 | Title: | Pause Frame not dropped on HIF without LLFC on |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
HIF port on FEX connected to Nexus9300 will forward pause frame to fabric port channel.
By default LLFC is "OFF" on HIF. Which means if it receives "pause" for device connected to HIF it should consume and not forward.
Conditions:
This is only for HIF ports on FEX.
Workaround:
Enable 'receive flow-control' on FEX ports result of this FEX port 'absorbs' pause frames instead of flooding them to parent device.
Transmit flow-control is enabled on FEX ports by defaul.
interface Ethernet102/1/4
flowcontrol receive on
switch(config)# int et 102/1/4
switch(config-if)# flowcontrol receive on
switch(config-if)# sh interface ethernet 102/1/4 flowcontro
--------------------------------------------------------------------------------
Port Send FlowControl Receive FlowControl RxPause TxPause
admin oper admin oper
--------------------------------------------------------------------------------
Eth102/1/4 on off on on 0 0
switch(config-if)#
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(3) |
|
Known Fixed Releases: * | 7.0(3)I2(1.38), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup35239 | Title: | Packets egressing via Northstar port not seen with ethanalyzer |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Ethanalyzer does not show captured packets going out L3 interfaces attached to northstar ports.
Conditions:
Nexus 9k with L3 ports on northstar asic
Version: 6.1(2)I1(2a) or later
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I2(2a) |
|
Known Fixed Releases: * | 7.0(3)I2(1.38), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv24927 | Title: | N9K - DHCP Traffic Punted to Control Plan w/o SVI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
DHCP packets are seen at the control plane of a Nexus 9000 Series Switch
Conditions:
No SVI for the vlan the DHCP traffic is traversing the switch in
DHCP Feature not enabled
DHCP Snooping not configured
DHCP Relay not configured
Workaround:
Contact Cisco TAC
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I3(3a), 6.1(2)I3(4b), 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I2(0.568), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux07629 | Title: | SSTE: n9k- Error message & password validation inconsistency |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Error message & password validation inconsistency
Conditions:
config
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.62) |
|
Known Fixed Releases: * | 7.0(3)I3(0.155), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut48218 | Title: | ISIS: forwarding adjacency next-hops unresolved after reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After reload or power-cycle, ISIS next-hop forwarding adjacencies remain unresolved.
Conditions:
This is seen with configurations in which BFD is NOT present, since BFD masks
the issue.
Workaround:
1. The issue can be resolved by pinging the next-hop
2. If bfd is enabled, the issue will not be seen
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(1) |
|
Known Fixed Releases: * | 7.0(3)I2(0.542), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw74970 | Title: | n9k doesn't count input error, but count Symbol Error |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
n9k doesn't count input error, but count Symbol Error
Conditions:
- n9k count "Symbol-Err" on "show interface counter error"
- but n9k doesn't count "input error" on "show interface"
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I3(3a) |
|
Known Fixed Releases: * | 7.0(3)I2(1.51), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur86374 | Title: | Load interval set-to random high value after port breakout |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Running "show interface" may show very high load-interval value on some interfaces.
Ex:
503316480 seconds input rate 0 bits/sec, 0 packets/sec
503316480 seconds output rate 0 bits/sec, 0 packets/sec
Conditions:
Issue was noticed when MTS stats timeout occurred. This could be due some other process running in the background causing MTS stats process to timeout.
"show interface" command execution could be slow when this happens.
Workaround:
This is a cosmetic bug. When MTS stats timeout occurs, software is incorrectly returning 503316480 for load-interval.
Issue is seen at random. There is no functional impact due to high load-interval value.
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(0.157) |
|
Known Fixed Releases: * | 7.0(3)I2(1.51), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw01873 | Title: | sh tech plcmgr detail return mts_print traceback on console |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
With a large OpenFlow configuration (32,000 L2 flows and 3,000 L3 flows) applied, attempts to run the command "show tech plcmgr detail" may result in the following failure:
%KERN-2-SYSTEM_MSG: [19232.955952] "show tech plcmgr detail" in sap 6907, uuid 0 send_opc 7679, pid 7741, proc_name plcmgr - kernel
mts_acquire_q_space() failing - no space in sap ... - kernel
mts_is_q_space_available_haslock_old(): NO SPACE ...
Conditions:
Only occurs when a large OpenFlow configuration is applied.
Workaround:
Save the log/show_tech to a file in bootflash:
show tech plcmgr detail > xxx.txt
In this way, CLI no crash.
Further Problem Description:
After installing 35,000 flows, the switch will have many PPF nodes. The "show tech plcmgr detail" command was simply trying to print all thesey PPF nodes at once and this fills up the MTS buffers and fails the command.
Our fix is to print the nodes in multiple loops.
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.568), 7.0(3)I2(0.585) |
|
Known Fixed Releases: * | 7.0(3)I2(1.7), 7.0(3)I2(2), 7.0(3)I3(0.128), 7.0(3)I3(1), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw67332 | Title: | Mac Address flapp in Vlan 1 between Admin Shut down ports -Nexus9000 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
MAC address flapping only in Vlan 1 between random ports and some of the ports are in "Admin shut"
Conditions:
vPC and system configured to operate in spanning tree MST mode and receiving FcOE FIP Vlan request frame.
Workaround:
None
Further Problem Description:
No production impact
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I2(1.52), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux27489 | Title: | BFD timer configuration change is not getting applied to running config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When non-default BFD timers are configured they are not inserted into running config.
Default BFD timers don't have any issues.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.144) |
|
Known Fixed Releases: * | 7.0(3)I2(2.15), 7.0(3)I2(2a), 7.0(3)I2(2x), 7.0(3)I2(3), 7.0(3)I3(0.159), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun26341 | Title: | Enhancement Request: Send hostname in SYSLOG message |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
No hostname (or ipaddr for that matter) in SYSLOG msg content.
tcpdump
-----------------------------------------------------------------
Raw message received from 'v6-n9508-agg1' (192.168.10.191):
root@avr-lubuntu[~]# tcpdump -nXli eth1 host 192.168.10.191 and port 514
16:15:23.043290 IP 192.168.10.191.514 > 192.168.12.220.514: SYSLOG local7.notice, length: 115
0x0000: 4500 008f 3227 0000 3f11 b04b c0a8 0abf E...2'..?..K....
0x0010: c0a8 0cdc 0202 0202 007b 1346 3c31 3839 .........{.F<189
0x0020: 3e3a 2032 3031 3420 4665 6220 3139 2031 >:.2014.Feb.19.1
0x0030: 393a 3134 3a35 3920 4553 543a 2025 5653 9:14:59.EST:.%VS
0x0040: 4844 2d35 2d56 5348 445f 5359 534c 4f47 HD-5-VSHD_SYSLOG
0x0050: 5f43 4f4e 4649 475f 493a 2043 6f6e 6669 _CONFIG_I:.Confi
0x0060: 6775 7265 6420 6672 6f6d 2076 7479 2062 gured.from.vty.b
0x0070: 7920 6164 6d69 6e20 6f6e 2031 3932 2e31 y.admin.on.192.1
0x0080: 3638 2e31 322e 3232 3040 7074 732f 31 68.12.220@pts/1
Note above there is no information in the actual msg indicating where the msg came from. This is in contrast to messages received from ASR1Ks. Here is an example from 'v6-asr1k-pe1' (192.168.10.195) in response to a 'conf t' and 'ctrl-z':
root@avr-lubuntu[~]# tcpdump -nXli eth1 host 192.168.10.195 and port 514
16:31:51.719438 IP 192.168.10.195.57055 > 192.168.12.220.514: SYSLOG local7.notice, length: 121
0x0000: 4500 0095 0a73 0000 fe11 18f5 c0a8 0ac3 E....s..........
0x0010: c0a8 0cdc dedf 0202 0081 5798 3c31 3839 ..........W.<189
0x0020: 3e33 3135 353a 2076 362d 6173 7231 6b2d >3155:.v6-asr1k-
0x0030: 7065 313a 202a 4665 6220 3139 2031 373a pe1:.*Feb.19.17:
0x0040: 3330 3a31 322e 3934 303a 2025 5359 532d 30:12.940:.%SYS-
0x0050: 352d 434f 4e46 4947 5f49 3a20 436f 6e66 5-CONFIG_I:.Conf
0x0060: 6967 7572 6564 2066 726f 6d20 636f 6e73 igured.from.cons
0x0070: 6f6c 6520 6279 2061 646d 696e 206f 6e20 ole.by.admin.on.
0x0080: 7674 7931 2028 3139 322e 3136 382e 3132 vty1.(192.168.12
0x0090: 2e32 3230 29 .220)
You can clearly see in the dump above (ASCII interpreted column on the right) that the hostname is part of the syslog message.
On ASR1K we can specify "logging origin_id hostname". Something similar to this would be great on N9K, or maybe better put, in NX-OS (I'm not sure if this is a limitation of all NX-OS devices or just N9K).
Conditions:
Here is how the environment was configured:
Unlike the ASR1Ks, since the Nexus 9Ks do not appear send hostname, nor provide any configuration knobs to specify an "origin-id", we had to key off ipaddr:
root@avr-lubuntu[~]# cat /etc/rsyslog.d/40-network.conf
:fromhost-ip, startswith, "192.168" /var/log/network/all.log
:msg, contains, "v6-asr1k-pe1" /var/log/network/v6-asr1k-pe1.log
& ~
:msg, contains, "v6-asr1k-pe2" /var/log/network/v6-asr1k-pe2.log
& ~
:msg, contains, "v6-asr1k-pe3" /var/log/network/v6-asr1k-pe3.log
& ~
:fromhost-ip, isequal, "192.168.10.191" /var/log/network/v6-n9508-agg1.log
& ~
:fromhost-ip, isequal, "192.168.10.192" /var/log/network/v6-n9508-agg2.log
& ~
:fromhost-ip, isequal, "192.168.10.193" /var/log/network/v6-n9396-p1a.log
& ~
:fromhost-ip, isequal, "192.168.10.194" /var/log/network/v6-n9396-p1b.log
& ~
:fromhost-ip, isequal, "192.168.10.198" /var/log/network/v6-n6001-trsw1.log
& ~
:fromhost-ip, isequal, "192.168.10.199" /var/log/network/v6-n6001-trsw2.log
& ~
:fromhost-ip, isequal, "192.168.100.51" /var/log/network/v6-gold101-csr1
& ~
:fromhost-ip, isequal, "192.168.101.51" /var/log/network/v6-gold101-csr2
& ~
:fromhost-ip, isequal, "192.168.112.51" /var/log/network
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I2(0.159) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.166), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), command, convert_version.pl:, found |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux39834 | Title: | N9K Vxlan Remote mac not relearned after vlan is deleted re-added on vpc |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Remote MAC address is not learned on a VPC primary.
Conditions:
The conditions and triggers for this defect are very specific
1) Vlan needs to be removed on the VPC secondary
2) Vlan needs to be added back on the VPC secondary
3) This will result in:
- VPC secondary learning remote MAC address
- VPC secondary learning local MAC address
- VPC Primary learning local MAC
Workaround:
Either
- remove/readd the vlan on the VPC primary
- clear mac add dynamic on the VPC primary
Further Problem Description:
|
|
Last Modified: | 24-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(2) |
|
Known Fixed Releases: * | 7.0(3)I2(2.39), 7.0(3)I2(2a), 7.0(3)I2(3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv96212 | Title: | "[FSM:FAILED]:Task for updating FNV(TASK:ifc:dhcpd:DhcpClientUpdateFnv) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ACI 1.1(1j), A major fault against DHCP client with the description "[FSM:FAILED]:Task for updating FNV(TASK:ifc:dhcpd:DhcpClientUpdateFnv)
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 24-DEC-2015 |
|
Known Affected Releases: * | 1.1(1j), 1.1(1r) |
|
Known Fixed Releases: | 1.1(2.53), 1.1(3f), 1.2(0.104a), 1.2(0.107), 1.2(0.94), 1.2(1.17), 1.2(1i), 2.0(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03670 | Title: | Agent trying to delete vmmDomain after it came online again. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
The APIC will have a connect-failed Fault Code F1676 to the SCVMM and the SCVMM logs will indicate an exception 12/17/2015 3:03:41 PM-23596-14||UpdateVmmDomains|| Failed: Cleanup
vmmDomain failed to update new cloud from old
cloud
Conditions:
Version 1.1(4e)
Workaround:
Further Problem Description:
|
|
Last Modified: | 24-DEC-2015 |
|
Known Affected Releases: | 1.2(0.80a) |
|
Known Fixed Releases: | 1.2(0.104a), 1.2(0.107), 1.2(1.17), 1.2(1i), 2.0(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux52079 | Title: | N9k:No separation b/w context name and protocol inst in Sh snmp context |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show snmp context
Conditions:
show command on SNMP
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 27-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.140) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.189), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), command, convert_version.pl:, found |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux44737 | Title: | Python: cli_execution_error when executing commands on module |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When using the Python API to retrieve the output of commands from a module a cli_exec_error will be reported>>> output = cli('slot 1 quoted \"show clock\"')
Traceback (most recent call last):
File "", line 1, in
File "/isan/python/scripts/cli.py", line 38, in cli
raise cmd_exec_error(msg)
errors.cmd_exec_error: 'non-option ARGV-elements: clock \n'
Conditions:
Use Python API to retrieve commands from a Nexus 9500 Module.
Workaround:
Retrieve the output of the commands via console, telnet or ssh
Further Problem Description:
|
|
Last Modified: | 27-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1a) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.178), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), command, convert_version.pl:, found |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux50198 | Title: | switch logs tech support contains db and cli tech support |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The tech support that contains ACI Switch logs also contains ACI switch database and CLI tech supports.
Conditions:
This occurs on 11.1 version of ACI Switch software when a non-local tech support is collected.
Workaround:
None
Further Problem Description:
None
|
|
Last Modified: | 26-DEC-2015 |
|
Known Affected Releases: | 11.1(3f) |
|
Known Fixed Releases: * | 1.2(1.117) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux38308 | Title: | ifTableLastChange is not updating after add/remove nve interface. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ifTableLastChange is not updating after add/remove nve interface.
Conditions:
Add or remove nve interface with command "[no] interface nve 1" and mibwalk ifTableLastChange object.
Workaround:
None.
Further Problem Description:
The fix exists in NXOS software release 7.0(3)I3(1)
|
|
Last Modified: | 27-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.163) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.177), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), command, convert_version.pl:, found, not |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux41327 | Title: | Evaluation of n9k-standalone-sw for OpenSSL December 2015 vulnerabilitie |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Cisco Nexus 9000 Series (standalone, running NxOS) includes a version of OpenSSL that is affected by the vulnerability identified by one or more of the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-3193, CVE-2015-3194, CVE-2015-3195, CVE-2015-3196 and CVE-2015-1794
And disclosed in http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20151204-openssl
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent.
Cisco has reviewed and concluded that this product is affected by one or more of these vulnerabilities.
Cisco Nexus 9000 Series (standalone, running NxOS) is affected by:
CVE-2015-3195
Cisco Nexus 9000 Series (standalone, running NxOS) is not affected by:
CVE-2015-3193, CVE-2015-3194, CVE-2015-3196 and CVE-2015-1794
Workaround:
Not available.
Further Problem Description:
Additional details about those vulnerabilities can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 4.3/3.4
http://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 27-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I3(5), 7.0(3)I2(2) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.182), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), command, convert_version.pl:, found, not |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux56499 | Title: | Same VRF tag gets displayed repeatedly on XML of sh bgp all summary|xml |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Same VRF tag gets displayed repeatedly on XML of "sh bgp all summary | xml"
nxos-pe1(config-evpn-evi)# show bgp all summary | xml
<__readonly__>
default
1.1.1.1
100
1
1
default
1.1.1.1
100
2
1
Conditions:
No conditions.
Workaround:
Take XML for a specific AFI SAFI you are interested, such as "show bgp ipv4 unicast summary | xml "
Further Problem Description:
None
|
|
Last Modified: | 27-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.180) |
|
Known Fixed Releases: * | 7.0(3)I3(0.195), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.3(0)D1(0.190), 7.3(0)N1(0.246), 7.3(0)N1(1), 7.3(0)ZD(0.208), 7.3(0)ZN(0.222) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw66057 | Title: | Interop issue with Intel NIC causes 10G to link up @ 1G |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Interop issue with Intel NIC running on certain server vendor links up at 1 G instead of 10G
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I1(3) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I2(1.56), 7.0(3)I2(1.74), 7.0(3)I2(2.14), 7.0(3)I2(2a), 7.0(3)I2(3), 7.0(3)I3(0.132), 7.0(3)I3(0.197), 7.0(3)I3(0.87), 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux52707 | Title: | BFD timer not able to change in some sequence - CSCux27489 patch |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
When using "bfd interval min_rx multiplier " on 2.2 image, under some scenarios, the config does not go thru.
Conditions:
After reloading the box with 2.2 image which had the above mentioned config, changing it to some other values does not take effect.
Also, when config is not taking effect and customer tries to upgrade to 2.2a or to 2.2x image, then also the above config might not take effect.
Workaround:
Workaround is to first load 2.2a or 2.2x image or apply released patch on top of 2.2 image and then undo the "bfd interval config" and then reconfigure.
Further Problem Description:
Issue happens because sometimes stale config gets persisted but not applied. To get out of the problem, user can undo/change the config to some other value and then try to reconfigure. From then onwards, one can use the system as usual without having to worry about this. The issue can potentially be seen one time only until the user tries the workaround steps.
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(2) |
|
Known Fixed Releases: * | 7.0(3)I2(2.29), 7.0(3)I2(3), 7.0(3)I3(0.191), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.62), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv43018 | Title: | aclqos crash after heartbeat failure |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"aclqos" crashed following a heartbeat failure
Conditions:
When an application makes an RPC call (request), a lock is held, and if for any reason the response does not have the right RPC sequence number, the lock is not released, potentially leading to heartbeat miss. To prevent this, the lock is held for a small finite time instead of holding lock infinitely.
Workaround:
To prevent this, the lock is held for a small finite time instead of holding lock infinitely.
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I1(3.4) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.197), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.62), 7.0(3)IDP3(2), command, convert_version.pl:, found |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux52085 | Title: | N9k: Invalid help while configuring snmp host |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
configuring snmp host
Conditions:
config/SNMP
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 27-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.140) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.189), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), command, convert_version.pl:, found |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux43297 | Title: | A closed summary pane cannot be reopened by clicking on the same tile |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
The summary pane is closed and clicking the same tile does not reopen it
Conditions:
This issue will happen after closing the summary pane for any tile
Workaround:
Click on any other tile to open the summary pane, and then click the original tile again. If there are no other tiles available, refresh the web browser page.
Further Problem Description:
|
|
Last Modified: | 07-DEC-2015 |
|
Known Affected Releases: | 1.0(0.398) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux43296 | Title: | Tasks for adding members appear to show the object itself being created |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
The task summary shows that an object was created instead of members being added
Conditions:
This issue will be seen for any action that adds members to an object
Workaround:
There is no workaround for this issue, but it is purely cosmetic in nature
Further Problem Description:
|
|
Last Modified: | 07-DEC-2015 |
|
Known Affected Releases: | 1.0(0.442) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux43282 | Title: | Selected VRFs appear to be unselected after a failed deletion |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
The VRFs selected for deletion are no longer selected
Conditions:
This issue will occur if the VRF deletion fails
Workaround:
Refresh the web browser page
Further Problem Description:
|
|
Last Modified: | 08-DEC-2015 |
|
Known Affected Releases: | 1.0(0.531) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw11807 | Title: | openssl ciphers list still includes non-working ciphers |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The NGINX cipher list includes ciphers that do not actually work.
Conditions:
This is a follow-up to CSCuv94846 which removed explicit support for the ciphers but the ciphers are still included implicitly. The ciphers also need to explicitly remove from the cipher list.
Workaround:
Further Problem Description:
There are only ten supported ciphers:
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
|
|
Last Modified: | 09-DEC-2015 |
|
Known Affected Releases: | 1.2(0.89) |
|
Known Fixed Releases: * | 1.2(0.101), 1.2(1.17), 1.2(1i) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux60574 | Title: | OSPF Timers Show Sub-Second, Negative or Offset Timestamps |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
In the Leaf CLI, OSPF timers show as sub-second, negative or not matching system time.
Leaf# show ip ospf neighbors vrf all
OSPF Process ID default VRF L3Test2:L3Out2_VPC
Total number of neighbors: 3
Neighbor ID Pri State Up Time Address Interface
100.0.0.1 1 TWO-WAY/DROTHER 0.756030 10.0.0.1 Vlan22 <--- Sub-second Up Time
100.0.0.5 1 FULL/BDR 0.252539 10.0.0.4 Vlan22 <--- Sub-second Up Time
100.0.0.8 1 FULL/DR 0.163662 10.0.0.2 Vlan22 <--- Sub-second Up Time
Leaf# show ip route vrf L3:L3Test
IP Route Table for VRF "L3:L3Test"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
*via 10.0.0.1, vlan22, [110/5], -07:32:50, ospf-default, intra <--- Negative timer
100.0.0.8/32, ubest/mbest: 1/0
*via 10.0.0.2, vlan22, [110/5], -07:32:50, ospf-default, intra <--- Negative timer
Leaf# date
Thu Dec 17 18:49:06 UTC 2015 <--- Not matching event-history entries
Leaf# show ip ospf event-history adj
Adjacency events for OSPF Process "ospf-default"
2015 Dec 17 10:49:02.695349 ospf default [5042]: TID 5153:ospfv2_send_nbr_ddesc:535:(L3:L3Test-base) mtu 9000, opts: 0x42, ddbits: 0, seq: 0x7270265c
2015 Dec 17 10:49:02.695339 ospf default [5042]: TID 5153:ospfv2_send_nbr_ddesc:531:(L3:L3Test-base) Sent DBD with 0 entries to 10.0.0.4 on Vlan22
Conditions:
Command output for OSPF on Leaf switches show timers that exhibit the same issues described in Symptoms.
Workaround:
Ensuring the Time Zone and Display Format in Fabric Pod Policies match. For example, use the following settings for PDT or PST time zones:
Time Zone: America/Los Angeles
Display Format: Local
This workaround has shown to resolve time stamp issues only in some cases.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 11.1(3f), 11.2(1i) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux69901 | Title: | pinning max-links does not show under FEX config tree |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
pinning max-links does not show under FEX configuration tree but can still be configured
Conditions:
fex configuration
Workaround:
none, the configuration can still be applied
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv78766 | Title: | "%ETHPORT-3-IF_UNSUPPORTED_TRANSCEIVER:" for LOROM twiax cable |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Syslog message
%ETHPORT-3-IF_UNSUPPORTED_TRANSCEIVER: Transceiver on interface Ethernet1/5 is not supported
%ETHPORT-4-IF_NON_QUALIFIED_TRANSCEIVER: Non-qualified transceiver on interface Ethernet1/5 was detected
Conditions:
When following Twiax cable/SFP is inserted into Nexus N9K-C9396PX running 6.1(2)I3(4b)
Ethernet1/5
transceiver is present
type is SFP-H10GB-CU5M
name is CISCO-LOROM
part number is LRHSPB54A050
revision is B0
serial number is XXXXXXX
nominal bitrate is 10300 MBit/sec
Link length supported for copper is 5 m
cisco id is --
cisco extended id number is 4
DOM is not supported
Workaround:
Issue is cosmetic in nature as switch detects the SFP okay and interface also comes up okay.
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.1(2)I3(4b) |
|
Known Fixed Releases: * | 7.0(3)I2(0.568), 7.0(3)I2(0.587), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.0(3)ITI2(1.37), 7.0(3)IX1(1.257), 7.0(3)IX1(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux52554 | Title: | L4-7 Device Package Supported Protocols not displaying in APIC GUI |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
The correct Rest HTTP get is being sent and the "supportedProtocols" response is correctly received however the browser does not display the contents. Expecting to see "bgp,bgpv6,ospf,ospfv3" in the GUI for the below example as a result of this call.
method: GET
url: https://10.66.80.242/api/node/mo/uni/infra/mDev-CISCO-ASA-1.2/mClusterCfg.json?query-target=children&target-subtree-class=vnsRoutingCfg&subscription=yes
response: {"totalCount":"1","subscriptionId":"72057628415557641","imdata":[{"vnsRoutingCfg":{"attributes":{"childAction":"","dn":"uni/infra/mDev-CISCO-ASA-1.2/mClusterCfg/mRoutingCfg","lcOwn":"local","modTs":"2015-12-12T16:11:48.091+11:00","name":"","status":"","supportedProtocols":"bgp,bgpv6,ospf,ospfv3"}}}]}
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 14-DEC-2015 |
|
Known Affected Releases: | 1.2(1i) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv65994 | Title: | PortChannel Memeber Policy is difficult to configure in GUI |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Enhancement Request for the way LACP fast Timeout is currently implemented
Conditions:
version 1.1(1j)
Workaround:
Further Problem Description:
|
|
Last Modified: | 15-DEC-2015 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux56191 | Title: | BCM Adj fails when static route prefix is the same as BD subnet |
|
Status: * | Other |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
Some routes are not working in a static route. You do not see these packets leave the switch and do not see them received on the other end of the l3 connection.
Conditions:
You had a BD SVI, then added a static route for that subnet pointing to a next hop IP in an L3 Out. You then deleted the BD SVI.
Look at the routing table and verify that the route is in the Routing Information Base (RIB) and points to the next hop of the L3Out:
leaf1# show ip route vrf Joey-Tenant:Joey-Internal2
IP Route Table for VRF "Joey-Tenant:Joey-Internal2"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF
192.168.2.0/24, ubest/mbest: 2/0, attached, direct, pervasive
*via 27.27.27.11, vlan63, [1/0], 02:58:12, static <-------------
192.168.2.1/32, ubest/mbest: 1/0, attached
*via 192.168.2.1, vlan65, [1/0], 02:58:42, local, local
Find the BCM VRF ID for that VRF. on the leaf, run the following:
vsh_lc
module-1# show system internal eltmc info vrf
VRF-TABLE: Joey-Tenant:Joey-Internal2
vrf_type: tenant ::: context_id: 23
overlay_index: 0 ::: vnid: 2949121
scope: 23 ::: sclass: 32770
v4_table_id: 0x16 ::: v6_table_id: 0x80000016
intf_count: 3 ::: intrn_vlan_id: 0
VRF Intf: Vlan63 ::: src_plcy_incomp: 1
vnid_hex: 0x2d0001 ::: policy_mode: Egress
vrf_intf_list: loopback10,Vlan65,Vlan63,
vrf_bd_list: 63,65,
BCM Info:
bcm_vrf_id: 22 <---------- ::: bcm_l3_intf_id: 0
NorthStar Info:
qq_tbl_id: 1102 ::: seg_state_tbl_id: 61
::::
exit out of the "vsh_lc" shell:
exit
Find the subnet in the L3 table of the BCM:
bcm-shell-hw "l3 defip show" | grep
leaf1# bcm-shell-hw "l3 defip show" | grep 192.168.2.0
2320 22 192.168.2.0/24 00:00:00:00:00:00 100006 0 0 0 0 n <---- The second column in is the VRF. This matches ELTMC so we know this in the Route. The fifth column in is the "INTF" which will map to the destination. Validate that the destination is incorrect:
leaf1# bcm-shell-hw "l3 egress show
leaf1# bcm-shell-hw "l3 egress show 100006"
unit is 0
Entry Mac Vlan INTF PORT MOD MPLS_LABEL ToCpu Drop RefCount
100006 00:00:00:00:00:00 0 0 0 0 -1 yes no 40 <---- CPU bit is set.
If the entry points to the CPU, the forwarding decision is incorrect. It should point to the next how MAC of the L3 router. The mac in this case is all 0's.
Workaround:
reload the leaf
Further Problem Description:
|
|
Last Modified: | 17-DEC-2015 |
|
Known Affected Releases: | 11.2(1i) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux70460 | Title: | APIC initial setup script should be automated |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When adding a new APIC into an existing fabric, users need to make sure to enter the exact fabric domain name, cluster size, tep ip pool and infrastructure for the new APIC to join the cluster.
Conditions:
When running the initial set up script
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 31-DEC-2015 |
|
Known Affected Releases: | 1.2(1i) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv80422 | Title: | Per Bridge Domain level MTU setting |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
An administrator wishes to change the MTU for a particular Bridge Domain (BD) but can only change it fabric-wide.
Conditions:
MTU needs to be changed at the BD level.
Workaround:
Use QoS Levels in Fabric Access Policies to set the MTU and then apply the QoS Level in an EPG.
Further Problem Description:
|
|
Last Modified: | 20-DEC-2015 |
|
Known Affected Releases: | 11.1(1j), 11.1(3f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux52176 | Title: | Changing LooseNode Mgmt IP address causes blackhole of traffic |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
After changing UCS FI OOB management address, VMM connectivity is broken. When checking "moquery -c fvDyPathAtt" you will see the entries as zero.
Conditions:
UCS FI
ACI
Workaround:
"Trigger inventory sync" on APIC for corresponding vCenter controller.
Further Problem Description:
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 1.1(3f), 1.2(1i) |
|
Known Fixed Releases: * | 1.2(1.102a), 1.2(1.105a), 1.2(1.107), 1.2(1.97c), 1.2(1j) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv46733 | Title: | Enhancement: need to set BGP attrib. when redist. route from OSPF on ACI |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The routes from other protocols on layer 3 out (OSPF, and EIGRP) should have a way to be identified during redistribution and being mark with certain BGP attribute (i.e. community).
The current implementation, the only way to add community to OSPF learned routes on BGP is to specify the exact subnet prefix on BGP outbound policy.
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
N/A
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 1.1(1n) |
|
Known Fixed Releases: * | 1.2(1.111), 1.2(1.38), 1.2(1.51a), 1.2(1.53a), 1.2(1.55a), 1.2(1.57a), 1.2(1.65), 1.2(1.84), 2.0(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux06308 | Title: | Import check for Route Control Enforcement should be disabled by default |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When configuring an External Routed Network (L3 Out) and selecting BGP as the protocol, Import option will be selected by default on GUI
Conditions:
BGP is the L3 Out Protocol
Workaround:
uncheck Import for Route Control Enforcement
Further Problem Description:
|
|
Last Modified: | 12-DEC-2015 |
|
Known Affected Releases: | 1.1(3f), 1.2(0.139i) |
|
Known Fixed Releases: * | 1.2(1.78), 1.2(1.84), 1.2(1b), 1.2(1i) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu03257 | Title: | EPM and EPMC changes for MAC/IP based EPG feature |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
- IP/MAC Ckt EP configuration not supported in combination with static EP configurations
- IP/MAC Ckt EP configuration not supported with L2-only BDs (config will not be blocked, it just won't take effect as there is
no L3 learning in these BDs)
- IP/MAC Ckt EP configuration not supported with external and Infra BDs (again because there is no L3 learning in these BDs)
- IP/MAC Ckt EP configuration not supported with shared services provider config (same or overlapping prefix cannot be used for shared services provider and IP Ckt EP). However, this config can be applied in BDs having shared services consumer EPGs.
- IP/MAC Ckt EP configuration not supported with dynamic EPGs. Only static EPGs are supported
- No fault will be raised if the IP/MAC Ckt EP prefix configured is outside BD subnet range. This is because user can configure BD subnet and IP/MAC Ckt EP in any order and so this is not error condition. If the final configuration is such that IP/MAC Ckt EP prefix configured is outside all BD subnets, the config has no impact and is not an error condition.
- Dynamic deployment of contracts based on instrImmedcy set to onDemand/lazy not supported, only immediate mode is supported.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 24-DEC-2015 |
|
Known Affected Releases: * | 11.0(3.928), 12.0(0.1) |
|
Known Fixed Releases: | 1.2(0.31), 1.2(1.17), 1.2(1.48), 2.0(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus39418 | Title: | Need kernel panic logs from standby sup included in techsupport |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Cisco C9508 running in ACI mode does not include kernel panic log files from the standby supervisor module.
Conditions:
If a kernel panic occurs, an "oops" kernel panic file is generated to provide critical information about the source of the crash. This information normally is present in the techsupport output but if after the crash the supervisor which was active during the crash becomes the standby supervisor, these files will not be present.
Workaround:
Access the standby supervisor via console and gather the file content output from the /mnt/pstore directory.
Further Problem Description:
|
|
Last Modified: | 26-DEC-2015 |
|
Known Affected Releases: | 11.0(2j) |
|
Known Fixed Releases: * | 11.2(1.170) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux38542 | Title: | Subnet not deleted in Broadcom even if subnet is not in use anymore |
|
Status: | Other |
|
Severity: | 6 Enhancement |
Description: | Symptom:
If you use as Layer 3 out static route a subnet that is already in use for a BD part of the same tenant.
and if then you delete the subnet from the BD.
The layer 3 out static route will never work.
Conditions:
The subnet is stuck in ASic. To verify it use the following command from the leaf:
bcm-shell-hw "l3 defip show" | egrep "subnet"
1153 11 x.x.x.x/27 00:00:00:00:00:00 100006 0 0 0 0 n
And then keep the number after the 000 mac (here 100006) and get:
leaf1# bcm-shell-hw "l3 egress show" | egrep "Entry|100006"
Entry Mac Vlan INTF PORT MOD MPLS_LABEL ToCpu Drop RefCount
100006 00:00:00:00:00:00 0 0 0 0 -1 yes no 19
If the MAc address above is all 00 and not the mac of the next hop, it is likely the issue
Workaround:
Further Problem Description:
|
|
Last Modified: | 03-DEC-2015 |
|
Known Affected Releases: | 11.1(3f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux69651 | Title: | ACI leaf - Enh - Req to save core in different partition if full |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Enhancement request to ensure core file of a process crash are alwasy saved even if the partition is full.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-DEC-2015 |
|
Known Affected Releases: | 11.1(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux52979 | Title: | APIC: Remove orphan files after failed or cancelled Firmware Upload Task |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Orphan files are left in the firmware repository directory /firmware/fwrepos/fwrepo.Uploads/ and cannot be manually deleted by admin user.
Conditions:
APIC running 1.2(1i) has an issue where the failed or cancelled firmware upload leaves orphan files in the firmware repository directory /firmware/fwrepos/fwrepo.Uploads/.
Workaround:
Orphan files in the firmware repository directory /firmware/fwrepos/fwrepo.Uploads/ can be deleted manually as "root" user only
OR
Use the "Upload Firmware to APIC" to successfully upload an image to the Firmware Repository. After completed, the janitor process will clean up any orphan files in the /firmware/fwrepos/fwrepo.Uploads/ directory
Further Problem Description:
|
|
Last Modified: | 14-DEC-2015 |
|
Known Affected Releases: | 1.2(1i) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut84965 | Title: | Vlans are programmed on interfaces unassociated to the pool |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
You are receiving "Invalid Path Configuration faults" pointing to an IP address of a blade switch (fabric interconnect). The access policies for these paths are correct. Vlans are programmed on interfaces that are not associated to a pool that has those vlans. This is because you have a blade switch that has multiple uplinks to the fabric. Some of those uplinks are mapped to the VMM domain AEP, some are mapped to another AEP.
Conditions:
dynamic paths are associated to the wrong interface policy groups. We build and adjacency to the blade switch itself, and since other interfaces are learning CDP from that, but those interfaces are not part of the VMM domain AEP, we throw a fault.
Workaround:
Change the Resolution Immediacy of the VMM domain to "Pre-Provisioning" within the EPG. This bypasses the need for an adjacency and will push the VLAN only to interfaces that are part of the VMM AEP.
If this does not resolve it, it is because there may be some stale objects pointing t the blade switch. The 1.2(1i) code is confirmed to have the fix if you continue to use pre-provisioning.
Further Problem Description:
|
|
Last Modified: | 11-DEC-2015 |
|
Known Affected Releases: | 1.0(3f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux57344 | Title: | SCVMM/Hyper-V Agent should not install on non-US Windows Server |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
SCVMM Agent Set-ApicConnInfo fails with error: "The remote server returned an error: (400) Bad Request."
Conditions:
SCVMM Agent is installed on non-ASCII Windows platform
Workaround:
none
Further Problem Description:
The xml payload from the POST request sent from the Set-ApicConnInfo cmdlet to the APIC SCVMM Agent service is malformed. More specifically, it is missing the first two characters ("
................
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 1.1(4e) |
|
Known Fixed Releases: | |
|
|
| |
:
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论