| |
|
Alert Type: | New |
Bug Id: | CSCuy54378 | Title: | port-channel core after copy r s |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
The port-channel will be cored after ascii replay config and copy r s
Conditions:
The save-config is ascii-replay and copy r s. The save-config has FCOE config and fex config
Workaround:
None. Should not done ascii replay and copy r s.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.0(3)IDP3(1.150) |
|
Known Fixed Releases: | 7.0(3)I3(1.6), 7.0(3)I3(2), 7.0(3)I4(0.42), 7.0(3)I4(1) |
|
|
| |
| |
|
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: | 08-APR-2016 |
|
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), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy42951 | Title: | Disk usage for /var/log is 100% |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Disk usage for /var/log is 100%.
Conditions:
df -h shows:
none 50M 50M 0 100% /var/log
none 50M 50M 0 100% /var/log/messages
ls -lah and du -h show there is no large file in /var/log.
Workaround:
none
Further Problem Description:
none
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.1(2h) |
|
Known Fixed Releases: * | 11.2(3a), 11.3(0.217) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy65581 | Title: | ARP resolution fails on an EPG marked as dot1p |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IP nodes on a path marked as 802.1P cannot communicate with other node.
This is because ARP resolution fails.
On problematic nodes and their peers, arp entries are incomplete status
Conditions:
This problem is observed with 11.2(2g)
This is not observed with 11.2(1m).
Only 802.1P vlan encapsulation is affected by this problem.
Workaround:
Configuring static arp entries on nodes on 802.1P path and their peers resolve the communication issue.
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 11.2(3a), 11.3(0.226) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw79734 | Title: | ACI Line Card Reload - nsausd Unresponsive and dt_helper Crash |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
An N9K-X9736PQ line card in ACI mode spontaneously reloads during normal operation. This is caused by the nsausd driver becoming unresponsive due to incorrect handling of interrupts, causing the dt_helper process to crash and produce a core file. The result of the process crashes triggers a HAP reset on the line card. Following the reload, the line card resumes normal operation without lasting symptoms.
The HAP reset can be identified by running 'show module internal activity module #' where # is the module number of the affected line card.
spine# show module internal activity module 7
67) At 280000 usecs after Fri Jan 1 01:00:00 2016
Sequence initiation: LC removal
68) At 280513 usecs after Fri Jan 1 01:00:00 2016
Sending MTS_OPC_LC_STATUS_CHANGE to Registry
69) At 280610 usecs after Fri Jan 1 01:00:00 2016
Critical failure on ports: 1-0 due to Service on linecard had a hap-reset in device 134 <- HAP reset
Device error code: 0x0
Conditions:
On the affected Spine, a core file for dt_helper is identified via one of the following methods. A core file for aclqos may also exist as well. Analysis of the core file is required to confirm the bug is being encountered.
1. On Spine CLI: show cores
spine# show cores
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
1 7 1 dt_helper 2737 01/01/2016 01:00:00
2. On Spine CLI: ls -l /logflash/core
spine# ls -l
total 10028
-r--r----- 1 root admin 2953804 Jan 1 01:00 1445128372_0x702_dt_helper_log.2737.tar.gz
If a certain period of time has passed since the core file was created, it may be located on one of the APICs. The core file may have been uploaded to any one of the APICs, so each must be checked.
1. On APIC CLI: ls -l /data/techsupport/
admin@apic:techsupport> ls -l /data/techsupport/
-r--r----- 1 root admin 2953804 Jan 01 01:00 dbgexp_coreexp-default_spine_sysid-201_2016-01-01T01-00GMT_1445128372_0x702_dt_helper_log.2737.tar.gz
2. On APIC GUI: Check for dt_helper core files generated on the affected Spine node.
Navigate to Admin -> Import/Export -> Core -> [CORE EXPORT POLICY] -> Operational Tab
Workaround:
No known workaround without upgrading to a patched version of software.
Further Problem Description:
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 11.0(4), 11.2(0.69), 11.2(0.70) |
|
Known Fixed Releases: | 11.2(0.72) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz22073 | Title: | /var/sysmgr/tmp_logs/ full after 0x101_sshd:-<#>_uncollect files created |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
The /var/sysmgr/ directory is full:
Nexus9K# show system internal flash
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2097152 801336 1295816 39% /
proc 0 0 0 - /proc
sysfs 0 0 0 - /sys
.
.
none 3670016 3670016 0 100% /var/sysmgr
This can cause error messages similar to the following which can also cause severe traffic loss:
2016 Apr 13 23:55:51 Nexus9K %SYSMGR-2-LAST_CORE_BASIC_TRACE: : PID 1828 with message non-sysmgr(non-sysmgr) crashed, core will be saved .
After going into bash, it was found that the /var/sysmgr/tmp_logs/ directory is fully of sshd files causing the issue:
bash-4.2$ ls -al | grep ssh
-rw------- 1 root root 275726336 Apr 1 09:51 0x101_sshd:-6515_uncollect
-rw------- 1 root root 275726336 Apr 1 09:51 0x101_sshd:-6521_uncollect
-rw------- 1 root root 275726336 Apr 1 09:48 0x101_sshd:-6522_uncollect
-rw------- 1 root root 275726336 Apr 1 09:48 0x101_sshd:-6523_uncollect
-rw------- 1 root root 275726336 Mar 31 16:15 0x101_sshd:-6525_uncollect
-rw------- 1 root root 275726336 Mar 31 20:01 0x101_sshd:-6663_uncollect
-rw------- 1 root root 275726336 Apr 1 04:41 0x101_sshd:-6664_uncollect
Conditions:
The conditions are not yet known
Workaround:
The directories can temporarily be cleared out using sudo:
Nexus9K# run bash
bash-4.2$ cd /var/sysmgr/tmp_logs/
bash-4.2$ sudo rm 0x101_sshd*
In severe cases the directories may fill back up within a day. A script will likely need to be generated to automatically clear the directories.
applying the script bellow will cause those specific files to be automatically deleted out of that directory every 3600 seconds which is every hour. The first time you enter the script a new process will be created so take note of the process that was created:
bash-4.2$ while [ True ]; do echo "Deleting sshd files..."; sudo rm /var/sysmgr/tmp_logs/0x101_sshd*; sleep 3600; done &
[1] 9336
Deleting sshd files...
When you first enter the script, the script runs right away deleting the files. After that, the script will run every hour. To stop the script, you can use the kill ?9 . So in this case it would look like this:
bash-4.2$ kill -9 9336
bash-4.2$
[1]+ Killed while [ True ]; do
echo "Deleting sshd files..."; sudo rm /var/sysmgr/tmp_logs/0x101_sshd*; sleep 3600;
Done
while [ True ]; do echo "Deleting sshd files..."; sudo rm /var/sysmgr/tmp_logs/0x101_sshd*; sleep 60; done &
Further Problem Description:
|
|
Last Modified: | 16-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy36547 | Title: | Evaluation of fabric-apic for glibc_feb_2016 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco Prime Data Center Network Manager includes a version of glibc that is affected by the vulnerability identified by one or more of the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-7547
And disclosed in http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160218-glibc
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 the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-7547
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: 10.0/9.5
http://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 1.2(1.214), 1.2(1m) |
|
Known Fixed Releases: * | 1.2(3a), 1.2(3c), 1.3(0.66), 2.0(0.222) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut95590 | Title: | Match IP next hop not functional in route-map configuration |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BGP filtering not functional with the use of "match IP next hop".
The following behavior was recorded with BGP:
1st: When "match IP next hop" configured with another match statement, it seem the NX-OS is ignoring this match statement and only considering the other match statements like (match as-path)
2nd: When " match IP next hop" configured with no other match statement, the NX-OS ignores the specific allowed prefixes and allows all routes to be sent to the neighbor.
Conditions:
BGP route-maps configured with "match IP next Hop". Consider configuration example below.
route-map BLOCK_STC permit 10
match ip address prefix-list BLOCK_STC
match ip next-hop prefix-list TEST-NEXT-HOP
or
route-map BLOCK_STC permit 10
match ip next-hop prefix-list TEST-NEXT-HOP
Both of the route-maps do not function/filter routes as designed
Workaround:
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.0(3)I1(1a) |
|
Known Fixed Releases: * | 7.0(3)I1(1.201), 7.0(3)I1(2), 7.0(3)IX1(1.93), 7.0(3)IX1(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv20065 | Title: | EVPN External routing BGP EVPN OSPF redistribution fail on 7.0(3)I1(2) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BGP Evpn redistribute into OSPF failed after upgrading to 7.0(3)I1(2)
Conditions:
7.0(3)I1(2)
Workaround:
use "match internal" when redistribute BGP into OSPF
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.0(3)I1(2z) |
|
Known Fixed Releases: * | 7.0(3)I1(2.12), 7.0(3)I1(3), 7.0(3)I2(0.556), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy63393 | Title: | 'Install ACI Service Catalog' erroneously deletes all service blueprints |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Using the 'Install ACI Service Catalog' blueprint erroneously deletes all (including non-Cisco) service blueprints on the target system
Conditions:
Customer has existing service blueprints before running install workflow
Workaround:
Either
a) Avoid using the service blueprint for installation.
b) Comment out line 35 of the 'Install ACI Service Catalog' subtask 'Scriptable Task (Delete all service blueprints)'
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 1.2(2g) |
|
Known Fixed Releases: * | 1.2(3a), 1.2(3c), 1.3(0.61), 2.0(0.222) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy77009 | Title: | Fabric link down between Leaf and Spine when OOB Mgmt Port link down/up |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When a cable in OOB mgmt port of fabric nodes (Spines or Leaves) is disconnected or connected again, some packet drops for a short time (less than 100 msec) on fabric links (data traffic) were observed.
Port-state-changes on front-ports and link-state-change between Leaf and Spine were seen in the log.
Conditions:
IP address is assigned to OOB mgmt port of fabric nodes.
Workaround:
none
Further Problem Description:
none
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 11.2(3a), 11.3(0.233), 12.0(0.108) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy62136 | Title: | vCenter Hypervisors disappear |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Faults indicate DVS was deleted and port groups were deleted from vCenter on the APIC
During normal operations, some of the API calls from APIC to vCenter started to fail. As a result, the inventory fetched from vCenter was not successful and EPGs experienced a connectivity issue.
Conditions:
Workaround:
Workaround:
1. A delete/re-add of vCenter controller configuration as noted in the Fault description. OR
2. Restart of VMM service
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: * | 1.1(4j), 1.1(4k), 1.2(3a), 1.2(3c), 1.3(0.79), 1.3(0.85a), 1.3(0.87a), 1.3(0.88), 2.0(0.243), 6.0.1.23i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv35406 | Title: | Nexus 9300 does not learn MAC addresses on FEX HIF ports |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus 9300 switches may not learn MAC addresses on FEX HIF ports
Conditions:
Nexus 9300 running 7.0(3)I1(2) with FEX attached.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.1(2)I3(4), 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I1(2.4), 7.0(3)I1(3), 7.0(3)I2(0.487), 7.0(3)I2(0.496), 7.0(3)I2(1), 7.0(3)I4(0.74), 7.0(3)I4(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.15), 7.0(3)ITI2(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw86858 | Title: | On shut, ITD crash with Service "iscm" (PID X) hasn't caught signal 11 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On "shut" command, ITD may crash.
Sample logs:
9k-179# config t
9k-179(config)# itd s2
9k-179(config-itd)# shut
%SYSMGR-2-SERVICE_CRASHED: Service "iscm" (PID 7807) hasn't caught signal 11 (core will be saved)
Conditions:
Issue is seen in 7.0(3)I1 and I2 releases.
Workaround:
None.
Issue is resolved in 7.0(3)I2(2) or later releases.
More Info:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(1.54) |
|
Known Fixed Releases: | 7.0(3)I2(1.65), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz04110 | Title: | vspan failed for Interhost/Intrahost when config Apic with NXOS CLI |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Configuring vspan destination group from cli doesn't seem to work properly.
Conditions:
1. Configure vspan dest group from cli and assign it to the vmware domain
Workaround:
There are 2 options :
1. Configure vspan entirely using GUI.
2. If CLI is used to create vspan source and destination groups then use GUI to update the destination group as CLI naming convention is different.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.2(2g), 1.3(0.107) |
|
Known Fixed Releases: * | 1.3(0.125a), 1.3(0.128), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz25908 | Title: | leaked routes being advertised out L3out due to stale route-map entry |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Routes leaked from one VRF Y to another VRF X are advertised from L3out of VRF X.
Leaked routes are BD subnets in VRF Y.
Even though leaked routes are not allowed to advertised, they are advertised from L3out.
Conditions:
Trigger 1:
VRF X has a global contract (which is exported to VRF Y) provided by l3out.
AEPG-1 from VRF Y consumed the contract interface.
AEPG-1 from VRF Y remove the consumption of the contract interface.
Trigger 2:
VRF X has a global contract (which is exported to VRF Y) provided by l3out.
AEPG-1 from VRF Y consumed the contract interface.
AEPG-2 from VRF Y consumed the same contract interface.
Both of these would result of stale route-map entry like below. Due to Route-map Entry 7801 does not have IPV4 prefix-list, all the IPV4 route are redistributed to OSPF/Eigrp which is controlled by exp-ctx-st-2293762
route-map exp-ctx-st-2293762, permit, sequence 7801
Match clauses:
ip address prefix-lists: IPv6-deny-all
Set clauses:
route-map exp-ctx-st-2293762, permit, sequence 7802
Match clauses:
ip address prefix-lists: IPv6-deny-all IPv4-st26-2293762-exc-int-inferred-export-dst
Set clauses:
route-map exp-ctx-st-2293762, permit, sequence 7803
Match clauses:
ip address prefix-lists: IPv6-deny-all
Set clauses:
Workaround:
1. issue "acidiag touch clean" from the border leaf then reboot. Then do not trigger either of the conditions any more.
2. Contact TAC for using test-api to remove the stale route-map entry. Then do not trigger either of the conditions any more.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.2(1k) |
|
Known Fixed Releases: * | 1.3(0.137), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus71452 | Title: | N9300 - ADJMGR and FIB Next Hop Interface Out Of Sync |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Certain IP's are unreachable when sending traffic through a Nexus 9300
Conditions:
Following a loop in the network
Workaround:
Clear ip arp x.x.x.x force-delete
Further Problem Description:
This is due to a disconnect in the state between ADJMGR and the FIB:
N9K-1# sh ip arp detail
Flags: * - Adjacencies learnt on non-active FHRP router
+ - Adjacencies synced via CFSoE
# - Adjacencies Throttled for Glean
IP ARP Table for context default
Total number of entries: 2
Address Age MAC Address Interface Physical Interface
1.1.1.250 00:00:52 0000.0000.0001 Vlan1 port-channel3 <---------------- SW points to Po3
N9K-1# sh forwarding adjacency platform
slot 1
=======
IPv4 adjacency information
next_hop:1.1.1.250 rewrite_info:0000.0000.0001 interface:Vlan1 (Phy 0x16000001) <------ FIB points to Po2
HH:0x7 Refcount:2 Flags:0x800 Holder:0x1 pbr_cnt:0 wccp_cnt:0
BCM adj: unit-0:100011 unit-1:0 unit-2:0, cmn-index: 7, LIF:1 Upd 3
BCM NVE adj: unit-0:0 unit-1:0 unit-2:0, cmn-index: 7, LIF:1 Upd 3
N9K-1# sh int snmp-ifindex | i 0x16000001
Po2 369098753 (0x16000001) <------------------------------------------------- SNMP IFindex for Po2
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 6.1(2)I2(1), 6.1(2)I2(2), 6.1(2)I2(2a), 6.1(2)I2(2b), 6.1(2)I2(3), 6.1(2)I3(1), 6.1(2)I3(2), 6.1(2)I3(3.50), 6.1(2)I3(3a) |
|
Known Fixed Releases: * | 6.1(2)I3(3.56), 6.1(2)I3(4), 6.1(2)I3(4.4), 6.1(2)I3(5), 7.0(3)I1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv05263 | Title: | N9K Looping VTP Advertisement within vPC Domain |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
High CPU (netstack and VTP).
The VTP packet storm could hit adjacent devices causing instability downstream or upstream.
Conditions:
When VTP advertisement is received in Nexus 9000 fully transparent VTP vPC domain.
Workaround:
Disable VTP feature (no feature ftp)
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 6.1(2)I3(4a) |
|
Known Fixed Releases: * | 6.1(2)I3(4.7), 6.1(2)I3(5), 7.0(3)I1(2.3), 7.0(3)I1(3), 7.0(3)I2(0.452), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.0(3)IX1(1.245), 7.0(3)IX1(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy99125 | Title: * | Stale gst-l3-tcam entries after deleting l3extOut or l3extInstP |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
There is a connectivity loss for traffic leaving and/or entering the ACI fabric through an L3 Out, due to a policy drop caused by stale IP prefix entries in GST-L3-TCAM of Border Leafs.
Conditions:
After one of the following two conditions:
1. An L3 Out policy (l3extOut) has been deleted in the VRF.
2. Some (but not all) of the External Network Instance Profiles (l3extInstP) under the L3 Out have been deleted.
Workaround:
Note: Reloading doesn't clear the entries.
(1) Remove all of the External Network Instance Profiles (l3extInstP's) from the L3 Out, after last one is removed the entries should clear. If the entire L3 Out (l3extOut) was deleted, use #2.
(2) Clean and reboot the leaf using the following commands:
acidiag touch clean
acidiag touch setup
acidiag reboot
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 11.2(3a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy11992 | Title: | L4-7 Device subnet doesn't immediately deploy and advertise after submit |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Any subnets added under Device Selection Policy after the service graph is rendered are not pushed to the leaf.
Conditions:
This happens when there is a VRF split in the fabric and operator has to configure subnets to leak between VRF.
Workaround:
Detach and re-attach contract/graph association.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.2(1k) |
|
Known Fixed Releases: * | 1.2(1.200), 1.2(1.210b), 1.2(1.214), 1.2(2g), 1.3(0.11a), 1.3(0.16), 1.3(1f), 2.0(0.191), 2.0(0.226) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz44537 | Title: | rollback for port-profile fails for fex HIF PO ports |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
The rollback fails when interface is part of port-channel, in l2 interface take checkpoint and we do no interface port-channel, now we try to do the rollback to chckpoint, it fails with no switchport command since its not allowed for fex interface
Conditions:
It occurs only on l2 switches where interface is part of port-channel
Workaround:
lback with best-effort option works fine for it
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.0(3)I4(0.110) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz44793 | Title: | QoS conf'd under Ctrct is not taking prio in L3out scenario |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Filter rules for a contract that are reverse of each other contain different qos priority values.
Conditions:
When different values of qos priority are specified on l3Out and contract, one of the filters picks up priority value from contract and other filter from l3Out.
Workaround:
Specify qos priority at either contract level or l3Out level.
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 1.3(1e) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz29177 | Title: | 10g-4x breakout map not supported on last two ports |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
On N3K-C31108TC-V and N3K-C31108PC-V TORs, unable to breakout ports 53 and 54 to 10g-4x mode. It can operate only in 100G or 40G speeds.
Other four QSFP ports 49-52 support 10g-4x breakout and can work in 10G mode.
Conditions:
Always
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.0(3)I4(0.89) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux94180 | Title: | Unable to remove MEv6 mac-extract cli from intf with no mac-addr |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
On Layer 3 routed port physical or port channel sub-interfaces, the command "no mac-address"
does not remove previously configured "mac-address ipv6-extract".
Conditions:
The symptom only occurs in this release, not prior release. Only subinterfaces with the above
conditions are affected.
Workaround:
is shown on "no mac-address ?" for user to enter carriage return. User can use
"no mac-address ipv6-extract" (or substring of ipv6-extract) to remove it.
If this does not work, do a shut on the interface and then 'no mac-address ipv6-extract'.
Further Problem Description:
N/A
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.266), 7.0(3)I4(0.26) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu22980 | Title: | vlan show missing port membership after network event |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Broadcast/Multicast traffic is not sent out of the interface.
"show interface" counters will show no broadcasts/multicast counts, ARP requests may not be sent out, etc.
To verify this issue, you must look at the broadcom programming on the affected module. The below example is for VLAN 501 and interface Eth1/48 (xe47, the ports are 0 based):
nexus_9000# bcm-shell module 1 "vlan show 501"
vlan 501 ports xe30-xe38,hg4-hg5 (0x00000000000000000000000000000000000000000000000000003fe000000060), untagged xe30-xe34 (0x000000000000000000000000000000000000000000000000000003e000000000) MCAST_FLOOD_UNKNOWN <<<<<<< MISSING xe47 from "ports" section
Conditions:
Network flap or network event that requires reprogramming of the VLAN broadcast index.
Workaround:
Anything that requires reprogramming the broadcast index for the VLAN, including flapping the port/port-channel, changing the spanning-tree state, and/or reconfiguring the interface.
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 6.1(2)I2(3), 7.0(3)I1(0.248), 7.0(3)I1(1.232) |
|
Known Fixed Releases: | 7.0(3)I1(2.10), 7.0(3)I1(3), 7.0(3)I2(0.336), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.72), 8.3(0)SF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy83816 | Title: | Tahoe Modular bootup time is around 2 to 2.5 mins more than T2/TH |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Bootup time for N9508 with Sugarbowl linecards and Lacrosse fabric modules is 2-.25 minutes longer than N9508 with T2 basic linecards.
Conditions:
Bootup time for N9508 with Sugarbowl linecards and Lacrosse fabric modules is 2-.25 minutes longer than N9508 with T2 basic linecards.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.0(3)IDM3(0.28) |
|
Known Fixed Releases: | 7.0(3)IM3(1.61), 7.0(3)IM3(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz43013 | Title: | N9K-X9732C-EX - module bootup with golden fpga always |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
N9K-X9732C-EX modules always uses the golden copy of the FPGA only for its operation even though it has primary copy of the FPGA.
There is no impact to the functionality of the line card module
Conditions:
N9K-X9732C-EX linecard modules show this behavior always
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.0(3)IM3(1.77) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy68619 | Title: | N9K-C92304QC : sh mod output should reflect all speed capabilities |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | "show module" on Bellevue shows all 64 ports as 40G ports
Symptom:
"show module" on Bellevue shows all 64 ports 40G ports.
bellevue(config)# sh mod
Mod Ports Module-Type Model Status
--- ----- ------------------------------------- --------------------- ---------
1 64 64x40G Ethernet Module N9K-C92304QC active *
Conditions:
Seen when "show module" CLI is executed.
Workaround:
None
Further Problem Description:
"Show module" output should also show 100G ports.
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.0(3)IM3(0.14) |
|
Known Fixed Releases: | 7.0(3)I4(0.97), 7.0(3)I4(1), 7.0(3)IBS3(1), 7.0(3)IBS3(1.2), 7.0(3)IM3(1.36), 7.0(3)IM3(1.64), 7.0(3)IM3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz12404 | Title: | Subnet not deleted in previous vrf |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A subnet is not deleted in previous vrf after it's moved to another vrf. Now both vrf shows this subnet.
Conditions:
Two vrfs in unenforce mode.
Workaround:
1. Delete all EPGs under this vrf or move all epgs to other vrf temperately so that the vrf is undeployed.
2. Delete the vrf and create exact same one.
3. Provide and consume "default" contract for both VRFs as vzAny and remove that vzAny.
Further Problem Description:
When the problem happen, fvAssocBDDefCont DN for bd-data has the original vrf pointed until a acidiag touch clean and reboot the leaf.
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 1.1(4e), 1.2(1k), 1.2(2h) |
|
Known Fixed Releases: * | 1.2(3d), 1.3(0.123a), 1.3(0.124a), 1.3(0.125a), 1.3(0.128), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux07619 | Title: | SSTE:n9k- 'enforcepriv' config option is hidden in Dublin image |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
no option to configure snmp user 'enforcepriv'
Conditions:
config
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.62), 7.0(3)I4(0.44) |
|
Known Fixed Releases: * | 7.0(3)I4(0.116), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz42134 | Title: | "%IPFIB-SLOT1-4-UFIB_ROUTE_CREATE:" seen with parity correction |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
%IPFIB-SLOT1-4-UFIB_ROUTE_CREATE error can be seen for v4 and v6 prefixes
Eg:
IPFIB-SLOT1-4-UFIB_ROUTE_DESTROY 4 Unicast route destroy failed for VRF: 1,, flags:0x20000, intf:0x0, Error: Operation failed(-11).
Conditions:
This is a transient error seen when parity error correction is done for certain tables. Running v4 and v6 CC will confirm that there are no inconsistent prefixes. Syslogs will also be printed to that effect if it passes.
Eg:
UFDM-3-FIB_IPv6_ADJ_CONSISTENCY_CHECKER_PASS: FIB IPv6 consistency checker PASSED on slot ALL
UFDM-3-FIB_IPv6_ROUTE_CONSISTENCY_CHECKER_PASS: FIB IPv6 route consistency checker PASSED on slot ALL
UFDM-3-FIB_IPv4_ADJ_CONSISTENCY_CHECKER_PASS: FIB IPv4 adjacency consistency checker PASSED on slot ALL
UFDM-3-FIB_IPv4_ROUTE_CONSISTENCY_CHECKER_PASS: FIB IPv4 route consistency checker PASSED on slot ALL?
Workaround:
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 6.1(2)I3(4c) |
|
Known Fixed Releases: * | 6.1(2)I3(4d) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut12974 | Title: | JSON REST API requests fail depending on the order of the contents |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The Cisco APIC may process JSON requests in an inconsistent manner.
Conditions:
The order of the contents of the requests may cause the request to fail. For example if the "children" array comes before an attributes object, the request may fail.
Workaround:
Sort the keys for objects in an alphabetical order so that attributes always come before the children.
Further Problem Description:
The rest api error has been updated to say:
invalid data at line '1'. Attributes are missing, tag 'attributes' must be specified first, before any other tag
This restriction will not be lifted.
|
|
Last Modified: | 01-APR-2016 |
|
Known Affected Releases: | 1.0(3f) |
|
Known Fixed Releases: * | 1.2(0.1), 1.2(1.17), 1.3(0.24a), 1.3(0.26), 2.0(0.202a), 2.0(0.203), 2.0(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu47831 | Title: | ' no diagnostic monitor module 1 test all' not disabling RewriteEngineLo |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
NXOS diagnostic test "RewriteEngineLoopback" is not disabled.
Conditions:
This happens when the "all" option is used to disable the entire suit of NXOS diagnostic tests.
Workaround:
Specifically disable the "RewriteEngineLoopback".
Further Problem Description:
When NXOS command "no diagnostic monitor module 1 test all' is used to disable all the diagnostics the "RewriteEngineLoopback" test is not disabled. To disable the "RewriteEngineLoopback" test use the following command:
"no diagnostic monitor module 1 test 14"
|
|
Last Modified: | 01-APR-2016 |
|
Known Affected Releases: | 7.0(3)IDD1(1.75) |
|
Known Fixed Releases: * | 7.0(3)IDD1(1.78), 7.0(3)IX1(1.99), 7.0(3)IX1(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus97328 | Title: | Cisco Nexus 9000 Vulnerability cmd injection via DHCP offer options |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Command injection via DHCP offer options used with PowerOn Auto Provisioning (POAP)
Conditions:
NX-OS Switch would have to be in a state where POAP is initiated, and if
an attacker can either:
A) Inject their own DHCP server and respond to the POAP DHCP request with
crafted DHCP options.
B) Compromise an existing DHCP server, and craft the specific DHCP
options.
Then during the POAP process, when the crafted DHCP options are processed
arbitrary commands on the system could be executed in the context of root
user.
Note this issue only occurs during the POAP DHCP boot process.
Workaround:
None.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.8/5.9:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:H/Au:N/C:C/I:C/A:C/E:H/RL:OF/RC:C&version=2.0
CVE ID CVE-2015-0658 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 04-APR-2016 |
|
Known Affected Releases: * | 6.1(2)I3(3.78), 7.0(3)I1(1) |
|
Known Fixed Releases: | 6.1(2)I3(3.84), 6.1(2)I3(4), 7.0(3)I1(1.127), 7.0(3)I1(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy76758 | Title: | Cannot right-click and delete node from Fabric Membership |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
You cannot right click on an object in the Fabric Membership to delete it.
Conditions:
You are trying to delete a node in the Fabric Membership section.
Workaround:
Click on "Actions" in the work pane and select "Delete"
Further Problem Description:
|
|
Last Modified: | 04-APR-2016 |
|
Known Affected Releases: | 1.2(2g) |
|
Known Fixed Releases: * | 1.3(0.79), 2.0(0.243) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz04994 | Title: | ACI: F1471 raised after adding an EPG subnet |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Fault F1471 raised after configuring a subnet under an EPG already linked to an SCVMM domain
Conditions:
EPG already linked to an SCVMM domain and there is already a virtual machine in the corresponding virtual network.
Workaround:
Remove the virtual machine from the corresponding network and add it back.
Further Problem Description:
|
|
Last Modified: | 05-APR-2016 |
|
Known Affected Releases: | 1.2(2g) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz10629 | Title: | ACI: Traffic polarization issue on External Leaf |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
When traffics are from Internal Leaf side to external leaf side, from IntLeafs to ExtLeaf traffics are load-balanced well, however, from ExtLeaf to External side it is not load-balanced(using a single path only among two paths)
If we eliminate one of External Leaf switch(among two ExternalLeaf SWs), the remained ExternalLeaf switch is sending traffics with both of ECMP links well.
Additionally when we generated packets thru other port of InternalLeaf#1(in case of traffics were injected thru two ports from internal Leaf), the traffics were transmitted thru other ECMP port also of Ext_Leaf#1. So in this case, both of links were used.
Conditions:
- Configured two external Leafs(each ExternalLeaf has two paths to external network side)
- Traffics were generated from a single port of a single Internal Leaf
Workaround:
none
Further Problem Description:
none
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy53333 | Title: | vmtracker status is not connected after reload |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
vmtracker connection is not connected after reload
Conditions:
After "copy r s", then reload. After the switch booted up, vmtracker connection is not connected. This issue does not always happen.
Workaround:
Issue "no connect" and then "connect" of the vmtracker connection. The connection will be reconnected.
Further Problem Description:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu44651 | Title: | Remove-private-as and as-path prepend do not work together |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On the N9K as-path prepend does not work when remove-private-as is configured
Conditions:
When remove-private-as is added to the config the private-as and the prepended AS's are all removed.
Workaround:
Only workaround is to configure as-path prepend on the inbound route-maps on the peers.
Further Problem Description:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I1(2.7), 7.0(3)I1(3), 7.0(3)I2(0.454), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.123), 8.3(0)SF(0.67) |
|
|
| |
| |
|
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: | 08-APR-2016 |
|
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), 8.3(0)KMS(0.31), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul92989 | Title: | LC failure cause 38 sec traffic loss |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
LC failure on N9k cause 38 sec traffic loss
Conditions:
Total 38K BGP routes
Workaround:
none
Further Problem Description:
none
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.1(2)I1(1) |
|
Known Fixed Releases: * | 6.1(2)I2(0.230), 6.1(2)I2(1), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz13614 | Title: | L3Out contract counter always shows zero on SugarBowl ToR(BL) |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
For traffic coming out L3out to internal EPG, stats for the actrlRule will not increment.
Conditions:
This is change in behavior compared to older NorthStar based ToR platform.
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 11-APR-2016 |
|
Known Affected Releases: | 11.3(0.246) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy45705 | Title: | ACI VPC : Syncing Endpoint information from VPC peer for non-vpc vlan |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
endpoint learning from VPC peer for a non-vpc vlan
Conditions:
VPC setup
Workaround:
na
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 1.3(0.215), 1.3(0.43b), 1.3(0.45), 11.3(0.215), 2.0(0.206) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy02543 | Title: | bfd echo not supported between vpc peers and ospfv3 neighbors. |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
BFD Echo mode is not supported for some session types
Conditions:
BFD echo mode is not supported on ipv6 bfd sessions carrying link-local as source and destination ip address.
BFD echo mode is not supported on ipv4 bfd sessions over Multihop or vpc peer links.
Workaround:
No workaround exist.
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: * | 11.3(0.187) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy70566 | Title: | ACI Leaf: False detection of outlet sensor temperature. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A sensor on nexus 9000 detects wrong temperature.
F103824: TCA: normalized temperature current value(eqptTemp5min:normalizedLast) value 82% raised above threshold 80%
Conditions:
Unknown
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.2(1k) |
|
Known Fixed Releases: * | 11.3(0.229) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux94520 | Title: | ospf name lookup does not resolve long hostnames |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
DNS host names of ospf neighbors are truncated to 44 letters.
Conditions:
Length of DNS host names greater than 44 characters
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.2(1.184) |
|
Known Fixed Releases: * | 11.3(0.216) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy49977 | Title: | [Platform] Factory Reset of switch in BZMR1 is not working. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
NXOS doesn't boot properly and admin login wont work.
Conditions:
While Factory Reset is done from loader, using init_system and boot , it can also happen in Standalone to ACI conversion cases.
Workaround:
After Factory install, power cycle or reload the switch again. In the next boot, switch comes up fine.
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 11.2(3a), 11.3(0.217) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy47950 | Title: | ACI policy upgrade does not upgrade EPLD/FPGA on both supervisors |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After completing the switch firmware upgrade from the APIC GUI, fault F1582 (firmware-version-mismatch) is raised for one of the supervisors of the switch.
Conditions:
After completing the switch firmware upgrade from the APIC GUI, EPLD/FPGA needs to be upgraded on both supervisors on a switch.
Workaround:
Downgrade the switch, then put the supervisor that needs the EPLD/FPGA to be upgraded as standby, then upgrade the switch again.
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 11.2(3a), 11.3(0.220) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux90501 | Title: | IP subnet check erroneously applied to static EPs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The IP subnet check, when configured on a bridge domain, is erroneously applied to statically configured IP EPs. This will prevent a static EP from being configured on the switch if the IP address is not within the range of the configured subnets for the applicable bridge domain.
Conditions:
This may occur when the IP subnet check is enabled on bridge domain and static IP EPs are configured on the bridge domain.
Workaround:
There are two workarounds. Either disable the IP subnet check on a bridge domain where static IP EPs are to be configured OR configure static IP EPs to be within the range of the configured subnets for the applicable bridge domain.
Further Problem Description:
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 11.2(1.181) |
|
Known Fixed Releases: | 11.3(0.189) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux95853 | Title: | show tech-support fcoe needs to contain all pertinent FC information |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:Enhance show tech-support fcoe so that it includes all FC pertinent information. This should be similar to the MDS show tech-support details
Conditions:Applicable to the Nexus 9000 switches using FCoE.
Workaround:Use individual show tech-support commands. For example:
show tech-support zone
show tech-support fcns
show tech-support fcdomain
show tech-support port
etc...
More Info:None.
Resolution Summary:
show tech-support fcoe will now contain the following commands:
show system internal fcoe_mgr event-history errors
show system internal fcoe_mgr event-history msgs
show system internal fcoe_mgr info global
show system internal fcoe_mgr mem-stats detail
show system internal fcoe_mgr info pcfcfmac
show system internal fcoe_mgr info pss
show system internal fcoe_mgr info sdb
show fcoe
show tech-support assoc_mgr
show system internal fcfwd mpmap vfcs
show system internal fcfwd pcmap
show system internal fcfwd idxmap interface-to-port
show system internal fcfwd flogimap entries
show system internal fcfwd sfib statistics
show system internal fcfwd spanmap tx
show system internal fcfwd spanmap rx
show fcoe database
show tech-support npv
show tech-support fc2
show tech-support vsan
show san-port-channel summary
show san-port-channel internal event-history all
show san-port-channel internal event-history errors
show san-port-channel internal event-history debugs
show san-port-channel internal event-history msgs
show san-port-channel internal event-history lock
show san-port-channel internal mem-stats detail
show san-port-channel consistency
show san-port-channel database
show tech-support dcbx
show tech-support lldp
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(1) |
|
Known Fixed Releases: | 7.0(3)I3(0.280), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.100) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz20447 | Title: | CRC errors observed on AOC Molex after remote interface shut or reload |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Incrementing CRC or FCS Errors are seen on a port despite the cable and optic being fine
Conditions:
This is seen after the remote side is flapped or a reload is performed. It is not seen all the time but one out of every 5-10 times. This problem only affects port ethernet1/9-16, ethernet1/25-32,ethernet1/41-48 and ethernet1/57-64 in 6.1(2)I2(2a). In 6.1(2)I2(2b) and later we resolved this issue
Workaround:
Shut/no shut the affected port
Further Problem Description:
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 6.1(2)I2(2a) |
|
Known Fixed Releases: | 6.1(2)I2(2b) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux25207 | Title: | 8 mins traffic loss during upgrade from 1.1(4e) to 1.2(0.247a) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
8 mins traffic loss on VMs
Conditions:
During upgrade of TORs from BMR3 1.1(4e) to Brazos 1.2(0.247a). After upgrade, when the maint-grp-1 set of TORs goes for a reboot, traffic loss is seen on the VMs.
Workaround:
Traffic will be recovered after 8 mins automatically
Further Problem Description:
Reason: Timing issue where EP sync from peer happened before SVI came up locally and hence some L3 EPs could not programmed.
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 11.1(4e), 11.2(0.85) |
|
Known Fixed Releases: * | 12.0(0.97) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz05365 | Title: | N9K 9300 Internal Storage Information Exposed via RPC from remote cmd |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptoms:
A vulnerability in a configured loopback interface of the Cisco Nexus 9000 Series Switch could allow an unauthenticated,
remote attacker to access certain sensitive data. The attacker could use this information to conduct additional
reconnaissance attacks.
The vulnerability is due to having certain TCP and UDP ports listening on the loopback interface which are not required.
An attacker could exploit this vulnerability by connecting to the affected device on one of the exposed TCP or UDP ports.
An exploit could allow the attacker to discover certain sensitive data which could be used to conduct further attacks.
Conditions:
The Cisco Nexus 9000 Series has the loopback interface configured with a routable IP address.
Workaround:
Remove the loopback interface.
Apply an ACL to the loopback interface to prevent access to the unwanted ports.
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 5/4.1:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:N/C:P/I:N/A:N/E:F/RL:OF/RC:C&version=2.0
CVE ID 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: | 15-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2c), 7.0(3)I3(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz11926 | Title: | Invalid VLAN fault on changing AEP of an accBaseGrp or deleting a AEP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Invalid VLAN fault on changing AEP of an access port group or deleting a AEP.
Conditions:
encap blocks in VLAN name space deleted and re-created with different range AND single domain is shared by multiple AEPs AND changing AEP of an accBaseGrp / deleting AEP
Workaround:
Delete the association between domain and VLAN name space and associate them back again
Further Problem Description:
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 1.2(2g) |
|
Known Fixed Releases: * | 1.3(0.123a), 1.3(0.124a), 1.3(0.125a), 1.3(0.128) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw84370 | Title: * | PE does not deploy subsequent cktEps when VLAN validation fails |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
With an EPG using multiple VLAN/VXLAN encaps and an Invalid Path Configuration fault, some encapsulation with known good configuration also fail to deploy. In this case, one encapsulation has failed validation but others attached to the EPG are still not deployed.
Conditions:
An EPG using multiple VLAN/VXLAN encapsulations
A nwIssues fault (Invalid Path Configuration, Invalid VLAN Configuration, etc.)
A VLAN/VXLAN deployment that is causing above fault
Other VLAN/VXLAN encapsulations that are configured properly with appropriate domains, VLAN pools, and AEP
Workaround:
Configure the policies necessary to clear the nwIssues fault
Further Problem Description:
The vlanCktEp object can be used to verify what VLAN/VXLAN encaps are going to be deployed for a particular EPG.
|
|
Last Modified: | 18-APR-2016 |
|
Known Affected Releases: | 1.0(4h) |
|
Known Fixed Releases: | 1.1(3.10), 1.2(0.177), 1.2(1i) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz15601 | Title: | eBGP TTL exceeded for directly connected neighbor |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After upgrading to 1.2.2x, eBGP neighborship is down from external router to ACI border leaf
Conditions:
- eBGP configured on external SVI between vPC peers
- no IGP (OSPF/EIGRP) configured on the L3Out
- eBGP with default TTL of 1
Workaround:
Two different workarounds available:
1) Initiate a ping between border leafs using external SVI IP addresses
2) Configure eBGP multi-hop with TTL >= 2
Further Problem Description:
|
|
Last Modified: | 19-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 11.3(0.255), 11.3(0.260) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux24692 | Title: | RACL cant match on packets with Multicast MAC DA on n9200 |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Routed ACL's will not match for packets with Multicast Ethernet MAC address as destination.
Conditions:
Routed ACL's will not match only for packets with Multicast Ethernet MAC address as destination.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 19-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.140) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz15715 | Title: | ACI: Unable to upload APIC 1.2(3c) to Firmware Repository via GUI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
GUI displays error "Upload error: 413".
Conditions:
While uploading the 1.2(3c) APIC image to the firmware repository via the GUI from:
Firmware > Firmware Repository > Actions > Upload Firmware to APIC
Workaround:
Use SCP to upload the file to the APIC and use the command "firmware add " to add the APIC image to the Firmware Repository.
Further Problem Description:
|
|
Last Modified: | 19-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: * | 1.3(0.128), 2.0(0.260) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz10612 | Title: | ACI: Traffic polarization issue on External Leaf |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When traffics are from Internal Leaf side to external leaf side, from IntLeafs to ExtLeaf traffics are load-balanced well, however, from ExtLeaf to External side traffics are not load-balanced(using a single path only - polarization)
If we eliminate one of External Leaf switch(among two ExternalLeaf SWs), the remained Ext_Leaf#1 switch is sending traffics with both of ECMP links well.
Additionally when we generatd packets thru other port of InternalLeaf#1(in case of traffics were injected thru two ports from InternalLeaf#1), the traffics were transmitted thru other ECMP port also of Ext_Leaf#1. So in this case, both of links in Ext_Leaf#1 were used correctly.
Conditions:
- Configured two external Leafs(each ExternalLeaf has two paths to external network side)
- Traffics were generated from a single port of a single Internal Leaf
Workaround:
none
Further Problem Description:
none
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 11.3(0.263) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy40280 | Title: | match community does not work on CLI and Basic UI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"match community" statement under the route-map does not take effect.
Conditions:
In the current software release, match community statement configured through CLI will not take effect on the switch. show running-config will show the configuration fine, but the configuration will not applied on the switch.
Workaround:
There is no workaround for this problem.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 1.2(2f) |
|
Known Fixed Releases: * | 1.2(3a), 1.2(3c), 1.3(0.30), 2.0(0.202a), 2.0(0.203) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy65545 | Title: | Service Graph Stuck in Applying/vnsREPpInfo shows pcTag = any |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Service graphs tied to a particular device are stuck in the Applying state
At least one of the function connectors for the device shows a classID/pcTag of any
The BD placement of the connectors of the device have been changed while graphs were deployed on the device
Conditions:
Using a L4-L7 device for Service Graph deployment
Modifying the BD placement of the connectors of the device while graphs were deployed
Workaround:
Remove the current graphs and problem L4-L7 device.
Recreate the L4-L7 device and re-deploy the graphs
Further Problem Description:
In the broken state, vnsREPpInfo for the BD of the problem device will show any in the pcTag field.
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 1.2(1k) |
|
Known Fixed Releases: * | 1.2(3a), 1.2(3c), 1.3(0.70a), 1.3(0.72b), 1.3(0.74), 2.0(0.243) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy60386 | Title: | Wizard to add interface in APIC pushing wrong config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When you create Access port Selector profile using Wizard "Configure an interface, PC, and VPC" under Fabric->Access Policies-> quick start.From the Wizard if you perform following steps to add an interface.
1. Select and existing Switch Profile name.
2 Add the the interface
3. Select an existing Interface Policy group.
4. Save and Submit
you will see that Access port selector will be created under the right Interface profile . But instead of using existing Interface policy group defined by user, it will create a new interface group and use that.
Conditions:
When using wizard and using existing interface policy group
Workaround:
manually create the access port selector when using an existing interface policy group.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: * | 1.2(3a), 1.2(3c), 1.3(0.49), 1.3(0.66), 2.0(0.222) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy40276 | Title: | CLI: inherit-profile under route-map match bridge-domain doesn't work |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Public subnets in a Bridge-domain can be advertised out through a routing protcol using a "match bridge-domain " in the route-map associated with the protcol. Route control properties such as "set tag"or "set metric" can be set for these public subnets through "inherit route-profile " under the "match bridge-domain" command.
If the route-profile name is not equal to "default-export", then the route control properties are not set correctly on the exported BD subnets.
Conditions:
Use of "inherit route-profile " under match bridge-domain, where profile Name is not equal to "default-export"
Workaround:
Workaround is to set required route control in "default-export" route-profile.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 1.2(2f) |
|
Known Fixed Releases: * | 1.2(3a), 1.2(3c), 1.3(0.45), 2.0(0.206) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy50173 | Title: | APIC: 1.2(2) KVM install causes divergence/login issues |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If apic 1: Admin login 1 will not work after APIC installation. You may continuously see the message:
"REST Endpoint user authorization datastore is not initialized"
When attempting to login to the GUI.
or
If Apic 2 or 3: Apic will be unable to complete convergence when attempting to join the fabric. It will show up under cluster but remain partially diverged.
You may see the following faults under the leaf nodes that the apic is connected to:
F608163
Severity:
major
Last Transition:
2016-03-15T02:19:58.393+00:00
Lifecycle:
Raised
Affected Object:
topology/pod-1/node-xxx/sys/lldp/inst/if-[eth1/x]/ctrlradj
Description:
[FSM:FAILED]: Lldp handshake between leaf and the controller(TASK:ifc:policyelem:LldpCtrlrAdjEpHandshakeWithApic)
Explanation:
This fault is raised when handshake between PE and AD fails
Recommended Action:
This task is automatically retried. If you see repeated failures, collect tech-support file and contact Cisco TAC.
Conditions:
This behavior has been seen when a user does an ISO install of the apic APIC OS to 1.2(2g) or 1.2(2h).
Workaround:
1. Reboot the Apic
2. Boot into an earlier version and then perform a policy upgrade to 1.2.2
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 1.2(2g), 1.2(2h) |
|
Known Fixed Releases: * | 1.2(3a), 1.2(3c), 1.3(0.45), 1.3(0.61), 2.0(0.202a), 2.0(0.203), 2.0(0.206), 2.0(0.222) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy40206 | Title: | DSCP not getting set in shared L3Out rules when L3out is consumer |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
DSCP not getting set in shared L3Out rules when L3out is consumer
Conditions:
This will occur when l3Out is configured as consumedIf and EPG as provider
Workaround:
Configure l3Out as provider and EPG as consumer
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 1.2(2e) |
|
Known Fixed Releases: * | 1.2(3a), 1.2(3c), 1.3(0.45), 2.0(0.206) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux79170 | Title: | Need support for TCP flag masking on N9K and 3164 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Enhancement request to have TCP flag mask options in ACL
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 23-APR-2016 |
|
Known Affected Releases: | 6.1(2)I3(4b) |
|
Known Fixed Releases: * | 7.0(3)IBL3(1), 7.0(3)IBL3(1.30), 7.0(3)IBL3(1.36), 7.0(3)IBL3(1.51), 7.0(3)IDM3(0), 7.0(3)IDM3(0.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur59733 | Title: | IPv6 TACACS Auth Fails On N7K/N9K Over Mgmt VRF |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
IPv6 TACACS Authentication Fails On N7K/N9K Over Mgmt VRF.
Conditions:
When TACACS+ is setup to communicate over the management network using IPv6 then authentications fail.
Workaround:
none
Further Problem Description:
none
|
|
Last Modified: | 23-APR-2016 |
|
Known Affected Releases: | 6.1(2)I3(1) |
|
Known Fixed Releases: | 6.1(2)I3(3.80), 6.1(2)I3(4) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz36977 | Title: | Invalid Subnet can be configured under L3 External Network |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When Configure subnet under L3 external network, there is no validity check, illegal subnet like 172.16.123.124/26 can be configured as external subnet.
Conditions:
Workaround:
Manually check
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz25145 | Title: | N9K: OSPF Area0 routes NOT install into RIB when enabling BGP EVPN |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
N9K that is in a specific area does not install external and inter-area routes from backbone area into RIB.
Conditions:
BGP EVPN is configured
Workaround:
There is no workaround.
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2c) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz29623 | Title: | NGINX Core after "stimulus (envelope 0x2000000000004) will be dropped!" |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
NGINX Process Core
Conditions:
Unknown
Workaround:
Unknown
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.1(4f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu87980 | Title: * | Users with admin privileges should be allowed to use TSW |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Only user 'admin' can access "Visibility Tool", aka Troubleshooting Wizard. User with role admin cannot access the tool.
Conditions:
Workaround:
Login as admin and use the tool. (In a future release, role-admin will be provided access to the tool)
Further Problem Description:
Role-admin currently does not have permission to download report, pcap files, etc. This restricts the functionality that the user can access within the Troubleshooting wizard. And hence in the initial release (1.1), 'admin' user was only provided access to the tool.
This will be expanded to role-admin users in a future release.
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: | 1.1(1j) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy28590 | Title: | N9k doesnt respond when incoming ARP request contains Vlan tag 0 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N9k does not respond to incoming ARP request when request contains Vlan tag 0.
Conditions:
N9k connects to UCS Server. UCS Server sends ARP request which contains Vlan tag 0.
Workaround:
- On UCS Server, the vNIC adapter must be configured as TRUNK and ACCESS VLAN must be configured.
- On N9k, configure the switchport as TRUNK.
- Shut down VPC Port-Channel going to UCS Server. This may or may not fix the problem.
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(1) |
|
Known Fixed Releases: * | 7.0(3)I3(1.4), 7.0(3)I3(2), 7.0(3)I4(0.19), 7.0(3)I4(0.21), 7.0(3)I4(1), 7.0(3)IM3(1.73), 7.0(3)IM3(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy72316 | Title: | Ping does not work between base and regular epg with intra-deny enforced |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Ping doesn't work between base and regular epg with intra-epg isolation enforced
Conditions:
Regular EPG with intra-epg isolation doesn't have proxy-arp enabled on it.
Workaround:
No workaround on the regular EPG with isolation.
Further Problem Description:
There is no provision to enable proxy-arp on an isolated EPG today. Without this, ARP requests from this EPG will be dropped within fabric.
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.3(0.62a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz23400 | Title: | Port-profile Inheritance not in effect after port Out-of-Quarantine |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Taking an interface out of Quarantine removes the configs inherited from a port-profile by an interface in sh run.
Conditions:
Interface is put into Quarantine mode when FEX is down and taken out of Quarantine using 'no shut' command.
Workaround:
Re-inherit port-profile to get back the configs of port-profile under the interface.
Further Problem Description:
It is a scenario which is hit when interfaces inheriting a Port-profile are quarantined by the Port-profile.
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.0(3)I4(0.82) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy32056 | Title: | Firmware missing from APIC Firmware Repository |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
New firmware has not been added to the Firmware Repository after an hour.
Conditions:
Uploaded new firmware from APIC GUI; Firmware Repository does not reflect that firmware has been uploaded, even though it is present in the /firmware/fwrepos/fwrepo/ folder.
Workaround:
Used "firmware add /firmware/fwrepos/fwrepo/" with the missing APIC image; the command outputs that it fails, but the firmware is now available in the Firmware Repository.
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.1(1o), 1.2(1k) |
|
Known Fixed Releases: * | 1.2(3a), 1.2(3c), 1.3(0.36), 1.3(0.61), 1.3(0.85a), 1.3(0.87a), 1.3(0.88), 2.0(0.202a), 2.0(0.203), 2.0(0.216) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy51472 | Title: | ACI:DOC caution about interface counter reset on interface flap |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
need explanation about interface counter reset on interface flap
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.2(1i) |
|
Known Fixed Releases: * | 1.3(0.62a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy77213 | Title: | ACI: CallHome Query Configured with Empty Class Name is Invalid |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
CallHome emails are not being sent to the destinations in a destination group.
The email is only being sent to the some or none of the configured destination in the destination group.
Conditions:
CallHome configured with destinations with AML/XML format.
CallHome Query is configured with type as class, and the class name is left blank.
Workaround:
Remove CallHome Query that has an empty class name or input a valid class name for the CallHome Query.
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.2(2g), 1.2(2h) |
|
Known Fixed Releases: * | 1.3(0.87a), 1.3(0.88), 2.0(0.243) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy30816 | Title: | VNID allocation issue in shrd service after moving bd to diff ctx & back |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Traffic loss in shared service after following configuration changes:
Toggle shared service provider's BD between consumer's ctx and provider's ctx.
This operation will disable/enable shared service.
Conditions:
Shared service between application EPgs.
Workaround:
Delete and readd relation to contract from one of the consumer epg.
Further Problem Description:
rwEncap on the provider's subnet leaked into consumer's vrf gets set to consumer's vrf vnid rather then provider's vrf vnid.
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: * | 1.3(0.11a) |
|
Known Fixed Releases: | 1.2(3a), 1.2(3c), 1.3(0.28), 2.0(0.202a), 2.0(0.203) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv34286 | Title: | many acidiag options are not documented |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Cisco APIC CLI acidiag command documentation missing several arguments.
Conditions:
Numerous options for the APIC CLI command acidiag allow for checking and impacting system performance. Several of these options are not documented and should not be run unless while working with the TAC.
Workaround:
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: * | 1.3(0.62a) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz40413 | Title: | Stale TCAM entry on leaf after deleting L3Out |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
L3Out subnet traffic in inter-tenant epg to epg contract dropped due to hitting cpu/fwdrop alternately.
Conditions:
Gst-l3-tcam entry of l3out subnet programmed in vrf, but l3out epg is not in logical model.
Workaround:
Move epg / BD to new vrf
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz21597 | Title: | ibash CoPP stats shows incorrectly very large number of dropPkts cnt |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
ibash CoPP statistics might appear incorrect
Conditions:
Very large number of drop packets reported against few protocols
Workaround:
No workaround to fix ibash command. But the following vsh_lc command can be used to get stats of protocols:
vsh_lc -c "show sys int aclq br c e u 0"
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 11.3(0.254) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy16601 | Title: | Track object down after ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
This is specific to TOR boxes in ISSU scenario. Interface track objects are configured and at least one client is tracking it. After ISSU , when box comes up, track objects still shows as down even if the interfaces are UP.
Conditions:
This is specific to TOR boxes in ISSU scenario. Interface track objects are configured and at least one client is tracking it
Workaround:
1) Do "shut" and "no shut" on the interfaces for which track objects are configured.
2) Reapply the track objects config.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.306) |
|
Known Fixed Releases: | 7.0(3)I4(0.104), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus13518 | Title: | VNTAG flag not removed from route when host moves |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Unable to route traffic toward host after the host is migrated to a different port
Conditions:
Host which was connected to a FEX is migrated to a non VNtag enabled interface
Workaround:
use "clear ip arp W.X.Y.Z force-delete" for the affected host
If clearing arp does not work, you will have to clear the route. 'clear ip route x.x.x.x'
Further Problem Description:
Issue will only occur for routed traffic toward a host which previously was connected to a FEX and is now on a non VNTag enabled port
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.1(2)I3(1) |
|
Known Fixed Releases: * | 6.1(2)I3(2.37), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 7.0(3)I1(0.188), 7.0(3)I1(1), 7.1(0)I3(0.41) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy50611 | Title: | N9K: Link goes up when inserting SFP without cables |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Link goes up when inserting SFP without cables
Conditions:
This issue is seen with the combination of Nexus9396PX and 10G-SR SFP.
Workaround:
Remove / Insert the SFP
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.1(2)I3(2) |
|
Known Fixed Releases: * | 7.0(3)I4(0.109), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz18908 | Title: | N9K - Drops ICMPv6 NA Sourced From Link Local Address |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ICMPv6 Neighbor Discovery between a Nexus 9000 and a neighboring IPv6 enabled device is failing.
Conditions:
This condition has been seen with Palo Alto Firewalls.
Workaround:
Configure a static neighbor entry under the SVI for the neighbor on the Nexus 9000.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2a) |
|
Known Fixed Releases: * | 7.0(3)I4(0.109), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv55858 | Title: | ACI subnet leaked to vrf common:default from other vrfs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Prefixes from other Vrfs will show up in the routing table of vrf default as attached routes
Conditions:
vrf default is unenforced and the vrf for a BD is originally linked to vrf default and then it's changed to another vrf.
Workaround:
Select the "Enforced" Policy Control Enforcement for Vrf default
Or
Delete the InsP of the l3out, and redeploy the same configuration
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 1.1(1j), 1.1(1o) |
|
Known Fixed Releases: | 1.1(1.142), 1.1(1r), 1.2(0.41), 1.2(1.17), 1.2(1i), 2.0(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz01934 | Title: | "Internal error in displaying logfile - 40540001\n" returned in nxapi |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When trying to get output for "show logging last xxx" then "Internal error in displaying logfile - 40540001\n" returned in nxapi
Conditions:
show logging last xxxx by nxapi
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2a) |
|
Known Fixed Releases: * | 7.0(3)I4(0.109), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz01843 | Title: | VXLAN decap icmp packet is classified to class-default of CoPP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
VXLAN decap icmp packet is classified to class-default instead of "copp-class-monitoring".
After getting ICMP packets thru VXLAN on N9K(L3 GW),
class-map class-default (match-any)
module 1 :
transmitted 1000 packets; <<<
dropped 0 packets;
Conditions:
L3 GW which is running VXLAN Flood and Learn mode.
Workaround:
none
Further Problem Description:
none
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2a), 7.0(3)I3(1) |
|
Known Fixed Releases: * | 7.0(3)I4(0.110), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz35582 | Title: | Log rotate not working for svc stderr |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On ACI switch, DME log files with file name in the format of svc_ifc_*.log.stderr can grow into large size and eventually fills up the partition and cause the switch to restart. To check the file size of these log files:
ls -la /var/sysmgr/tmp_logs/ | grep log.stderr
To verify the partition usage:
df -h | grep sda7
Sample output:
leaf1# ls -la /var/sysmgr/tmp_logs/ | grep log.stderr
-rw-rw-rw- 1 root root 0 Apr 20 17:46 nginx.log.stderr
-rw-rw-rw- 1 root root 6545 Apr 20 17:46 sharedmemmgr.log.stderr
-rw-rw-rw- 1 root root 351 Apr 22 16:34 svc_ifc_confelem.log.stderr
-rw-rw-rw- 1 root root 351 Apr 22 16:34 svc_ifc_dbgrelem.log.stderr
-rw-rw-rw- 1 root root 550 Apr 22 16:34 svc_ifc_eventmgr.log.stderr
-rw-rw-rw- 1 root root 498 Apr 22 16:34 svc_ifc_observerelem.log.stderr
-rw-rw-rw- 1 root root 0 Apr 26 18:35 svc_ifc_opflexelem.log.stderr
-rw-rw-rw- 1 root root 725 Apr 22 16:34 svc_ifc_opflexp.log.stderr
-rw-rw-rw- 1 root root 248646 Apr 22 16:34 svc_ifc_policyelem.log.stderr
leaf1# df -h | grep sda7
df: `/nxos/tmp': No such file or directory
df: `/var/home': No such file or directory
df: `/var/tmp': No such file or directory
df: `/nginx': No such file or directory
df: `/debugfs': No such file or directory
df: `/cfg0': No such file or directory
df: `/cfg1': No such file or directory
df: `/mnt/plog': No such file or directory
df: `/data/challenge.old.plugin (deleted)': No such file or directory
/dev/sda7 12G 2.8G 8.0G 26% /logflash
/dev/sda7 12G 2.8G 8.0G 26% /var/log/dme/log
/dev/sda7 12G 2.8G 8.0G 26% /var/sysmgr
/dev/sda7 12G 2.8G 8.0G 26% /logflash
Conditions:
The issue happens when some DME process print excessive logs to svc_ifc_*.log.stderr over a certain amount of time. The issue has been reported on leaf with AVS connected.
Workaround:
Enable log rotation so that these log files do not cross pre-defined size.
root login to the switch is required to enable the log rotation, please call TAC for assistance.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 11.2(1.177) |
|
Known Fixed Releases: | 11.3(0.266), 11.3(0.269) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz12865 | Title: | could not bring up the ACL to edit in GUI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Missing graphs from edit ACL, cannot use GUI to apply graph name parameter on folder.
Conditions:
Workaround:
Using Post
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.1(4k) |
|
Known Fixed Releases: * | 1.3(0.123a), 1.3(0.124a), 1.3(0.125a), 1.3(0.128), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy84982 | Title: | DHCPd process continuous crash, no core file |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
DHCPd crashes continuously; no core file found
Conditions:
Workaround:
Upgrade
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.2(1i) |
|
Known Fixed Releases: * | 1.3(0.137), 2.0(0.230a), 2.0(0.232), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz03535 | Title: | TSW: Span-to-apic/host doesn't work for packets bigger than 1476 B |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In troubleshooting wizard when SPAN to APIC or to a host via APIC is configured then packets larger than 1476 bytes are not captured.
Conditions:
Packets larger than 1476 bytes being SPAN-ed to APIC or to a host via APIC.
Workaround:
Instead of SPAN-ing the traffic towards APIC, use a different SPAN analyzer reachable via a front-panel ToR access port either as local SPAN or as ERSPN.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.3(0.91a) |
|
Known Fixed Releases: * | 2.0(0.266a), 2.0(0.267a), 2.0(0.269), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz34848 | Title: | SCVMM: Duplicate host group name breaks inventory sync |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Integrated Hyper-V hosts are not showing up in the Hypervisors section of the APIC GUI under the Microsoft VMM domain.
Conditions:
When there are multiple host groups configured on SCVMM with the same name.
Workaround:
Make sure all host group folder names are unique, even across subfolders.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.2(3c) |
|
Known Fixed Releases: * | 1.3(1b), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz33671 | Title: | Import config failed for Shared service EPG Subnet Scope 'Public,shared' |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Import config failed for Shared service EPG Subnet Scope 'Public,shared'
Conditions:
This can happen when EPG subnets are configured as public in a newer release, and then system is downgraded to an older version that does not support this.
Workaround:
Unset public from the epg subnet before or after downgrading (and before exporting the config).
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.1(4k) |
|
Known Fixed Releases: * | 2.0(0.272a), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz17875 | Title: | AVS L4L7 services - Route peering failures with ASAv |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
AVS + RHI is not supportedSymptom:Conditions:Workaround:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.3(0.101a) |
|
Known Fixed Releases: | 2.0(0.263a), 2.0(0.264) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy18505 | Title: | GUI not matching CLI for Link Oper State when using LACP hot-standby |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Looking at ONLY the hot-standby port-channels in the GUI, we see some Po that are in hot-standby (with Fast timer) show as link-up while CLI shows down.
Under GUI > Fabric > Inventory > L1 > Po3 shows as admin up
In CLI we see the links as:
Leaf1# show interface eth 1/3
Ethernet1/3 is down (hot-standby-in-bundle)
admin state is up, Dedicated Interface
Belongs to po3
Conditions:
Connect 2 devices (say ASR) in VPC with 2 leafs with 2 links from each leaf going to the ASR (total 4 links from each leaf).
Each link connecting ASR to leaf is a port-channel with Fast Timer enabled under "override policy"
The 2nd link from each leaf to each ASR is in hot-standby mode.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.1(3f) |
|
Known Fixed Releases: * | 11.2(3a), 11.3(0.215) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy68354 | Title: | standby sup kernel logs not copied into active sup |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Cisco Nexus 9500 may not have kernel messages from the standby supervisor when collecting techsupports.
Conditions:
Cisco Nexus 9500 running in ACI mode when collecting techsupports.
Workaround:
Collect the required files from the console on the standby sup.
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: * | 11.3(0.219) |
|
Known Fixed Releases: * | 11.3(0.224) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux97999 | Title: | ACI - L3 external STATS not visible on GUI |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Tenants > Tenant_ID > Tenant Tenant_ID > Networking > External Routed Networks > L3 external profile > Stats
L3 external Stats doesn't show any statistics while traffic is passing, it will show "no stats data to display".
Packets are counted by Hardware, stats can be seen for Physical interfaces, and VPCs, as well as broadcom level.
Conditions:
Workaround:
Check Physical/VPC interface stats.
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 1.2(1k) |
|
Known Fixed Releases: * | 11.3(0.192) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy46629 | Title: | ACI - L3 external STATS not visible on GUI |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Tenants > Tenant_ID > Tenant Tenant_ID > Networking > External Routed Networks > L3 external profile > Stats
L3 external Stats doesn't show any statistics while traffic is passing, it will show "no stats data to display".
Packets are counted by Hardware, stats can be seen for Physical interfaces, and VPCs, as well as broadcom level.
Conditions:
Workaround:
Check Physical/VPC interface stats.
Further Problem Description:
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: * | 1.2(2g), 1.2(2h) |
|
Known Fixed Releases: | 1.3(0.43) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz15042 | Title: | GUI: Deleting VPC via Topology>Configure doesn't remove infraAccBndlGrp |
|
Status: | Terminated |
|
Severity: | 4 Minor |
Description: | Symptom:
Interface policies groups, which have been deleted via Basic GUI or Advanced (Topology -> Configure menu), still show up in the Fabric -> Access Policies -> Interfaces -> Interface Policy Groups.
Conditions:
After deleting a VPC from the Basic GUI or Advanced (Topology -> Configure menu).
Workaround:
Go to Fabric -> Access Policies -> Interfaces -> Interface Policy Groups and delete the policy manually.
Further Problem Description:
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 1.2(2g), 1.2(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy40279 | Title: | CLI: default-export route-profile with single set command won't deploy |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
match statements on a route-map such as match bridge-domain, community, prefix-list which do not have specific route-profiles defined under the match statement use the default-export route-profiles when the route-map is applied in the export direction and default-import route-profile when the route-map is applied in the import direction.
Route-profile set action associated with "default-export", "default-import" route-profiles does not take effect on the route-map under certain conditions.
Conditions:
All of the following conditions need to apply for the set action on the default-export, default-import route-profile not to take effect:
1. The "default-export"/"default-import" route-profile has only one set action.
2. Route-map is already created and associated with a routing protocol before adding the set action to the "default-export"/"default-import" route-profile.
If either one of the above conditions are not true, the problem does not happen.
Workaround:
Configure the "set " under the template route-profile default-export command one more time.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 1.2(2f) |
|
Known Fixed Releases: * | 1.2(3a), 1.2(3c), 1.3(0.30), 2.0(0.202a), 2.0(0.203) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz33221 | Title: | APIC : F1800 Fault not clearing |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
F1800 actrl-resource-unavailable & F1801 actrl-resource-unavailable doesnot clear
Conditions:
these faults when raised due to a misconfig, where we have a subnet defined under BD and overlapping subnet is now defined under L3out in same vrf .
Workaround:
na
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.2(1m), 1.2(3c) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz34707 | Title: | stats collection for VMM domains not working with same vmm.CtrlrP |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
If we use same VMM controller (vmm.CtrlrP) name for multiple VMM Domains. because of overlapping name the stats collection only works for one of them.
Conditions:
using same name for all VMM controllers
Workaround:
use unique VMM controller names for each VMM domain.
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: | 1.3(1b) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz33928 | Title: | Stale Route-map Found for Shared Service's Provider VRF |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Step 1: Epg-(tn-Prod/ap-ebiz/epg-data) consumed a contract interface (Stage_Contact_Intf) which is a global contract exported from tn-Stage where it is provided by a shared l3out (tn-Stage/out-BackBone/instP-local). which create a route-map entry matches ipv4 prefix list "IPv4-st49156-2850816-reg-2260992-16327-shared-svc-int-dst"
Step 2: Then Epg-(tn-Prod/ap-ebiz/epg-data) provided a global contract (Inter-VRF-contract) defined from the common VRF and consumed by epg (tn-Stage/ap-prod/epg-avswin), Which changed the epg-data's pcTag from local to global. Which create a new route-map entry matches ipv4 prefix "IPv4-st49156-2850816-reg-2260992-26-shared-svc-int-dst"
Here we can see two issues: The first issue is while switch create a new route-map entry in step 2, the previous route-map entry created in step 1 should be removed because the pcTag has changed from local to global. The second issues is even customer removes the contract relations between EPG and l3extInstP, the route-map entry created from step 2 will not be removed, only the route-map entry created from step 1 is cleared.
Conditions:
Workaround:
1. Remove the shared service contract relations between the EPG and l3extInstP.
Or
2. contact TAC and using testapi to delete the route-map entry.
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.2(1k), 1.3(0.139a), 1.3(0.141a) |
|
Known Fixed Releases: | 1.3(1b) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz17395 | Title: | Basic UI:Failed to add static route error when next hop is not specified |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
'1883||2016-04-12 13:06:41,352||decoy||ERROR||Unknown error while processing request {"context":"_configCb","attributes":{},"children":[{"context":"leaf","attributes":{"nodeRange":"201"},"children":[{"context":"vrfRef","attributes":{"tenantName":"t1","vrfName":"ctx0"},"children":[{"context":"ipv4Route","attributes":{"ipv4Prefix":"193.3.2.0/24","ipOrNull":"0.0.0.0/0","ZeroOrPref":"unspecified","BfdOrPref":""}}]}]}]}||/mgmt/opt/controller/decoy/apps/ncapi/main.py||92'
Traceback (most recent call last):
File "/mgmt/opt/controller/decoy/apps/ncapi/main.py", line 82, in _process
handleData(data, yaci.config, context)
File "/mgmt/opt/controller/decoy/apps/ncapi/main.py", line 61, in handleData
handleData(child, cmd, ctx)
File "/mgmt/opt/controller/decoy/apps/ncapi/main.py", line 61, in handleData
handleData(child, cmd, ctx)
File "/mgmt/opt/controller/decoy/apps/ncapi/main.py", line 61, in handleData
handleData(child, cmd, ctx)
File "/mgmt/opt/controller/decoy/apps/ncapi/main.py", line 56, in handleData
ctx.invokeCmd(toInvoke, reraise=True)
File "/mgmt/opt/controller/yaci/yaci/_ctx.py", line 565, in invokeCmd
configMos = self.__invokeCb(cmd.toConfigCb, None)
File "/mgmt/opt/controller/yaci/yaci/_ctx.py", line 653, in __invokeCb
return cb(**cbArgs)
File "/mgmt/opt/controller/yaci/config/leaf/vrf/ip.py", line 175, in ipv4RouteToConfig
type=type, pref=pref, bfd=bfd)
File "/mgmt/opt/controller/yaci/lib/utils/route.py", line 285, in staticRouteHelper
nexthop, type=type, pref=pref, bfd=bfd)
File "/mgmt/opt/controller/yaci/lib/utils/route.py", line 139, in addRoute
raise UnsupportedConfigException(errorMsg)
UnsupportedConfigException: Failed to add route, route preference must be a number in range <1-255>
'1883||2016-04-12 13:06:41,360||decoy||INFO||Status: 200 OK||/mgmt/opt/controller/decoy/apps/ncapi/main.py||109'
'1883||2016-04-12 13:06:41,360||decoy||INFO||RESPONSE: {"error": "An internal server error occured. Check decoy logs for more information.\nFailed to add route, route preference must be a number in range <1-255>", "statusCode": 500}||/mgmt/opt/controller/decoy/apps/ncapi/main.py||110'
'1897||2016-04-12 13:06:47,315||decoy||INFO||TID: 102||CLI Command: ''||/mgmt/opt/controller/yaci/yaci/_transaction.py||67'
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 2.0(0.250a) |
|
Known Fixed Releases: * | 2.0(0.267a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy50191 | Title: | Inband EPG does not allow contract with a - in the name |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
-missing-target message when configuring a consumed contract under a inband EPG
Conditions:
contract with a "-" in the name
Workaround:
create a new contract without a "-" in the name
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.2(1m) |
|
Known Fixed Releases: * | 1.3(0.19b) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz28614 | Title: | ACI - F1386 Appears when creating a new Bridge Domain |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
When creating a new Bridge Domain with the following Settings:
Forwarding: Custom
L2 unknown Unicast: Flood
L3 Unknown Multicast Flooding: Flood
Multi Destination Flooding: Flood in BD
Uncheck Unicast Routing without checking ARP Flooding (ARP Flooding check box instantly disappears)
Results in error:
F1386
Severity:warning
Description:
ARP flooding must be enabled when L2 unknown unicast is set to flood
But checkbox for ARP Flooding is grayed out.
Conditions:
Workaround:
* Change the L2 Unicast to Hardware Proxy
* Check the ARP Flooding Checkbox
* Move L2 Unicast back to Flood mode.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: | 1.3(0.141a), 1.3(1a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy80988 | Title: | N92304: Kernel protocol buggy seen during fast-reload with rj-45 traffic |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Following message is seen on console and syslog/logfile:
%KERN-2-SYSTEM_MSG: [ 3563.158897] protocol f104 is buggy, dev eth2 - kernel
Conditions:
The following message may be seen during fast-reload - it comes directly from the kernel and is seen before switching over to new kernel when using fast reload. This is a non impacting message seen only for traffic destined to 100M ports 1/65 and 1/66. There is no functional impact due to this message.
%KERN-2-SYSTEM_MSG: [ 3563.158897] protocol f104 is buggy, dev eth2 - kernel
Workaround:
None. Issue is only seen with heavy traffic on 100M RJ-45 ports during fast-reload.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.0(3)IM3(0.27), 7.0(3)IM3(1) |
|
Known Fixed Releases: * | 7.0(3)IM3(1.76) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz11284 | Title: | ACI: ishell "show version" reset version differs from vsh "show version" |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
When using ishell to run the "show version" command, the times are displayed in UTC instead of the configured time zone on the switch.
Also, when using ishell, the last reset reason shows that the current running version reset the switch for the upgrade, when the previous running version should be the version that reset the switch for the upgrade.
Conditions:
Workaround:
Check "show version" in vsh.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 1.3(0.122b), 1.3(0.123a), 1.3(0.124a), 1.3(0.125a), 1.3(0.128), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz05625 | Title: | second logical interface on L3 out can be configured on same encap vlan |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Second logical interface on L3 out should not be able to configure as same encap vlan that is used on another one.
Conditions:
Step to recreate:
-configure a SVI on L3 Out with Ip address 10.0.11.2/24 with encap vlan 110
-configure another SVI on this L3 Out with ip address 10.0.10.2/24 with encap vlan 110, no error prompt And you will get below configuration on the SVI:
120-Leaf1# show ip int vlan 28
IP Interface Status for VRF "ten_shdu:vrf-shdu"
vlan28, Interface status: protocol-up/link-up/admin-up, iod: 81,
IP address: 10.0.11.2, IP subnet: 10.0.11.0/24
IP address: 10.0.11.1, IP subnet: 10.0.11.0/24 secondary
IP address: 10.0.10.2, IP subnet: 10.0.10.0/24
IP address: 10.0.10.1, IP subnet: 10.0.10.0/24 secondary
IP broadcast address: 255.255.255.255
IP primary address route-preference: 1, tag: 0
Workaround:
N/A
Further Problem Description:
This will mislead customer about configuration done, but will actually lead to some other issue.
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: * | 1.3(0.115), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy83221 | Title: | Add OSPF Stub area help information to APIC |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Cisco ACI fabrics as of 1.2 now supports OSPF Stub area. The online documentation available through the APIC does not reflect that as one of the options.
Conditions:
APIC running 1.2 or later release support OSPF Stub area. Online help available through the GUI (https:///help/content/index.html#l3ext_infoROut.html) does not reflect this option.
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: * | 1.3(0.115), 1.3(0.120a), 1.3(0.122), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz33157 | Title: | ACI : wrong trace "No space in LPM TCAM" in policy manager trace |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
The trace log says "No space in LPM TCAM" where as the error is that the entry already exists. This is not an LPM Tcam space issue.
Conditions:
subnet is already defined under a BD for the same vrf
Workaround:
this is due to an unsupported config
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 11.2(1m), 11.2(3a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz33199 | Title: | APIC : F1800 & F1801 need better description |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
F1800 actrl-resource-unavailable & F1801 actrl-resource-unavailable
Conditions:
We have seen these two faults being raised in a condition where, in the same VRF, there is a BD subnet and the same subnet is also configured under the L3out networks.
Workaround:
this is due to an unsupported config. Remove the networks under the L3out EPG and check for a misconfiguration such as the network not being marked as Public.
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 1.2(1m), 1.2(3c) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy44839 | Title: | ACI-mode: N9K-C9508 FAN LED is OFF after Power-cycle. |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
ACI-mode: N9K-C9508 FAN LED is OFF after Power-cycle.
Conditions:
use N9K-C9508 with ACI-mode.
after power-cycle, FAN LED is OFF.
Workaround:
1. Removing a Fan Tray
2. Installing a Fan Tray
Further Problem Description:
none
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 11.3(0.220) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz45663 | Title: | Cannot delete GUI created policies |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Unable to delete policies starting with "__ui_" when created using advanced mode configuration wizard.
Conditions:
Hit when using advanced mode configuration wizard to create access policies (accessible through the topology view).
Workaround:
1. Delete using REST API POST
2. Delete using modelete; navigate to the appropriate folder containing the object, then issue an modelete of that object, followed by moconfig commit
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: | 2.0(0.277b) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz46153 | Title: | accounting logs for scheduler are misleading when negating a schedule |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Removing a scheduler indicates that the schedule removed was successfully created, when in fact it was deleted
Conditions:
removing a scheduler
Workaround:
na
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz00884 | Title: | Fault F0053: Improve description when there's a permissions error |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
A configuration export policy fails, fault F0053 is raised with the following description:
Upload error: Upload failed (at start/before it took off)
or
Upload error: No such file or directory. Error in the SSH layer
Conditions:
When the user configured in the remote location policy doesn't have the correct permissions to write to the remote directory.
Workaround:
Verify the permissions are properly set on the remote server for the user configured on the remote location policy in ACI.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.2(2g), 1.2(2h) |
|
Known Fixed Releases: * | 1.3(0.118a), 1.3(0.120a), 1.3(0.122), 2.0(0.260), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy70476 | Title: | "show environment" output doesn't include all sensors |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
When a sensor (Ex. temperature or voltage sensor) fails, it is no longer listed in the "show environment" output.
Conditions:
When a sensor has failed
Workaround:
On the affected device, issue the following command:
cd /mit/sys/ch/supslot-1/sup/sensor-X (where X is the affected sensor number)
cat summary (look for the operSt)
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 1.3(0.224), 1.3(0.81a), 1.3(0.82), 11.3(0.224), 2.0(0.243) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz15097 | Title: | B22 Port mapping shows incorrect port in topo view |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Fabric/ Inventory/ Topology shows incorrect uplinks for B22
Conditions:
B22 FEX used
Workaround:
Use "show interface fex-fabric" ont he Leaf to see the correct port mapping.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.3(0.103) |
|
Known Fixed Releases: * | 1.3(0.124a), 1.3(0.125a), 1.3(0.128), 2.0(0.273a), 2.0(0.276) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy58574 | Title: | BPDUs Received on Routed Sub-interfaces Should Not Trigger F1888 |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Fault 1888 is raised on one or more routed sub-interfaces on ACI Leafs that are connected to a switch that is transmitting Multiple Spanning Tree Bridge Protocol Data Units (MST BPDU).
The fault is not impactful and is cosmetic in this scenario.
Conditions:
Routed sub-interfaces are configured on the ACI fabric, but fault F1888 is generated on these interfaces.
Workaround:
Option 1. Enable BPDU Filter on outside devices connected to the affected ACI Leaf interfaces.
Option 2. Enable BPDU Filter for the affected ACI Leaf interfaces.
The existing F1888 fault may not clear after either configuration is made. In which case, remove the sub-interface configuration and confirm the fault enters a clearing state. Reapply the sub-interface configuration.
Both options will prevent BPDUs on the affected links. Be sure to understand the full impact of this configuration on a production environment.
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.2(1k) |
|
Known Fixed Releases: * | 11.3(0.219) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy71757 | Title: | F1371 policy-deployment-failed for nonexistent node 4 |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Fault F1371 policy-deployment-failed is raised for nonexistent node 4
Conditions:
This occurs anytime we modify one of the default policies here:
Fabric -> Fabric Policies -> Pod policies
Fabric -> Fabric Policies -> Global policies
Workaround:
none
Further Problem Description:
code : F1371
escr : Failed to deploy policy uni/fabric/dnsp-default to service 8 on node with id 4
lc : raised
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 1.2(1m) |
|
Known Fixed Releases: * | 1.3(0.94), 2.0(0.243), 2.0(0.260) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy70084 | Title: | kmem_cache_alloc() calls in blackbird throwing errors |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
When running the "dmesg" command from the ibash prompt, sometimes a message may similar to
"BUG: sleeping function called from invalid context at ....."
Conditions:
Workaround:
Further Problem Description:
This message is benign and there should be no concern. This bug is being filed to inform the customer that we will fix the code causing this message.
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.2(1m), 11.2(2g) |
|
Known Fixed Releases: * | 11.3(0.224) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz14893 | Title: | show tacacs-server command shows test user |
|
Status: | Other |
|
Severity: | 5 Cosmetic |
Description: * | Symptom:
show tacacs-server cli command from APIC shows a dummy 'test' user in the output. This is a cosmetic bug.
Conditions:
At least a TACACS server is configured on APIC controller
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 12-APR-2016 |
|
Known Affected Releases: | 1.2(1k) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCur76840 | Title: | Clarification on Nexus 9000 3rd Party QSA Support |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Third party QSA adapter such as Mellanox does not work on a Nexus 9000 switch.
This is because third party QSA adapters are not supported on the Nexus 9000 platform.
There is no plans to support third part QSA adapters.
Conditions:
None.
Workaround:
Use Cisco branded QSA adapter.
Further Problem Description:
|
|
Last Modified: | 16-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz25408 | Title: | KVM startup script on APIC stuck at "Press any key" |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Cisco ACI APIC during installation may be stuck at the console prompt "Press any key to continue". Hitting any key results in a keystroke echo on the screen but the startup script does not appear to start.
Conditions:
Cisco ACI APIC during initial installation or after clearing the configuration.
Workaround:
Connect to CIMC via ssh and enabled the serial over lan port.
- scope sol
- set enabled yes
- commit
- exit
Once enabled, access the console via the command "connect host".
Further Problem Description:
|
|
Last Modified: | 23-APR-2016 |
|
Known Affected Releases: | 1.2(3c) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz38339 | Title: | Need to document FEX limitations when used with ACI fabric |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Need a public document that explains limitations and capabilities of FEX when used with ACI fabric. I'd like to see an outline of what features we loose on FEX ports, and how they differ from say a native Leaf port
Conditions:
none
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.2(3c) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz30120 | Title: | Ability to assign alpha-numeric to the username for config import/export |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
APIC doesnt allow the first character to be a number. For example username : 1234567890,
Conditions:
APIC gives an error
Workaround:
NONE
Further Problem Description:
NONE
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 1.2(2g) |
|
Known Fixed Releases: | 1.3(0.141a), 1.3(1a) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz36980 | Title: | Add support on RADIUS/TACACS+ audit on switch |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Currently we don't support cli audit on switch
Conditions:
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 11.2(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy89963 | Title: | Need CLI/Syslog/SNMP support for features pending reload |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
This is a requirement to have CLI/Syslog/SNMP support for features pending reload.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.0(3)IM3(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz40545 | Title: | [apic cluster] Enh: Allow different version to join Cluster for Upgrades |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
One or More APICs cannot join the APIC Cluster in the fabric.
Conditions:
The APICs are running different Controller firmware versions
Workaround:
Manually upgrade the APICs to the configured APIC firmware version configured for the cluster in the Controller policy.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 1.2(3c), 2.0(0.272a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz24961 | Title: | Enh: Give admin user ability to suppress console messages |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Admin user is unable to use all dmesg commands.
Conditions:
When logged in as the admin user.
Workaround:
You must gain root access in order to perform all dmesg commands.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy94826 | Title: | Update description of untagged and tagged situation |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
There are only description of the situation when combine tagged and untagged interface on the ACI funda
mental, configure untagged and tagged static binding on same interface will lead to same situation of 802.1p.
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI_Fundamentals_BigBook_chapter_0100.html#concept_450C8C73C1DE4A4EAF6390E862BD9952
Conditions:
Documentation for upcoming APIC 1.3(x) and switch 11.3(x) release will read as follows:
When an access port is configured with multiple EPGs, one in native 802.1p mode and some with VLAN
tags, all packets exiting that access port are tagged in the following manner:
?For untagged EPG packets:
?On switch hardware starting with the APIC 1.3(x) and switch 11.3(x) release, the untagged
EPG packets exit the access port untagged.
?On switch hardware prior to the APIC 1.3(x) and switch 11.3(x) release, the untagged EPG
packets exit the access port tagged as VLAN zero.
?For the other EPGs, packets exit with their respective VLAN tags.
Workaround:
Further Problem Description:
Configure untagged and tagged on same interface on different EPG,the port will be tagged on follow manner:
When an access port is configured with multiple EPGs, one in untagged mode, and some with VLAN tags, all packets exiting that access port are tagged in the following manner:
-For the EPG configured in untagged mode, packets are tagged as VLAN zero.
-For the other EPGs, packets exit with their respective VLAN tags.
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: * | 1.3(0.132a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz40683 | Title: | APIC show running-config output should show version like NX-OS |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:Enhancement request to add APIC version to show running-config output to be equivalent to NX-OS
Conditions:Version 1.2(3c)
Workaround:
More Info:The show running-config header in the APIC indicates the command it is displaying but not the version of the APIC.
APIC
apic1# show run
# Command: show running-config
# Time: Tue Apr 26 14:33:27 2016
NX-OS
ACI-N3K# sh run
!Command: show running-config
!Time: Tue Apr 26 20:16:54 2016
version 6.0(2)A6(2)
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 1.2(3c) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz43946 | Title: | ACI: request for unique fabric MAC address |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Observed behaviour
------------------------
All ACI fabrics have the default MAC address of 00:22:BD:F8:19:FF.
Expected behavior
----------------------
The default fabric MAC address should be configurable or should be randomly assigned to each ACI fabric so that each fabric has a unique default MAC address.
Conditions:
Workaround:
The MAC address can be manually changed for each BD and for each L3-OUT SVI or routed (sub)interface.
Further Problem Description:
Having a unique MAC address per fabric would simplify configuration and avoid downtime when two ACI fabrics are interconnected via a L2 network, for example like in this scenario:
ACI FABRIC 1 (L3-OUT) <--> L2 network <--> (L3-OUT) ACI FABRIC 2
In the case above, both fabrics will have a unique IP in the same subnet, but a common MAC address with the default configuration, thus communication will not take place over the interconnect.
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz46181 | Title: | schedule jobs should be editable |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Users cannot edit schedule jobs
Conditions:
Utilizing schedulers to execute commands and wishing to have the ability to edit
Workaround:
Delete and recreate the scheduler
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz22962 | Title: | ACI Doc Bug: Explanation Needed for Unified Cluster Time |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Conditions:
Workaround:
Further Problem Description:
In the Cisco APIC Online Help, the UnifiedClusterTime and the Difference Between Local Time and Unified Cluster Time value (positive or negative number) needs to be explained.
|
|
Last Modified: | 16-APR-2016 |
|
Known Affected Releases: | 1.2(3c) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux82283 | Title: | Gui should reflect RBAC rules or have a switch to do so |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
RBAC rules are not properly reflected in the GUI when utilizing a custom security domain
Conditions:
Custom security domains are used in conjunction with RBAC rules that fall under infra.
Workaround:
Currently the only way to give a non admin user access to other tabs in the GUI is to give them at least read only access of security domain "all". However, this allows a user to see everything in those tabs, not just what was defined in the RBAC rules. A this point, RBAC rules would only serve to allow for write access to specific objects that the user would see while being part of security domain "all"
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 1.2(1k) |
|
Known Fixed Releases: * | 2.0(0.136) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv69562 | Title: | Fault for excessive spanning tree TCN on VLAN |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When a leaf switch in ACI receives a Topology Change Notification (TCN), there is no method for seeing that on the APIC. This bug was filed to track the enhancement request for an event created when TCN is received and a fault when excessive TCN are received.
Conditions:
When receiving a TCN on a leaf switch.
Workaround:
Issue "show mcp internal info vlan " on the switch to see number of TCN
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.1(1j) |
|
Known Fixed Releases: | 1.2(0.110a), 1.2(0.112a), 1.2(0.113b), 1.2(0.115a), 1.2(0.116), 1.2(1.17), 11.2(0.46), 11.2(0.47), 11.2(0.48), 2.0(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur85686 | Title: | Reload command does not work as root |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The REST API on the CLI of switch throws an error when trying to reload.
Conditions:
N9K running ACI code. Logged in as root.
Workaround:
Login as admin and issue reload or issue vsh -c reload as root.
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 11.0(2) |
|
Known Fixed Releases: * | 11.3(0.218) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu38404 | Title: | [eft-bputra] Port lockdown feature for open ports on Fabric SVI interfac |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
In the release notes, we clearly document the current list of protocols that are allowed (and cannot be blocked through contracts).
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/release/notes/aci_nxos_rn_1103n.html
Conditions:
In the release notes, we clearly document the current list of protocols that are allowed (and cannot be blocked through contracts).
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/release/notes/aci_nxos_rn_1103n.html
Workaround:
none
Further Problem Description:
Security Vulnerabilities
|
|
Last Modified: | 12-APR-2016 |
|
Known Affected Releases: | 1.1(0.766m), 1.1(0.766p), 1.1(0.867h), 7.2(0)ZN(99.198) |
|
Known Fixed Releases: | 12.0(0.81) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj59073 | Title: | rtg-bgp/bgp: 4 BGP show commands that require XMLization (4) |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
the following 4 CLIs are not XMLized.
- show bgp statistics
- show bgp self-originated
- show bgp policy statistics xxx
- show bgp neighbor x.x.x.x commands
Conditions:
show-cmd | xml doesn't have the xml output.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.2(2.199) |
|
Known Fixed Releases: * | 7.1(0)BF(0.12), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux87714 | Title: | VMM Integration Change Portgroup Pipe Naming Convention |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
When Cisco ACI deploys an EPG as a portgroup in VMWare VMM Integration, it names it in the following manner:
tenant|application profile|EPG
The pipe '|' character can cause problems for third party tools that are unable to properly parse the portgroup name.
Cisco ACI does not currently allow this naming convention to be modified.
Conditions:
A tool or language is used to read the name of a portgroup deployed by Cisco ACI but fails due to the pipe '|' character.
Workaround:
Modify the tool or script to allow the pipe '|' character to be read properly.
Further Problem Description:
|
|
Last Modified: | 04-APR-2016 |
|
Known Affected Releases: | 1.1(3f), 1.2(1k) |
|
Known Fixed Releases: | 2.0(0.226) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur73197 | Title: | 'show copp policy stats' is not accurate for spine nodes |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
'show copp policy stats' is inaccurate on spine nodes
Conditions:
command issued on spines. No functionality impact.
Workaround:
use vsh_lc commands.
Further Problem Description:
|
|
Last Modified: | 04-APR-2016 |
|
Known Affected Releases: | 11.0(2) |
|
Known Fixed Releases: * | 1.3(0.217), 1.3(0.54a), 1.3(0.57), 1.3(0.70a), 1.3(0.72b), 1.3(0.74), 11.2(1.205), 11.2(1.206), 11.2(2.217), 11.2(2e) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy94688 | Title: | Callhome inconsistency after port reset, sometimes no Fault/Callhome |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Call home sometimes results with critical Fault, and call home message after Resetting Leaf-to-Spine port, and sometimes doesn't result with critical Fault.
Conditions:
See config via attached screen caps.
Workaround:
Further Problem Description:
|
|
Last Modified: | 04-APR-2016 |
|
Known Affected Releases: | 1.2(1.206a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz01754 | Title: | add new fault "fltEthpmIfPortDownEPG" to handle only EPG case |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
You are seeing the following fault "Port is down, reason:noOperMembers(connected), used by:EPG" being classified as F0532 fltEthpmIfPortDownInfraEpg, when there is no Infra on that port
Conditions:
Currently, all ports that only have a Usage of "EPG" are classified under this. This is viewable in the documentation:
http://APIC-IP/doc/html/
Fault fltEthpmIfPortDownInfraEpg
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 01-APR-2016 |
|
Known Affected Releases: | 1.2(2g) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy70768 | Title: | Add Ability to upload multiple files in a single upload |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Enhancement request for multiple file uploads at once when uploading images to the APIC via the web browser
Conditions:
Version 1.2(1k)
Workaround:
Further Problem Description:
|
|
Last Modified: | 04-APR-2016 |
|
Known Affected Releases: | 1.2(1k) |
|
Known Fixed Releases: | |
|
|
| |
没有评论:
发表评论