| |
Bug Id: | CSCus63191 |
Title: | ISIM: Addtional config from isim leafs should be added automatically |
|
Description: | Symptom:
There is no infra vlan connectivity to the leaf in the simulator from the ESX (host) added to AVS.
Ping to 10.0.0.30 (opflex discovery ip) does not work.
Conditions:
Add an ESX host to AVS with the simulator.
Workaround:
Add a static route to the DHCP IP of the ESX's vmk1 as follows on the leaf:
Steps:
(1) ssh root@esx
(2) esxcfg-vmknic -l
(Note the ip addr of vmk1)
(3) ssh as root into leaf1
(4) route add leaf2-1-1.4
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 1.0(2.111) |
|
Known Fixed Releases: | 1.0(3.15), 1.0(3d), 1.0(3f), 1.1(0.667), 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCup97505 |
Title: | Under heavy prolonged control plane stress a fabric module could reload |
|
Description: | Symptom:
When sending a large amount of ARPs or other control plane traffic over a long period, one random fabric module could reload due to EPC heartbeat failure. This will cause zero packet loss due to only one fabric module reloading
Conditions:
When sending a large amount of ARPs or other control plane traffic over a long period, one random fabric module could reload due to EPC heartbeat failure. This will cause zero packet loss due to only one fabric module reloading
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I2(2a) |
|
Known Fixed Releases: | 7.0(3)I1(0.171), 7.0(3)I1(0.180), 7.0(3)I1(1), 7.0(3)I1(1.20), 7.0(3)I1(2), 7.0(3)I2(0.54), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCup47703 |
Title: | EPG) DSCP marking overwritten with vzAny in l3Out |
|
Description: | Config is not supported
Symptom:
The DSCP value specified on an external endpoint group (EPG) does not take effect on filter rules on the leaf switch.
Conditions:
This issue occurs when an external EPG is configured as part of vzAny (a collection of endpoint groups within a context).
Workaround:
Attach the external EPG directly to contract.
Further Problem Description:
When specifying vzAny config for a contract, external EPGspecific target DSCP values are not honored. This happens because vzAny is a collection of all EPGs in that context and EPG specific config can not be applied. If EPg specific target DSCP values are expected to be applied on filters, then external EPG should attach to contract directly and not through vzAny.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 1.0(0.318) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo37016 |
Title: | L3 switched packets going out of FEX Hif interface not spanned |
|
Description: | Symptom:
When configuring the output span on a FEX Hif interface, all the layer 3 (L3) switched packets going out of that FEX Hif interface are not spanned. Only layer 2 (L2) switched packets going out of that FEX Hif are spanned.
Conditions:
This issue occurs when the output span on a FEX Hif interface is configured, and the packets are L3 switched and going out of that FEX Hif interface.
Workaround:
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 11.0(0.772) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu27351 |
Title: | Unable to change the PN to 'Unenforced' |
|
Description: | Symptom:
Command fails with error "Configuration is invalid due to GraphInst does not have any configuration parameters" after a policy based upgrade.
Conditions:
Policy-based upgrade was done from 867d or earlier image to a latter version
Workaround:
Please run the script cleanupRsLIfCtxToBD.py by pointing it at your APIC ip address. Script can be obtained from AS folks
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 1.1(0.867b), 1.1(0.872a) |
|
Known Fixed Releases: | 1.0(4i), 1.1(0.904), 1.1(0.906) |
|
|
| |
| |
Bug Id: | CSCuu56104 |
Title: | APIC Troubleshooting in scale setup: consistent Communication failures |
|
Description: | Symptom:
When in scale setup where large number of leaf switches, and large number of tenants and large routing table,
APIC troubleshooting session may exceed the GUI time out value and time out.
Conditions:
n scale setup where large number of leaf switches, and large number of tenants and large routing table are present.
Workaround:
Using CLI or simpler setup.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 1.1(0.912a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu45269 |
Title: | [Tib Fex]: policyelem core observed during fex hw regression |
|
Description: | Symptom:
Conditions:
Workaround:
Further Problem Description:
Program terminated with signal 11, Segmentation fault.
#0 0xf70d76ed in nw::PathEpBI::getFabricPathEpDnFromNwPathEpDn(mo::DnBuffer const&, mo::DnBuffer&, bool) () from /isan/lib/libsvc_ifc_policyelem.so
(gdb) bt
#0 0xf70d76ed in nw::PathEpBI::getFabricPathEpDnFromNwPathEpDn(mo::DnBuffer const&, mo::DnBuffer&, bool) () from /isan/lib/libsvc_ifc_policyelem.so
#1 0xf6eb59f2 in ifc_policyelem::Svc::taskNwPathEpUpdatePathEpContextFormatCb(meta::ActionHandler const*, mo::Mo*, mo::Mo*) () from /isan/lib/libsvc_ifc_policyelem.so
#2 0xf6831475 in meta::TaskHandler::trigger(mo::Mo*, mo::Mo&, bool) const () from /isan/lib/libcore.so
#3 0xf68352f1 in meta::TaskHandler::trigger(mo::Mo&, unsigned int) () from /isan/lib/libcore.so
#4 0xf70d93a0 in nw::PathEpBI::postExplicitCb(mo::Mo&) const () from /isan/lib/libsvc_ifc_policyelem.so
#5 0xf674f2b8 in ?? () from /isan/lib/libcore.so
#6 0xf6758a92 in mo::Changer::processObjects(void (*)(mo::Mo*), bool, proc::Transactor::State) const () from /isan/lib/libcore.so
#7 0xf674db8a in mo::Transactor::explicitEndCb() () from /isan/lib/libcore.so
#8 0xf67cfd9b in proc::Doer::bulk(std::vector >&) () from /isan/lib/libcore.so
#9 0xf67d0d3c in proc::Doer::tryBulk(std::vector >&) () from /isan/lib/libcore.so
#10 0xf67d0f61 in proc::Doer::process(std::vector >&) () from /isan/lib/libcore.so
#11 0xf67d21b2 in proc::Doer::react(std::array const&, unsigned int) () from /isan/lib/libcore.so
#12 0xf66f953c in core_queue::BsqReader::process(core_queue::BatchServiceQueue&, unsigned char) () from /isan/lib/libcore.so
#13 0xf66f02bc in core_queue::BatchServiceQueue::consume(unsigned char) () from /isan/lib/libcore.so
#14 0xf66ef54e in boost::asio::detail::completion_handler, unsigned char>, boost::_bi::list2*>, boost::_bi::value > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned int) ()
from /isan/lib/libcore.so
#15 0xf62f087f in boost::asio::detail::strand_service::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned int) () from /isan/lib/libosiris.so
#16 0xf62ee836 in boost::asio::detail::task_io_service::run(boost::system::error_code&) () from /isan/lib/libosiris.so
#17 0xf62eac66 in core_thread::WorkDispatcher::onThreadCreation() () from /isan/lib/libosiris.so
#18 0xf62ec40d in boost::detail::thread_data, boost::_bi::list1 > > >::run() () from /isan/lib/libosiris.so
#19 0xf2dd58ec in ?? () from /usr/lib/libboost_thread.so.1.49.0
#20 0xf2db69ab in start_thread (arg=0xf11cfb40) at pthread_create.c:309
#21 0xf2ad
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 1.1(0.902a) |
|
Known Fixed Releases: | 1.1(0.910a), 1.1(0.911) |
|
|
| |
| |
Bug Id: | CSCuu40659 |
Title: | Punting packet to pktmgr err 126 |
|
Description: | Symptom:
2015 May 19 00:49:22 N9504_109_2021_VTEP-2 %$ VDC-1 %$ May 19 00:49:22 %KERN-3-SYSTEM_MSG: [11617.450262] lcnd_inband_decap:2029:Could not obtain dest if-index (smod 0 sport 0 svp 15253) Punting packet to pktmgr err 126 - kernel
2015 May 19 00:53:22 N9504_109_2021_VTEP-2 %$ VDC-1 %$ May 19 00:53:22 %KERN-3-SYSTEM_MSG: [11857.079426] lcnd_inband_decap:2029:Could not obtain dest if-index (smod 0 sport 0 svp 15253) Punting packet to pktmgr err 126 - kernel
2015 May 19 00:56:55 N9504_109_2021_VTEP-2 %$ VDC-1 %$ May 19 00:56:55 %KERN-3-SYSTEM_MSG: [12069.943778] lcnd_inband_decap:2029:Could not obtain dest if-index (smod 0 sport 0 svp 15254) Punting packet to pktmgr err 126 - kernel
2015 May 19 00:59:29 N9504_109_2021_VTEP-2 %$ VDC-1 %$ May 19 00:59:29 %KERN-3-SYSTEM_MSG: [12223.510691] lcnd_inband_decap:2029:Could not obtain dest if-index (smod 0 sport 0 svp 15253) Punting packet to pktmgr err 126 - kernel
2015 May 19 01:04:08 N9504_109_2021_VTEP-2 %$ VDC-1 %$ May 19 01:04:08 %KERN-3-SYSTEM_MSG: [12502.272058] lcnd_inband_decap:2029:Could not obtain dest if-index (smod 0 sport 0 svp 15254) Punting packet to pktmgr err 126 - kernel
2015 May 19 01:05:59 N9504_109_2021_VTEP-2 %$ VDC-1 %$ May 19 01:05:59 %KERN-3-SYSTEM_MSG: [12612.909359] lcnd_inband_decap:2029:Could not obtain dest if-index (smod 0 sport 0 svp 15253) Punting packet to pktmgr err 126 - kernel
Conditions:
NA
Workaround:
NA
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.303) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq39829 |
Title: | Switch falls back to local authentication even when TACACS is reachable |
|
Description: | Symptom:
Switch rescue user ("admin") can log into fabric switches even when TACACS is selected as the default login realm.
Conditions:
TACACS is configured as the default login realm
Workaround:
None
Further Problem Description:
This only applies to the specific switch username "admin", which also serves the purpose of rescue user on the switch. Rescue user is useful when there are software issues with securitymgr, and can always login regardless of the configured authentication domain.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 11.0(1b) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu58601 |
Title: | PO member are disabled or suspended by LACP |
|
Description: | Symptom:
ALL PO are down, because no operational member.
Conditions:
NA
Workaround:
NA
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 06-JUN-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.333) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu66580 |
Title: | Fabric Module unrecoverable-error caused by /var/sysmgr/ fully used |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 11.0(3k), 11.0(4) |
|
Known Fixed Releases: | 11.1(0.235), 11.1(0.236) |
|
|
| |
| |
Bug Id: | CSCut64977 |
Title: | N9K: odd number Vlans are missing in vtpVlanTable |
|
Description: | Symptom:
vtpVlanTable does not instantiate odd numbered vlans during snmpwalk.
snmpget works fine for both odd and even vlans.
Conditions:
Permform snmpwalk on vtpVlanTable with odd numbered vlans (3,5,7,9 etc. configured).
Workaround:
Use snmpget to retrieve values for odd numbered vlans.
Further Problem Description:
The issue exists in NXOS software release 7.0(3)I1(1). The fix exists in 7.0(3)I2(1) and all the later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 7.0(3)I1(1.168) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu79056 |
Title: | OSPF Process Leaks Memory with table-map configuration |
|
Description: | Symptom:
Memory leak can be seen in Nexus 9000 switch while running ospf. This issue is related to presence of table-map in the configuration. The leak in ospf process occurs in librpm_dll.so libraries.
Conditions:
The leak seems to occur whenever there's an SPF run/topology updates, and the size of the leak increases with the size of the OSPF area. The memory leaks happens due to the presence of table-map configuration within ospf.
Workaround:
remove table-map command from ospf configuration. This should prevent the memory in ospf process from increasing. To completely free the holding memory please clear the ospf process using clear ip ospf neighbor *
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut68343 |
Title: | svi down on leaf after ctx delete and add |
|
Description: | Symptom:
After adding a subnet under a BD or an EPG, the subnet will stay in a "protocol-down/link-down/admin-up" state. The SVI will also be in a "LOCKED" state. You can verify this by going onto the leaf CLI:
vsh
show system internal interface-vlan info vlan
svi_cli_debug_show_all(115): per_vlan
SVI database
------------
SVI=16
ifindex=0x9010010 LOCKED SVI_STATE_READY <-------
Conditions:
problem was seen after re-importing config, but may happen in other situations.
Workaround:
reboot the switch
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 11.1(0.185) |
|
Known Fixed Releases: | 11.0(3.930), 11.1(0.191) |
|
|
| |
| |
Bug Id: | CSCus62828 |
Title: | bcm_usd service crashed during PoC sub-IF configuration |
|
Description: | Symptom:
Module reload due to bcm_usd crash (hap-reset)
Service "bcm_usd" (PID xxxx) hasn't caught signal 6 (core will be saved).
%MODULE-2-MOD_DIAG_FAIL: Module x (Serial number: XXXXXXXXXXX) reported failure due to Service on linecard had a hap-reset in device DEV_SYSMGR
Conditions:
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(3) |
|
Known Fixed Releases: | 6.1(2)I3(3.80), 6.1(2)I3(4) |
|
|
| |
| |
Bug Id: | CSCuu75496 |
Title: | Cannot configure L3 Out static route via GUI |
|
Description: | Symptom:
Cannot create static route through the APIC when using GUI. The Prefix prompt will not recognize any value.
Conditions:
When attempting to add a static route through the GUI. Prefix prompt will not accept any value preventing the configuration to be completed.
Workaround:
Use CLI or REST API to add the external routed network if static routes are needed.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 1.1(1c) |
|
Known Fixed Releases: | 1.1(1d) |
|
|
| |
| |
Bug Id: | CSCup81353 |
Title: | STP current timer rollover after 100 days and repeated TC's |
|
Description: | Symptom:
On Nexus 9000 switch, if there is any Topology Change during the uptime of the switch and if the switch uptime exceeds 90-100 days then the STP timer rolls over (overruns) and STP Topology Change BPDUs are sent every hello interval (ie 2 sec)
Conditions:
Nexus 9000 Switch running for about 90 to 100 days and experienced a TCN during the uptime of the switch.
Active Supervisor Uptime can be found from "show system uptime":
N9K-RTP-ESC# show system uptime
System start time: Fri Oct 25 09:40:58 2013
System uptime: 236 days, 8 hours, 56 minutes, 59 seconds
Kernel uptime: 110 days, 23 hours, 7 minutes, 49 seconds
Active supervisor uptime: 110 days, 23 hours, 2 minutes, 23 seconds <<<<<<<<<<<
Workaround:
For dual-supervisor setups:
1. Reload the standby supervisor using cli "reload module x" where x is standby supervisor slot number.
2. Use the 'show module' command to confirm that the standby supervisor is up and in the ha-standby mode.
3. Use the system 'switchover command' to switch to the standby supervisor.
For single-supervisor setups:
1. Upgrade to a release with the fix for this issue.
In case of dual SUP or Single SUP Nexus 9000 chassis, workaround would be to install the SMU which can be downloaded on Cisco.com under NX-OS Software Maintenance Upgrades (SMU)-6.1(2)I2(2a). SMU is a non-disruptive install process.
Further Problem Description:
Issue is fixed in 6.1(2)I2(2b) and 6.1(2)I3(1) and later.
There is a similar defect opened on the Nexus 7000 switch. It is being tracked via CSCuo80937.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I2(2.53), 6.1(2)I2(2.81) |
|
Known Fixed Releases: | 6.1(2)I2(2b), 6.1(2)I2(2c), 6.1(2)I3(1) |
|
|
| |
| |
Bug Id: | CSCur79845 |
Title: | DHCP Relay ACL not applied on Line Card 9464TX/PX |
|
Description: | Symptom:
Dhcp relay ACL is not programmed for some VLANS for some of the Line Cards including 9464TX/PX
Conditions:
Nexus 9000 acting as DHCP Relay.
Workaround:
Remove ip dhcp relay address command under VLAN SVI and then readd it again.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(2) |
|
Known Fixed Releases: | 6.1(2)I3(2.28), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 7.0(3)I1(0.174), 7.0(3)I1(1) |
|
|
| |
| |
Bug Id: | CSCut36428 |
Title: | End Point Attachment Issues with Multiple Service Graphs |
|
Description: | Symptom:
End point attachment notification 1) does not always result in attachment notification, or 2) attachment notification is only sent to a subset of deployed service graph instances, or 3) attachment notification is sent to the incorrect service graph instance.
Conditions:
- ACI L4-L7 device package integration
- Attachment Notification enabled for service graph template(s)
- Multiple service graph instances are deployed
Workaround:
Use static end point attachment using params
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUN-2015 |
|
Known Affected Releases: | 1.0(3i), 1.1(0.737a) |
|
Known Fixed Releases: | 1.1(0.745d), 1.1(0.750a), 1.1(0.752a), 1.1(0.760a), 1.1(0.764a), 1.1(0.766a), 1.1(0.768b), 1.1(0.779a), 1.1(0.784) |
|
|
| |
| |
Bug Id: | CSCuq42002 |
Title: | Prevent duplicate IP address between inb and oob mgmt for apic nodes |
|
Description: | Symptom:
The system currently allows to reconfigure the same IP or Inband and OOB management addresses of the controller nodes.
Doing so will introduce a duplicate IP address and potential routing problems to the customer's network where the two networks are not logically segmented outside the fabric. As a result connectivity to the APIC Controllers for which connectivity has been modified will be unreachable.
The system should prevent such change by presenting an error. A check can be made by the system if a RN with the same IP address value already exists under the mgmt tenant.
Conditions:
Modification of the APIC Controller Node Management Policy where the same IP address is allowed to be configured for both Inband and Outband fabric connectivity.
Workaround:
N/A
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1e) |
|
Known Fixed Releases: | 1.0(1.67a), 1.0(1.80), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCup79380 |
Title: | path config missing under static endpoint for ERSPAN |
|
Description: | Symptom:
Cannot configure Static CEP for ERPSAN using the cli.
Conditions:
Workaround:
Use the GUI or the REST API for configuring Static CEP for ERSPAN.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(0.99p) |
|
Known Fixed Releases: | 1.0(1.20), 1.0(1.8), 1.0(2j), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur62608 |
Title: | Policy-based Downgrade waiting on cluster health from 1.0.2h to 1.0(1l) |
|
Description: | Symptom:
The cluster does not converge to a healthy state.
Conditions:
This occurs when upgrading or downgrading APICs to different versions.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2h), 1.0(2j), 7.2(0)ZN(99.9) |
|
Known Fixed Releases: | 1.0(1n), 1.1(0.456), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus26627 |
Title: | Scale: Slow policymgr causing remote user logins vis ssh to fail |
|
Description: | Symptom:
On large scale setups, some login requests are taking more than 30 seconds.
Conditions:
This can happen when the system is busy deploying policies to the leaves.
Workaround:
None. Retry login
Further Problem Description:
When a remote user logs in, it results in policy push of a few objects to all the leafs and spines. The MIT from which the objects to be pushed are selected, is very very large due to the scale. We go over this huge tree for each destination where the config needs to be pushed. As this search is very expensive, the transaction takes more than 30s and this results in slow responsiveness.
The fix is to reuse the config across destinations.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2m), 1.1(0.747a) |
|
Known Fixed Releases: | 1.1(0.594), 1.1(0.619a), 1.1(0.768b), 1.1(0.779a), 1.1(0.784), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCuq57822 |
Title: | nginx HAP Reset When Custom Key Ring Configured |
|
Description: | Symptom:
When a custom key ring is configured for HTTPS (GUI, API) access, switch nodes in the fabric may fail to boot properly. The following output is seen on the console of the switch:
The console output after loading the image is:
*** Running INXOS PE IFC image ***
User Access Verification
Restore Last Core[0]:
/bootflash/./sysmgrLcore_0x1b01_policy_mgr_log.4177.tar.gz
(none) login: Found card_index=21000
[ 71.284872] nvram_klm wrote rr=16 rr_str=nginx hap reset to nvram
[ 71.355709] obfl_klm writing reset reason 16, nginx hap reset
[ 71.431847] Collected 8 ext4 filesystems
[ 71.479536] Freezing filesystems
[ 71.632409] Collected 1 ubi filesystems
[ 71.679079] Freezing filesystems
[ 71.719590] Done freezing filesystems
[ 71.765261] Putting SSD in stdby
[ 72.302056] Done putting SSD in stdby 0
[ 72.348723] Done offlining SSD
After three (3) failed attempts to load the NX-OS image, the switch falls into the loader> prompt.
Conditions:
- APIC version 1.0(1e)
- NX-OS version 11.0(1b)
- Custom Key Ring configured and applied to HTTPS communication policy
Workaround:
1. Disable HAP resets through the switch console loader> prompt:
loader> cmdline no_hap_reset
loader> boot aci-n9000-dk9.11.0.1b.bin
2. Once the switch has booted, login and perform a clean reboot:
switch# /bin/setup-clean-config.sh
switch# vsh -c "reload"
The switch will reload with no configuration and should be automatically rediscovered as part of the fabric.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1e) |
|
Known Fixed Releases: | 1.0(1.102b), 1.0(1.110a), 1.0(1.114), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus26991 |
Title: | On Redmond2, QSFP/QSA ports allow invalid port speed configurations |
|
Description: | Symptom:
(i) speed 100, speed auto 100, speed auto 100 1000 are not valid commands on Redmond2 QSFP ports
(ii) speed 40000 is not valid command on Redmond2 QSA ports
Conditions:
When QSFP is plugged in Redmond2 port for issue (i), QSA is plugged in Redmond2 for issue (ii)
Workaround:
Configure 'speed auto' for auto-neg & 'speed 40000' for fixed speed since those are the only two valid speeds for QSFP.
Configure 'speed auto' or 'speed 1000' or 'speed 100' for QSA depending on the peer device connected.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq77039 |
Title: | After switch reboot, can't login to that switch using Remote AAA users |
|
Description: | Symptom:
After leaf reboot, can't login using certain TACACS usernames
Conditions:
-Reboot leaf
-Try to login with usernames that were previously used
-Can't login with previously used usernames. New usernames work
Workaround:
Delete username from APIC and try to log in again
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 11.0(1c), 11.0(1d) |
|
Known Fixed Releases: | 1.0(1.169), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur59512 |
Title: | policyelem core on downgrade from 2e to 1d |
|
Description: | Symptom:
Downgrade failure from 1.0(2x) to 1.0(1x)
Conditions:
Workaround:
Fixed in 1.0(1l) or later releases.
Further Problem Description:
The APIC will not downgrade from 1.0(2x) to 1.0(1k) or earlier releases. The issue is fixed in 1.0(1l) and later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2e), 1.0(2j), 1.1(0.596) |
|
Known Fixed Releases: | 1.0(1n), 1.0(2.43a), 1.0(2.45), 1.0(2.79), 1.0(3f), 1.1(0.456), 1.1(0.619a), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus75822 |
Title: | ifav41: rules missing on ifav41-leaf132 after BD delete/add |
|
Description: | Symptom:
After deleting all BDs and then importing them back, contract for one of the EPGs was not correctly deployed.
Conditions:
This issue can intermittently occur if a large configuration is deleted and then added back.
Workaround:
Delete the affected Epg to contract relation and create it back, or remove static deployment of Epg and reconfigure
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2.145a) |
|
Known Fixed Releases: | 1.0(3.15), 1.0(3d), 1.0(3f), 1.1(0.667), 1.1(1j), 1.1(2.24), 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCur90000 |
Title: | dfabricPathEp still exists after deleting tenant and configuration |
|
Description: | Symptom:
Unable to create new configuration on APIC
Conditions:
Old stale objects still in concrete model on APIC. vPC configuration not removed from concrete model
Workaround:
The order that is required to create this issue is:
1. Create infraAccBndlGrp, Create fabricExplicitGEp -> In any order
2. Delete fabricExplicitGEp
3. Delete infraAccBndlGrp
The order that will work is:
1. Create infraAccBndlGrp, Create fabricExplicitGEp -> In any order
2. Delete infraAccBndlGrp
3. Delete fabricExplicitGEp
Once the fabric enters the state of stale fabricPathEp, the only option is to create infraAccBndlGrp again with the same name, and delete it. This should cleanup the stale object.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2j) |
|
Known Fixed Releases: | 1.0(2.117), 1.0(3f), 1.1(0.470a), 1.1(0.474a), 1.1(0.480a), 1.1(0.484a), 1.1(0.488a), 1.1(0.495), 1.1(0.631), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus65107 |
Title: | .Apic fails to pull inventory from VC under certain condition |
|
Description: | Symptom:
The APIC may fail to pull inventory from the vCenter in case one of the ESx Hosts in the Vcenter is not responding.
Conditions:
This issue occurs during VMM Integration.
Workaround:
Perform triggered inventory update
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.418) |
|
Known Fixed Releases: | 1.0(3.34), 1.0(3l), 1.1(0.631), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur49305 |
Title: | 288c to 1k downgrade - PM dumped core and Config is deleted |
|
Description: | Symptom:
Downgrades from an internal 288c version to 1k image deleted Tenant Config and dumped core (core dump happens due to illegal access of memory space by a running process. And the PolicyManager process ran into such situation and dumped core).
Conditions:
Downgrades from internal 288c version to 1k image
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.9) |
|
Known Fixed Releases: | 1.0(1.302b), 1.0(1n), 1.0(2.21), 1.0(2b), 1.0(2j), 1.1(0.379), 1.1(0.406), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCuq73335 |
Title: | 1.0(1h): invalid Graph fault when deleted EPG top level vnsFolderInst |
|
Description: | Symptom:
When configuration parameters under EPG are modified or deleted, it can cause corresponding Graph Instance to go into "missing config-params" fault state.
From this point, even if the deleted configuration parameter is added back or a modified parameter is restored, Graph Instance still stays in "missing-config-params" fault state. It doesn't recover.
Conditions:
This condition is caused by deleting or modifying a configuration parameter under EPG. If an active GraphInstance is using those configuration parameter, it'll affect the active GraphInstance.
Workaround:
GraphInstance can be made to recover by modifying LDevCtx. In the LDevCtx used by GraphInstance
Add or delete a dummy LifCtx with dummy name. This is just to trigger a modification on LDevCtx. The modification of LDevCtx triggers re-instantiation of GraphInst. It makes GraphInst to come out of fault state.
Further Problem Description:
This condition is caused by deleting or modifying a configuration parameter under EPG. If an active GraphInstance is using those configuration parameter, it'll affect the active GraphInstance.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1h) |
|
Known Fixed Releases: | 1.0(1.135), 1.0(1k), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur73052 |
Title: | Used VLANS not cleaned properly after changing VLAN pool in VMM domain |
|
Description: | Symptom:
invalid-vlan fault is given on an EPG after associating to an EPG. But, all of the port groups are pushed to the vCenter.
Conditions:
1)1 Single AEP
2)1 Single VLAN pool (198 VLANs)
3)5 VMM domains which are all mapped to the same AEP from #1
4)120 EPGs associated with each VMM domain (600 EPG total)
-This causes an issue because there are more total EPGs than total VLANs. So:
5)Create 5 identical VLAN pools with VLANs from #2
6)Remove all EPG associations
7)Associate VMM1 with VLAN_Pool1 and VMM2 with VLAN_Pool2, etc
8)Associate all EPGs with their VMM domains as in #4
Workaround:
Create a separate AEP for each VMM domain instead of using one AEP for each VMM domain.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2j) |
|
Known Fixed Releases: | 1.0(2.43a), 1.0(2.45), 1.0(3f), 1.1(0.422), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus61122 |
Title: | When incorrect XML attempts to be corrected by correct XML, error raised |
|
Description: | Symptom:
After posting an XML with an incorrectly configured parameter, a correctly configured XML must be posted. When the correctly configured XML is posted, an error stating "Failed to re-trigger graph instantiation for graphs related to device cluster for tenant tenantName." is raised on the APIC GUI and the graph is not deployed
Conditions:
When attempting correct a misconfigured XML with a correctly configured XML this issue can arise.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.606a) |
|
Known Fixed Releases: | 1.1(0.639), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur97373 |
Title: | IFC didn't respond after policy upgrade from 2k to 451 |
|
Description: | Symptom:
During policy upgrade of APIC controller some APIC fails to reboot after upgrade process has completed.
Conditions:
In some rare cases reboot triggered by APIC upgrade process would fail to reboot APIC.
Workaround:
Manually reboot APIC if its stuck during upgrade by logging in via CIMC.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.451) |
|
Known Fixed Releases: | 1.1(0.484a), 1.1(0.488a), 1.1(0.495), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus74493 |
Title: | Int policies not applied to all ports after creating fwd referenced pols |
|
Description: | Symptom:
Interface policies are not applied to all ports if interface policy group is associated with policy before the policy is created
Conditions:
This can happen if forward references to interface policies are created
Workaround:
Remove and re-add the association to the policy.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.629) |
|
Known Fixed Releases: | 1.1(0.667), 1.1(0.685a), 1.1(0.687), 1.1(1j), 1.1(2.24), 1.2(0.4) |
|
|
| |
| |
Bug Id: | CSCus71848 |
Title: | core seen on aclqos |
|
Description: | Symptom:
aclqos crash happens when IPv6 prefix is configured
Conditions:
This crash will occur if IPv6 prefix is configured in 1.0x release. In these releases, IPv6 is not supported.
Workaround:
Use only IPv4 prefix
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.629a) |
|
Known Fixed Releases: | 1.1(0.644a), 1.1(0.647), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur16683 |
Title: | "missing-bd" when creating SG with L3Out as consumer |
|
Description: | Symptom:
When creating L4-7 SG with the following topology:
Consumer (L3Out) -> ASA-FW (transparent) -> Provider (BD)
the following fault is raised and it is preventing the SG to be rendered/deployed "configIssues:missing-bd, configSt:failed-to-apply".
Conditions:
L3Out is used as Consumer.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1e) |
|
Known Fixed Releases: | 1.0(1.217b), 1.0(1.223a), 1.0(1.226a), 1.0(1.233), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus18136 |
Title: | vmmmgr process crash/core and APIC cluster in diverged state |
|
Description: | Symptom:
-Unable to make changes to VM Networking
-APIC cluster in diverged state
Conditions:
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1k) |
|
Known Fixed Releases: | 1.0(2.74), 1.0(3f), 1.1(0.508a), 1.1(0.518), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus38227 |
Title: | Config with EPG/L2Out/L3Out as providers doesn't get deployed |
|
Description: | Symptom:
When a Layer 2 (l2extInstP) or Layer 3 (l3extInstP) external instance profile is specified as a provider to a contract, and a collection of endpoint groups within a context (vzAny) is specified as the consumer, the provider will be skipped. This can result in the graph not get deployed.
Conditions:
The issue happens when vzAny is specified as consumer, and l2extInstP or l3extInstP is specified as provider for a contract that will be used for deploying a service graph. The fix corrected the issue, and now when vzAny is consumer, l2extInstP or l3extInstP can be used as provider, to deploy a service graph.
Workaround:
Do not use l2extInstP or l3extInstP as provider
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.566a) |
|
Known Fixed Releases: | 1.1(0.599a), 1.1(0.603), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus63168 |
Title: | Config deletions fail due to deviceAudit(state=3) API calls |
|
Description: | Symptom:
When sending requests to remove ASA failover configuration or port channel configuration, the configuration is removed from the APIC but may not be removed from the ASA.
Conditions:
Request is made at the APIC to remove failover configurations or port channel configuration. The APIC deletes the data from the APIC configuration, but the ASA does not receive a request to remove the data from its configuration.
Workaround:
From the device cluster actions trigger re-query for device-validation
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.606a) |
|
Known Fixed Releases: | 1.0(3.15), 1.0(3.34), 1.0(3h), 1.1(0.647), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus21805 |
Title: | Config of L3 routed interface in one tenant breaks other tenant |
|
Description: | Symptom:
If you have a running/working L3 out in a tenant X using a given routed interface.
and if you then apply another L3 out config to a different tenant in tenant Y but using the same routed interface, the last config is applied and first tenant lost its routing config.
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2j) |
|
Known Fixed Releases: | 1.0(2.79), 1.1(0.619a), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur65929 |
Title: | BD not deleted on leaf |
|
Description: | Symptom:
when a BD is deleted, it may happen that the vlan used by that BD is not freed on the leaves.
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1k) |
|
Known Fixed Releases: | 1.0(2.122a), 1.0(2.124a), 1.0(2.129a), 1.0(2.131a), 1.0(2.136a), 1.0(2.139a), 1.0(2.145a), 1.0(2.146), 1.0(3f), 1.1(0.422) |
|
|
| |
| |
Bug Id: | CSCus69032 |
Title: | External image download stuck on IFC due to leader change |
|
Description: | If there is a Cluster leadership change due to fabric connectivity changes or other reason this could affect the download action. The leadership/re-election changes needs to be handled gracefully.
Symptom:
The image download gets stuck and does not complete.
Conditions:
Clustering changes (any link flaps or node flaps that could affect cluster or trigger a leadership change)
Workaround:
Manually retrigger the Firmware download, by deleting the old Firmware Download policy and creating a new firmware download policy of same name or by just creating a new firmware download policy of different name
Further Problem Description:
During the Image download if there is some fabric churn and APIC leader re-election happened, it will result in the download action(download,validate and create firmware objects) not resulting to completion. This needs to be handled without interruption gracefully(re-spawn on new leader).
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.622a) |
|
Known Fixed Releases: | 1.0(3.52), 1.1(0.662a), 1.1(0.667), 1.1(0.839a), 1.1(0.843a), 1.1(0.846), 1.1(1j), 1.1(2.24), 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCuq40507 |
Title: | APIC connected port gets removed from infra EPG |
|
Description: | Symptom:
APIC loses connectivity to the nodes in the fabric.
Conditions:
When APIC connected ports are part of the infra EPG related port selector that is deployed to the node, those ports could be removed from infra EPG causing controllers to lose connectivity with the fabric.
Workaround:
If this happens, remove the APIC connected ports from the port selector, and clean reboot the TORs where these port selectors were deployed. This should restore the connectivity back.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1.1) |
|
Known Fixed Releases: | 1.0(1.34), 1.0(2j), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus25759 |
Title: | FabricLooseLink on Port-channel disappear when PC member goes down |
|
Description: | Symptom:
One a member of a port-channel goes down unmanaged fabric switch will not be seen anymore over this port-channel even if there are remaining functional port on the port-channel
Conditions:
Workaround:
Further Problem Description:
Impact could be :
- Full lost of the unmanaged switch from ACI perspective (could be blade swtich as well)
- Lost of connectivity for Dynamic found VM in EPG using that Port-channel...
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2j) |
|
Known Fixed Releases: | 1.0(2.91), 1.0(3f), 1.1(0.539), 1.1(0.619a), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCuq73081 |
Title: | Graph instance is stuck in 'applying' state |
|
Description: | Symptom:
Graph instance would never transition to 'applied' state even though all the required IDs for the graph are allocated.
User would not find the rendered device cluster for this particular graph instance in the UI and data traffic would not be passing through the consumer/provider associated with this contract.
Conditions:
The LDev used in this Graph instance is provisioned in tenant 'mgmt' and being consumed by this tenant(the tenant where Graph instance is rendered) via vns:LDevIf.This could happen when the ID for the LDevInst is the last one of all the required IDs that need to be allocated for the Graph instance to transition to 'applied' state.
Workaround:
Try deleting the contract to graph attachment and recreate the contract to graph attachment. Another alternative is to delete the vendor device package and upload the device package back again.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1h) |
|
Known Fixed Releases: | 1.0(1.129a), 1.0(1.131a), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur81785 |
Title: | After upgrade, the number of TCAM entries is much higher than before |
|
Description: | Symptom:
In case an L3 Out configured with the 0/0 subnet allowed.
If the L3 Out is consuming or providing a contract some traffic might not flow as expected.
Conditions:
In case an L3 Out configured with the 0/0 subnet allowed.
Upgrade ACI from 1.0(1h) to 1.0(2j) by upgrading controllers first and then switches.
If the L3 Out is consuming or providing a contract some traffic might not flow as expected.
Workaround:
Two work arounds were found:
1) Change the description of any of the contracts provided/consumed by an L3 Outs with the 0/0 subnet allowed
2) Delete the private network (context) with the stale entries and re-add it
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2i), 1.0(2j) |
|
Known Fixed Releases: | 1.0(2.43a), 1.0(2.45), 1.0(3f), 1.1(0.456), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur45067 |
Title: | PM cores in getStatsGroup while importing configuration. |
|
Description: | Symptom:
Config import fails (success-with-warnings) and policy managers cores
Conditions:
Config import triggered
Workaround:
unknown
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1k) |
|
Known Fixed Releases: | 1.0(1.294a), 1.0(1.302b), 1.0(1n), 1.0(2.21), 1.0(2b), 1.0(2j), 1.1(0.379), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus63207 |
Title: | Nexus 9k Kernel Panic Due Watchdog Timeout During Interrupt Storm |
|
Description: | Symptom:
A Nexus 9k switch may experience a kernel panic due to a high volume of interrupt events, possibly due to link flaps seen over an attached FEX module.
`show logging onboard module 1 stack-trace`
Dumping interrupt statistics
CPU0 CPU1 CPU2 CPU3 intrs/last_sec max_intrs/sec
60: 1 3851542938 0 0 122 12430 PCI-MSI-edge linux-kernel-bde
Conditions:
High amount of interrupts are being sent to one of the switch's CPUs. Possible trigger could be a high rate of interface flaps.
Workaround:
None known.
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I2(3), 7.0(3)I1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut26163 |
Title: | scriptwrapper process is not killed after deleting the package on a APIC |
|
Description: | Symptom:
The script wrapper process is still present after deleting Cisco.haproxy package.
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.718c) |
|
Known Fixed Releases: | 1.0(3.34), 1.1(0.735b), 1.1(0.737b), 1.1(0.739a), 1.1(0.739b), 1.1(0.741a), 1.1(0.743a), 1.1(0.745), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut57196 |
Title: | TaskQ is stuck at 41 entries and with failures in getting TaskList info |
|
Description: | Symptom:
APIC does not clean up state for some vCenter tasks it initiated. As a result, APIC may not be able to process new tasks as fast as it does under normal conditions.
Conditions:
APIC verifies the status of tasks it has initiated at vCenter to ensure they have completed. When vCenter does not report status for some of these tasks, they are never cleaned up at APIC. This results in lowering the limit of maximum new outstanding tasks that APIC can trigger at vCenter, slowing operations.
Workaround:
Reloading the APIC will clear tasks stuck in the queue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.768c) |
|
Known Fixed Releases: | 1.0(3.34), 1.0(3.37), 1.1(0.779a), 1.1(0.784), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut46796 |
Title: | zoning-rule missing when 0/0 and particular subnet present in an l3out |
|
Description: | Symptom:
The zoning-rule is missing after deleting or adding 0/0 and/or a particular subnet present in a Layer 3 external network.
Conditions:
0/0 subnet was present and a particular subnet is added or particular subnet was present and 0/0 subnet was added
Workaround:
Re-create the the l3out
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.750a) |
|
Known Fixed Releases: | 1.1(0.787), 1.1(0.788a), 1.1(0.797), 1.1(0.797a), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCuq92077 |
Title: | APIC vulnerable to DDOS reflection attack |
|
Description: | Symptom:
APIC is vulnerable to NTP DDoS reflection attacks.
Conditions:
Prior to the fix described in Cisco bug ID CSCuo97759, the APIC without an NTP provider configured/applied, the ntpd service starts in server mode.
After the fix, the APIC without any NTP provider configured/applied, will not have the NTPd service started.
Workaround:
None.
More Info:
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5/4.5:
http://tools.cisco.com/security/center/cvssCalculator.x?version=2.0&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:W/RC:C/
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
CVE ID CVE-2013-5211 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1e) |
|
Known Fixed Releases: | 1.0(1.202a), 1.0(1.206a), 1.0(1.217b), 1.0(1.223a), 1.0(1.226a), 1.0(1.233), 1.0(1n), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCuq27192 |
Title: | NGINX core at event::SubscriptionMgr::addSubFilterToMap |
|
Description: | Symptom:
- Attempts to access the APIC GUI time out.
- Executing CLI commands from the APIC GUI results in the following error:
Code: 408
Output:
Data Posted:
None
- The following log message is seen in /var/log/dme/log/nginx.bin.log:
30336||14-08-06 10:04:01.185+00:00||log||CRIT||co=doer:32:3:0x80000000000002d:1||ASSERT(lSecAuthElems->size() == aInSecAuthInfo.size()) failed @ ../common/src/framework/./core/event/Subscriptions.cc:1082
Conditions:
- APIC Version: 1.0(1e)
- Change HTTP Redirect policy to Enabled, leaving HTTP Admin State Disabled
- logging back after the above policy change as a different user before the user who changed the policy
Workaround:
Reboot the APIC.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1e) |
|
Known Fixed Releases: | 1.0(1.18), 1.0(1.20), 1.0(2j), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur44626 |
Title: | Registration for shard 32 does not complete |
|
Description: | Symptom:
Client endpoints behind some leaves are not created on the APIC after upgrading.
Conditions:
This is caused by stale monitoring policies present on APIC that cannot be recognized on leaf switches. This can happen when downgrading from higher version starting from the leaf switches first. Once APICs are downgraded to the same version then the issue will get resolved.
Workaround:
Either cleanup stale monitoring policies or match the APIC and leaf switch versions.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(1.280), 1.1(0.451) |
|
Known Fixed Releases: | 1.0(1n), 1.0(2.21), 1.0(2.79), 1.0(2b), 1.0(2e), 1.0(2h), 1.0(2j), 1.0(3f), 1.1(0.406), 1.1(0.470a) |
|
|
| |
| |
Bug Id: | CSCus39019 |
Title: | Internal MO leak in eventmgr store on switch causes crash |
|
Description: | Symptom:
Cisco Nexux 9000 switches running in ACI mode may experience eventmgr process crash.
When faultable MOs are created, some internal objects are created in eventmgr data store.
If the faultable MOs are created without faults, the internal objects do not get released properly.
Common symptom is an eventmgr process crash followed by continuous failed restart attempts.
Conditions:
Affected versions: 1.0(2m) [Switch 11.0(2m)] and earlier.
On a long-running system with new MOs being constantly created/deleted (example MOs representing test results running in the background) the eventmgr data store can eventually fill up, rendering eventmgr inoperable.
This has more of an impact on C9508 and C9504 switches.
Workaround:
Once the eventmgr process is in this state, the workaround to recover from this is to reload the switch.
To reduce the resource leak, reduce the frequency of the diagnostics tests on spine switches with the following CLI command:
switch# cd /aci/fabric/fabric-policies/monitoring-policies/monitoring-policy-default/diagnostics-policies/
switch# cd line-module-\(eqpt.lc\)/eqptdiagp-sptshllc-default
switch# moset health-diag-test-frequency every-1-day
switch# cd ../..
switch# cd supervisor-module-\(eqpt.supc\)/eqptdiagp-sptshlsc-default
switch# moset health-diag-test-frequency every-1-day
switch# cd ../..
switch# cd fabric-module-\(eqpt.fc\)/eqptdiagp-sptshlfc-default/
switch# moset health-diag-test-frequency every-1-day
switch# cd ../..
switch# cd system-controller-module-\(eqpt.sysc\)/eqptdiagp-sptshlscc-default/
switch# moset health-diag-test-frequency every-1-day
switch# cd ../..
switch# moconfig commit
You can also make the changes in the APIC GUI under:
Fabric > Fabric Policies > Monitoring Policies > default > Diagnostics Policies
For each of the following Monitoring Objects, change the Test Frequency to 'Every 1 day':
Fabric Module (eqpt.FC) - Ongoing policy default
Line Module (eqpt.LC) - Spine ongoing policy default
Supervisor Module (eqpt.SupC) - Spine ongoing policy default
System Controller Module (eqpt.SysC) - Ongoing policy default
Further Problem Description:
User with administrative privileges can use the following switch CLI command to check the current size of the data store:
ls -l /dev/shm/lpssmu/ifc_eventmgr-1_ud1
the issue manifests itself when the file size reaches approximately 1 GB
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2j), 1.0(2m) |
|
Known Fixed Releases: | 1.0(2.104a), 1.0(2.106), 1.0(2.98a), 1.0(3f), 1.1(0.619a), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus21730 |
Title: | policyelem core on Leaf after deleting 24 vPCs infraAccBndlGrp |
|
Description: | Symptom:
Policy Element crash on the leaf after deleting infrastructure config like infraAccBndlGrp, Selectors, VLAN/VXLAN Namespace.
Conditions:
The deleted infrastructure config was in use by almost all the EPgs deployed on the leaf.
Workaround:
Delete the association between the EPgs and the infrastructure config first. Perform the action on 200 EPgs at a time.
Example:
1. If EPgs have static binding with a VPC's fabric path (fabric::PathEp with lagT==node), then delete the static binding first before deleting the infraAccBndlGrp (represents the VPC).
2. If the encaps (VLAN/VXLAN) used by the EPgs are allocated from a VLAN/VXLAN namespace "Foo", then release the encaps from those EPgs before deleting the namespace "Foo".
3. If the EPgs are associated with a Domain (VMM or Phys or External Domain) then delete the association to domain before deleting the domain.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2m) |
|
Known Fixed Releases: | 1.0(3f), 1.1(0.599a), 1.1(0.603), 1.1(0.647), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus74188 |
Title: | traffic loss after delete/restore 0.0.0.0 pfx FCS+6 |
|
Description: | Symptom:
Traffic loss occurs after deleting and restoring the 0.0.0.0 prefix.
Conditions:
Dont correctly filter due to a limitation in how we program rules with priority.
Workaround:
No
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 11.0(2.915) |
|
Known Fixed Releases: | 1.0(3.15), 1.0(3.43a), 1.0(3.45a), 1.0(3.46a), 1.0(3.47a), 1.0(3.48a), 1.0(3.49), 1.0(3d), 1.0(3f), 1.1(0.667) |
|
|
| |
| |
Bug Id: | CSCur73570 |
Title: | Zoning rule not present on leaf switch |
|
Description: | Symptom:
Some zone rules or Contracts may not be deployed on the switch on clean reboot of the switch or on upgrade of the switch
Conditions:
On Upgrade of the switch or on clean reboot of the switch
Workaround:
remove the contract configuration between the EPGs that was failing to be downloaded and re-add the contract. Sometimes clean reboot of the switch may also fix the issue
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 11.0(2h) |
|
Known Fixed Releases: | 1.0(2.43a), 1.0(2.45), 1.0(3f), 1.1(0.422), 1.1(0.468), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCut83360 |
Title: | [VPC] rsvpcConf relation unformed after switch profile delete/add |
|
Description: | Symptom:
VPCs failed to get created on one side of a VPC pair causing a "Peer does not have corresponding vPC" failure and then traffic loss.
Conditions:
Conditions under which the bug shows up:
1. 2 Leaves in a VPC pair
2. Remove the switch profile that covers the infra::AccBndlGroup representing the VPC
3. Wait for 300 seconds
4. Re-add the same switch profile
Workaround:
Delete and recreate the infra::AccBndlGroup representing that VPC.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 11.1(0.180) |
|
Known Fixed Releases: | 1.1(0.816a), 1.1(0.825a), 1.1(0.827), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut65913 |
Title: | DME service does not restart after the crash |
|
Description: | Symptom:
After a DME service has crashed, it does not recover. This issue prevents a service from restarting due to a crash if the internal journal is corrupted. There will be multiple restarts after the first crash, preventing service from coming back online. Cluster health will show degraded due to the service not running.
Conditions:
DME service crash due to out of memory or due to some other bug.
Workaround:
APIC which is impacted needs to be restarted clean after doing decomission/comission. If this issue is hit on more than one APIC at the same time it may require clean reboot of APICs and reimport the configuration.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.779c) |
|
Known Fixed Releases: | 1.0(3.34), 1.1(0.784a), 1.1(0.797), 1.1(0.797a), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCus82518 |
Title: | QBranch: DHCP traffic impact due to missing mcast address in EPG |
|
Description: | Symptom:
Flood towards the ESX for VXLAN port groups will not work.
Conditions:
The mcast address for a VXLAN endpoint group on the leaf is programmed with 0 (Seen in 1.0(2j)).
Workaround:
After verifying that compEpPD has the mcast addr filled in itdetach and reattach EPs on that EPG in that domain
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2j) |
|
Known Fixed Releases: | 1.0(3.15), 1.0(3.34), 1.0(3e), 1.0(3f), 1.1(0.667), 1.1(1j), 1.1(2.24), 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCut70441 |
Title: | AVS-SCALE: assert in the object store infra leads to vleaf elem core |
|
Description: | Symptom:
The VTEP tunnel is not present on the leaf.
Conditions:
AVS host reconnect.
Workaround:
vem restart on the AVS host.
Further Problem Description:
On an AVS host reconnect, the heartbeat counter for that device in opflexODev on the leaf gets reset to 0 without the expect heartbeat counter getting reset. This is causing the heartbeat check to mistakenly think that it was missing heartbeats.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.784) |
|
Known Fixed Releases: | 1.0(4d), 1.1(0.797b), 1.1(0.799), 1.1(0.801a), 1.1(0.801c), 1.1(0.805), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut02297 |
Title: | AVS opflexODev mo - tunnel interface not removed on ileaf, remains stale |
|
Description: |
Symptom:
Fault F0214 with severity Major observed with description similar to: "Operational issues detected for OpFlex device: 175192220 0.0.0.0 for logical switch comp/prov-VMware/ctrlr-[Company-AVS]-Company-vcenter01/sw-dvs-65500 detected, error: [Invalid dvs name]"
Conditions:
AVS is used within fabric and moved from one port to another.
Workaround:
Contact TAC to remove stale opflexODev object.
Further Problem Description:
(release notes added by addprefcs-org.ksh)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(3f), 1.1(0.694a) |
|
Known Fixed Releases: | 1.0(3.32), 1.1(0.706a), 1.1(0.709), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut02482 |
Title: | ipfib core after upgrading and posting graph config |
|
Description: | Symptom:
The process ipfib crashes on the leaf.
Conditions:
For this to occur, ALL of the following conditions must be met:
- An external Layer 3 endpoint group (EPG) is providing/consuming a contract that makes it talk with another EPG in a different VRF.
- And that external Layer 3 EPG is also providing/consuming a contract that makes it talk with another EPG in the same VRF.
- That external Layer 3 EPG has a user configured static route in it.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 11.1(0.152) |
|
Known Fixed Releases: | 1.0(3.34), 1.1(0.709), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut45880 |
Title: | MARCH 2015 OpenSSL Vulnerabilities |
|
Description: | Symptom:
This product includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-0286, CVE-2015-0287, CVE-2015-0289, CVE-2015-0292, CVE-2015-0293, CVE-2015-0209, CVE-2015-0288
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent.
APIC Controller Version 1.0(1X), 1.0(2X),1.0(3X)
Workaround:
Not available.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 7.1/6.9
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2m), 1.0(3f) |
|
Known Fixed Releases: | 1.0(3.49), 1.1(0.797), 1.1(0.797a), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut45754 |
Title: | VC upgrade cause recurring soap error on APIC from vshpere - Cisco IT |
|
Description: | Symptom:
Post vCenter upgrade, the APIC was not able to collect inventory or start event listener. As a result, vCenter port group objects were not created. On the APIC, we saw a lot of recurring SOAP timeout errors returned by vSphere APIs while trying to pull inventory as well when trying to create event collector.
Conditions:
Workaround:
We restarted vmmmgr process on APIC and vcenter inventory pull and event listener got created successfully.
Further Problem Description:
APIC attempts to retry inventory or event collector creation failures on continuous basis and they were some clean up issues on APIC/soap-client client sidewhich could have lead to further soap error. These cleanup issues are fixed as part of this bugfix.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(3i) |
|
Known Fixed Releases: | 1.0(3.34), 1.0(3k), 1.1(0.766a), 1.1(0.766f), 1.1(0.768b), 1.1(0.779a), 1.1(0.784), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut80792 |
Title: | APIC using obsolete security crypto for message authentication (SHA-1) |
|
Description: | Symptom:
WebServer uses ciphers which use SHA1. Web browsers (like chrome) report a warning indicating that SHA1 is obsolete and that a stronger hashing algorithm should be used. (as shown in the attached enclosure)
Conditions:
The warning can be seen when logging into APIC and inspecting the browser lock icon.
Workaround:
None. This is fixed in 1.1(1) image.
Further Problem Description:
SHA/1 is vulnerable and is deprecated and considered obsolete.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.797) |
|
Known Fixed Releases: | 1.1(0.825a), 1.1(0.827), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut25657 |
Title: | Two ARM SLB: Traffic between client EPG and SLB ingress L3Out is dropped |
|
Description: | Symptom:
Traffic between application endpoint groups and external Layer 3 networks on different leafs is dropped if multiple external Layer 3 networks are configured in the same context.
Conditions:
This can happen when multiple L3Out are deployed in the same private network (fvCtx) in the following scenario:
Application EPG A deployed on leaf1, in contract with L3Out A on leaf 2
L3Out B deployed on leaf1. Due to implicit deny rules for this L3Out, this will drop traffic on the same context between the application EPG and the other L3Out.
Workaround:
If multiple L3Out are deployed for the same private network, then change the private network to policy unenforced.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.718a) |
|
Known Fixed Releases: | 1.1(0.750a), 1.1(0.752a), 1.1(0.760a), 1.1(0.764a), 1.1(0.766a), 1.1(0.768b), 1.1(0.779a), 1.1(0.784), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut19696 |
Title: | PM core on 2 IFCs after posting config |
|
Description: | Symptom:
The policy manager cores on 2 IFCs after posting a configuration.
Conditions:
This may happen during upgrade from an older release and if a message with unknown config is received.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.706a), 1.1(0.766m) |
|
Known Fixed Releases: | 1.0(3.34), 1.1(0.726), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut23967 |
Title: | Negative hold timer values were observed on leafs for eigrp |
|
Description: | Symptom:
Negative hold timer values were observed on leafs for eigrp
Conditions:
It will be seen momentarily when the neighbor first comes up
Workaround:
Execute the command again in a few seconds
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 11.1(0.163) |
|
Known Fixed Releases: | 1.1(0.797), 1.1(0.797a), 1.1(1j), 1.1(2.24), 11.1(0.177), 11.1(0.191) |
|
|
| |
| |
Bug Id: | CSCut60986 |
Title: | Missing fvCEp after upgraded to 766j image |
|
Description: | Symptom:
Endpoints are not reported after leaf is upgraded.
Conditions:
This can happen if traceroute for endpoints on that leaf is configured at the time that leaf is upgraded or clean rebooted.
Workaround:
Unconfigure traceroute configuration to endpoints on a leaf prior to doing either policy upgrade or clean reboot of that leaf. Otherwise, user will need to export configuration, clean reboot the apics, and re-import configuration
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.766j) |
|
Known Fixed Releases: | 1.1(0.784), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut56615 |
Title: | vmm FSM failed in scale setup |
|
Description: | Symptom:
Slow convergence of port group updates and VM placements for the DVS/AVS switch created by APIC at the vCenter
Conditions:
This problem may occur in large scale setups when a very large volume of vCenter tasks are initiated by the APIC.
Workaround:
Reloading the APIC may recover the system.
In case convergence is still slow after the reload, and if a very large number of EPGs are associated with the VMM domain, removing those associations and adding them back in small batches should help.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.1(0.768c) |
|
Known Fixed Releases: | 1.0(3.34), 1.0(3.37), 1.1(0.779a), 1.1(0.784), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCus83262 |
Title: | Backend returned an unparsable response due to no input validation |
|
Description: | Symptom:
When configuring LDAP Providers and using special characters you may run into the following error.
"Server Error backend returned unparsable response"
This was using LDAP provider with the hostname 1.1.1.1
Conditions:
Workaround:
You can find this under Admin>AAA>LDAP Management then you right click and Save As
You will need to save the LDAP Management configuration based on:
Content: All Properties
Scope:Subtree
Export Format: XML or JSON
CLI using the API
It would look something like this where you would change the 1.1.1.1 to the IP or DNS name.
admin@apic1:~> icurl -u admin:password -X "DELETE" http://a.p.i.c/api/node/mo/uni/userext/ldapext/ldapprovider-1.1.1.1.json
{"imdata":[]}
API
URL using an HTTP Delete using POSTMAN or some other REST Client
http://a.p.i.c/api/node/mo/uni/userext/ldapext/ldapprovider-1.1.1.1.json
Further Problem Description:
The key thing to check is the higher container folder to pull down all configuration since you will not be able to pull it down by sub folder.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 1.0(2m), 1.1(0.644b) |
|
Known Fixed Releases: | 1.0(3.15), 1.0(3.34), 1.0(3h), 1.1(0.662a), 1.1(0.667), 1.1(1j), 1.1(2.24), 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCur28114 |
Title: | Fabric Switch : evaluation of SSLv3 POODLE vulnerability |
|
Description: |
Symptom:
This product includes a version of SSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-3566
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent
Workaround:
Fix for this is available in NX-11.0(1d) or later releases of Nexus 9000 ACI Mode Switches.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the
time of evaluation are: 2.6/2.5
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 11.0(1d) |
|
Known Fixed Releases: | 11.0(1.881), 11.0(1.882), 11.0(1d) |
|
|
| |
| |
Bug Id: | CSCuu60820 |
Title: | EPG not deployed on leaf if static EPG is created on leaf. |
|
Description: | Symptom:
vNIC placed in a vCenter portgroup on AVS will be blocked for traffic
Conditions:
This vNIC has to be the first port (endpoint) in an EPG on an AVS host behind a leaf where the EPG is not deployed currently.
Workaround:
A script will be provided and attached to this bug which has the following steps.
0)Enable testapi on the apic
1)create this Mo under infraInfra using testapi
https:///testapi/policymgr/mo/uni.xml
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 1.0(4h) |
|
Known Fixed Releases: | 1.0(4i), 1.0(4k), 1.1(0.827) |
|
|
| |
| |
Bug Id: | CSCus42784 |
Title: | JANUARY 2015 OpenSSL Vulnerabilities |
|
Description: | Symptom:
This product includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-3569, CVE-2014-3570, CVE-2014-3571, CVE-2014-3572, CVE-2014-8275, CVE-2015-0204, CVE-2015-0205, CVE-2015-0206
This bug has been opened to address the potential impact on this product.
Conditions:
N9K is not vulnerable to the two DTLS issues:
- (CVE-2014-3571) DTLS segmentation fault in dtls1_get_record
- (CVE-2015-0206) DTLS memory leak in dtls1_buffer_record
N9k is vulnerable to fourCVEs:
- (CVE-2015-0205) is from an old protocol which is not used in most (we have to see if it is used by any if at all) of existing nxos application
- (CVE-2014-3570) is a bug with very low probability of occurring.
- (CVE-2014-3572) and (CVE-2015-0204).
N9K is not vulnerable to CVEs:
- (CVE-2014-3569) ssl23_get_client_hello function does not properly handle attempts to use unsupported protocols
- (CVE-2015-0205) DH client certificates accepted without verification [Server]
Workaround:
None.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 5.0/3.7
http://tools.cisco.com/security/center/cvssCalculator.x?version=2.0&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:U/RL:OF/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.0(3)I1(1.1) |
|
Known Fixed Releases: | 7.0(3)I1(1.168), 7.0(3)I1(2), 7.0(3)I2(0.177), 7.0(3)I2(1), 7.0(3)IX1(1.93), 7.0(3)IX1(2) |
|
|
| |
| |
Bug Id: | CSCuu52394 |
Title: | ISIS PDU from tenant space dropped in leaf |
|
Description: | Symptom:
ACI leaf do drop ISIS hello when received from an epg in a user tenant
Conditions:
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 11.0(4) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.230) |
|
|
| |
| |
Bug Id: | CSCuu75672 |
Title: | Some 802.3 SNA frames are dropped by ingress leaf |
|
Description: | Symptom:
SNA session will not establish between endpoints.
Conditions:
Endpoints communicating via SNA are in different EPGs.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 11.0(4) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.241), 11.1(0.244), 11.1(1e), 11.1(1h) |
|
|
| |
| |
Bug Id: | CSCus78838 |
Title: | ACI - SNMP src ip for trap generation is random |
|
Description: | Symptom:
Source ip of SNMP traps is using mgmt inband epg for snmp is randomly chosen within the ip addresses of the mgmt:inb vrf.
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 11.0(2.912), 11.0(2j) |
|
Known Fixed Releases: | 11.0(3.925), 11.1(0.161) |
|
|
| |
| |
Bug Id: | CSCuu47721 |
Title: | Fabric nodes goes inactive after shut the outgoing traffic port. |
|
Description: | Symptom:
ISIS packet drops in spine and tunnels may go down.
Conditions:
If there is bi-directional L2 traffic between two EPs sitting on different ports. If we shutdown one port then traffic coming from other port will go to spine. It might cause ISIS packet drop in spine and tunnels may go down. It happens only for L2 traffic.
Workaround:
no shut the port and it will recover
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 11.1(0.218) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.224) |
|
|
| |
| |
Bug Id: | CSCuu72103 |
Title: | InB Mgmt ip not reachable on some leafs |
|
Description: | Symptom:
On configuring Inband Management VRF, ping, ssh to some nodes in the cluster do not work sometimes
Conditions:
Configure Inband Management VRF
Workaround:
Remove and Add the Inband Management VRF
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 11.1(0.233) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.242), 11.1(1f) |
|
|
| |
| |
Bug Id: | CSCuu34073 |
Title: | Ipv6 EP looping on leaf5 causing traffic loss and high CPU utilization |
|
Description: | Symptom:
Traffic loss and high CPU utilization.
Conditions:
Could be seen in cases when you have vrf-crossing configured only in one direction for shared-services, ie, either provider->consumer or vice versa.
Looping is triggered by the presence of an l3out with a catch-all route on the shared side.
Traffic from shared side to other will work fine. Other direction traffic will keep looping in the fabric.
Workaround:
Either:
- Configure shared-mode/vrf-crossing on both sides.
Or:
- Remove l3out with catch-all entry.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 11.1(0.213) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.220), 11.1(0.229) |
|
|
| |
| |
Bug Id: | CSCuu56433 |
Title: | [Platform] PFM crashed in C-16 spine |
|
Description: | Symptom:
At least one of the following symptoms:
1) "show module" is very slow or fails from vsh
2) PFM process crashes
Conditions:
One of the following conditions is enough to trigger:
1) Only one system controller card is inserted
2) Both system controller cards are inserted but the mts path to at least one of the system controller cards is down. For example, when system controller cards are reloaded continuously
Workaround:
1) Insert the second system controller card
2) Don't reload the system controller cards
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 11.1(0.219), 11.1(0.225) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.232), 11.1(0.233) |
|
|
| |
| |
Bug Id: | CSCuu31457 |
Title: | Device wizard creates port as "0" for vnsLDevVip |
|
Description: | Symptom:
cluster manage port can not be saved.
Conditions:
after fix, the cluster management port is aved.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 1.0(4k), 1.1(0.878), 1.1(0.882a) |
|
Known Fixed Releases: | 1.0(4k), 1.1(0.887a), 1.1(0.890a), 1.1(0.892a), 1.1(0.895a), 1.1(0.897), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCuu33894 |
Title: | src mac rewrite is not happening after flipping BD mode |
|
Description: | Symptom:
On enabling routing on the bd, existing endpoints will have issue of not rewriting source MAC on routing traffic.
Conditions:
BD should be in routing disabled mode and then enabling routing on the BD might trigger this issue.
Workaround:
Clear EP and relearn
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 11.1(0.213) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.216) |
|
|
| |
| |
Bug Id: | CSCus84448 |
Title: | epmc core in epmc_pd_handle_ep_destroy() on pc/vpc triggers |
|
Description: | Symptom:
This bug was resulting in a core of EPMC process.
The reason being memory corruption in EPMC process. Although this was not seen very frequently, it was reproducible under specific scenario, which being approx. 30 iterations of port-flapping.
Conditions:
Approx. 30 iterations of port-flapping.
Workaround:
As part of the bug fix we found some issue in the code related to memory allocation and deallocation in adjacency module of EPMC. This is certainly a fix that can very well prevent the issue. But due to the sporadic nature of this bug, we cannot conclusively say that this fix is the complete solution.
Further Problem Description:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 11.1(0.147) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.231) |
|
|
| |
| |
Bug Id: | CSCur69668 |
Title: | inband can't interpret some 802.1p frames |
|
Description: | Symptom:
9k inband can't interpret some 802.1p(vlan tag = 0) frames e.g, ARP, LACP as expected, this might cause some connectivity issues.
Conditions:
peer is sending frame with 802.1p header.
Workaround:
disable 802.1p on peer device
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(2) |
|
Known Fixed Releases: | 6.1(2)I3(3.67), 6.1(2)I3(4), 7.0(3)I1(0.171), 7.0(3)I1(1), 7.0(3)I1(1.16), 7.0(3)I1(2) |
|
|
| |
| |
Bug Id: | CSCuu81963 |
Title: | After fabric upgrade, source mac is set 00.00.00.00.00.00 on leaf port |
|
Description: | Symptom:
The ACI N9K switches use the router MAC as the source MAC address, which is all zeros, for sending CDP packets. When receiving CDP packets, most switches do not check the source MAC address to determine if the CDP packets should be dropped.
Conditions:
If CDP is running on the ESX with 5.5 version, the CDP packets are possible to get dropped due to the zero source MAC address.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 11.1(1g) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.244), 11.1(1h) |
|
|
| |
| |
Bug Id: | CSCuu55855 |
Title: | ACI Leaf reload affecting Traffic - possible vPC convergence |
|
Description: | Symptom:
When routing is disabled on the BD and unkown mac unicast is set to porxy, traffic loss is seen on Leaf reload/vPC flap.
Conditions:
BD has to be in unkown unicast proxy and routing disabled
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.9) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.236) |
|
|
| |
| |
Bug Id: | CSCuu48859 |
Title: | Nexus 9500: ECMP load-sharing hashing is not randomized |
|
Description: | Symptom:
With ECMP from a Nexus 9500, hashing will take a predominant path for most flows and not evenly distribute the load across all paths.
Conditions:
Multiple paths exist for destination IPs and ECMP is configured with load-sharing.
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(3.4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut13651 |
Title: | APIC NTP security vulnerability |
|
Description: | Symptoms:
The Cisco Fabric Application Policy Infrastructure Controller (APIC) includes a
version of Network Time Protocol Daemon (NTPD) that is affected by the
vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2013-5211
This bug was opened to address the potential impact on this product.
Conditions:
Device with default configuration.
Workaround:
Not currently available.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5/4.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2013-5211 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 1.1(0.696a) |
|
Known Fixed Releases: | 1.0(3.34), 1.1(0.721), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCuu18910 |
Title: | VRF Ctx is in Delete-Pending State Because of BGP |
|
Description: | Symptom:
A Cisco Nexus 9000 running in ACI made may get into a stats where an administrator finds that a context is not deployed onto one or more fabric nodes with endpoints attached. Other contexts in the same Tenant deploy properly. This failed deployment causes routing in the fabric to fail.
Conditions:
Cisco Nexus 9000 running in ACI mode under rare conditions may get into a state where a tenant private network (also know as a context and vrf) may not be programmed on the fabric node. The condition may occur if the problematic context has been removed in the past and re-added to the configuration with the same name.
The Logical Model of the fabric shows that the problematic context is properly associated to a particular Bridge Domain.
A fabric node in this state will show "Delete Pending" for the context with the output of "show vrf" as shown in this example:
node102#show vrf
VRF-Name VRF-ID State Reason
Test_Tenant:Test_vrf1 32 Down Delete Pending
If the context is added back in again before clearing from this state, The context will not display at all with the command output "show vrf". Instead, check the output of "cat /mit/sys/ctx-[vxlan-2490368]/summary | grep operStQual". Note, substitute the context scope ID in the vxlan- directory for the system in question. operStQual will have a value of delete-pending when in this state.
Workaround:
Reloading affected Leaf switches has shown to clear this issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 11.0(4) |
|
Known Fixed Releases: | 11.0(3.938) |
|
|
| |
| |
Bug Id: | CSCut58693 |
Title: | APIC : vCenter reload causes APIC to loose vDS/ESXi inventory |
|
Description: | Symptom:
Some ESXi hosts may not be displayed under vDS controllers in the APIC.
Conditions:
On a vCenter restart, the APIC syncs the inventory with the vCenter. vCenter APIs do not return all the hosts and VMs in the inventory. This may cause some hosts to be missing.
Workaround:
Trigger the inventory collection manually
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 1.0(3f) |
|
Known Fixed Releases: | 1.0(3.34), 1.0(3l), 1.1(0.784), 1.1(0.787), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCus79275 |
Title: | bcm_usd crash/ N9K-X9564PX, fix Incorrect SER Parity Error correction |
|
Description: | Incorrect handling of parity error correction mechanism can lead to traffic drops and some cases the ASIC not responding to route add/delete and can print syslogs similar to the below:
IPFIB-SLOT1-4-UFIB_ROUTE_DESTROY: Unicast route destroy failed for VRF: x, 1, flags:0x0, intf:0x0, Error: Internal error(-1)
A parity error crash on N9K-X9564PX Line card could also be the result of the incorrect handling of parity error correction mechanism.
Symptom:
Conditions:
Workaround:
This issue is fixed in 6.1(2)I3(4)
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(2), 6.1(2)I3(3a) |
|
Known Fixed Releases: | 6.1(2)I3(3.64), 6.1(2)I3(4) |
|
|
| |
| |
Bug Id: | CSCus61617 |
Title: | Kernel panic - not syncing: Unexpected SERR |
|
Description: | Symptom:
N9K Switch experienced a kernel panic crash saying "SERR"
Conditions:
This issue was first observed on 6.1(2)I3.
Workaround:
This is a parity error. Follow below corrective action:
first occurrence - monitor
2nd occurrence - RMA
Further Problem Description:
due to code error in reporting, the kernel panic reports "SERR" error. It should report as single bit or multi-bit error. This error in report is fixed in 6.1(2)I4 or newer releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(2) |
|
Known Fixed Releases: | 6.1(2)I3(3.73), 6.1(2)I3(3.81), 6.1(2)I3(4), 7.0(3)I1(1.100), 7.0(3)I1(2) |
|
|
| |
| |
Bug Id: | CSCuu53624 |
Title: | Top level folder names with default names are not marked RED |
|
Description: | Symptom:
user can submit the template even the top folder has a name ends with -default and it is red.
Conditions:
after fix,if top folder has a name ends with -default, it can not be submitted.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 1.0(4g), 1.0(4l) |
|
Known Fixed Releases: | 1.0(4k), 1.1(0.927a), 1.1(0.930a), 1.1(0.932a), 1.1(0.936a), 1.1(0.939a), 1.1(0.941), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCut99603 |
Title: | variable TTL echo reply when pinging OOB of spine and leaf switches |
|
Description: | Symptom:
When pinging the OOB ip address of the switch nodes in the fabric (leaf or spine) the TTL value keep changing with values between 250 and 1.
Conditions:
Nexus 9K in ACI mode running system version 11.0(3k)
Workaround:
Not available
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 11.0(3f), 11.0(3k) |
|
Known Fixed Releases: | 11.0(3.931), 11.1(0.207) |
|
|
| |
| |
Bug Id: | CSCuu98008 |
Title: | traffic takes 3-8seconds to converge on downgrade from +9 to +6 image |
|
Description: | Symptom:
On downgrading the fabric from 1.1.1x to 1.0.4x image with shared service configuration, depending on timing conditions the traffic takes anywhere between 0-10seconds to convergence.
Conditions:
Image downgrade with shared service configuration
Workaround:
Traffic will restore after 10seconds
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 11.0(4o) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut46858 |
Title: | ifav41 : Core Found - node: 1201 Service Name: nginx - ifav41-spine121 |
|
Description: | Symptom:
Nginx web server may dump core and restart if stats that are not supported in a downgraded image are queried after a downgrade to that image.
Conditions:
ACI is downgraded from 1.1(1*) image to 1.0(4*) or lower version and then a stats query is made
for an object that is present in 1.1(1*) image but not in 1.0(4*) image.
Workaround:
Query only the stats that are supported in an image.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 1.1(0.750d) |
|
Known Fixed Releases: | 1.0(4k), 1.1(0.768b), 1.1(0.779a), 1.1(0.784), 1.1(1j), 1.1(2.24) |
|
|
| |
| |
Bug Id: | CSCus14460 |
Title: | APIC ML2 Driver incorrectly creates two interface policy groups for vPC |
|
Description: | Symptom:
APIC ML2 Driver incorrectly creates two interface policy groups for one vPC
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 1.0(2m) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus87985 |
Title: | sensor log issues if stat fails for any file in sysmgr tmp_logs |
|
Description: | Symptom:
Leaf switch may encounter dc3_sensor crash and exhibit many sensor logs in /var/sysmgr/tmp_logs directory.
Conditions:
Normal operation after several months (log retention must have reached archival limits before issue is triggered). Affected switches can be identified by checking for the presence of more than 3 sensor logs in /var/sysmgr/tmp_logs.
Workaround:
Upgrade to fixed release.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 11.0(2j) |
|
Known Fixed Releases: | 11.0(3g) |
|
|
| |
| |
Bug Id: | CSCus68764 |
Title: | Nexus 9k: assess GHOST vulnerability in glibc (CVE-2015-0235) |
|
Description: | Symptom:
On January 27, 2015, a buffer overflow vulnerability in the GNU C library (glibc) was publicly announced. This vulnerability is related to the various gethostbyname functions included in glibc and affect applications that call these functions. This vulnerability may allow an attacker to obtain sensitive information from an exploited system or, in some instances, perform remote code execution with the privileges of the application being exploited. This vulnerability is documented in CVE-2015-0235.
A Cisco Security Advisory has been published to document this vulnerability at:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150128-ghost
This bug has been opened to address the potential impact on this product.
Conditions:
Under normal conditions the D9036 does not take hostnames as an input parameter. This vulnerability is not exploitable remotely
Workaround:
Not available.
Further Problem Description:
PSIRT Evaluation:
All previously released versionsand NX-OS software are affected. The fix will be delivered for currently supported releases as follows:
NX-OS 7.0 release - first fixed release is 7.0.3 which is available on CCO
NX-OS 6.1 release - is scheduled to be available in April 2015
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 10/7.8
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C/CDP:ND/TD:ND/CR:ND/IR:ND/AR:ND
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(3) |
|
Known Fixed Releases: | 6.1(2)I3(3.61), 6.1(2)I3(4), 7.0(3)I1(0.274), 7.0(3)I1(1), 7.0(3)I2(0.83), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCut25121 |
Title: | OSPF crash seen while executing "show ip ospf router" command |
|
Description: | Symptom:
OSPFv2 crashes
Conditions:
If routes are churning when "show ip ospf route" is issued, OSPFv2 may crash.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.0(3)I1(1.124), 7.0(3)I1(2) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.0(3)I1(1.140), 7.0(3)I1(2), 7.0(3)IEF1(2), 7.0(3)IEF1(2.7), 7.0(3)IX1(1.93), 7.0(3)IX1(2), 7.1(0)AV(0.74), 7.1(0)IB(120), 7.2(0)D1(0.481) |
|
|
| |
| |
Bug Id: | CSCur04948 |
Title: | Product evaluation for CVE-2014-6271 and CVE-2014-7169 |
|
Description: | Symptom:
Symptoms:
The includes a version of bash that is affected by the vulnerabilities
identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-6271
CVE-2014-7169
This bug has been opened to address the potential impact on this product.
Conditions:
Conditions:
Devices with default configuration.
Workaround:
Workaround:
Not available.
Further Problem Description:
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2
score. The Base and Temporal CVSS scores as of the time of evaluation
are 7.5/7.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:P/A:P/E:H/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained
from multiple sources. This includes the CVSS score assigned by the
third-party vendor when available. The CVSS score assigned may not
reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be
found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0.1)VB(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur02700 |
Title: | Nexus 9000 evaluation for CVE-2014-6271 and CVE-2014-7169 |
|
Description: |
Symptom:
The Cisco Nexus 9000 includes a version of bash that is affected by the vulnerabilities
identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-6271
CVE-2014-7169
This bug has been opened to address the potential impact on this product.
Conditions:
A user must first successfully log in and authenticate via SSH to trigger this vulnerability.
Workaround:
Not available.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2
score. The Base and Temporal CVSS scores as of the time of evaluation
are 7.5/7.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:P/A:P/E:H/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained
from multiple sources. This includes the CVSS score assigned by the
third-party vendor when available. The CVSS score assigned may not
reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be
found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
The following CVE's are fixed in 6.1(2)I3(1).
CVE-2014-6271
CVE-2014-7169
6.1(2)I3(2) release will have the fix for the above two CVEs, and the additionally reported CVEs of
CVE-2014-7186, CVE-2014-7187,CVE-2014-6277, CVE-2014-6278
Hot patch that includes fixes for all the above 6 x CVEs for existing releases are now available for download.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I2(2b), 7.2(0.1)VB(0.1) |
|
Known Fixed Releases: | 6.1(2)I1(3a), 6.1(2)I3(1) |
|
|
| |
| |
Bug Id: | CSCur04945 |
Title: | Product evaluation for CVE-2014-6271 and CVE-2014-7169 |
|
Description: | Symptom:
Symptoms:
The includes a version of bash that is affected by the vulnerabilities
identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-6271
CVE-2014-7169
This bug has been opened to address the potential impact on this product.
Conditions:
Conditions:
Devices with default configuration.
Workaround:
Workaround:
Not available.
Further Problem Description:
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2
score. The Base and Temporal CVSS scores as of the time of evaluation
are 7.5/7.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:P/A:P/E:H/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained
from multiple sources. This includes the CVSS score assigned by the
third-party vendor when available. The CVSS score assigned may not
reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be
found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0.1)VB(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus68928 |
Title: | Ghost Vulnerability for APIC CVE-2015-0235 |
|
Description: | Symptom:
On January 27, 2015, a buffer overflow vulnerability in the GNU C library (glibc) was publicly announced. This vulnerability is related to the various gethostbyname functions included in glibc and affect applications that call these functions. This vulnerability may allow an attacker to obtain sensitive information from an exploited system or, in some instances, perform remote code execution with the privileges of the application being exploited. This vulnerability is documented in CVE-2015-0235.
A Cisco Security Advisory has been published to document this vulnerability at:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150128-ghost
This bug has been opened to address the potential impact on this product.
Conditions:
Default configuration
Workaround:
Not available
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 10/7.8
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C/CDP:ND/TD:ND/CR:ND/IR:ND/AR:ND
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 1.0(2.117), 1.0(2m) |
|
Known Fixed Releases: | 1.0(2.145a), 1.0(2.146), 1.0(3f), 1.1(0.647), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCup22625 |
Title: | Multiple Vulnerabilities in OpenSSL - June 2014 |
|
Description: | Symptoms:
This Cisco products include a version of openssl that may be affected by one or more of the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2010-5298 - SSL_MODE_RELEASE_BUFFERS session injection or denial of service
CVE-2014-0076 - Fix for the attack described in the paper "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
CVE-2014-0195 - DTLS invalid fragment vulnerability
CVE-2014-0198 - SSL_MODE_RELEASE_BUFFERS NULL pointer dereference
CVE-2014-0221 - DTLS recursion flaw
CVE-2014-0224 - SSL/TLS MITM vulnerability
CVE-2014-3470 - Anonymous ECDH denial of service
This bug has been opened to address the potential impact to the product.
Conditions:
Not applicable
Workaround:
Not applicable
Further Problem Description:
Additional details about those vulnerabilities can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 10/8.3:
https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 1.0(0.880), 1.0(0.911a) |
|
Known Fixed Releases: | 1.0(0.488) |
|
|
| |
| |
Bug Id: | CSCus29415 |
Title: | NTPd Vulnerabilities |
|
Description: | Symptom:
The following Cisco products
Cisco Nexus 9000 Switches
include a version of NTPd that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-9293, CVE-2014-9294, CVE-2014-9295 and CVE-2014-9296
This bug has been opened to address the potential impact on this product.
Please consult http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141222-ntpd for further information.
Conditions:
feature ntp
Workaround:
Block NTP query requests:
ntp access-group query-only query-only-acl
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 7.5/7.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:P/A:P/E:H/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.0(3)I1(0.197) |
|
Known Fixed Releases: | 11.1(0.174), 6.1(2)I3(3.99), 6.1(2)I3(4), 7.0(3)I1(0.227), 7.0(3)I1(1), 7.0(3)I2(0.101), 7.0(3)I2(0.97T), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCur01249 |
Title: | APIC evaluation for CVE-2014-6271 and CVE-2014-7169 |
|
Description: | Symptom:
The following Cisco product
Cisco Application Policy Infrastructure Controller, Release 1.0(1e)
includes a version of Bash that may be affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-6271
CVE-2014-6277
CVE-2014-6278
CVE-2014-7169
CVE-2014-7186
CVE-2014-7187
Cisco has analyzed this vulnerability and concluded that while the previously listed products may run a vulnerable version of Bash, there are no exploitation vectors present - therefore, those products are not impacted.
Conditions:
Not applicable
Workaround:
Not applicable
Further Problem Description:
Even though no exploitation vectors are present in the product, release 1.0(1k) (available 2014/10/06) contains a patched Bash that is not affected by the listed vulnerabilities.
Additional details about those vulnerabilities can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has evaluated those issues and they do not meet the criteria for PSIRT ownership or involvement. Those issues will be addressed via normal resolution channels.
If you believe that there is new information that would cause a change in the severity of those issues, please contact psirt@cisco.com for another evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 1.0(1h) |
|
Known Fixed Releases: | 1.0(1k), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur28110 |
Title: | APIC : evaluation of SSLv3 POODLE vulnerability |
|
Description: |
Symptom:
This product includes a version of SSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-3566
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent
Workaround:
Not Available
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the
time of evaluation are: 2.6/2.5
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 1.0(1k) |
|
Known Fixed Releases: | 1.0(1.259), 1.0(1.266a), 1.0(1.269a), 1.0(1.273a), 1.0(1.280), 1.0(1n), 1.0(2j), 1.1(0.379), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCur28092 |
Title: | Nexus 9000 : evaluation of SSLv3 POODLE vulnerability |
|
Description: |
Symptom:
This product includes a version of SSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-3566
This bug has been opened to address the potential impact on this product.
Conditions:
Web based HTTPS interface is provided in Nexus 9000 only when "feature nxapi" is enabled.
This feature is disabled by default.
When this feature is not enabled, Nexus 9000 is not vulnerable.
Workaround:
Disable 'feature nxapi' by doing 'no feature nxapi' in global config mode, if the feature is enabled.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the
time of evaluation are: 2.6/2.5
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(1) |
|
Known Fixed Releases: | 6.1(2)I3(1.25), 6.1(2)I3(2), 6.1(2)I3(2.5), 6.1(2)I3(3), 6.1(2)I3(3.87), 6.1(2)I3(4) |
|
|
| |
| |
Bug Id: | CSCup24057 |
Title: | Multiple Vulnerabilities in OpenSSL - June 2014 |
|
Description: | Symptom:
The following Cisco products
Nexus 9300
Nexus 9500
Nexus 3164
include a version of openssl that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-0076 - Fix for the attack described in the paper "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
CVE-2014-0224 - SSL/TLS MITM vulnerability
CVE-2014-3470 - Anonymous ECDH denial of service
This bug has been opened to address the potential impact on this product.
Conditions:
"Devices with default configuration."
Workaround:
Not available.
Further Problem Description:
CVE-2014-0076 can only occur when a malicious third party app is running on the device. As such there are no such malicious third party app running on the device. The devices allows any other third party app to be run though. So administrator(s) would need to make sure that any third party app/tool added by the dev-op team has no such malicious content
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 7.1/6.3:
https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:M/Au:N/C:N/I:N/A:C/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I2(2a), 6.2(8)IA(1), 7.2(0.1)VB(0.1) |
|
Known Fixed Releases: | 6.1(2)I3(0.164), 6.1(2)I3(1), 7.0(3)I1(0.61), 7.0(3)I1(1) |
|
|
| |
| |
Bug Id: | CSCur02102 |
Title: | Nexus 9k Fabric-sw evaluation for CVE-2014-6271 and CVE-2014-7169 |
|
Description: | Symptom:
The Cisco Nexus 9K includes a version of bash that is affected by the vulnerabilities
identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-6271
CVE-2014-7169
This bug has been opened to address the potential impact on this product.
Conditions:
A user must first successfully log in and authenticate via SSH to trigger this vulnerability.
Workaround:
Cisco Nexus 93128TX Switch : Release 11.x First fixed release is 11.0(1d) Available 06/10/2014
Cisco Nexus 9336PQ ACI Spine Switch : Release 11.x - First fixed release is 11.0(1d) Available 06/10/2014
Cisco Nexus 9396PX Switch : Release 11.x - First fixed release is 11.0(1d) Available 06/10/2014
Cisco Nexus 9508 Switch : Release 11.x - First fixed release is 11.0(1d) Available 06/10/2014
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2
score. The Base and Temporal CVSS scores as of the time of evaluation
are 7.5/7.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:P/A:P/E:H/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained
from multiple sources. This includes the CVSS score assigned by the
third-party vendor when available. The CVSS score assigned may not
reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be
found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 11.0(1b), 11.0(1c) |
|
Known Fixed Releases: | 11.0(1.867), 11.0(1d) |
|
|
| |
| |
Bug Id: | CSCuu47759 |
Title: | N9k -- connectivity breaks in vpc when one leg is down |
|
Description: | Symptom:
in N9k setup with two vpc port-channels, if first vpc is single legged to N9k-1 and second vpc is single-legged to N9k-2, connectivity from first vpc towards second vpc and back is broken.
Conditions:
conditions found so far
1. configured VPC primary should be VPC operational secondary
2. shutdown command should not be issued on N9k side, but rather on switches connected through VPC port-channel
Workaround:
explicitly shut down vpc members which are already down on N9k with 'shutdown' command
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur63227 |
Title: | Traffic drop for BGP RNH routes during switchover |
|
Description: | Symptom:
Temporary traffic loss during switchover
Conditions:
When BGP prefixes have the Nexthop learnt over BGP itself and in the presence of a default route in the system then during switchover BGP prefixes can have some temporary traffic drop. This will get fixed up after BGP convergence is done post switchover.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(1.53) |
|
Known Fixed Releases: | 7.0(3)I1(0.185), 7.0(3)I1(0.190), 7.0(3)I1(0.225), 7.0(3)I1(1), 7.0(3)I1(1.20), 7.0(3)I1(1.214), 7.0(3)I1(1.216), 7.0(3)I1(2), 7.0(3)I2(0.419), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCuu20850 |
Title: | ACI Fan Slot 1 Failure |
|
Description: | Symptom:
"show logging onboard module 1 exception-log" from the N9K switch will indicates that FAN is removed and inserted multiple times.
System Errorcode : FAN_REMOVED: Fan module is removed
System Errorcode : FAN_INSERTED: Fan module is inserted
Conditions:
N9K switch running ACI code
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 11.0(4), 11.0(4l), 11.1(0.205), 11.1(0.209) |
|
Known Fixed Releases: | 11.1(0.212), 11.1(0.220), 11.1(0.222) |
|
|
| |
| |
Bug Id: | CSCus71452 |
Title: | N9300 - ADJMGR and FIB Next Hop Interface Out Of Sync |
|
Description: | Symptom:
Certain IP's are unreachable when sending traffic through a Nexus 9300
Conditions:
Following a loop in the network
Workaround:
Clear ip arp x.x.x.x force-delete
Further Problem Description:
This is due to a disconnect in the state between ADJMGR and the FIB:
N9K-1# sh ip arp detail
Flags: * - Adjacencies learnt on non-active FHRP router
+ - Adjacencies synced via CFSoE
# - Adjacencies Throttled for Glean
IP ARP Table for context default
Total number of entries: 2
Address Age MAC Address Interface Physical Interface
1.1.1.250 00:00:52 0000.0000.0001 Vlan1 port-channel3 <---------------- SW points to Po3
N9K-1# sh forwarding adjacency platform
slot 1
=======
IPv4 adjacency information
next_hop:1.1.1.250 rewrite_info:0000.0000.0001 interface:Vlan1 (Phy 0x16000001) <------ FIB points to Po2
HH:0x7 Refcount:2 Flags:0x800 Holder:0x1 pbr_cnt:0 wccp_cnt:0
BCM adj: unit-0:100011 unit-1:0 unit-2:0, cmn-index: 7, LIF:1 Upd 3
BCM NVE adj: unit-0:0 unit-1:0 unit-2:0, cmn-index: 7, LIF:1 Upd 3
N9K-1# sh int snmp-ifindex | i 0x16000001
Po2 369098753 (0x16000001) <------------------------------------------------- SNMP IFindex for Po2
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I2(1), 6.1(2)I2(2), 6.1(2)I2(2a), 6.1(2)I2(2b), 6.1(2)I2(3), 6.1(2)I3(1), 6.1(2)I3(2), 6.1(2)I3(3.50), 6.1(2)I3(3a) |
|
Known Fixed Releases: | 6.1(2)I3(3.56), 6.1(2)I3(4), 7.0(3)I1(1) |
|
|
| |
| |
Bug Id: | CSCuu81949 |
Title: | 9372TX:Ports go down randomly, dont negotiate 1g on extended cable later |
|
Description: | Symptom:
Intermittent failure of interfaces on the Nexus 9372TX switches running 6.1(2)I3(4a), with the interfaces sometimes remaining down and not recovering. Reload might or might not recover it.
We dont know the trigger as of now.
This is a typical interface config:
interface Ethernet1/42
switchport access vlan 28
spanning-tree port type edge
speed auto 100 1000
Some trigger breaks the port and it does not come up with an extended cable ((about 175 - 250 feet)) using patch panel in between. Same port comes up with directly stretched cable of about 15-100 feet with or without patch panel. When you shift the same cable with same host from broken port to new port, it works.
With extended cable in broken condition (with the fact that host works on 1gig):
+ 'speed auto 100' gets the port up in 100g
+ 'speed auto' does not get the port up
+ 'speed 100' gets it to work
+ 'speed 1000' doesn't
+ 'speed auto 100 1000' doesn't
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(4a) |
|
Known Fixed Releases: | 6.1(2)I3(4b) |
|
|
| |
| |
Bug Id: | CSCuu61826 |
Title: | svc_ifc_opflexelem_core core encuntered with 1.0.4.j build |
|
Description: | Symptom:Opflex Element process restart on the ToR
Conditions:ESX host connect. Timing related. Cannot happen easily.
Workaround:No workaround necessary. opflex element process will restart automatically.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.8) |
|
Known Fixed Releases: | 1.0(4k), 1.1(0.939a), 1.1(0.941), 1.1(1j), 1.1(2.41) |
|
|
| |
| |
Bug Id: | CSCuu61433 |
Title: | Dupe Tunnels after detach / Attach host causing epm core |
|
Description: | Symptom:Crash in epm on leaf switch due to duplicate tunnels
Conditions:This can happen when the southbound tunnels are created with AVS/Microsoft/VMware vShield. In certain conditions e.g. host attach/detach the old tunnels was not getting cleaned.
Workaround:Clean reboot leaf
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.9) |
|
Known Fixed Releases: | 1.0(4k), 1.1(0.936a), 1.1(0.939a), 1.1(0.941), 1.1(0.942a), 1.1(0.945a), 1.1(0.949a), 1.1(1j), 1.1(2.41) |
|
|
| |
| |
Bug Id: | CSCuu84967 |
Title: | ifav41 - Validation of x509 Cert submitted failed during cfg import |
|
Description: | Symptom:
a) Expired user authentication certificates cannot be deleted.
b) Expired user authentication certificates cannot be deleted via config import with replace option.
Conditions:
User submits an x509 certificate to be used for authentication and the certificate expires.
Workaround:
Replace the certificate with a new valid certificate. Deletion of the aaaUserCert object will now be permitted.
Further Problem Description:
The aaaUserCert mo contains user certificates in x509 format. x509 certificates are validated when submitted (or imported via config import). They are also being validated during deletion which causes this issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 1.1(1h) |
|
Known Fixed Releases: | 1.1(1.72a), 1.1(1.75a), 1.1(2.37), 1.1(2.41) |
|
|
| |
| |
Bug Id: | CSCuu40526 |
Title: | N9k:Fexqos Clear qos stats not clearing the counters |
|
Description: | Symptom:
Clearing queuing statistics for FEX host interfaces is not supported
Conditions:
when user attempts to clear queueing statistics using "clear qos statistics" command , counters will not be reset to zero
Workaround:
No workaround. Two snapshots of the cli can be taken and difference of the counters will give same information
1) clear qos statistics followed by
2) show queuing interface
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.307) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu73003 |
Title: | On downgrading some fvCEps are getting lost |
|
Description: | Symptom:
Some end-points are not getting reported under EPG.
Conditions:
When leaves are downgraded in quick succession after APIC, this happens.
Workaround:
End-points will get reported successfully after they age out and learned again.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 1.1(0.945a) |
|
Known Fixed Releases: | 1.0(4k), 1.1(1.55), 1.1(1b), 1.1(1j), 1.1(2.41) |
|
|
| |
| |
Bug Id: | CSCuu79239 |
Title: | core on ifc_reader - error cannot create or open DB ~/ifc_policymgr.db |
|
Description: | Symptom:
APICs cored on the ifc_reader process with a error (Server error cannot create or open DB: var/run/mgmt/db/ifc_policymgr/S32_R1/ifc_policymgr.db) being displayed in the GUI anytime a policy is clicked on.
Conditions:
APICs core and lose connectivity to one another. APIC's believe they're fully fit but no longer have the one of the other APICs in topology.
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 1.0(3f) |
|
Known Fixed Releases: | 1.0(4l), 1.1(1.56a), 1.1(1.58a), 1.1(1.60a), 1.1(1.62a), 1.1(1.65), 1.1(1i), 1.1(1j), 1.1(2.41) |
|
|
| |
| |
Bug Id: | CSCuu64031 |
Title: | aclqos Core downgrading from 936a to 4h |
|
Description: | Symptom:
When downgrading fabric from 1.1 release to an earlier release, aclqos process is coring
Conditions:
This will happen if IPv6 L3 prefixes (l3extSubnet) are configured on the system, and then fabric is downgraded.
Workaround:
Please use one of the following workarounds:
1. Delete IPv6 prefixes before downgrading leafs
2. Downgrade APICs before downgrading leaves
3. Downgrade leaves to version 1.04K or later
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 11.0(4) |
|
Known Fixed Releases: | 1.1(0.941), 1.1(0.945a), 1.1(0.949a), 1.1(1.55), 1.1(1j), 1.1(2.41) |
|
|
| |
| |
Bug Id: | CSCuu62942 |
Title: | N9K3: ARP packet not forwarded on FEX with DAI |
|
Description: | Symptom:
ARP reply is not forwarded on FEX host interface
Conditions:
- DAI is enabled
- Host is connected on FEX
Workaround:
- Connect host to parent switch
OR
- Disable DAI
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu58397 |
Title: | scripthandler memory usage is linearly increasing |
|
Description: | Symptom:
The memory usage of scripthandler keeps increasing. This should happen only when L4L7 device packages are used in the APIC. The issue specifically happens when a device package is removed and installed again.
Conditions:
This issue does not happen every time a device package is removed and installed. There is a timing element to this and the issue is seen only when multiple conditions occur together.
Workaround:
Delete the L4L7 device package and install them again.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 1.1(0.912a) |
|
Known Fixed Releases: | 1.0(4k), 1.1(0.930a), 1.1(0.932a), 1.1(0.936a), 1.1(0.939a), 1.1(0.941), 1.1(1j), 1.1(2.41) |
|
|
| |
| |
Bug Id: | CSCuu06634 |
Title: | Enable func type option for LDev in Device wizard |
|
Description: | Symptom:
The package is device only supports go throught. However when user create a service graph using those package devices, those device's mode becomes go to.
That was the bug which has already been resolved.
Conditions:
N/A
Workaround:
Do not need workarounds. Already fixed.
Further Problem Description:
No futhere problem
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 1.0(4l), 1.1(0.839a) |
|
Known Fixed Releases: | 1.0(4k), 1.1(1.55), 1.1(1.56a), 1.1(1.58a), 1.1(1.60a), 1.1(1.62a), 1.1(1.65), 1.1(1j), 1.1(2.41) |
|
|
| |
| |
Bug Id: | CSCut81958 |
Title: | fex crash in satmgr_show_all_fcot_info() with 'show fex transceiver' |
|
Description: | Symptom:
2248 PQ FEXs attached to a Nexus 9000 will go offline with a satmgr crash when running "show fex trans detail"
Conditions:
Nexus 9000 running 6.x
2248PQ FEX attached
"show fex trans detail" command is issued
Workaround:
None
Further Problem Description:
A fix for this issue is available in 7.0(3)I1(2).
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 7.0(3)I1(1.178) |
|
Known Fixed Releases: | 7.0(3)I1(1.216), 7.0(3)I1(2), 7.0(3)ISH1(2), 7.0(3)ISH1(2.13), 7.0(3)IX1(1.93), 7.0(3)IX1(2) |
|
|
| |
| |
Bug Id: | CSCut56520 |
Title: | Support Compat check for PV mappings in vpc scenario |
|
Description: | Symptom:
The wrong PV mapping configuration will not be detected across vPC links.
Conditions:
When PV mapping is not configured properly on vPC, the links are not brought down.
Workaround:
None. The configuration should be cross checked manually.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 7.0(3)I1(1.136), 7.0(3)I1(1.156), 7.0(3)I2(0.406) |
|
Known Fixed Releases: | 7.0(3)I2(0.424), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCut08582 |
Title: | N9000 snmp crash with snmpbulkget and role configuration |
|
Description: | Symptom:
Snmpd crashed when user issue snmpgetbulk request with multiple oid.
Problem exists in 6.1.2.I1.1.
Fix had been integrated into 7.03.I1.2.
Conditions:
1. The role only has deny oid rule.
2. The role has deny oid rule and permit oid rule but both are not overlap.
Workaround:
snmpgetbulk with single oid.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(3a) |
|
Known Fixed Releases: | 6.1(2)I3(4b), 7.0(3)I1(1.213), 7.0(3)I1(2), 7.0(3)ISH1(2), 7.0(3)ISH1(2.13), 7.0(3)IX1(1.93), 7.0(3)IX1(2) |
|
|
| |
| |
Bug Id: | CSCuu95970 |
Title: | switch does not forward control plane packets out of broadcom asic |
|
Description: | Symptom:
port will go into "suspended" and end server will not receive LLDP or LACP packets from the switch.
Conditions:
Server is a linux server running a bond with active active LACP. Could be any operating system but linux supports LACP.
Workaround:
reload the switch
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 11.0(4m) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul56483 |
Title: | Not able to route between vlans for traffic traversing peer link twice |
|
Description: | Symptom:
On the Nexus 9000 switch if traffic ingressing on peer link on one vlan, and egress out on different vlan via the same vpc peer link ports, then the hairpin traffic will be dropped. BFD echo mode is one example where BFD enabled on SVI will not establish in echo mode.
Conditions:
Issue happens when switch is enabled for VPC. Issue does not happen in non vpc environments.
Workaround:
1. Use peer-gateway under vpc domain.
2. Use of FHRP based protocols with vpc (which is a more common configuration) will not see this issue.
Further Problem Description:
This is vpc limitation on the nexus 9000 switch and hence behavior cannot be changed.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I2(0.53) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur69353 |
Title: | Cisco Nexus 9000 Series Switches APIC OpenSSH Vulnerabilities |
|
Description: | Symptom:
Cisco Nexus 9000 Series Switches LAN Switch Software includes a version of APIC OpenSSH that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2007-2243, CVE-2007-4752, CVE-2008-1483, CVE-2008-1657, CVE-2008-3234, CVE-2008-5161
This bug was opened to address the potential impact on this product.
Conditions:
Device running with default configuration running an affected version of software.
Workaround:
None.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 7.5/6.2:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:P/A:P/E:F/RL:OF/RC:C
CVE-2007-2243 and CVE-2008-3234 have been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 1.0(2h), 1.0(4e) |
|
Known Fixed Releases: | 1.1(0.443), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCuu58251 |
Title: | Missing HSRP VIP v6 link-local after reload of both HSRP routers |
|
Description: | Symptom:
The HSRP VIP v6 link-local address of the SVI is missing in the output of "show ipv6 interface vlan x". As a result v6 hosts will not learn the RA messages from the router.
Conditions:
Reload of HSRP routers at the same time.
Workaround:
Remove the HSRP v6 configuration from the affected SVI and re-add.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I1(3.4) |
|
Known Fixed Releases: | 7.0(3)I2(0.428), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCup55648 |
Title: | ipfib crash seen during extended stress and scale condition |
|
Description: | Symptom:
MTS build-up for SAP 199 may lead to IPFIB crash of multiple line cards.
Conditions:
A large amount of adjacency updates/change notifications generated by the adjacency manager can cause buildup of these adjacency change MTS messages.
Workaround:
None
Further Problem Description:
With this fix a flow-control mechanism for adjacency manger & FIB adjacency updates is introduced to ensure the MTS queues are not overwhelmed due to any pending messages. The following commands may be used to monitor this condition -
show system internal mts memory
show system internal mts buffers summary
show system internal mts lc sap 199 stats
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I2(2a), 7.0(3)I1(1.187), 7.0(3)IDD1(1.73) |
|
Known Fixed Releases: | 7.0(3)I2(0.426), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCuv05263 |
Title: | N9K Looping VTP Advertisement within vPC Domain |
|
Description: | Symptom:
High CPU (netstack and VTP).
The VTP packet storm could hit adjacent devices causing instability downstream or upstream.
Conditions:
When VTP advertisement is received in Nexus 9000 fully transparent VTP vPC domain.
Workaround:
Disable VTP feature (no feature ftp)
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(4a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCum58876 |
Title: | RPF change is not updated correct or mfdm/ipfib crash if oifl > 40 svis |
|
Description: | <B>Symptom:</B>
The QA-tested scalability limit for multicast on the Nexus 9500 is 40 outgoing interfaces
(OIFs) per multicast route (i.e. per (*,G) or (S,G) entry). When this is exceeded, unexpected
behavior has been observed, such as:
- RPF update failure - if the RPF path for a multicast source moves from a L3 interface to a
VLAN interface (SVI), this is not correctly updated in the FIB and in hardware programming. As
a result, streams from this source are punted to the supervisor due to RPF failure.
- The 'mfdm' service may crash on the supervisor, causing a HAP reset of one or both
supervisors.
- The 'ipfib' service may crash on any or all line cards and/or fabric modules,
causing a HAP reset of the affected module(s).
- MTS exhaustion may be observed.
<B>Conditions:</B>
The noted issues are known to occur when the OIF list (OIFL) exceeds 40 entries for one or more
multicast routes.
The device is not guaranteed to experience these crashes or programming failures once in this
state. However, once in this state, multicast churn (any actions that would require
reprogramming of multiple OIF lists in hardware) can cause the aforementioned issues to appear.
<B>Workaround:</B>
Limit the size of the OIFL for any given multicast route to 40 entries or fewer.
<B>Further Problem Description:</B>
This issue is caused by the current N9K multicast software architecture. Large OIF lists exceed
the capacity of the messages used to communicate between MFDM on the supervisor and IPFIB on
the line cards, and this causes corruption which directly leads to the programming failures and
crashes.
There is a two-part plan to address this:
- In the next major release (Bronte) a preventative fix will be implemented to prevent crashes
and warn a user if a given OIFL exceeds 40 entries.
- In the following major release (Camden) there will be significant code re-design to increase
the verified OIFL scalability numbers above 40 OIFs per group.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I1(1.149) |
|
Known Fixed Releases: | 6.1(2)I3(3.74), 6.1(2)I3(4), 7.0(3)I1(0.209), 7.0(3)I1(1), 7.0(3)I1(1.54), 7.0(3)I1(2) |
|
|
| |
| |
Bug Id: | CSCuu82359 |
Title: | Evaluation of n9k-standalone-sw for OpenSSL June 2015 |
|
Description: | Symptom:
This product includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-4000, CVE-2015-1788, CVE-2015-1789, CVE-2015-1790, CVE-2015-1792, CVE-2015-1791, CVE-2014-8176
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent.
Affects Nexus 9300 and 9500 Series. Affected versions include 7.0(3)I1(2) and prior.
Fixed version will be 7.0(3)I2(1). Estimated CCO 6/31/2015.
Workaround:
Not available.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the
time of evaluation are: 7.8/6.4
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(4a), 7.0(3)I1(2) |
|
Known Fixed Releases: | 7.0(3)I2(0.432), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCuv03171 |
Title: | APIC 1.1.1j : VMM crashes child (Rn) of class compIp is already attached |
|
Description: | Symptom:
VMM process dumps core after upgrade to 1.1(1j)
In /var/log/dme/log/svc_ifc_vmmmgr.bin.log.stderr file we observe error message such as follows:
terminate called after throwing an instance of 'error::CoreException'
what(): child (Rn) of class compIp is already attached. dn[(Dn0)] Dn0=, Rn=ip-[fe80::aaaa:bbbb:cccc:dddd]
Conditions:
This problem occurs when duplicate IPv4/IPv6 addresses are reported by vCenter in the guest.net data of virtual machine (GuestInfo managed objects).
Such condition may occur, for instance, when virtual interfaces exist and IPv6 auto-configuration is enabled
Workaround:
Remove duplicate IP address configuration from the virtual machine.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu82032 |
Title: | N9K: CoPP Some ACLs are not programmed |
|
Description: | Symptom:Some of the control packets are not getting classify in their respective class. This results in control packet drops due to default copp policy.
For eg:
vpc peer-keepalive will fail
Conditions:This issue has been seen on 6.1(2)I3(4)
Some of the CoPP ACLs are not programmed in the hardware.
For eg:
`show policy-map interface control-plane`
Control Plane
Service-policy input: copp-system-p-policy-strict
class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
--------SNIP-----------
show access-list will not list those access-list
show access-lists summary will show that total ACE configured is 0.
IPV4 ACL copp-system-p-acl-undesirable
Total ACEs Configured: 0
Configured on interfaces:
Active on interfaces:
IPV4 ACL copp-system-p-acl-vpc
Total ACEs Configured: 0
Configured on interfaces:
Active on interfaces:
IPV4 ACL copp-system-p-acl-vrrp
Total ACEs Configured: 0
Configured on interfaces:
Active on interfaces:
IPV4 ACL copp-system-p-acl-wccp
Total ACEs Configured: 0
Configured on interfaces:
Active on interfaces:
Workaround:re-apply 'copp profile strict'
Note: There could be a momentary spike in CPU and packet drop to CPU which can cause control plane drops, as Control plane is unprotected. It is better to do this during a maintenance window. Appropriate warnings are are printed when you attempt this.
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I3(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq77485 |
Title: | RBAC Security not working for health score |
|
Description: | Symptoms:
A vulnerability in the role-based access control (RBAC) of the Cisco Application Policy Infrastructure Controller (Cisco APIC) could allow an
authenticated, remote attacker to have ''read'' access to certain information stored in the affected system .
The vulnerability is due to improper handling of role-based access control (RBAC) for health scoring. An attacker could exploit this
vulnerability by gaining access to information that they should not be able to.
Conditions:
Devices running an affected version of 1.0(1e).
Workaround:
None.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5.5/4.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:P/I:P/A:N/E:F/RL:OF/RC:C
CVE ID has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 1.0(1.110a) |
|
Known Fixed Releases: | 1.0(1.156a), 1.0(1.172), 1.0(2j), 1.1(0.319), 1.1(1j) |
|
|
| |
| |
Bug Id: | CSCus20557 |
Title: | Traceroute between VMs - some nodes missing |
|
Description: | Symptom:
When Traceroute is issued between two VMs with ACI in-between, some nodes along the path may not show up
Conditions:
When Traceroute is issued between two VMs with ACI in-between, some nodes along the path may not show up
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.9) |
|
Known Fixed Releases: | 11.0(2.901) |
|
|
| |
| |
Bug Id: | CSCuq09078 |
Title: | Hsrp move active/standby from vpc domain to another leaves gmac |
|
Description: | Symptom:
Two different symptoms have been seen:
1) Traffic destined to VIP is looped on a backup/ listening/ standby switch
2) VMAC is programmed in hardware as a gateway MAC on backup/ listening/ standby switch
Conditions:
Two vPC pairs are L2 adjacent to each other, each pair is enabled for FHRP in the same group.
Traffic destined to VIP is received on backup/ listening/ standby which has gateway MAC configured in hardware, at this point the traffic will loop in software. No operational impact.
Workaround:
Remove second HSRP pair and flap SVI.
Further Problem Description:
This design is not supported on the Nexus 9000 at this time.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.1(2)I2(2b), 6.1(2)I3(0.178), 7.0(3)I1(1), 7.0(3)I2(1) |
|
Known Fixed Releases: | 7.0(3)I2(0.350), 7.0(3)I2(1) |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论