| |
|
Alert Type: | Updated * |
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: | 01-JUL-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), 7.0(3)IED5(0), 7.0(3)IED5(0.145) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva31498 | Title: | EPM/COOP failed to sync EP, md5 mismatch |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic loss is seen after clean reboot of spines.
Conditions:
COOP is configured in strict mode and all spines in fabric are reloaded at the same time. This leads to fabric partition briefly where all APIC nodes are not able to talk to each other until reload is complete.
Workaround:
There are couple of workarounds.
1. Do not reload ALL spines at the same time i.e. that makes sure fabric is not partitioned.
2. Configure COOP is compatible mode.
Further Problem Description:
When fabric gets partitioned, it is possible that all nodes do not have same key used for authenticating COOP messages between nodes. The nodes can continue to be in that state up to 1hr even after partition is healed.
Every 1hr, new key generated and then all nodes will end up having same key and COOP communication between
spines and leaf nodes is established again and traffic is restored.
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 12.0(1l) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy37092 | Title: | dublin_bel: 50g link btwn StMoritz nd Havasu comes up with fec off on TH |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
50G links on N9K-C9232C or N9K-C9236C connected to N3K-C3232C or N9K-X9732C-EX or any FEC capable 100G peer for that matter, will not come up with FEC enabled.
Conditions:
If ToR N9K-C9232C or N9K-C9236C is connected to N3K-C3232C or N9K-X9732C-EX or any FEC capable 100G peer for that matter, 50G links (in breakout mode) will not come up if FEC is enabled on both the peers.
Workaround:
Workaround is to disable FEC on both peers. This is the only and permanent workaround for this limitation.
Further Problem Description:
|
|
Last Modified: | 15-JUN-2016 |
|
Known Affected Releases: * | 7.0(3)I4(1), 7.0(3)IBL3(1.29), 7.0(3)IM3(2.49), 7.0(3)IM3(2.54) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz46848 | Title: | Special FIB adjacency of drop route is incorrect |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Drop adjacency handling in FIB is incorrect
Conditions:
This should have no functional impact on its own but with certain sequences of routes being programmed can cause process crash in tahusd
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(3)IM3(1.74) |
|
Known Fixed Releases: | 7.0(3)I4(0.121), 7.0(3)I4(1), 7.0(3)IM3(2.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: | 23-JUN-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: | 11.2(3a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva18685 | Title: | Ports moving to err-disable state after adding few other vlans to pvlan |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Ports moving to err-disable state after adding few other vlans to pvlan configs
Conditions:
Ports moving to err-disable state after adding few other vlans to pvlan configs
Workaround:
Ports moving to err-disable state after adding few other vlans to pvlan configs
Further Problem Description:
Ports moving to err-disable state after adding few other vlans to pvlan configs
|
|
Last Modified: | 24-JUN-2016 |
|
Known Affected Releases: * | 7.0(3)IPV2(1.9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz79293 | Title: | OpFlex SDK timer doesn't start or starts multiple times after timing out |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
The OpFlex connection fails because its timer isn't created on the Cisco AVS host. In this case, the TOR ages out the ODev. Or, the OpFlex connection flaps continuously because its timer is created multiple times on the Cisco AVS host. In this case, the Cisco AVS host sends many redundant IDEp attaches to the TOR. In either case, the result is complete or significant loss of OpFlex control traffic.
Conditions:
This problem occurs under the following conditions:
- Link flaps
- ESXi reboots
- TOR reloads
- Policy upgrades
Workaround:
On the Cisco AVS host, enter the vem restart command.
Further Problem Description:
|
|
Last Modified: | 24-JUN-2016 |
|
Known Affected Releases: | 1.3(2a), 2.0(0.331) |
|
Known Fixed Releases: | 1.2(3f), 2.0(0.337d), 2.0(0.340), 2.1(0.32), 5.2(1)SV3(1.25) |
|
|
| |
| |
|
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: | 24-JUN-2016 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: * | 1.1(4j), 1.1(4k), 1.2(2i), 1.2(3a), 1.2(3c), 1.3(0.79), 1.3(0.85a), 1.3(0.87a), 1.3(0.88), 1.3(1g) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy43013 | Title: | in-band managment ip address is deleted when arpflood is enabled |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In-band IP address becomes 0.0.0.0 in show switch command.
ip addresses are actually deleted from the node and in-band management does not work.
Conditions:
Unknown L2 uni-cast (arpFlood) is changed from proxy to flood for in-band management BD.
Workaround:
The best way to resolve this is to change the BD for the in-band EPG to 'default', wait for a few seconds, and move it back to 'inb' (or original) BD. This will re-trigger a programming of the BD configuration including the in-band management IP addresses for the nodes.
Further Problem Description:
|
|
Last Modified: | 24-JUN-2016 |
|
Known Affected Releases: | 11.2(1k) |
|
Known Fixed Releases: * | 1.2(2g), 1.3(0.36), 1.3(1g), 1.3(2f), 2.0(0.202a), 2.0(0.203) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz67594 | Title: | ACI - Leaf diagmgr crash |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ACI Leaf Crash with the following reason:
show system reset-reason
*************** module reset reason (1) *************
Reason: reset-triggered-due-to-ha-policy-of-reset
Service:diagmgr hap reset
Conditions:
Workaround:
Not available at the moment.
Further Problem Description:
|
|
Last Modified: | 26-JUN-2016 |
|
Known Affected Releases: | 11.0(3f) |
|
Known Fixed Releases: * | 12.0(0.134), 12.0(0.138), 12.0(0.139), 12.0(1.5), 12.0(1.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu66580 | Title: | Fabric Module unrecoverable-error caused by /var/sysmgr/ fully used |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
All fabric modules of customer become unrecoverable-error. It could happen one by one and eventually all of them get failed.
dmesg from fabric module shows
[ 155.835722] last reset at 1432590112.707548, reason: pcie switch error, code 63
[ 175.562666] unable to detect the device knet0
[ 185.582673] unable to detect the device knet0
df -h on fabric module shows /var/sysmgr are being filled up, the file /var/sysmgr/tmp_logs/eltmc_trace_dump.txt are continuely growing.
bash# df -h
Filesystem Size Used Available Use% Mounted on
devpts 1.5G 116.0K 1.5G 0% /dev/pts
shmfs 1.5G 116.0K 1.5G 0% /dev/shm
tmpfs 128.0M 34.6M 93.4M 27% /var/volatile/tmp
none 1.5G 116.0K 1.5G 0% /dev
/dev/ubi8_0 14.3M 252.0K 13.3M 2% /mnt/plog
/dev/ubi0_0 86.6M 24.0K 86.5M 0% /mnt/bootflash
tmpfs 200.0M 4.0K 200.0M 0% /mnt/pss
none 1.0G 1.0G 0 100% /var/sysmgr
none 25.0M 0 25.0M 0% /var/sysmgr/srv_logs
Conditions:
Interface flapping are seen by looking the eltmc log, as a result the eltmc dump trace are increasing and get filled till the /var/sysmgr is fully utilised.
Workaround:
ssh to all the LC and FC by root/root
ssh root@fc21
cd /var/sysmgr/tmp_logs/
echo 0 > eltmc_trace_dump.txt
Further Problem Description:
|
|
Last Modified: | 26-JUN-2016 |
|
Known Affected Releases: | 11.0(3k), 11.0(4) |
|
Known Fixed Releases: * | 11.0(4k), 11.1(0.235), 11.1(0.236), 12.0(1e) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva18519 | Title: | NGINX crashing when using TACACS authentication |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
NGINX coring on APIC every few days
Conditions:
Large number of login requests per day to APIC (in this case, 22k per day)
Device logging in this way is not reusing their token as they should be
Workaround:
Reconfigure login device to use webtoken instead of requesting new one every time
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 1.1(4f) |
|
Known Fixed Releases: * | 2.0(1j) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva21169 | Title: | Traffic between Enforced & UnEnforced EPG will not work with N9k as IPN |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic between Enforced EPG in POD 1 and UnEnforced EPG in POD 2 in a MultiPOD setup will not work if standalone N9k is used as IPN.
Conditions:
N9k as IPN connecting POD1 and POD2.
EPG in POD1 in intra-EPG deny mode. ( EPG as Enforced)
EPG in POD2. ( Normal UnEnforced Mode)
Send any traffic between them and they wont work.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: | 12.0(1b) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva23187 | Title: | epmc crash due to mac and ip independent moves |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
epmc process crash
Conditions:
MAC and IP are moving independently and very rapidly.
When MAC moves from remote to local and IP moves from local to local and these MAC and IP move to the same EP, the crash happens.
Before crash
EP-1, Mac-A and IP-B, remote
EP-2, Mac-B and IP-A, local port-x
When Mac-A and IP-A are moving as follows, epmc process is aborted.
EP-3, Mac-A and IP-A, local port-y
Workaround:
Moving MAC and IP independently and rapidly could be caused by design issue or cabling issue. By resolving this kind issues and making EP moving less frequently, this problem is prevented.
Further Problem Description:
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: | 11.2(3c) |
|
Known Fixed Releases: * | 12.0(1.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz86494 | Title: | ifav41: Not able to deploy EPGs on ToRs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
EPG deployment fails due to insufficient VLANs available
Conditions:
This can happen when isolated EPGs (for intra-EPG deny) are configured and then deleted. The internal ID for these remain in use on the leaf.
Workaround:
Clean reboot the leaf
Further Problem Description:
|
|
Last Modified: | 06-JUN-2016 |
|
Known Affected Releases: | 2.0(0.335b) |
|
Known Fixed Releases: * | 2.0(0.337g), 2.0(0.345a), 2.0(0.347a), 2.0(0.349a), 2.0(0.351), 2.0(0.357a), 2.0(0.360a), 2.0(0.364a), 2.0(1.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz98754 | Title: | Mac Entry missing from Mac Address table with Inconsistant Port State |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
DUT IP: 172.28.82.9
login: admin/Cisco12345
Traffic is running on all 48 ports, however the mac entry is missing on port e1/17,no issues with the cable and setup:
Turin# show mac add co
MAC Entries for all vlans :
Dynamic Address Count: 47
Overlay Address Count: 0
Static Address (User-defined) Count: 0
Secure Address Count: 0
Conditions:
With the lates tbuild 7.0(3)I4(1.38), the Inconsistantport state issue went away, however, traffic forwarding issue still there. detail in attachment "Turin-Traffic-Problem-Detail"
Workaround:
Further Problem Description:
|
|
Last Modified: | 14-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I4(1.26) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy93241 | Title: | epmc core on SB TOR on scale1-leaf112 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:A leaf node is reloaded due to epmc crash which is following to epmc process infinite loop.
Conditions:- A BD with ARP Flood mode
- One of leaf nodes having the BD receives one ARP or GARP packet whose source mac address is all zeros
- Other remote leaf nodes with the BD would be reloaded
Workaround:- Stop GARP/ARP with all zeros source mac address
or
- Turn off ARP Flood mode of the BD
More Info:In case of epmc process crash, following message is repeated a lot of times in epmc-trace log before crash
2016 May 21 13:03:21.328955762:5005:epmc_proc_lrn_inline_get_l2_key:6265:E] MAC learn coming with 0 mac
Just before the above repeated messages, following message about an end point is also recorded in epmc-trace.
mac should be 0x0 and add64_0:1 shows the ip address in hex of the EP to cause this problem.
Notify: valid=1 key-type=L3 V4 oidx=0 seg_vrf=0xf8ffa7
addr64_0:1=0xac1c3b74:0x0 mac=0x0 mode=1
smod/sport=0x4/0x63 vp=0x0 port=0x25f
sclass=0xc009 nd_ow=0 learn_from=1
prio=0 chg=0 spare=0 source=2 location=0
rsvd_0/1/2/3=0/0/0/0
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 11.3(0.229) |
|
Known Fixed Releases: * | 11.2(3f), 11.2(3g), 11.3(0.236) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz90976 | Title: | L3out SVI encap vlan not removed after deleted logical interface profile |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
After deleting svi under the logical interface profile of an l3out the encap vlan with this svi never gets deleted.
Conditions:
Stale VLAN resolved model can be found in leaf switches:
leaf-101# moquery -c fvIfConn -f 'fv.IfConn.encap=="vlan-270"'
# fv.IfConn
encap : vlan-270
addr : 10.8.0.254/24
auto : no
bcastP : 225.1.117.32
childAction :
classPref : encap
descr :
dn : uni/epp/rtd-[uni/tn-common/out-L3out/instP-0.0.0.0]/node-101/stpathatt-[101-102-3]/conndef/conn-[vlan-270]-[10.8.0.254/24]
extEncap : vxlan-14876649
gw : 0.0.0.0
ifInstT : ext-svi
lcOwn : resolveOnBehalf
llAddr : ::
mac : 00:22:BD:F8:19:FF
mcastAddr : 0.0.0.0
modTs : 2016-05-18T01:36:28.921+02:00
mode : regular
monPolDn : uni/tn-common/monepg-default
mtu : inherit
name :
resImedcy : lazy
rn : conn-[vlan-270]-[10.8.0.254/24]
status :
validState : not-validated
Workaround:
1. Collect full tech_support logs for all APICs and leaves that are affected.
2. Login to the affected leaf switches.( Make sure your production network has redundancy or arrange maintenance window for the below steps)
3. leaf-101#acidiag touch clean or setup-clean-config.sh
4. leaf-101#reload
Further Problem Description:
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz72895 | Title: | Congo: Artesyn PSU shows shut |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
N9K-PAC-3000w-B HW revision 2.2 shows 'shut' in 'show environment power'
Conditions:
ARTxxxxxx PSU Serial Number
Workaround:
Use PSU normally - cosmetic reporting error
Further Problem Description:
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 12.0(0.121) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz90970 | Title: | PolicyElem: Validation Failed when trying to deploy EPG |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: * | Symptom:
VPC configuration doesn't work on the Leaf.
Conditions:
After changing the ports on the Interface Selector's port block associated to the VPC Interface Policy Group.
Workaround:
Delete and recreate the Interface Policy Group.
Further Problem Description:
|
|
Last Modified: | 03-JUN-2016 |
|
Known Affected Releases: | 11.2(3b) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz96337 | Title: | On the border leaf, EP not updated by traffic going to an L3 out. |
|
Status: * | Other |
|
Severity: * | 3 Moderate |
Description: | Symptom:
On the border leaf, for traffic from an EP (so on the fabric) to an L3 out, EP interface won't be update if the EP moves from a leaf to another.
Conditions:
EPG not instantiated on the border leaf so we have actually only the IP EP (and not the mac EP).
Workaround:
Further Problem Description:
|
|
Last Modified: | 07-JUN-2016 |
|
Known Affected Releases: | 11.2(3b) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 08-JUN-2016 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: * | 1.3(0.62a), 1.3(1g), 1.3(2f) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy09939 | Title: | Exporting/reimporting a snapshot seems to break the diff |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A snapshot that was imported and used as the base for a diff reports "Failed to get diff".
Conditions:
A json snapshot was initially exported to a remote location then imported for use. In this release, json diff is not supported.
Workaround:
Generate snapshot locally onto apic so that it shows in the left pane, THEN right click and export to remote location. This seems to get past whatever is causing the diff to fail.
Further Problem Description:
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 1.2(1.192b), 1.2(1.206), 1.2(1k) |
|
Known Fixed Releases: * | 1.2(1.200), 1.2(2g), 1.3(0.11a), 1.3(0.16), 1.3(0.19), 1.3(0.6a), 1.3(0.9), 1.3(1g), 1.3(2f), 2.0(0.191) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus63206 | Title: | fvns:UcastAddrBlk To and From Addresses Should Not Use Mask Bits |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The From and To IP addresses under Management IP Address Pools (vnsAddrInst) require IP addresses in the format:
x.x.x.x/y
and do not perform input validation to restrict entries in an invalid format.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 1.0(2m) |
|
Known Fixed Releases: * | 1.0(2.145a), 1.0(2.146), 1.0(3f), 1.1(0.647), 1.1(1j), 1.3(0.94), 1.3(1g), 1.3(2f), 2.0(0.260), 2.0(1.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy20938 | Title: | Opflex in Send functionality for more than 12 minutes |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
AVS opflex hand-shake is delayed for upto 5 mins after VIB upgrade when there is an high-load of VMotions in progress.
Conditions:
AVS VIB upgraded before VMotion events (due to host being put in maintenance mode) get soaked by APIC/fabric.
Workaround:
- opflex communication will recover and state will be 'active' once VMotion events are soaked by APIC/fabric.
- to avoid this delay, wait for 10 minutes between putting the host in maintenance mode and starting the VIB update.
Further Problem Description:
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 1.2(1.192) |
|
Known Fixed Releases: * | 1.3(0.32a), 1.3(0.34), 1.3(1g), 1.3(2f), 2.0(0.202a), 2.0(0.203) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut21435 | Title: | DHCP Relay address not removed after removing dhcpRelayPolicy and label |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
dhcp relay policy continues to work even after the dhcp relay label and policy are deleted from the tenant.
Conditions:
After a dhcp relay policy and label are created and applied, dhcp relay works as expected. But if the dhcp relay label and\or the dhcp relay policy is deleted, the dhcp relay policy continues to work. The dhcp relay policy remains programmed in hardware.
Workaround:
erase the switch configuration and reboot. The switch will reload and reconfigure without the deleted dhcp relay policy. Note: If you reconfigure a dhcp relay policy and dhcp relay label, the same symptoms and conditions will reappear if you delete the dhcp relay configuration.
Further Problem Description:
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 1.0(3f) |
|
Known Fixed Releases: * | 1.0(3.15), 1.0(3.34), 1.1(0.764), 1.3(1.19), 1.3(2f), 2.0(0.345a), 2.0(0.347a), 2.0(0.349a), 2.0(0.351), 2.0(1.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux74601 | Title: | spine decommission/commission raised fault for policy deployment |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:You are seeing fault "F1371" and it says "Failed to deploy policy uni/userext to service 5 on node with id X". It references some dn pointing to a directory in "/uni/userext". Example:
registry/class-1491/instdn-[uni/userext]/ra-[uni/fabric/secRelnHolder]-5-104-1-0-Subtree-mo/fault-F1371
Conditions:A new switch was added and the fault never cleared after adding this switch.
Workaround:Upgrade to version 1.2(2g) or greater and the fault should clear after the upgrade.
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 1.2(1.120) |
|
Known Fixed Releases: | 1.2(1.138), 1.2(2g), 2.0(0.172) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv78244 | Title: | APIC shows fault for decommissioned switch |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Faults of decommissioned nodes stayed.
Cosmetic
Conditions:
Workaround:
Reload apics one at a time (waiting for fully fit cluster before reloading next)
Further Problem Description:
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: | 7.2(99)ZZ(99.1) |
|
Known Fixed Releases: | 1.2(0.56b), 1.2(0.58a), 1.2(0.60), 1.2(1.17), 1.2(1i), 2.0(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz47165 | Title: | APIC upgrade - File checksum validation |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When attempting to copy a presumed good file (a checksum was not performed after the download completes) into the repository via the command line, if the file fails its checksum, no error will be given in response to the "firmware repository add " command. The command line will return in the same manner as if a valid file were moved into the repository. However, the file will never appear in the repository via the GUI and the available space in the 'firmware-repository' partition decrements will each failed attempt. So the file is being moved into the partition but not added to the catalog. The partition fills up and there is no way to delete the corrupted files.
Conditions:
Copying a file to the /home/admin directory via SCP using either an application such as WinSCP or SCP via the command line. After the file is copied to the listed directory, the "firmware repository add " command is used to add the file to the firmware repository.
Workaround:
None
Further Problem Description:
The customer would like a message that says that the file has failed it's checksum validation.
|
|
Last Modified: | 10-JUN-2016 |
|
Known Affected Releases: | 1.2(2h), 1.2(3c) |
|
Known Fixed Releases: * | 1.3(1.20a), 1.3(1.21a), 1.3(1.22), 1.3(2f), 2.0(0.295a), 2.0(0.300), 2.0(0.345a), 2.0(0.347a), 2.0(0.349a), 2.0(0.351) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz27965 | Title: | File size of iso image displayed incorrectly in the backend. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
GUI/moquery is showing incorrect file size although file on FS is with the proper file size
Conditions:
When viewing the files size in the APIC repository when the APIC image is greater than 4G; for example 1.2(3c) or 1.3(1g).
To view the files in the repository, this can be done through the GUI through the Admin->Firmware tab or through ssh with the "show firmware repository" command.
The incorrect file does in this particular case does not impact functionality.
Workaround:
To see the correct size, view the file through ssh with the command "ls -l /firmware/fwrepo/fwrepo/"
Further Problem Description:
|
|
Last Modified: | 10-JUN-2016 |
|
Known Affected Releases: | 1.3(0.137), 1.3(0.91a) |
|
Known Fixed Releases: * | 1.3(1.20a), 1.3(1.21a), 1.3(1.22), 1.3(2f), 2.0(0.276), 2.0(0.277), 2.0(0.345a), 2.0(0.347a), 2.0(0.349a), 2.0(0.351) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva02321 | Title: | Configure infra vrf using API and tenant using cli is not supported |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: |
Not a common usecase. Also, difficult to implement.Symptom:For BGP EVPN scenario, if the External-L3 provider configuration in tenant Infra is configured using the API/Advanced UI or through CLI Named/Explicit L3Out Mode, external-l3 configuration for Tenants which use the BGP EVPN has to be in CLI Named/Explicit L3Out Mode. The external-l3 configuration for Tenants, which need to be in the Named/Explicit L3Out mode include the "external-l3 epg" and the "route-map" configuration.
Conditions:
For the above scenario i.e if there is a named L3Out configuration for tenant infra BGP evpn sessions, when the user configures the consumer tenant configuration on the spine using the CLI implicit mode, the configuration will not be accepted. As a example,
spine 201
vrf context tenant infra vrf overlay-1 l3out providerOut --> Named L3Out
Now, when the user configures
spine 201
vrf context tenant t1 vrf v1 -> Implicit L3Out
the configuration will be rejected.
Workaround:Tenant external-l3 configuration using BGP EVPN should be in Named Mode, if the provider L3Out is in named mode.
|
|
Last Modified: | 10-JUN-2016 |
|
Known Affected Releases: | 2.0(0.355) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva03160 | Title: | Config restore does not verify fvSubnet on infra vlan |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
An incorrect fvSubnet range is imported
Conditions:
ACI 1.2(2h)
Performing a backup restore on an APIC with a different TEP address pool then the source system
Workaround:
na
Further Problem Description:
|
|
Last Modified: | 11-JUN-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz70931 | Title: | COS is not preserved across multi pod |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
The cos preservation feature is not supported in multipod setup. However we can still make sure of cos preservation of inside the POD but across the POD it is not supported. However when you user is configuring CLASS to DSCP marking for multipod qos then this feature is not supported even inside the POD.
Conditions:
Cos preservation feature is supported only inside the POD, it is not supported across the POD.
CLASS to DSCP marking for multipod qos policy is not supported with cos preservation.
Workaround:
class to dscp and cos preservation features are not supported simultaneously.
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 12.0(0.121) |
|
Known Fixed Releases: | 12.0(0.137) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz77146 | Title: | In Eigrpv6 0::0/0 advertised when no defaultRtLeak policy configured. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Even After Removing Default RtLeak policy for IPv6, EIGRP advertises IPv6 default route.
Conditions:
EIGRP is running on IPv6, and Default route leak policy has been configured and de-configured.
Workaround:
clear ipv6 eigrp topology 0::/0 vrf
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: * | 11.3(1.280), 12.0(0.138) |
|
Known Fixed Releases: | 11.3(1.285), 11.3(1.286) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva04315 | Title: | N92304 : Support for LPM heavy mode |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Support LPM heavy mode to support more than 2048 v6 prefixes (/64)
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 14-JUN-2016 |
|
Known Affected Releases: | 7.0(3)IM3(2) |
|
Known Fixed Releases: | 7.0(3)IM3(2a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz14680 | Title: | switch is returning wrongValue for a GET on vlanTrunkPortVlansEnabled2k |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
User not able to enable the last vlan (vlan 2047) of vlanTrunkPortVlansEnabled2K and system return wrongValue.
setany -v2c 172.28.84.97 private vlanTrunkPortVlansEnabled2k.436237824 -o 0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff:0xff
Error code set in packet - WRONG_VALUE_ERROR: 1.
Conditions:
Workaround:
Using CLI instead.
Further Problem Description:
Problem exists in 7.03(I1)1 and later.
|
|
Last Modified: | 14-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I4(0.72) |
|
Known Fixed Releases: * | 7.0(3)I2(3.7), 7.0(3)I2(4), 7.0(3)I4(0.81), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz66604 | Title: | ACI: RARP is not controlled as expected |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
RARP is flooded in the BD. Customer is unable to control RARP in the BD.
Conditions:
ARP Flooding lever does not affect RARP.
Flood in Encapsulation mode for Multi Destination Flooding also does not affect RARP.
Workaround:
RARP can only be contained within 1 encapsulation at most by putting 1 encapsulation per BD; however, flooding cannot be controlled.
Further Problem Description:
|
|
Last Modified: | 14-JUN-2016 |
|
Known Affected Releases: | 11.2(1k), 11.3(1g) |
|
Known Fixed Releases: * | 2.0(0.381a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv65927 | Title: | ACI: PortChannel Member Policy for fast LACP timeout not working |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LACP fast timeout on PortChannel Member Policy does not take effect when added as an Override policy on the Interface Policy Group
Conditions:
Version 1.1(1j)
Workaround:
None
Further Problem Description:
To change the priority or timeout for LACP on a port-channel or vPC, you create a PortChannel Member Policy setting the timeout to Fast and apply the policy on the Interface Group Policy for the vPC or port-channel. The PortChannel Member Policy is applied as an Override Policy Group. After applying the policy, the other side still sees the fabric switches using a "slow" [30 second] timeout for the port-channel.
|
|
Last Modified: | 14-JUN-2016 |
|
Known Affected Releases: * | 1.1(1j), 2.0(0.374c) |
|
Known Fixed Releases: | 1.1(2.17), 1.1(2a), 1.1(2h), 1.2(0.49), 1.2(0.76a), 1.2(0.77b), 1.2(0.80a), 1.2(0.83), 1.2(1.17), 1.2(1i) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup63288 | Title: | APIC GUI online help - Cluster |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Click on System tab then click on Controllers and select one of the APIC clusters on the left then expand cluster.
Information should be easy to read and should give proper context. For example: Target size table has 2 state:
undefined and local - what are they ?
Health State: what all these type means to user ?
Conditions:
APIC GUI URL:
http://172.23.96.10/#a:b|topology/pod-1/node-1|infraControllerCluster
Online help URL:
http://172.23.96.10/help/content/index.html#infra_infoControllerCluster.html
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 15-JUN-2016 |
|
Known Affected Releases: | 1.0(0.840)T |
|
Known Fixed Releases: * | 7.2(0)ZN(99.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva07273 | Title: | LACP Fast not applied onto the switch |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
LACP Fast does not take effect on a switch
Conditions:
Workaround:
Misconfig. Two step process:
-From interface policy group, need to create an override for LACP fast
-From access port selector. need to apply the override.
Further Problem Description:
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 12.0(0.140) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz77449 | Title: | Contract export to common tenant failed with error message |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Contract export to common tenant failed with error message
Conditions:
This can happen when the configuration contains an EPG associated with to a contract interface and also there is a vzAny (and the Epg is behind this) to contract interface . This configuration is not needed
Workaround:
Remove one of the redundant contract interface associations.
Further Problem Description:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.1(4k) |
|
Known Fixed Releases: * | 1.3(2d), 1.3(2f), 2.0(0.340), 2.0(0.347a), 2.0(0.349a), 2.0(0.351), 2.0(0.370a), 2.0(0.372), 2.0(1.21), 2.0(1.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut21401 | Title: | Add note about default /32 to l3extLifP and l3extLp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
User deploys /32 route unknowingly
Conditions:
User did not enter a subnet mask when creating SVI Interface or Secondary IP Address on an External Routed Network's Logical Interface Profile
Workaround:
Delete and reconfigure the SVI with a subnet mask defined
Further Problem Description:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.0(2m), 1.0(3f) |
|
Known Fixed Releases: * | 1.0(3.34), 1.1(0.737a), 1.3(0.67c), 1.3(0.70a), 1.3(0.72b), 1.3(0.74), 1.3(1.19), 1.3(1g), 1.3(2f), 2.0(0.222) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw11670 | Title: | Queries for fault counts return wrong results or broken responses |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Fault counts queries for controller fabric node and fault class queries using rsp-subtree-include for fabricNode class return incomplete fault count information..
Conditions:
This occurs on all versions of APIC software.
Workaround:
There is no workaround for the issue with the mo query for a controllers fault count.
Rather than doing a class query for fabric nodes and asking for a fault-count, do a mo query for the node but include the fltCnts relative name at the end so you are querying the switches fault count instead.
Further Problem Description:
Queries for fault counts for the controller fabric nodes returns a totalcount in the response of 1 but then the imdata is empty.
Class queries for fault counts using rsp-subtree-include against the fabricNode class returns an incomplete fault count subtree and the counters are all zero.
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.1(2h) |
|
Known Fixed Releases: * | 1.1(3.4), 1.2(0.113b), 1.2(0.115a), 1.2(0.116), 1.2(1.17), 1.2(1i), 1.3(0.49), 1.3(0.67c), 1.3(0.70a), 1.3(0.72b) |
|
|
| |
| |
|
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: | 20-JUN-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(1.3), 1.3(1f), 1.3(1g), 1.3(2f) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz87828 | Title: | High CPU on APIC after deploying FEX vPC to VMM Domain |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
While using the APIC, you notice the GUI is very slow and some policy is not being deployed on the switches. When you SSH to the APIC, and run "top", you see very high CPU utilization on "policymgr" and "eventmgr"
Conditions:
This happens after configuring a FEX vPC and tying it to an AEP using a vmm domain.
Workaround:
use a static path binding instead of VMM< domain for FEX VPC
Further Problem Description:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.2(2h), 1.2(3c) |
|
Known Fixed Releases: * | 2.0(0.357a), 2.0(0.360a), 2.0(0.364a), 2.0(0.366a), 2.0(0.370a), 2.0(0.372), 2.0(1.21) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz73973 | Title: | Stale endpoint after EP moves outside of fabric |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Endpoint becomes unreachable from inside the fabric. This endpoint was previously located inside the fabric and then was migrated/ moved to outside of the fabric
Conditions:
Traffic flow to the endpoint now takes a routed path through the Border Leaf
Workaround:
1) Clear the endpoint from the affected border leaf using the following command:
vsh -c 'clear system internal epm endpoint key vrf [vrf] ip [Host B IP]'
Note, if the border leafs is in a vPC, then the endpoint will needed to be cleared from the peer leaf as well.
Further Problem Description:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 11.2(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva02805 | Title: | DMEization of set nssa-only |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
DMEization of set nssa-only
Conditions:
DMEization of set nssa-only
Workaround:
NA
Further Problem Description:
NA
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.0(3)IED5(0.90) |
|
Known Fixed Releases: * | 7.0(3)IED5(0), 7.0(3)IED5(0.118), 7.0(3)IED5(0.119), 7.0(3)IED5(1), 7.0(3)IPV2(1.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz99114 | Title: | PFC Watchdog : Counter for packets dropped egress need to be cumulative |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Request to show aggregate packets dropped due to watchdog condition
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.0(3)IM3(2) |
|
Known Fixed Releases: * | 7.0(3)IM3(2.63), 7.0(3)IM3(2.64), 7.0(3)IM3(3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva15076 | Title: | Spine dropping class selector 6 packets arriving on IPN links |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
In Multipod where a L2-only BD which spans across two PODs, the ARP response packet (In response to ARP request) does not make it across the PODs (Over IPN)
Conditions:
This was confirmed when N7K is used for IPN. N7K IPN router set the outer COS bits of ivxlan frame carring the ARP-response packet to tc=6 (COS=6) when forwarding it to the spine.
The spine drops such packets where tc=6. This causes perpetual incomplete ARP issues in DC.
Workaround:
Configure QoS on N7K IPN router to implement COS marking set to something lower than 6. OR configure the "DSCP class-cos translation policy" on Cisco ACI under Infra tenant -> Networking -> Protocol Policies.
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 12.0(0.141) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz60713 | Title: * | Policy drops after upgrade of vPC pair to 1.2(3c) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
After upgrading a vPC pair of leafs, when a switch came back online, there was a disruption for a period of time.
Conditions:
You have 2 vPC leafs and you upgrade them 1 at a time.
YOnce a switch is reloaded and comes back up, you will see drops on the border leafs for specific traffic flows by running this command on the CLI of the leafs after it comes back up:
"show logging ip access-list internal packet-log deny"
This happens if you are using vzAny to deploy contracts on the VRF instead of on the EPG's themselves. You verify this by going to the VRF --> EPG Collection for VRF and check if you have contracts applied.
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 23-JUN-2016 |
|
Known Affected Releases: | 1.2(3d) |
|
Known Fixed Releases: * | 2.0(0.324), 2.1(0.26) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz88373 | Title: | QoS marking on T2 interface not working |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
On Nexus9332PQ(7.0.3.I2.3) , when try to apply QoS marking policy-map base on COS&DSCP value class (T2 interface), traffic can not be assigned into different qos-group.
Traffic pattern : L3 traffic which needs to be routed by Nexus 9332PQ.
AQ6-PT-9332PQ-02# show policy-map interface port-channel 1002 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!Service-policy qos applied correctly on T2 L3 port-channel
Global statistics status : enabled
port-channel1002
Service-policy (qos) input: trust_dscp
Class-map (qos): Q1 (match-all)
Aggregate forwarded :
0 packets
Match: cos 4,6
Match: dscp 32-39,48-55
set qos-group 1
Class-map (qos): Q3 (match-all)
Aggregate forwarded :
0 packets
Match: cos 5,7
Match: dscp 40-47,56-63
set qos-group 3
Class-map (qos): Q2 (match-all)
Aggregate forwarded :
0 packets
Match: cos 2-3
Match: dscp 16-31
set qos-group 2
Class-map (qos): class-default (match-any)
Aggregate forwarded :
0 packets
set qos-group 0
AQ6-PT-9332PQ-02# show queuing interface ethernet 1/31
slot 1
=======
Egress Queuing for Ethernet1/31 [Interface]
------------------------------------------------------------------------------
QoS-Group# Bandwidth% PrioLevel Shape QLimit
Min Max Units
------------------------------------------------------------------------------
3 - 1 - - - 6(D)
2 20 - - - - 6(D)
1 45 - - - - 6(D)
0 35 - - - - 6(D)
Port Egress Statistics
--------------------------------------------------------
Pause Flush Drop Pkts 0
+-------------------------------------------------------------------+
| QOS GROUP 0 |
+-------------------------------------------------------------------+
| Tx Pkts | 106995070| Dropped Pkts | 0| !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!all packets enter QoS group 0
Conditions:
Hardware:Nexus 9332PQ
Software version:7.0.3.I2.3
Traffic pattern: Brideged/routed packets and pure L3 routed packets.
Example
Briedged/routed:South-----P201(FEX)--N9K01(Bridged/routed:SVI 20/P1001.20)--P1001.20(T2)------North
Routed : South-----P1000.20(ALE)--N9K02(routed)--P1002.20(T2)------North
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva17151 | Title: | Out-Of-Service policy deployed to node with unmatched pod ID |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Out of Service policy is deployed to node even if POD ID does not match
Conditions:
It a node or interface is added to Out of Service Policy, APIC will honor the policy whenever node ID matches, ignoring POD ID in this case.
Workaround:
Ensure that node ID is correct when marking a node or interface out of service.
Further Problem Description:
|
|
Last Modified: | 26-JUN-2016 |
|
Known Affected Releases: | 2.0(1a) |
|
Known Fixed Releases: * | 2.0(1.23), 2.0(1.27) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva04411 | Title: | Config vfc-po failed when VPC config under "vpc context" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After configuring vPC, user cannot enter into individual port-channel mode:
apic1(config)# vpc context leaf 101 102
apic1(config-vpc)# interface vpc vpc1
apic1(config-vpc-if)# vlan-domain member vdom100
apic1(config)# leaf 101
apic1(config-leaf)# interface vfc-po vpc19
Error: Validation failed: There is an override for both PC and VPC: topology/pod-1/paths-101/pathep-[vpc19] topology/pod-1/protpaths-101-102/pathep-[vpc19]Rn=node-101,
Conditions:
In vPC, each leg cannot be in different port vsan.
Workaround:
There is not workaround from CLI. Please use GUI for this.
Further Problem Description:
|
|
Last Modified: | 26-JUN-2016 |
|
Known Affected Releases: | 2.0(0.357c) |
|
Known Fixed Releases: * | 2.0(1.24), 2.0(1.27) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva02619 | Title: | Stale faults exist in the ifc for failing to deploy epg |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
the ifc did not clear the faults after the epg deploy get delivered
Conditions:
the fault was not cleared when the policymgr and eventmgr were on the same apic, and the leadership was changed. both send the faultcleanup and redelegate to other shards.
Workaround:
removing the redelegate in case of cleanup message will solve the problem of creating the fault delegate again.
Further Problem Description:
|
|
Last Modified: | 26-JUN-2016 |
|
Known Affected Releases: | 2.0(0.366a) |
|
Known Fixed Releases: * | 2.0(1.27) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur59482 | Title: | QoS policer with CIR as percentage is not supported with no-stats |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Policer action with CIR as percentage is not supported when QoS policy of type "qos" is applied with "no-stats" keyword.
Conditions:
When QoS classification policy having policing action is applied with "no-stats" keyword, it is rejected.
Similarly while the policy is active with "no-stats" keyword, adding policing action is rejected.
Workaround:
There is no workaround. When policing action with CIR as percentage is desired, apply the QoS policy without "no-stats" keyword.
Further Problem Description:
|
|
Last Modified: | 26-JUN-2016 |
|
Known Affected Releases: | 6.1(2)I3(1.46) |
|
Known Fixed Releases: * | 7.0(3)I4(1.69), 7.0(3)I4(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz96719 | Title: | Opflex state shown as Send functionality after upgrading to 1.3(2f) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Conditions:
Workaround:
After doing VEM restart Opflex state is Active
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 1.3(2f) |
|
Known Fixed Releases: * | 1.1(4m), 1.2(3h), 1.3(2h), 2.0(0.378a), 2.0(0.381a), 2.0(0.384), 2.0(1.21), 2.0(1.31), 2.1(0.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva16881 | Title: | Doc:BD toggle for FCOE EPG MUST wait 30-35 seconds |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
We need to document the following:
"When toggling BD in an FCOE EPG, one must wait 30-35 seconds between each toggle. If toggle is performed in a quick succession, VFC interfaces will fail to come up and switch reload will be needed to recover."
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 2.0(1a) |
|
Known Fixed Releases: * | 2.0(1a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz16424 | Title: | Nexus 9504 Device is not generating CefcFRUInserted trap while OIR |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
While Performing OIR for Supervisor Card the Nexus 9k -9504 device after performing the Card In , device is not generating the CefcFRUInserted trap with OID (1.3.6.1.4.1.9.9.117.2.0.3) .
Conditions:
While performing Card In OIR for Supervisor card of Nexus 9504 .
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I2(2), 7.0(3)I2(2a) |
|
Known Fixed Releases: * | 7.0(3)I4(1.72), 7.0(3)I4(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva27106 | Title: | Port-channel consistency failure on nexus 9500 |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Port-channel consistency failed due to SDK resource failure. This bug is filed to enhance the logging to find the reason for the resource failure.
SWITCH# sh consistency-checker membership port-channels interface port-channel 217
Checks: Trunk group and trunk membership table.
Consistency Check: FAILED
Found inconsistencies for port-channel217:
Module:16, Unit:1
['Ethernet16/26']
Module:14, Unit:0
['Ethernet16/26']
Module:26, Unit:1
Found hardware missing inconsistencies for:port-channel217
Module:8, Unit:0, Size:1
['Ethernet16/26']
Module:8, Unit:1, Size:1
['Ethernet16/26']
show hardware internal bcm-usd event-history api
21278) Event:E_STRING, length:97, at 625398 usecs after Wed Apr 20 14:38:26 2016
API: bcm_trunk_member_add(0,714,...) -> -14 No resources for operation
uuid:324 took 1241 usec
21279) Event:E_STRING, length:96, at 624820 usecs after Wed Apr 20 14:38:26 2016
API: bcm_trunk_member_add(1,202,...) -> -14 No resources for operation
uuid:324 took 662 usec
21280) Event:E_STRING, length:96, at 624801 usecs after Wed Apr 20 14:38:26 2016
API: bcm_trunk_member_add(0,202,...) -> -14 No resources for operation
uuid:324 took 644 usec
Conditions:
None
Workaround:
Reload the affected switch/module
Further Problem Description:
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: | 6.1(2)I3(5) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva01339 | Title: | N9k Port-channel MTU not set correctly if configured on members first |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If MTU is configured on the member interfaces of the port-channel, and then the port-channel is created, then the port-channel is not assigned the correct MTU value.
Conditions:
.
Workaround:
reapply MTU
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I1(3) |
|
Known Fixed Releases: * | 7.0(3)I4(1.43), 7.0(3)I4(2), 7.0(3)IPM4(0), 7.0(3)IPM4(0.38) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva28796 | Title: | IGMPDom not present on 2nd L3-out in GUI created tenant |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
igmpIf is missing on leaf when multicast is enabled on a L3Out
Conditions:
Very rare and should only occur when posting multicast related configuration. Should not occur when using CLI or GUI to configure multicast.
Workaround:
#1
Create an identical IGMP policy as the policy presently use by the affected L3Out interface group and update the L3Out interface group to use this new policy. If no policy is use by the affected L3Out interface group then create a new default IGMP policy and update the L3Out interface group to use this new policy.
#2
Change a configuration parameter (e.g. 'Group Timeout') in the IGMP policy associated with the problematic L3Out interface group. This should trigger the creation of the missing igmpIf on the leaf. Restore the configuration parameter.
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 2.0(1k) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva29027 | Title: | N9K: Power supply shows as Shutdown even if the switch is operational |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Power supply shows as shutdown and switch is operational
NX9372A# Show environment
Power Supply:
Voltage: 12 Volts
Power Actual Actual Total
Supply Model Output Input Capacity Status
(Watts ) (Watts ) (Watts )
------- ------------------- ---------- ---------- ---------- --------------
1 UCS-PSU-6332-DC 0 W 0 W 0 W Shutdown
2 UCS-PSU-6332-DC 0 W 0 W 0 W Shutdown
The below syslog is also seen
2016 Jun 8 20:18:06 NX9372A %PLATFORM-2-PS_FAIL: Power supply 1 failed or shut down (Serial number xxxxxxxxx)
Conditions:
None
Workaround:
None
Further Problem Description:
The is purely cosmetic
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 7.0(3)I2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva22795 | Title: | l1RsFcIfPolCons not cleared when fcIfPol is removed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | This happens because the l1RsFcIfPolConsMo is not updated to the newly created policy.
Symptom:
The port mode on the l2VfcIf does not reflect the portMode set by the recreated fcIfPolMo
Conditions:
l2VfcIf is already deployed with fcIfPolMo confgured.
fcIfPol is then deleted and re-added
Workaround:
1. delete the infraAccPortGrp and recreate it
2. create another fcIfPol and toggle it with the already created and attached one
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 2.0(1d) |
|
Known Fixed Releases: * | 2.0(1.33a), 2.0(1.35) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva28421 | Title: | Stale endpoint after changing VRF from egress to ingress enforcement |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Stale endpoint on a border leaf after changing the VRF from egress policy enforcement to ingress policy enforcement
Conditions:
- A border leaf (BL) learns a remote endpoint (EP) while running in egress policy enforcement mode.
- the VRF is changed to ingress policy enforcement mode
- the EP learned on the BL moves to a new leaf.
The BL maintains endpoint database continues to point to the old leaf location creating a 'stale EP'. Traffic received on the border leaf to the stale EP is dropped.
Workaround:
After changing from egress to ingress policy enforcement, manually clear any stale endpoints in the fabric. Alternatively, a window can be scheduled to manually clear all endpoints in the VRF on each border at the time the VRF policy enforcement direction is changed.
On the APIC, endpoints can be cleared on a per-VLAN/BD basis or on a per-VRF basis:
fab-apic1# clear endpoints leaf tenant bridge-domain vlan
fab-apic1# clear endpoints leaf tenant vrf
Leaf CLI, clear an individual endpoint via MAC lookup or IP lookup:
fab2-leaf101# clear system internal epm endpoint key vrf vlan mac
fab2-leaf101# vsh -c 'clear system internal epm endpoint key vrf ip '
Note clearing multiple endpoints may cause a traffic impact until the endpoints are relearned in the fabric.
Further Problem Description:
In egress policy enforcement, a border leaf will learn all endpoints on that are sending traffic out the corresponding L3Out (allowing it to apply policy for traffic received on the L3Out). When changing the VRF to ingress policy enforcement, the previous remote learns on the border leaf are maintained.
Traffic egressing the L3out are marked with DL (don't learn) bit. This bit updates the hit-bit in hardware preventing the border leaf from timing out the entry. If the remote learn moves to a different leaf, all traffic continues to be sent with DL bit preventing the move from generating a new learn but also updating hardware hit bit. As a result, the border leaf maintains the old incorrect stale endpoint.
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 11.2(3h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva24993 | Title: | L3-Mcast: Need to wait for PIM routes to expire between config trigger |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Even though the switch has IGMP membership or fabric interest for particular groups, the traffic is not flowing. MRIB does not have the these interfaces in outgoing interface list for those groups.
Conditions:
This problem will happen when on a particular vrf PIM is disabled and enabled before the control planes states in PIM and MRIB are removed.
Workaround:
Once VRF is PIM disabled, make sure to wait for at least 5 minutes before re-configuring PIM on that vrf. This delay will allow the entries to expire or are removed on the box.
Re-configure PIM on vrf only when all entries have been removed from PIM and MRIB.
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 12.0(1i) |
|
Known Fixed Releases: * | 12.0(1.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut21286 | Title: | port-in CSCup66113 to N9k insuff perm to conf login user in enable mode |
|
Status: | Open |
|
Severity: * | 3 Moderate |
Description: | Symptom:
can't make user account of network admin when they are in enable mode
Conditions:
Attempt to configure via CLI in enable mode a user with network-admin role after authenticating with a priv15 user.
Workaround:
Don't use enable mode to make network admin user role
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 6.1(2)I3(3a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva31194 | Title: | Nexus 9k Device not sending ospfNbrStateChange trap related OId |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
While performing OSPF interface down , device is not sending 1.3.6.1.2.1.14.16.2.2.2 OID related to ospfNbrStateChange trap.
Conditions:
While performing OSPF interface down
Workaround:
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.0(3)I2(2), 7.0(3)I2(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva29084 | Title: | Fabric recovery is not happening even after bootstrap.xml is processed |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Pod2 spine does not join and get configuration changes after doing stateful reboot of spine
Conditions:
In case change in policy allowing connectivity between pods sometimes pod may not.converge and may require clean reboot of spine to reestablish connectivity. In case of multipod second pod policies are downloaded when spine is clean reloaded via DHCP. In case of issues which breaks connectivity in between pods stateful reload of spine may not recover connectivity.
Workaround:
Clean reboot of one the spine connecting to ipn network
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 2.0(1k) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva15774 | Title: | Non-breakout ports are missing in ciscoL2L3IfConfigMIB |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
When eth1/1 is configured as breakout port, the non-breakout interfaces will not be populated in cL2L3IfTable.
Conditions:
When eth1/1 is configured as breakout ports
Workaround:
Avoid enabling breakout on eth1/1 or use CLI "show inter status" to get the same info.
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.0(3)I4(1.42) |
|
Known Fixed Releases: | 7.0(3)I4(1.60), 7.0(3)I4(2), 7.0(3)IM3(2.67), 7.0(3)IM3(3) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva28658 | Title: | scale1: BGP session is stuck in CLOSING as peer structure being locked |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
BGP session is stuck in "CLOSING" state and doesn't reset back to "IDLE" state.
This can potentially cause the tenant VRF deletion to fail.
Conditions:
Workaround:
Possible workaround/recovery:
- Reload of the specific node (leaf/spine) is required.
Caveat:
Reloading the node can possibly cause BGP sessions to flap multiple times (especially in a scale setup with large number of BGP peers).
Further Problem Description:
In the example below, BGP peer 10.0.24.82 is stuck in closing (C) state.
scale2-spine6# show bgp sessions vrf overlay-1
State: I-Idle, A-Active, O-Open, E-Established, C-Closing, S-Shutdown
Neighbor ASN Flaps LastUpDn|LastRead|LastWrit St Port(L/R) Notif(S/R)
10.0.24.82 100 1 11:49:47|never |never C 0/0 1/0
>>> Peer is stuck in "CLOSING" and doesn't reset to "IDLE" state.
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 12.0(1i) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux72712 | Title: | smon-mib: snmpwalk with v1, Process did not respond within the expected |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When issuing snmpwalk with v1 against SMON-MIB (64 bits counters), slow response would happen.
The slowness could depend on the # of vlans configured on the setup.
Conditions:
issuing snmpwalk with SNMP v1 requests.
Workaround:
issuing snmpwalk with SNMP v2c requests
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.229) |
|
Known Fixed Releases: | 7.0(3)I2(2.121), 7.0(3)I2(3), 7.0(3)I3(0.236), 7.0(3)I3(0.237), 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva32528 | Title: | Chamonix - adj mgr core after power reset |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
After adj mgr core power cycle causing addition traffic loss
Conditions:
Traffic loss, impacts convergence time with adj manager core
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.0(3)I4(1.71) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva32564 | Title: | Chamonix - tahusd core after power reset |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
tahusd core after power reset
Conditions:
continuous reload, system not stable
Workaround:
use "system no hap-reset" to recover
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.0(3)I4(1.62) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva32534 | Title: | fabricSetupP once added, should not allowed to be deleted |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
After create delete of fabricSetupP policy results in inconsistent state
Conditions:
After create/delete of fabricSetupP policy for multipod
Workaround:
do not create /delete policies which includes tep pool configuration for pods. Nodes can be decommissioned and wiped to remove pods.
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 2.0(1l) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz80416 | Title: | Preprovision mode with AVS VMM domain lead to fault F607861 |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Fault F607861 is raised with description:
"[FSM:FAILED]: Send Endpoint Profile for pre-provision in AEP for domain (TASK:ifc:policymgr:VmmRsAEPSendPreProv)"
Conditions:
The problem occurs when resolution immediacy of "pre-provision" type is used for EPGs in VMM domains of AVS type
Workaround:
The use of pre-provision with AVS VMM domains is not supported. This issue has no workaround
Further Problem Description:
The current fault is not clear. A new fault will be defined to notify of this unsupported configuration in a more clear way.
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: * | 2.0(0.357a), 2.0(0.360a), 2.0(0.364a), 2.0(0.366a), 2.0(0.370a), 2.0(0.372), 2.0(1.21) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw86747 | Title: | N9K: downgrade 7.0 to 6.1 add un-deletable acl for copp in sh run all |
|
Status: | Terminated |
|
Severity: | 4 Minor |
Description: * | Symptom:
On Nexus9000 , downgrading from NXOS7.0 to NXOS6.1 cause addition of un-deletable acl for copp in sh run all.
following copp acl are added
ip access-list copp-system-p-acl-ptp
10 permit udp any 224.0.1.129/32 eq 319
20 permit udp any 224.0.1.129/32 eq 320
ipv6 access-list copp-system-p-acl-vrrp6
10 permit ipv6 any ff02::12/128
these are added to class-map for copp too.
class-map type control-plane match-any copp-system-p-class-redirect
match access-group name copp-system-p-acl-ptp
class-map type control-plane match-any copp-system-p-class-important
match access-group name copp-system-p-acl-vrrp6
Conditions:
Nexus9000
downgrade from 7.0(3)I1(1a) to 6.1(2)I3(3a)
Workaround:
- enable the copp profile again
- write erase and reboot after downgrade
Further Problem Description:
copp configuration is not changed during downgrade and when restoring in lower version, the new added ACLs in higher version is there.
And in the lower version , this new added ACLs are not there , so no way to delete.
This is expected. To recover from this , do one of above workaround.
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 6.1(2)I3(3a), 7.0(3)I1(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva28754 | Title: | Fex Profile Table sort issue |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
In ACI GUI Fabric->Access Policies->Profiles- >fex profile -> Interface selectors for fex.
There is an option to sort but it is not working correctly.
GUI is showing unexpected behavior and does not match the sorting function as in other portions of the GUI.
Conditions:
When creating interface selectors under fex profile in 1.2(3c)
Software Configuration
Workaround:
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 1.2(3c) |
|
Known Fixed Releases: | 2.1(0.38) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva18590 | Title: | EPLD upgrade script throws error on N9300 series |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The EPLD upgrade script (/bin/check-fpga.sh FpGaDoWnGrAdE) does not detect whether it is a N9300 or N9500 series switch. The script will attempt to upgrade all modules which throws an error on the N9300 series switch. The upgrade will complete successfully after a 10 minute timeout and error message.
Conditions:
After running the command "/bin/check-fpga.sh FpGaDoWnGrAdE" on a N9300 series switch, the upgrade script will hang for ten minutes and then throw the following error message:
"
Could not perform switchover.
VDC config has not been synced on Standby Supervisor.
A manual switchover is required to complete the upgrade of the Active Supervisor.
Unable to communicate with the EPLD Process
Module Type Upgrade-Result
------ ---- --------------
1 SUP Success
Reseting Active SUP (Module 1) FPGAs. Please wait...
EPLD Upgrade Completed.
"
The upgrade will complete successfully.
Workaround:
Perform the upgrade manually (requires TAC assistance).
Further Problem Description:
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: | 11.2(1k) |
|
Known Fixed Releases: * | 12.0(1.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz94684 | Title: | APICs GUI responses very slowly. |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Sluggish APIC GUI on specific tab.
1. When customer open the tab for /class/infraAccGrp, the APIC responsed very slow and even hung. Customer configured 1700 interfaces so there're 1700 policy-group.
2. On browser we get error of "A script on this page may be busy, or i may have stoopped responding. .....?
3. On other tab configured less items, the problem does not exist.
Conditions:
Customer configured 1700 interfaces so there're 1700 policy-group.
Workaround:
Reduce the number of policy-group.
Further Problem Description:
N/A
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.3(1h) |
|
Known Fixed Releases: * | 2.0(0.360a), 2.0(0.364a), 2.0(0.366a), 2.0(0.370a), 2.0(0.372), 2.0(1.21) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva00084 | Title: | EP Tracker / Visibility & Troubleshooting displays incorrect IPs |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
User searches for an IP address in the EP Tracker or Visibility & Troubleshooting tool and sees multiple instances of the IP address that are not expected.
Conditions:
There is a "shorter" IP address (e.g. x.x.x.2) and at least one "longer" IP address (e.g. x.x.x.20).
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.2(3c) |
|
Known Fixed Releases: * | 2.0(0.370a), 2.0(0.372), 2.0(1.21) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz88101 | Title: | Not-connected link triggers link down trap upon reboot |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
Link down fault raised on not-connected links.
Traps are sent on reboot.
Conditions:
Workaround:
Ignore the fault.
Will be fixed in future release.
Further Problem Description:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.1(3f) |
|
Known Fixed Releases: * | 2.0(0.370a), 2.0(0.372), 2.0(1.21) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz88083 | Title: | invalid fault for LACP hot standby link |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
When a leaf port goes into LACP Hot-standby state, a fault will be raised:
F0601 - fltPcAggrMbrIfPortHotStandby
Conditions:
When number of member link exceed LACP max link limit, some interfaces will be placed into hotstandby state.
Workaround:
Can be igored.
This fault will be categorized as event in future release.
Further Problem Description:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.1(3f) |
|
Known Fixed Releases: * | 2.0(0.364a), 2.0(0.366a), 2.0(0.370a), 2.0(0.372), 2.0(1.21) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux84433 | Title: | Missing log directory in var/log/dme |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
No 'log' directory is found in /var/log/dme directory.
Conditions:
This issue occurs when the switch default authentication is set to a non-local value such as tacacs.
Workaround:
View current logs in /var/sysmgr/tmp_logs. The 'oldlog' directory in /var/log/dme will still contain older logs.
Further Problem Description:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.2(1h) |
|
Known Fixed Releases: * | 2.0(0.366a), 2.0(0.370a), 2.0(0.372), 2.0(1.21) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz67044 | Title: | Doc: TEP Subnet line is misleading as defined |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Customer reads the following upgrade/downrade doc:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/apic_upgrade_downgrade/b_APIC_Software_Upgrade_Downgrade_Guide/b_APIC_Software_Upgrade_Downgrade_Guide_chapter_010.html
Conditions:
Customer sees the following:
There is a line that is repeated a few times:
The TEP subnet size must be /22 or lower.
which has potential to be interpreted incorrectly
Workaround:
The proposed update is to instead have it say the following:
"The TEP subnet mask should be in the range of /8 to /22. The recommended minimum mask is /19."
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 1.3(1g) |
|
Known Fixed Releases: * | 1.3(1g), 1.3(2f) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz72867 | Title: | APIC Online Help for OSPF Interface Policy is wrong |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
OSPF Interface Policy Online Help doc has incorrect URL
Conditions:
When viewing the online help documentation for OSPF Interface Policies in the APIC GUI
Workaround:
Navigate to https:///help/content/index.html#ospf_intfPolicyInfo.html instead.
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 1.2(3c) |
|
Known Fixed Releases: * | 2.0(0.372) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz98239 | Title: | F1853 Fault raised on fvAEP after upgrade 1.1(2h) to 1.2(3e) |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Fault F1853 was raised after an upgrade from 1.1(2h) to 1.2(3e), stating that the fvAEP limit was exceeded. However the total number of fvAEP was much smaller than the scale.
external@CARDC-APIC11:~> moquery -d globalPolCounts-[uni/fabric]/count-fvAEPg
Total Objects shown: 1
# pol.GCount
oCl : fvAEPg
childAction :
curr : 4294967295
dn : globalPolCounts-[uni/fabric]/count-fvAEPg
exceeded : yes
lcOwn : local
limit : 15000
modTs : 2016-06-06T05:39:32.217-05:00
rn : count-fvAEPg
status :
Conditions:
Upgrade from 1.1(2h) to 1.2(3e)
Workaround:
Delete the object using TestAPI. Root access needed in order to interact with TestAPI.
Further Problem Description:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 1.2(3c) |
|
Known Fixed Releases: * | 2.0(0.372), 2.0(0.374a), 2.0(0.378a), 2.0(0.381a), 2.0(0.384), 2.0(1.21) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz47137 | Title: | Primary encap should be optional is allow-micro-seg is not checked |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
APIC GUI requires to specify both Primary VLAN and Port Encap when Static VLAN Mode is selected in VMM Domain Association
Conditions:
Static VLAN Mode is selected in VMM Domain Association
Workaround:
Specify some valid value for Primary VLAN and then update/delete that value in Domains table.
Further Problem Description:
|
|
Last Modified: | 06-JUN-2016 |
|
Known Affected Releases: | 1.2(3c), 1.3(1g) |
|
Known Fixed Releases: * | 1.3(1.12a), 1.3(1.14a), 1.3(1.15a), 1.3(1.17), 1.3(1.6a), 1.3(1.7a), 1.3(1h), 2.0(0.300), 2.1(0.26) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux60574 | Title: | OSPF Timers Show Sub-Second, Negative or Offset Timestamps |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
In the Leaf CLI, OSPF timers show as sub-second, negative or not matching system time.
Leaf# show ip ospf neighbors vrf all
OSPF Process ID default VRF L3Test2:L3Out2_VPC
Total number of neighbors: 3
Neighbor ID Pri State Up Time Address Interface
100.0.0.1 1 TWO-WAY/DROTHER 0.756030 10.0.0.1 Vlan22 <--- Sub-second Up Time
100.0.0.5 1 FULL/BDR 0.252539 10.0.0.4 Vlan22 <--- Sub-second Up Time
100.0.0.8 1 FULL/DR 0.163662 10.0.0.2 Vlan22 <--- Sub-second Up Time
Leaf# show ip route vrf L3:L3Test
IP Route Table for VRF "L3:L3Test"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
*via 10.0.0.1, vlan22, [110/5], -07:32:50, ospf-default, intra <--- Negative timer
100.0.0.8/32, ubest/mbest: 1/0
*via 10.0.0.2, vlan22, [110/5], -07:32:50, ospf-default, intra <--- Negative timer
Leaf# date
Thu Dec 17 18:49:06 UTC 2015 <--- Not matching event-history entries
Leaf# show ip ospf event-history adj
Adjacency events for OSPF Process "ospf-default"
2015 Dec 17 10:49:02.695349 ospf default [5042]: TID 5153:ospfv2_send_nbr_ddesc:535:(L3:L3Test-base) mtu 9000, opts: 0x42, ddbits: 0, seq: 0x7270265c
2015 Dec 17 10:49:02.695339 ospf default [5042]: TID 5153:ospfv2_send_nbr_ddesc:531:(L3:L3Test-base) Sent DBD with 0 entries to 10.0.0.4 on Vlan22
Conditions:
Command output for OSPF on Leaf switches show timers that exhibit the same issues described in Symptoms.
Workaround:
Ensuring the Time Zone and Display Format in Fabric Pod Policies match. For example, use the following settings for PDT or PST time zones:
Time Zone: America/Los Angeles
Display Format: Local
This workaround has shown to resolve time stamp issues only in some cases.
Further Problem Description:
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 11.1(3f), 11.2(1i) |
|
Known Fixed Releases: * | 1.2(2e), 1.3(0.24a), 1.3(0.26), 1.3(0.32a), 1.3(0.34), 1.3(1g), 1.3(2f), 2.0(0.202a), 2.0(0.203) |
|
|
| |
| |
|
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: | 08-JUN-2016 |
|
Known Affected Releases: | 1.2(1m) |
|
Known Fixed Releases: * | 1.3(0.94), 1.3(1g), 1.3(2f), 2.0(0.243), 2.0(0.260), 2.0(1.6), 2.1(0.26) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz95120 | Title: | GUI BUG when creating Private Network |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Unable to create VRF by going to Tenant > VRF > Create "private network" without seeing error message that it exists already under tenant common.
Conditions:
Occurs when creating a new VRF by itself instead of along with BD. Seems cosmetic.
Workaround:
Create a BD first and under Private Network section > Click "Create New VRF" and proceed to create VRF from there > Finish will create both BD and VRF simultaneously.
Further Problem Description:
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: | 1.1(4l) |
|
Known Fixed Releases: * | 2.0(0.370a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva09448 | Title: | ACI DOC: Transit Routing and Shared L3OUT is actually not supported yet |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
As of June 2016, Fundamentals guide has below statement which sounds like that transit routing with shared L3OUTs is not supported "only" when this particular condition is meet.
Cisco Application Centric Infrastructure Fundamentals
- Chapter: Networking and Management Connectivity
- WAN and Other External Networks
- Shared Layer 3 Out
A l3extInstP EPG behind vzAny and a Layer 3 Out EPG provider is not supported for shared services. Also, transit routing is not supported with a shared Layer 3 Out when a consumer l3extInstP EPG is behina vzAny and a Layer 3 Out EPG is a provider with a direct contract.
(http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI-Fundamentals_chapter_010100.html#concept_A3828485EE594C37B2D5E5DA7765EC53)
However Transit Routing with shared L3OUTs (in other words across VRF) is not supported at all yet.
Conditions:
none
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 21-JUN-2016 |
|
Known Affected Releases: | 1.2(3e) |
|
Known Fixed Releases: * | 2.0(1a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy65173 | Title: | APIC GUI: i-help has no info about packet Drops filter |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
under Fabric-->Inventory --> History--> Events
There is an option of Packet drops filter. i-help has no mention of it.
Conditions:
na
Workaround:
na
Further Problem Description:
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 1.2(2h) |
|
Known Fixed Releases: * | 2.0(0.342) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur72541 | Title: | N9K-M12PQ: Incrementing IntMacRx-Er Errors |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: * | Rcv-Err and IntMacRx-Er errors incrementing:
N9K# show interface counters errors | exclude "\ 0\ *0\ *0\ *0\ *0\ *0"| ex "\ 0\ *--\ *0\ *0\ *0"
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth2/1 0 0 0 12118 0 0
--------------------------------------------------------------------------------
Port Single-Col Multi-Col Late-Col Exces-Col Carri-Sen Runts
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Port Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err
--------------------------------------------------------------------------------
Eth2/1 0 -- 0 0 12118 0
Symptom:Rcv-Err and IntMacRx-Er errors incrementing:
N9K# show interface counters errors | exclude "\ 0\ *0\ *0\ *0\ *0\ *0"| ex "\ 0\ *--\ *0\ *0\ *0"
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth2/1 0 0 0 12118 0 0
--------------------------------------------------------------------------------
Port Single-Col Multi-Col Late-Col Exces-Col Carri-Sen Runts
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Port Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err
--------------------------------------------------------------------------------
Eth2/1 0 -- 0 0 12118 0
Conditions:N9K-M12PQ (Slot 2) in N9K-C9396
also seen on 40G interfaces on 9372PX switches.
Workaround:None.
More Info:This is a non-impacting cosmetic issue. It is due to the port receiving packets where the actual number of bytes in the payload are not equal to type length field.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.1(2)I3(1) |
|
Known Fixed Releases: | 7.0(3)I1(0.148), 7.0(3)I1(1), 7.0(3)I1(1.8), 7.0(3)I1(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup70625 | Title: | Stats export mouseover for export frequency mentions non-stream options |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
The Stats export policies mouse over for export frequency displays configuration options that are not available.
Conditions:
This occurs in 1.0(1*) versions of APIC software.
Workaround:
None
Further Problem Description:
Other export frequencies were considered before the product was released and removed prior to release for various reasons. The mouse over/help was not updated to match the product functionality until after the product was released though.
|
|
Last Modified: | 15-JUN-2016 |
|
Known Affected Releases: | 1.0(0.367a) |
|
Known Fixed Releases: * | 1.0(1.294a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy14271 | Title: | Add a filter for Application Profile EPGs under AP Topology |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Application Profile Topology will display all the EPGs that are linked via contract to the existing EPGs in the Application Profile.
Conditions:
EPGs under a single AP linked to other EPGs via contract
Workaround:
none
Further Problem Description:
none
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: * | 1.2(1k), 1.2(1m), 1.3(2f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva06126 | Title: | FHS StaleLifeTime attribute and Entity/Inst MO permission issue |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Config error
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 14-JUN-2016 |
|
Known Affected Releases: | 2.2(0.39) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz96843 | Title: | Use router-id for loopback needs to be allowed for all L3Outs w/o F1425 |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Enhancement request to allow multiple L3Outs to use the same router-id and have all of them check the "use router-id as loopback" box without getting the F1425 fault.
Conditions:
version 1.3(1g)
Workaround:
Currently, only a single L3Out can have the "use router-id as loopback" checked even if multiple L3Outs are using the same router-id.
Further Problem Description:
|
|
Last Modified: | 07-JUN-2016 |
|
Known Affected Releases: | 1.3(1g) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy18060 | Title: | Remove WAP portal dependency on Cloud Cruiser extensions |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
* In WAP Admin Portal navigate to ACI -> Networks or ACI -> Shared Services
* Result: No content is shown, not even the table header and no refresh button.
Conditions:
WAP Cloud Cruiser extensions not installed on the WAP Admin Portal server
Workaround:
Install WAP Cloud Cruiser extensions on the WAP Admin Portal server
Further Problem Description:
none
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 1.2(1k) |
|
Known Fixed Releases: * | 1.3(0.28), 1.3(1g), 1.3(2f), 2.0(0.197a), 2.0(0.198a), 2.0(0.202a), 2.0(0.203) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz71133 | Title: | Lacrosse: Enable Per queue Per port Rx/Tx stats |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: * | Symptom:
Lacrosse: Enable Per queue Per port Rx/Tx stats
Conditions:
Show queue
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 24-JUN-2016 |
|
Known Affected Releases: | 7.2(0)IMP(0.9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup94070 | Title: | option to Export Device Package and have package part of config export |
|
Status: * | Other |
|
Severity: * | 6 Enhancement |
Description: * | Symptom:
After import of exported config, graph instances are not created and l4l7 packages are missing in the system
Conditions:
Config including l4l7 policies are exported from one system and imported to same or another system
Workaround:
Upload the package again after the config import
Further Problem Description:
When config is exported, the l4l7 device packages are not exported as part of config export.
|
|
Last Modified: | 24-JUN-2016 |
|
Known Affected Releases: | 1.0(0.422a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva02247 | Title: | Periodically Remove Stale Files in /firmware/tmp on APIC |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When attempting to upload a firmware files to an APIC, an error indicating the "repository [is] over 80% full" appears. Even deleting previously uploaded firmware files does not clear out enough space.
Conditions:
Firmware image uploads have previously failed, but repository space is still consumed.
Running "ls -lah /firmware/tmp/" on the affected APIC shows temporary files accumulating and not clearing out. Files are named in the following format:
firmware-iso-*
These directories are not cleared out and take up space in the APIC firmware repository.
Workaround:
Rebooting the affected APIC removes stale files from the /firmware/tmp/ directory.
Further Problem Description:
|
|
Last Modified: | 10-JUN-2016 |
|
Known Affected Releases: | 1.3(1g) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva30176 | Title: | Application Profile visual representation is inconsistent |
|
Status: | Other |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Visual representation of Application Profile shows EPGs and contracts from other Application profiles
Conditions:
Contracts are tied to an L3Out
Workaround:
None, cosmetic issue
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 1.3(2f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva24984 | Title: | N9k 10 second power fluctuation |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
After power outage of 10 seconds, even after power is supplied, the N9k does not boot and instead is stuck with power LED blinking green
Conditions:
Remove power for 10 seconds and plug it back
Workaround:
Unplug power until the LED stops blinking green and power it back on. The chassis will boot successfully.
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 11.2(3c) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu45286 | Title: | MSFT:D++ Provide SNMP MIB for Err-Disable State - CISCO-ERR-DISABLE-MIB |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
A user cannot poll the Interface Err-Disable state via SNMP (OID
Conditions:
This is only an issue when polling the data via SNMP
Workaround:
Use the CLI or XML to collect the data.
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.0(3) |
|
Known Fixed Releases: * | 7.0(3)I4(1.64), 7.0(3)I4(1.7), 7.0(3)I4(1.8), 7.0(3)I4(1.86), 7.0(3)I4(2), 7.0(3)IED5(0), 7.0(3)IED5(0.101), 7.0(3)IED5(0.145), 7.0(3)IED5(0.98), 7.0(3)IPM4(0) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz80389 | Title: | Add vPC and PC Load Balancing field to Policy Groups |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Either Fabric Wide, Per vPC domain, or as a Switch Policy Group, there is no method to change the LACP load balancing hashing.
Documented as MAC/MAC only, firewalls, and IP SAN replication benefits strongly from src IP dst IP L4 Port. Congo PBR will not satisfy the L2 Requirements of iSCSI vPC symmetric transparent firewall inspection via cluster.
Please unlock LACP hash adjustment. Preferred location would be under Fabric > Access Policies > Switch > Switch Policy Group.
Per multiple customer request to adjust LACP Hashing and no ability to do so.
Conditions:
Firewall Clusters, non-optimal load balancing
Workaround:
None known
Further Problem Description:
|
|
Last Modified: | 27-JUN-2016 |
|
Known Affected Releases: | 1.3(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq90291 | Title: | Need filter for Even/Odd Nodes in APIC GUI for Firmware Upgrades |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
This is an enhancement that would allow a user to check a single box that would select all of the even or odd nodes at once rather than having to select them one at a time.
Conditions:
Normal Use
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 1.0(1h) |
|
Known Fixed Releases: | 1.0(3.34), 1.1(0.584), 1.1(1j) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz80347 | Title: | Enhancement Request: Add Clone function to Interface Policy Groups. |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
No Clone function exists for Interface Policy Groups.
Conditions:
I recommend that BU adds a right click ?> clone, and then it prompts you for a name.
It then creates an object with that name with the identical attributes of the original.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 27-JUN-2016 |
|
Known Affected Releases: | 1.3(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz98469 | Title: | ACI : Clean-up issue with BD subnet, route stuck in routing table |
|
Status: | Other |
|
Severity: | 6 Enhancement |
Description: | Symptom:
If you have an existing static route defined towards an L3out. and you configure the same subnet as a BD subnet.
and realize that the subnet was not to be configured and delete the BD subnet, the BD subnet route gets stuck in routing table.
order of operation :
it doesnot matter which one you configured first ( BD subnet or static route).
only the BD subnet that has this clean-up issue.
Conditions:
same subnet configured as Static route out to L3out and also now configured as BD subnet in same vrf.
Workaround:
Delete the static route and add it back in. this will clear the stale route.
Further Problem Description:
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 1.2(3c) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy16419 | Title: | APIC CLI: Terminal length command missing to control output display |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
APIC CLI available in version 1.2 allows for additional NXOS-like CLI options. However, there is no way in the native output to control the length of the output similar to "terminal length" command in NXOS.
Conditions:
APIC CLI running version 1.2 and attempting to control the output length of show commands.
Workaround:
User can use the following:
- 'show | cat' to dump the output
- 'show | more -' to set the number of lines forwarded.
Further Problem Description:
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 1.2(1m) |
|
Known Fixed Releases: * | 1.2(1.208), 1.2(2g), 1.3(0.11a), 1.3(0.16), 1.3(1g), 1.3(2f), 2.0(0.191) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz69394 | Title: | Share service is not working for inband management on Spine |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Configure inter-vrf leaking between normal EPG and mgmt:inb. subnet is leaked properly on leaf in vrf mgmt:inb but not leafed to spine:
120-Spine1# show ip route vrf mgmt:inb
IP Route Table for VRF "mgmt:inb"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF
10.2.2.201/32, ubest/mbest: 2/0, attached, direct
*via 10.2.2.201, lo7, [1/0], 01:46:20, local, local
*via 10.2.2.201, lo7, [1/0], 01:46:20, direct
120-Spine1# show ip route vrf mgmt:inb
IP Route Table for VRF "mgmt:inb"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF
10.2.2.201/32, ubest/mbest: 2/0, attached, direct
*via 10.2.2.201, lo7, [1/0], 01:49:14, local, local
*via 10.2.2.201, lo7, [1/0], 01:49:14, direct
120-Leaf1# show ip route vrf mgmt:inb
IP Route Table for VRF "mgmt:inb"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF
10.2.2.0/24, ubest/mbest: 1/0, attached, direct, pervasive
*via 10.0.160.64%overlay-1, [1/0], 00:49:31, static
10.2.2.1/32, ubest/mbest: 1/0, attached, pervasive
*via 10.2.2.1, vlan18, [1/0], 00:49:31, local, local
10.2.2.3/32, ubest/mbest: 1/0, attached
*via 10.2.2.3, vlan18, [1/0], 01:48:20, local, local
192.168.15.0/24, ubest/mbest: 1/0, attached, direct, pervasive
*via 10.0.160.64%overlay-1, [1/0], 00:05:45, static
Conditions:
Share service is not working for inband management on Spine.
Configure share service between normal EPG and inband EPG on mgmt tenant, subnet on internal EPG is not leaked to vrf mgmt:inb on spine.
Workaround:
if you are about using share service, then there is no workaround.
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 11.2(2g) |
|
Known Fixed Releases: * | 12.0(0.145), 12.0(0.150), 12.0(1.8), 12.0(1d), 12.1(0.8) |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论