| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv72787 | Title: | VXLAN F&L: some nve peers are not learnt back after nve shut/no shut |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
some nve peers are not learnt back
Conditions:
flap nve interface
n9k-standalone
527/538/541 images
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.541) |
|
Known Fixed Releases: * | 7.0(3)I2(0.559), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw27697 | Title: | Deleting Port-channel from UI also deletes referenced interface polices |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: * | Symptom:
If a user to deletes a PC/VPC port-channel from Fabric--Inventory--Pod--Leaf--Interfaces--PC Interfaces, the associated Interface policies also get deleted.
In case the LACP policy is used by others PC/VPC, the PC/VPC would be impacted.
Conditions:
Only bputra,bputra-mr1 are affected, prior to MR2. Amazon or previous releases are not affected.
Affected releases:
1.1(1j)
1.1(1o)
1.1(1r)
1.1(2h)
Workaround:
To delete a PC/VPC, please do so from Fabric--Access Policy panel.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: * | 1.1(1j), 1.1(1r), 1.1(2h) |
|
Known Fixed Releases: | 1.1(1s), 1.1(3c) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv46792 | Title: | N9K - Loops DHCP Packet on Spanning-tree Blocked Port |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
A vulnerability in the Spanning Tree Protocol (STP) handling of Dynamic Host
Configuration Protocol (DHCP) packets in the Cisco Nexus 9000 (N9K) Series Switch
software could allow an unauthenticated, adjacent attacker to cause a partial
denial of service (DoS) condition due to high CPU. The high CPU is due to a the
DHCP packet looping on the STP blocked port.
The vulnerability is due to a DHCP broadcast packet being forwarded out a STP port
in the state ''Alternate Blocking State''. An attacker could exploit this vulnerability
by flooding DHCP broadcast packets to the affected device. An exploit could allow the
attacker to cause the CPU utilization of the device to be abnormally high due to the
DHCP broadcasts being mis-handled and incorrectly looped on the STP blocked port.
Conditions:
The N9K configured as DHCP Relay agent with a link in STP ''Alternate Blocking State''.
Workaround:
The user can shutdown down the STP which is in ''Alternate Blocking State'' or prune the
VLAN which the loop is occurring in from this interface
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 3.3/2.7:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C&version=2.0
No CVE ID has been assigned to this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I3(2), 6.1(2)I3(4b), 7.0(3)I1(0.206), 7.0(3)I1(2) |
|
Known Fixed Releases: * | 6.1(2)I3(4.10), 6.1(2)I3(4.12), 6.1(2)I3(5), 7.0(3)I1(2.7), 7.0(3)I1(3), 7.0(3)I2(0.568), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw10437 | Title: | BFD vxlan non-vpc not coming up |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BFD vxlan non-vpc case is not coming up
Conditions:
BFD vxlan non-vpc case is not coming up
Workaround:
none
Further Problem Description:
BFD vxlan non-vpc case is not coming up
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.0(3)IMK2(1.55) |
|
Known Fixed Releases: | 7.0(3)IMK2(1), 7.0(3)IMK2(1.56) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup55648 | Title: | ipfib crash seen during extended stress and scale condition |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I2(2a), 7.0(3)I1(1.187), 7.0(3)IDD1(1.73) |
|
Known Fixed Releases: * | 6.1(2)I3(4.5), 6.1(2)I3(5), 7.0(3)DEV1(1), 7.0(3)DEV1(1.5), 7.0(3)I1(2.7), 7.0(3)I1(3), 7.0(3)I2(0.426), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw13560 | Title: | Cisco Nexus 9000 (N9K) Series Switch Reserved VLAN Tag Vulnerability |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
A vulnerability in the handling of incoming Layer 2 (L2) packets tagged with a reserved VLAN number from the
Cisco Nexus 9000 (N9K) Series Switch could allow an unauthenticated, adjacent attacker to cause a partial denial
of service (DoS) condition due to increased CPU and possible control plan instability. In addition L2 packets which
should be dropped by the switch can be incorrectly forwarded on the connected interfaces.
The vulnerability is due to lack of input validation of the VLAN number in the L2 packet. An attacker could exploit this
vulnerability by sending a crafted L2 packet tagged with a N9K reserved VLAN number. An exploit could allow the
attacker to cause a partial DoS condition due to increased CPU and possible control plan instability. In addition this
packet should be dropped by the N9K and instead can be forwarded on the attached networks.
Conditions:
Device running with default configuration running an affected version of software.
Workaround:
The reserved VLAN range can be changed to not conflict with the incoming traffic.
To review the current reserved VLAN range and reconfigure the follow commands are used:
> show vlan internal usage
> system vlan #### reserve
> copy running-config startup-config
> reload
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 4.8/4.6:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:P/I:N/A:P/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2015-6295 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I3(4), 7.0(3)I1(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.22), 7.0(3)I2(2), 7.0(3)IX1(1.242), 7.0(3)IX1(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut64977 | Title: | N9K: odd number Vlans are missing in vtpVlanTable |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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.
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I1(1.168) |
|
Known Fixed Releases: * | 7.0(3)I2(0.376), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.72) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv03171 | Title: | APIC 1.1.1j : VMM crashes child (Rn) of class compIp is already attached |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: * | 1.1(1m), 1.1(2h), 1.2(0.1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw07942 | Title: | Bud Node: Mcast encap packets duplicated with VPC leg down scenarios |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Duplicate VxLAN encapsulated packets are received on certain ports
Conditions:
When an IGMP join is present on a local vPC or orphan port from a VTEP, duplicate packets will be sent when a native frame is received and encapsulated with a multicast VxLAN header.
This behavior is observed for vPC ports with remote leg down, or for orphan ports when the native frame is received on the vPC peer switch.
Workaround:
There is no workaround
Further Problem Description:
|
|
Last Modified: | 12-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.598) |
|
Known Fixed Releases: * | 7.0(3)I2(0.601), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.37) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw20223 | Title: | [Camden][N9K] Flows fail to install if port-channel used as output port |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When user tries to install a flow low installation fail if the monitor device is connected to port channel that consists of 40G interface ports
Conditions:
For NDB 2.2 when connected to a Openflow device of N9K platform of Camden image
Workaround:
Wait for Camden MR1 release and update the N9K device the image with Camden MR1
Further Problem Description:
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: | 7.0(3)I2(1.16), 7.0(3)I2(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv60458 | Title: * | Intersite traffic loss observed due to lst-egress entry missing |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Zoning rules show as disabled and traffic is not flowing through L3out as expected.
Faults are seen for "## number of Prefix failed"
Conditions:
Occurs in rare occasions where L3outs are configured with many contracts and subnets associated.
Workaround:
Wipe the switch where faults are seen using setup-clean-config.sh and reboot
Further Problem Description:
This issue is seen when prefix entries are not properly written in the forwarding table
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 1.1(1p) |
|
Known Fixed Releases: | 11.1(1.280) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv69713 | Title: | Cisco NX-OS IGMP Malformed Packet DoS Vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A vulnerability in the Internet Group Management Protocol (IGMP) Version 3 (IGMPv3) input
packet processing of the Nexus Operating System (NX-OS) could allow an unauthenticated,
adjacent attacker to cause the IGMP process to restart due to a malformed IGMP packet.
This can cause a denial of service (DoS) condition on the device.
The vulnerability is due to improper input validation when ensuring that the memory allocated
is large enough for the number of included sources in the IGMPv3 packet. An attacker could
exploit this vulnerability by sending a crafted IGMPv3 packet to the device. An exploit could
allow the attacker to cause the IGMP process to restart due to a buffer overflow which causes
the DoS condition. If the malformed IGMPv3 packet is continuously sent the device the DoS
condition will remain and the device is unavailable.
Conditions:
IGMP Version 3 snooping is configured on one or more Virtual Local Area Networks (VLANs).
Workaround:
The IGMP Version 3 snooping configuration has to be removed.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.1/5:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2015-4324 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.81) |
|
Known Fixed Releases: * | 7.0(3)I2(0.546), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu42733 | Title: | APIC with different image in existing cluster causes inconsistent state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The APIC appliance sees a crash in the DMEs while getting a replication transaction, or when a configuration is missing on the APIC that was introduced with different version.
Conditions:
This issue occurs in an existing cluster:
- If an appliance is decommissioned and brought back with a different version than other appliances, which are in majority
- If an appliance is introduced as a new appliance to extend a cluster but is running a different version than other appliances
Workaround:
Before introducing new appliances in the existing cluster, make sure it is running the same version as other appliances. If the appliance is already introduced with a different version, to fix this problem:
1. Decommission the appliance that is running a different version (decommission is done from the other appliance in the cluster)
2. Upgrade to the same version as the rest of the cluster (acidiag installer)
3. Reboot clean of the appliance after it has been upgraded (eraseconfig)
4. Commission appliance back in the cluster
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: * | 1.0(4h), 1.1(0.895a), 1.1(0.897a), 1.1(1.90a), 1.1(1j) |
|
Known Fixed Releases: | 1.1(2h), 1.2(0.1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv05263 | Title: | N9K Looping VTP Advertisement within vPC Domain |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
High CPU (netstack and VTP).
The VTP packet storm could hit adjacent devices causing instability downstream or upstream.
Conditions:
When VTP advertisement is received in Nexus 9000 fully transparent VTP vPC domain.
Workaround:
Disable VTP feature (no feature ftp)
Further Problem Description:
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I3(4a) |
|
Known Fixed Releases: * | 6.1(2)I3(4.7), 6.1(2)I3(5), 7.0(3)I1(2.3), 7.0(3)I1(3), 7.0(3)I2(0.452), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur40272 | Title: | APIC Simulator Fails to Load |
|
Status: * | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
The APIC hardware-based simulator is stuck at the Switch to APIC1 screen.
Conditions:
- APIC version 1.0(1k)
- Hardware-based simulator
Workaround:
Downgrade to a previous APIC release (i.e. 1.0(1e)
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 1.0(1k) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv20065 | Title: | EVPN External routing BGP EVPN OSPF redistribution fail on 7.0(3)I1(2) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BGP Evpn redistribute into OSPF failed after upgrading to 7.0(3)I1(2)
Conditions:
7.0(3)I1(2)
Workaround:
use "match internal" when redistribute BGP into OSPF
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I1(2z) |
|
Known Fixed Releases: * | 7.0(3)I1(2.12), 7.0(3)I1(3), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)PDB(0.57), 7.3(0)RTG(0.52) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv37825 | Title: | arp packets looped back through vpc leg of peer when TCN |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ARP packets might get looped back through vpc leg of peer when mac address table churn, in turn causing mac move events in the L2 network.
Conditions:
TCN/clear mac address-table manually.
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I3(4b), 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I1(2.11), 7.0(3)I1(3), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv75025 | Title: | MDP restore and config lock happening with reboot of same image post upg |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
After the switch image upgraded from Bronte to Camden, the switch could take long time to boot. The boot time could be around 15 minutes, which is a long time.
If the user does not do "copy running startup" and reload the switch again, the boot time will stay the similar amount of time as the upgrade boot.
NOTE: there are no functionality impacts to the switch.
Conditions:
This can happen when the user did "copy run startup" with Bronte image and then upgrade the switch to Camden image. This only happens if the startup config saved with Bronte image is a large config.
Workaround(s):
There is no workaround for the upgrade boot time. However, there is a workaround for the switch reloads after the upgrade. The user just needs to do "copy run startup" once after the upgrade with the Camden image. Then any future switch reload will be much faster and the issue no longer exists for the user.
Workaround:
There is no workaround for the upgrade boot time. However, there is a workaround for the switch reloads after the upgrade. The user just needs to do "copy run startup" once after the upgrade with the Camden image. Then any future switch reload will be much faster and the issue no longer exists for the user.
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.545) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu99618 | Title: | Hardcoding speed 100 / duplex full mgmt port goes down - Nexus 93xx |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Hardcoding speed 100 / duplex full on mgmt 0 port brings the link down on Nexus 93xx.
N93xx---mgmt0----fa0---catalyst 2960
N93xx---mgmt0----eth1/1---nexus 3k
In both scenarios, hardcoding speed 100 / duplex full, the mgmt 0 port remains not connected
Conditions:
the link goes down only when we hardcode the speed and duplex. if speed & duplex is auto on both sides, the link comes up without any issues.
Workaround:
"no duplex full " on mgmt 0, brings the link up.
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I1(2.16), 7.0(3)I1(2.9), 7.0(3)I1(3), 7.0(3)I2(0.516), 7.0(3)I2(0.553), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.15), 7.0(3)IMK2(1.65), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv24927 | Title: | N9K - DHCP Traffic Punted to Control Plan w/o SVI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
DHCP packets are seen at the control plane of a Nexus 9000 Series Switch
Conditions:
No SVI for the vlan the DHCP traffic is traversing the switch in
DHCP Feature not enabled
DHCP Snooping not configured
DHCP Relay not configured
Workaround:
Contact Cisco TAC
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I3(3a), 6.1(2)I3(4b), 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I2(0.568), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv02994 | Title: | cieIfUtilTable is always return 0, instead cli value. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
cieIfUtilTable still showing 0 values instead actual Packet Rate.
Problem exists in 6.1.2.I1.1.
Fix had been integrated into 7.0.(3).I2.1.
Conditions:
Always.
Workaround:
Use "show interface ..." CLI to get the equivalent information
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.418) |
|
Known Fixed Releases: * | 7.0(3)I2(0.500), 7.0(3)I2(0.524), 7.0(3)I2(0.527), 7.0(3)I2(0.579), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.15), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut84983 | Title: | Enforce log rotation for access.log |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
-Fault "Storage unit /data on node mounted at /data is X full"
-Output of du -H | sort -n (as root) shows that nginx is taking up large amount of space, causing the above fault
Conditions:
-APIC running 1.0(3f)
-access.log file in /data/nginx/logs/ taking up large amount of hard drive space
Workaround:
1 - Access APIC as root
2 - cat /dev/null > /data/nginx/logs/access.log
OR
1-Upgrade code to fixed version and log will automatically rotate
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 1.0(3f) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup10992 | Title: | 82bytes mem-leak in('ACLQOS_MEM_ptrie_mem_t', '73') with peer-link flap |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 13-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I2(2.45) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv56042 | Title: | dot1dStpPortTable does not instantiate some interfaces |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
dot1dStpPortTable does not instantiate some interfaces
Conditions:
Mibwalk dot1dStpPortTable for a given vlan or mst context.
Workaround:
None.
Further Problem Description:
The fix exists in NXOS software release 7.0(3)I1(3), 7.0(3)I2(1) and all the later releases.
|
|
Last Modified: | 14-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.494) |
|
Known Fixed Releases: * | 7.0(3)I2(0.519), 7.0(3)I2(1), 7.0(3)I2(1.5), 7.0(3)I2(2), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw16490 | Title: | Adding New Vlan and VNI segment for same Vlan may fail |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Newly added VLan/VNI segment for VxLan config will fail to forward the traffi.
Conditions:
VxLan VTEP in vPC mode. And config is applied using script .
Workaround:
Apply config by having some delay between two consecutive e commands.
Further Problem Description:
|
|
Last Modified: | 14-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I3(4) |
|
Known Fixed Releases: * | 7.0(3)I2(1.5), 7.0(3)I2(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw27059 | Title: | Openflow ACLQOS TCAM carving for Tomahawk |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
ACLQOS Openflow carving needed for Tomahawk
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 7.0(3)IDB3(0.84) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut07188 | Title: | secondary ip address configuration failed with a new SVI creation |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Unable to configure secondary address with a new SVI creation
Conditions:
Configure a new SVI with VPC
Workaround:
create a SVI and submit it, Then go back and edit the SVI, it will be able to keep the secondary ip address configuration..
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 11.0(2m) |
|
Known Fixed Releases: | 1.1(0.737a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw18244 | Title: | InbZone query only show the first one in mgmt inb egp deployment |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Deployment query for inband epg is not showing all inband zones that are associated with it
Conditions:
This problem can occur when there are multiple inband zones associated to the EPG
Workaround:
Nodes using this policy table shows the correct deployment information. It's only the 'Policies using this policy' that is missing one of the associated policies.There is no operational impact.
Further Problem Description:
This issue is a side effect of how mgmt zones are modeled. There is no operational impact
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 1.1(2.47) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw16254 | Title: | PC programming fails on 1 leg of FEX vPC to host |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
1 Leg of a VPC is not coming up when the hosts are plugged into a FEX
Conditions:
The host is plugged into 2 different FEX's and the interfaces are mapped to a VPC policy group. The interface will not get bundled into a port-channel.
Detailed reason:
1. Initially fex port was not part of any port channel and EPgs were deployed on the port.
2. User changed selector config and made the port part of port channel.
3. EPgs deployed on the port were not cleaned and this lead to inconsistent vlan deployment on the port channel and its member fex port.
4. NXOS validates this inconsistency and doesn't make the port operationally part of the port channel.
Workaround:
1. Remove the port from the port-channel.
2. Undeploy all the EPgs which were deployed on the fex port.
3. Make the port part of port-channel.
Further Problem Description:
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 1.1(2h) |
|
Known Fixed Releases: * | 1.1(2.55), 1.1(3f), 1.2(0.116), 1.2(0.121a), 1.2(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw20598 | Title: | bmr2: faultSwRetP is still show node when disc to conditionNodePolGrp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Some policies are shown as deployed to a node even when they are no longer in use on that node.
Conditions:
This can occur for some policy relations when user initially has a relation / association to one policy name, and then changes association to a different policy.
Workaround:
Re-check the configuration and policies consuming this poliyc. Also, click on the node details from the deployment query, and it will not show any resource.
Further Problem Description:
There is no operational impact. Only a false positive that a policy will show in use when it's not.
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 1.1(2.53) |
|
Known Fixed Releases: * | 1.2(0.116), 1.2(0.117), 1.2(0.121a), 1.2(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw22254 | Title: | Invalid path fault see when same dom attached to seletcor and override |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Invalid path fault see when same dom attached to seletcor and override
Conditions:
Seeing invalid path nwIssues on some EPGs whose static paths have both selectors and overrides, and in selectors Domain is not present but the domain is present on overrides.
Workaround:
Delete / recreate the override selector
Further Problem Description:
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 1.1(2.53) |
|
Known Fixed Releases: * | 1.2(0.120a), 1.2(0.121a), 1.2(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw34696 | Title: | SNMPwalk - OID not incrementing for rip2IfStatAddress w/ multiple IP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Mibwalk rip2IfStatAddres, observed OID not incrementing, keep looping.
Conditions:
when HSRP or multiple IP's are configured under RIP enabled interface.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 26-SEP-2015 |
|
Known Affected Releases: | 7.0(3)IX1(1.229) |
|
Known Fixed Releases: | 7.0(3)I2(1.19), 7.0(3)I2(2), 7.1(0)I3(0.19), 7.1(0)I3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw08975 | Title: | OpenSSH: Evaluation of Multiple OpenSSH CVEs for NX-OS |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptoms:
Cisco Nexus Operation System (NX-OS) includes a version of Open Secure Shell (OpenSSH)
software that is affected by the vulnerabilities identified by the following Common
Vulnerability and Exposures (CVE) IDs:
CVE-2015-5600, CVE-2015-6563, CVE-2015-6564 and CVE-2015-6565
This bug was opened to address the potential impact on this product.
Conditions:
Device with default configuration.
Workaround:
Not currently available.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at
http://cve.mitre.org/cve/cve.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5600
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6563
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6564
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6565
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.9/6.9:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:M/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C&version=2.0
CVE ID CVE-2015-5600, CVE-2015-6563, CVE-2015-6564, CVE-2015-6565 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.89) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw11670 | Title: | Queries for fault counts return wrong results or broken responses |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Fault counts queries for controller fabric node and fault class queries using rsp-subtree-include for fabricNode class return incomplete fault count information..
Conditions:
This occurs on all versions of APIC software.
Workaround:
There is no workaround for the issue with the mo query for a controllers fault count.
Rather than doing a class query for fabric nodes and asking for a fault-count, do a mo query for the node but include the fltCnts relative name at the end so you are querying the switches fault count instead.
Further Problem Description:
Queries for fault counts for the controller fabric nodes returns a totalcount in the response of 1 but then the imdata is empty.
Class queries for fault counts using rsp-subtree-include against the fabricNode class returns an incomplete fault count subtree and the counters are all zero.
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 1.1(2h) |
|
Known Fixed Releases: * | 1.2(0.113b), 1.2(0.115a), 1.2(0.116) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw34546 | Title: | arpStAdjEp not deleted from leaves after deleting the interface profiles |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Stale arp static adjacency objects remain in leaf after deleting interface profiles
Conditions:
This occurs if user has EPGs with static CEp configuration, and then deletes the interface profiles for the leaves / interfaces where these EPGs are deployed.
Workaround:
Recreate the interface profile, and then delete the static CEp configuration from the EPG.
Further Problem Description:
|
|
Last Modified: | 30-SEP-2015 |
|
Known Affected Releases: | 1.1(3e) |
|
Known Fixed Releases: * | 1.2(0.129b), 1.2(0.132) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw36876 | Title: | BMR2: Deployment query on subject doesn't work when toggling options |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Deployment query for contract may timeout when there are many providers or consumers in a single tenant
Conditions:
This may happen in scale configurations if the same contract is a provider or consumer for many EPGs, all in the same tenant.
Workaround:
Individually show usage of each EPG that is providing or consuming the contract
Further Problem Description:
There is no functional impact, but the deployment query will not show contract usage.
|
|
Last Modified: | 30-SEP-2015 |
|
Known Affected Releases: | 1.1(3f) |
|
Known Fixed Releases: * | 1.2(0.132) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo25060 | Title: | ipv4/ipv6 for vrf all consistency-checker timeout with multi-vrf context |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Syslogs show that a "full" inconsistency run does not complete.
Conditions:
L3 inconsistency runs do not complete when command is run for all vrfs at the same time.
Workaround:
run this command per vrf.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I2(1.27), 6.1(2)I2(2a), 7.0(3)I2(0.307) |
|
Known Fixed Releases: * | 6.1(2)I2(2a), 6.1(2)I2(2c), 7.0(3)I2(0.462), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.0(3)IX1(1.236), 7.0(3)IX1(1.243), 7.0(3)IX1(2), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw41463 | Title: | Fan failure faults raised due to spurious errors in reading fan status |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Leaf fan failure faults are spuriously raised and then cleared (within 30 seconds).
Conditions:
Normal operation.
Workaround:
Further Problem Description:
This is a cosmetic issue. Faults clear without user intervention and are not an indication of a hardware failure.
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: * | 11.0(4q), 11.1(3f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw38189 | Title: | Denied modifying incorrect asa configuration using APIC ASA Dev Pkg |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Configured incorrectly first time ?1200.200.0.0? but corrected immediately. Doesn't change config on ASA
Conditions:
Config changes are not pushed to ASA
Workaround:
TBD
Further Problem Description:
|
|
Last Modified: | 30-SEP-2015 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: * | 1.2(0.132) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu13617 | Title: | [eft-bputra] vzAny does not include external EPGs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
vzAny contracts that are applied do not include externally routed networks (external EPGs) in policy application.
Conditions:
Using an L3Out and having a contract set as provided or consumed or both onvzAny (EPg Collection for Context).
Workaround:
Apply contract to external EPGs specifically.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 1.1(0.766m), 1.1(0.766p), 1.1(0.849) |
|
Known Fixed Releases: * | 1.1(0.860), 1.1(1j), 1.2(0.1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv27688 | Title: | 5s wait to bring down local interfaces with ejector based shutdown |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Traffic disruption for 5s when module is removed or depending on topology STP reconvergence can be triggered when module is removed
Conditions:
Removing a line card module
Workaround:
"no hardware ejector enable"
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I3(4b) |
|
Known Fixed Releases: * | 7.0(3)I1(2.8), 7.0(3)I1(3), 7.0(3)I2(0.539), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv94453 | Title: | VRF Context RD is set as 0:0 when "rd auto" is enabled |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When "rd auto" is enabled under VRF context, it is expected to concatenate . But for some VRF, it is set as 0:0
Failing VRF,
VRF-Name: TEST1, VRF-ID: 4, State: Up
VPNID: unknown
RD: 0:0 ===> RD set to 0:0
VNI: 100001
Max Routes: 0 Mid-Threshold: 0
Table-ID: 0x80000004, AF: IPv6, Fwd-ID: 0x80000004, State: Up
Table-ID: 0x00000004, AF: IPv4, Fwd-ID: 0x00000004, State: Up
Working VRF,
VRF-Name: TEST2, VRF-ID: 3, State: Up
VPNID: unknown
RD: 10.1.1.1:3
VNI: 100004
Max Routes: 0 Mid-Threshold: 0
Table-ID: 0x80000003, AF: IPv6, Fwd-ID: 0x80000003, State: Up
Table-ID: 0x00000003, AF: IPv4, Fwd-ID: 0x00000003, State: Up
Conditions:
When "rd auto" is used under VRF context.
Workaround:
Manually configure the RD under VRF context
N9K(config)# vrf context TEST1
N9K(config-vrf)# rd 10.1.1.1:4
N9K(config-vrf)# address-family ipv4 uni
N9K(config-vrf-af-ipv4)# route-target both 10.1.1.1:4
N9K(config-vrf-af-ipv4)# route-target both 10.1.1.1:4 evpn
Further Problem Description:
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.559), 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(0.592), 7.0(3)I2(0.599), 7.0(3)I2(1), 7.3(0)RTG(0.71) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut72252 | Title: | APIC "Password Strength Check" requirements not documented |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
APIC "Password Strength Check" requirements not documented.
Conditions:
1.0(3i)
Workaround:
none
Further Problem Description:
Investigating what the passwords requirements are when the "password Strength Check is enabled and when it is disabled.
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 1.0(2m) |
|
Known Fixed Releases: * | 1.0(2n) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu98041 | Title: | MDP: policy-map is case-insensitive |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
When user configures two policy-maps which are same but (having different "cases" in their names), only 1 policy-map (the first one) takes effect
Conditions:
When two policy-maps with same names (but may be different cases) are configured.
Workaround:
This is inherent limitation in the way cmd file is written for QoS in bronte/camden. The policy-map names are case
insensitive. The work-around is to use different policy-map names (which have different alphanumeric characters as well).
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.413) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu99734 | Title: | ARP loop when TCAM is not carved for ARP supression and feature enabled |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ARP storm caused by flood of ARP packets between VPC VTEPs on the peer link
Conditions:
With ARP supression enabled, when a client sends a GARP on bootup, the packet loops between the two Nexus VPC VTEPs
TCAM for ARP suppression is not carved
Workaround:
To use ARP supression, carve a TCAM region for arp
Further Problem Description:
This bug is filed to ensure the ARP supression feature is not enabled until TCAM region for arp is carved
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)DEV1(1), 7.0(3)DEV1(1.5), 7.0(3)I1(2.5), 7.0(3)I1(3), 7.0(3)I2(0.431), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw16624 | Title: | Intersite and APIC - HTTPSConnectionPool Read timed out |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
APIC and Intersite.py script are not in sync with what has been exported from local site fabric to remote site fabric due to randomly missing endpoint subnet on InstP on remote site APIC controller.
Conditions:
Results in error and reach-ability between endpoints in two different sites.
Workaround:
Manually configure EP subnet in remote site InstP. In a large scale environment it is inconvenient and requires large configuration.
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun47041 | Title: | bgpPeerPfxPol needs to be removed since feature will not be supported |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
APIC GUI/REST APIs allows for configuration of maximum number of prefixes that BGP can receive from a BGP peer. This feature is not supported even though configuration is allowed. No fault is raised to indicate that this feature is not supported. Configuration is silently ignored by border leafs when the configuration is pushed by APIC.
Conditions:
When user configures BGP maximum prefix policy either through APIC GUI/REST APIs.
Workaround:
All the route filtering, route attribute modifications (for both BGP/OSPF) are expected to be done by external routers connected to border leafs. Border leafs accept all the routes advertised by external routers.
Further Problem Description:
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: * | 11.1(1j), 11.1(2.287) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv13054 | Title: | cfexConfigCreationTime alwasy return 0 instead correct timestamp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
cfexConfigCreationTime object in CISCO-ETHERNET-FABRIC-EXTENDER-MIB always returns 0.
Conditions:
Mibwalk cfexConfigCreationTime object.
Workaround:
None.
Further Problem Description:
The issue is fixed in NXOS software releases 7.0(3)I2(1).
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.438) |
|
Known Fixed Releases: * | 7.0(3)I2(0.454), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv32523 | Title: | syslogd hap reset when invoking /dev/log for syslogd through python |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Syslogd crashes when python script is invoked to log syslog
Conditions:
pyhton script is loaded on n9k and run to log syslog on the switch
Workaround:
modified python script to add date and timestamp before writing message to /dev/log for logging syslog. If message is passed in proper format, then syslog is getting logged on the console and syslogd doesn't crash
Further Problem Description:
Syslog expects message in a particular format and continues with the processing. Unformatted message was causing the crash.
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I2(0.565), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv08434 | Title: | Cisco Nexus 9000 VDC Authenticated Privilege Escalation Vulnerability |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A vulnerability in Command Line Interface (CLI) parser of the Cisco Nexus Operating
System (NX-OS) devices could allow an authenticated, local attacker to perform a
privilege escalation at the CLI.
The vulnerability is due to improper input validation of special characters within
filenames. An attacker could exploit this vulnerability by authenticating at the local
shell and writing a file to disk with certain special characters. The attacker could then
use that file with other CLI commands to obtain an shell prompt at their current
privilege level. An exploit could allowthe attacker to read/write files and perform
other privileged commands.
Conditions:
Device running with default configuration running an affected version of
software.
Workaround:
The user has to be authenticated so use care when distributing ''admin''
credentials to only trusted sources.
Further Problem Description:
Credit:
Cisco would like to thank Jens Krabbenhoeft for discovering and reporting this vulnerability.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are
4.3/4.1:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:P/I:P/A:P/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2015-4237 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: | 7.2(0)ZZ(99.3) |
|
Known Fixed Releases: * | 7.0(3)DEV1(1), 7.0(3)DEV1(1.5), 7.0(3)I1(2.9), 7.0(3)I1(3), 7.0(3)I2(0.439), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo49986 | Title: | Need a way to be able to support sub-interface number range from 1-4096 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In order to support static breakout configuration, sub-interface range is restricted to a number from 1-511.
This enhancement request is to allow user to configure any sub-interface number from 1-4094, but internally
re-map the sub-interface to one of the values from 1-511, so that it makes migration of configs from other platforms easier, and let user keep their dot1q vlan and sub-interface number the same for config readability
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I2(1), 6.1(2)I2(2a) |
|
Known Fixed Releases: * | 7.0(3)I1(2.6), 7.0(3)I1(3), 7.0(3)I2(0.463), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw02054 | Title: | CDP interface is down message seen when CDP policy is DISABLED |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Customer sets up SYSlog server - which shows many messages with "CDP interface is DOWN" on server interfaces when CDP policy is not configured ie DISABLED
Conditions:
CDP policy = DISABLE
syslog monitoring policy = info/warning/errors
interface is reset
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 1.1(1o) |
|
Known Fixed Releases: * | 1.2(0.93) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu59308 | Title: | vxlan small packets padding issue on GEM port after decap |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
64 byte packet with 4 byte dot1q coming in ingress VTEP will go out as 60 byte payload if the egress port is a 40G access port on the egress VTEP which is a 93xx device. Packet will get dropped on peer as runt.
Conditions:
Incoming packet on a trunk port on ingress VTEP is a 64 byte packet including 4 byte .1q tag and 4 byte CRC. Packet gets encapsulated as 56 bytes in VxLAN payload. On the egress VTEP which is a 93xx device, if the egress port is a 40G GEM port configured as switchport access, this packet will go out as 60 bytes and packet will get dropped on the peer device as runt.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw06953 | Title: | ifc reader core segmentation fault found on Sytem Upgrade test bed |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Conditions:
Workaround:
Further Problem Description:
Program terminated with signal 11, Segmentation fault.
#0 0x00007ff11156d37f in mo::Changer::processEventsFaultsLogs (this=0x7ff113d44900) at ../common/src/framework/./core/mo/Changer.cc:508
508 ../common/src/framework/./core/mo/Changer.cc: No such file or directory.
in ../common/src/framework/./core/mo/Changer.cc
Missing separate debuginfos, use: debuginfo-install insieme.app.reader-1.1.2.21-0.x86_64
(gdb) bt
#0 0x00007ff11156d37f in mo::Changer::processEventsFaultsLogs (this=0x7ff113d44900) at ../common/src/framework/./core/mo/Changer.cc:508
#1 0x00007ff11157292d in mo::Changer::end (this=0x7ff113d44900, aInIsSuccess=) at ../common/src/framework/./core/mo/Changer.cc:564
#2 0x00007ff1115e1ba4 in mo::Transactor::cleanup (this=0x7ff119336000, aInSuccess=) at ../common/src/framework/./core/mo/Transactor.cc:409
#3 0x00007ff1115e2bc4 in mo::Transactor::endCb (this=0x7ff119336000) at ../common/src/framework/./core/mo/Transactor.cc:332
#4 0x00007ff11161875f in proc::Doer::single (this=, aInStimulus=...) at ../common/src/framework/./core/proc/Doer.cc:1092
#5 0x00007ff111618cf8 in proc::Doer::process (this=0x7ff117ec9000, aInStimulus=...) at ../common/src/framework/./core/proc/Doer.cc:622
#6 0x00007ff1116193cb in proc::Doer::trySingle (this=0x7ff117ec9000, aInStimuli=std::vector of length 1, capacity 1 = {...}, aInFirstOnly=) at ../common/src/framework/./core/proc/Doer.cc:819
#7 0x00007ff111619930 in proc::Doer::process (this=0x7ff117ec9000, aInOutStimuli=std::vector of length 1, capacity 1 = {...}) at ../common/src/framework/./core/proc/Doer.cc:653
#8 0x00007ff11161a186 in proc::Doer::react (this=, aInNumberOfElements=, aInOutStimuliArray=...) at ../common/src/framework/./core/proc/Doer.cc:403
#9 0x00007ff1116a21b7 in shard::ReaderDoer::react (this=0x7ff117ec9000, aInNumberOfElements=, aInOutStimuliArray=) at ../common/src/framework/./core/shard/Manager.cc:1792
#10 0x00007ff111621508 in core_queue::BsqReader::process (this=, aInOutQueue=..., aInPriority=) at ../common/src/osiris/core/queue/BatchServiceQueue.h:548
#11 0x00007ff11161bce5 in core_queue::BatchServiceQueue::consume (this=0x7ff119370400, aInDummy=) at ../common/src/osiris/core/queue/BatchServiceQueue.h:330
#12 0x00007ff11161b9e6 in operator() (owner=0x7ff113b7e140, base=) at /usr/include/boost/bind/mem_fn_template.hpp:165
#13 operator(), unsigned char>, boost::_bi::list0> (owner=0x7ff113b7e140, base=) at /usr/include/boost/bind/bind.hpp:313
#14 operator() (owner=0x7ff113b7e140, base=) at /usr/include/boost/bind/bind_template.hpp:20
#15 asio_handler_invoke, unsigned char>, boost::_bi::list2*>, boost::_bi::value > > > (owner=0x7ff113b7e140, base=) at /usr/include/boost/asio/handler_invoke_hook.hpp:64
#16 invoke, unsigned char>, boo
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 1.1(2.21) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw06102 | Title: | N9K Ethanalyzer Match Rule Out of Range |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Ethanalyzyer decode-internal match rule is out of range.
Conditions:
Running Ethanalyzer on the N9K
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv32121 | Title: | Document CoPP Behavior Changed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
This is not a defect but a documentation issue about CoPP behavior changes
Pre 7.0(3)I2(x), the customer can disable copp. However, the CoPP actually is not getting disabled but the switch rate-limit the packets at 500 pps.
From 7.0(3)I2(x), the cli to disable CoPP will get rejected.
N9508a-SJ(config)# no copp profile strict
ERROR: Deactivating COPP service-policy/profile is not allowed.
Please activate an alternate policy using either "copp profile .." command OR
"service-policy .." command under control-plane submode
OR
N9508a-SJ(config)# control-plane
N9508a-SJ(config-cp)# no service-policy input customer-copp-policy-strict
This operation can cause disruption of control traffic. Proceed (y/n)? [no] y
ERROR: Deactivating COPP service-policy/profile is not allowed.
Please activate an alternate policy using either "copp profile .." command OR
"service-policy .." command under control-plane submode
Conditions:
NA
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.448) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv77996 | Title: | Techsupport export transfer leave open until finished |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
You will see Techsupport or On Demand Techsupports not transferring and eventually failing. The following fault should be raised as well
Description: Upload of techsupport triggered at 2015-05-29t16:19:19:959+01:00 for policy tsod-Techsupport timed-out. Detail reason= Time out; status before timeout= Running bash commands
You will also see the following in the svc_ifc_dbgr.bin.log under /var/log/dme/log:
10544||15-07-06 16:55:08.653+01:00||dataexport||ERROR||||Remote export failed. ErrorCode=28, ErrorStr=Timeout was reached, Detail=Operation timed out after 500000 milliseconds with 0 bytes received, Overall=Timeout was reached. Operation timed out after 500000 milliseconds with 0 bytes received||../common/src/dataexport/./ExportTask.cc||133 bico 56.389
10544||15-07-06 16:55:08.653+01:00||dataexport||ERROR||||Data task attempt failed. Will retry. 3 attempt(s) left. Sleeping 30sec before retry.||../common/src/dataexport/./DataTask.cc||107
Conditions:
-ACI Version found: 1.0(4h)
-On Demand Techsupport or Techsupport to Remote Location
Workaround:
Export Techsupport and On Demand Techsupport to APICs or Switch then grab off there.
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 1.0(4h) |
|
Known Fixed Releases: * | 1.2(0.77b), 1.2(0.80a), 1.2(0.83) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut48218 | Title: | ISIS: forwarding adjacency next-hops unresolved after reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After reload or power-cycle, ISIS next-hop forwarding adjacencies remain unresolved.
Conditions:
This is seen with configurations in which BFD is NOT present, since BFD masks
the issue.
Workaround:
1. The issue can be resolved by pinging the next-hop
2. If bfd is enabled, the issue will not be seen
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I1(1) |
|
Known Fixed Releases: * | 7.0(3)I2(0.542), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut18713 | Title: | N9K-ACLQOS syslog for TCAM Resource Exhaustion Needs To Have More Detail |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
When attempting to apply a customer CoPP policy to a Nexus 9300 or Nexus 9500 the following syslog is printed when the custom configuration exhausts the TCAM carved out for the CoPP TCAM Region by default:
2015 Feb 28 12:23:25 Nexus9K-1 %$ VDC-1 %$ %ACLQOS-SLOT1-2-ACLQOS_OOTR: Tcam resource exhausted: (null)
Conditions:
When attempting to apply a customer CoPP policy to a Nexus 9300 or Nexus 9500 and thee custom configuration exhausts the TCAM carved out for the CoPP TCAM Region by default:
Workaround:
None.
Further Problem Description:
This Bug is filed to make the log message printed to be more verbose. Ideally we would like it to include the following information:
1.) What TCAM Region the resource has been exhausted for
2.) What line of the ACL did the failure occur at so the user can make modifications to apply part of the config until the TCAM Region can be recarved and the chassis reloaded.
For more information on the TCAM region limitations on the Nexus 9000 series platform please review the following section of the configuration guide:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/qos/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Quality_of_Service_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_Quality_of_Service_Configuration_Guide_7x_chapter_0100.html
|
|
Last Modified: | 02-SEP-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(3a), 6.1(2)I3(3b), 6.1(2)I3(4) |
|
Known Fixed Releases: | 6.1(2)I3(3.107), 6.1(2)I3(4), 7.0(3)I1(1.125), 7.0(3)I1(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv88218 | Title: | Fault F1690 needs a better explanation and recommended Action |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Service Graph does not apply and displays cryptic fault F1690 indicating: Configuration is invalid due to id allocation failure.
Conditions:
Service graph is applied while no vlans are free in the associated vlan pool(s).
Workaround:
Add a new vlan block to the associated vlan pool.
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 1.1(2h) |
|
Known Fixed Releases: * | 1.2(0.91) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv24351 | Title: | Download info of ACI SDK and model is incorrect in documentation |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Customer was looking to download ACI python SDK and found documentation in Cisco.com.
The document found is - http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/api/python/install/b_Install_Cisco_APIC_Python_SDK_Standalone.pdf
Conditions:
Information about APIC python SDK download was found in http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/api/python/install/b_Install_Cisco_APIC_Python_SDK_Standalone.pdf
Workaround:
TAC provided correct information for download via APIC GUI instead
Further Problem Description:
|
|
Last Modified: | 08-SEP-2015 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: * | 1.1(1r), 1.2(0.80a), 1.2(0.83), 1.2(0.94) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw08304 | Title: | ACI GUI does not allow private scope contracts to be exported |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Cannot export private scope contract
Conditions:
Normally this is expected since this is required to export to another tenant, hence a global scope is required anyway.
However there is one specific use case where this is required. Specifically when two EPGs in two tenants are using the same common:VRF.
- Since both are in the same VRF, a private scope should be satisfactory
- However the GUI does not allow a private scoped contract to be exported
Workaround:
A) use API to push the config (which still allows private scoped contracts to be exported)
B) create the contract as a global scope, export, then revert back to private scope.
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: * | 1.1(2.35), 1.2(0.97) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw06400 | Title: | ACI DOC - adding community to SNMP context changes scope |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Customer is trying to poll an SNMP OID from the leaf switch with the following result:
ANDRECOM-M-W0HT:~ andrecom$ snmpwalk -v2c -c bootcamp2 -Of 10.48.22.105 ifTable
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable = No Such Object available on this agent at this OID
ANDRECOM-M-W0HT:~ andrecom$
Conditions:
This occured because we were are accessing a fabric-level OID using a community which has been defined at the fabric level (Fabric -> Fabric Policies -> Pod Policies -> SNMP), but then it has also been added to a SNMP context under a private network. This way, the community can no longer be used to access fabric-level OIDs, but only context-level OIDs.
Workaround:
Remove the community from the SNMP context of the private network, or create a new SNMP community under Fabric Policies and use that one.
Further Problem Description:
none
|
|
Last Modified: | 12-SEP-2015 |
|
Known Affected Releases: | 1.1(2h) |
|
Known Fixed Releases: * | 1.1(2r) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv01020 | Title: | DOC bug: Cisco AV Pair inconsistency in documentation |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
documentation inconsistency with screenshot and procedure
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: * | 1.1(1j) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw11807 | Title: | openssl ciphers list still includes non-working ciphers |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The NGINX cipher list includes ciphers that do not actually work.
Conditions:
This is a follow-up to CSCuv94846 which removed explicit support for the ciphers but the ciphers are still included implicitly. The ciphers also need to explicitly remove from the cipher list.
Workaround:
Further Problem Description:
There are only ten supported ciphers:
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 1.2(0.89) |
|
Known Fixed Releases: * | 1.2(0.101) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw38440 | Title: | fabric.Node.fabricSt should reflect the state in acidiag avread output |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
when fabricSt is set to inactive, "acidiag avread" will show the node as active
Conditions:
"moquery -d topology/pod-1/node-1" displays the node as inactive, where "acidiag avread" displays the node as active.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 1.0(3f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw06384 | Title: | ACI - Supported SNMP OIDs list not clear about scope |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Customer is trying to poll an SNMP OID from the leaf switch with the following result:
ANDRECOM-M-W0HT:~ andrecom$ snmpwalk -v2c -c bootcamp2 -Of 10.48.22.105 ifTable
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable = No Such Object available on this agent at this OID
ANDRECOM-M-W0HT:~ andrecom$
Conditions:
This occurs when we are accessing a fabric-level OID using a context-level SNMP community or vice-versa.
Workaround:
Use one SNMP community for fabric-level and separate SNMP communities for context-level. Use the correct community string to access each OID.
Further Problem Description:
none
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 1.1(2h) |
|
Known Fixed Releases: * | 1.1(3f) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw29324 | Title: | All nodes show up in DQ for default leaf/spine specific Diag BT/HL pol. |
|
Status: | Terminated |
|
Severity: | 4 Minor |
Description: | Symptom:
Deployment query for the Spine node diagnostic policies show that they are deployed on the leafs. Similarly, Leaf node diagnostics policies show that they are deployed on the Spines.
Conditions:
This happens when the monPolGroup with both spine diag and leaf diag policies is attached to a node selector which has both leafs and spins.
Workaround:
The workaround is to create separate node selectors for leafs and spines and create corresponding monPol with the appropriate diag policies in them.
Further Problem Description:
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 1.1(3b) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw42183 | Title: | clear example needed for fallback domain login |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
customer is configuring ACI with AAA.
Conditions:
Customer made mistakes with configuration and needs to use faillback
Workaround:
Customer contacted TAC for info on how to log on
Further Problem Description:
N/A
|
|
Last Modified: | 26-SEP-2015 |
|
Known Affected Releases: | 1.1(3f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw41884 | Title: | EPG=>Operational=>Contracts=>To EPG Traffic does not have pagination |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Browser (Chrome) hangs and not responding or slow to navigate within the page.
Conditions:
Over 1000 EPGs being consumed or provided.
Workaround:
None.
Further Problem Description:
When loading page, memory/browser utilization constantly increases until crash.
|
|
Last Modified: | 27-SEP-2015 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: | 1.2(0.119a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw41300 | Title: | ACI leaf generating duplicate SNMP Traps |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
if you have an snmp source in fabric/monitor policies /common policies
and one in fabric access policies/ monitoring policies,
you may get duplicate traps for some traps such as link down (interfaces.ifTable.ifEntry.ifAdminStatus)
Conditions:
Workaround:
remove the monitoring policy in the fabric->monitoring policy->SNMP policy
Further Problem Description:
|
|
Last Modified: | 30-SEP-2015 |
|
Known Affected Releases: | 11.1(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw46210 | Title: | l1:PhysIfspeed_failed fault thrown for interface not configured |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
l1:PhysIfspeed_failed message is seen as a fault under the switch
Conditions:
the interface was configured at one point but then was unconfigured.
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 01-OCT-2015 |
|
Known Affected Releases: | 1.1(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw02859 | Title: | Add ability to export configuration to local machine |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
can't export configuration to local machine natively
Conditions:
customer wants the config to be exported to a local machine and not a remote location
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 1.1(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq78913 | Title: | ENH: Need to preserve CoS across ACI Fabric for IP packets |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
CoS is not preserved across the fabirc for IP traffic.
Conditions:
IP traffic comes into the ACI fabric over a trunk with Dot1p markings.
Workaround:
Further Problem Description:
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 11.0(1b) |
|
Known Fixed Releases: * | 1.2(0.110a), 1.2(0.112a), 1.2(0.113b), 1.2(0.115a), 1.2(0.116), 1.2(0.89), 11.2(0.41), 11.2(0.46), 11.2(0.61) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw03648 | Title: | Provision for Multiple APIC IP's in the Intersite script |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Current version support single IP for APIC which prevents EP sync in the event of current APIC goes down or loose connectivity.
Conditions:
In such event, since there are 3 APIC minimum in typical deployment, other APIC IPs should be leverage and EP sync should continue to happen
Workaround:
Re-run the script with new APIC ip or run parallel script that uses different APIC IP
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw03641 | Title: | Validation check and result status for Intersite.py script |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
missing validation support
Conditions:
For ex. We need to understand if all EP are in sync on local as well as remote site. We need a verification command line before customer initiate troubleshooting and deep digger
Workaround:
manually verify APIC /query on visore
Further Problem Description:
Validation check and result status has to be there for customer to validate. For ex. How many total EP has been pushed from local site to remote site and if they all made it to remote site, per tenant/ap/epg would be great.
For ex. We need to understand if all EP are in sync on local as well as remote site. We need a verification command line before customer initiate troubleshooting and deep digger
Intersite > ep-validation ???tenant ?scale1? ???ap ?compliance? ???epg ?prod? (Ensure All EP per tenant/ap/epg on remote sites are in sync with local site)
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw03656 | Title: | Error Message for EP that didn't make it in exporting to remote site |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Currently information is distributed between two diff site APIC devices. Causing increased number of troubleshooting steps before finding which two EP/EPG/AP/Tenant have an issue.
Conditions:
Information on both site APIC/Border Leaf Switches/Leaf Switches needed to troubleshoot connectivity between local and remote site EP.
Workaround:
Manually navigate on APIC GUI or visore to troubleshoot
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu94860 | Title: | APIC GUI - Reword subnet scope checkboxes |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The meaning and function of subnet checkboxes are unclear from the wording.
Conditions:
When creating a subnet under and Endpoint Group or Bridge Domain.
Workaround:
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: * | 1.2(0.86a), 1.2(0.89) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw10958 | Title: | Add Firmware auto-upgrade feature to APIC |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Customer would like a "hands off" approach to upgrades to make it easier to manage,
Conditions:
n/a
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 1.1(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw11384 | Title: | simulator initial setup script output should also redirect to ttyS0 |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The console for the APIC simulator does not redirect the Input/Output for the APIC consoles to ttyS0.
Conditions:
This occurs on all versions of the hardware simulator.
Workaround:
Use KVM to setup and manage the APIC simulator.
Further Problem Description:
N/A
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 1.2(0.83) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur81749 | Title: | Need one arm service graph ADC profile for F5 |
|
Status: * | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
An ACI fabric running 1.0.2j only includes service graph profiles for two-armed F5 environments. A profile for one-armed environments is also needed.
Conditions:
Workaround:
Create service graph with custom profile.
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 1.0(2j) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw12551 | Title: | Enhancement to allow for health score to ignore acknowledged faults |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
health score is degraded but the faults aren't actual issues in their environment.
Conditions:
faults are thrown but they can safely be ignored.
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 1.1(2h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu18737 | Title: | "ip http source-interface" is shown twice in config |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The "ip http source-interface" command is shown twice in both running and startup config.
Conditions:
The "ip http source-interface" command is shown twice in both running and startup config.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I3(4) |
|
Known Fixed Releases: * | 6.1(2)I3(4a), 7.0(3)I1(2.4), 7.0(3)I1(3), 7.0(3)I2(0.455), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus49784 | Title: | enhancement request: support static end-pionts in Ctx scope |
|
Status: * | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
when LVS-DR solution is migrated to a L3 enabled BD, it introduce overlapped IP address, this confuse ACI IP learning.
Conditions:
LVS-DR uses overlapping IP address.
Workaround:
working in traditional mode. disable IP routing in ACI.
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 11.0(2m) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus92777 | Title: | N9K: linkUp/Down traps are not sent for PO sub Interfaces. |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
linkUp/linkDown/cielinkUp/cielinkDown traps are not sent Po subinterfaces
Conditions:
creating/shut/no shut of Po subinterface,
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I3(3.72) |
|
Known Fixed Releases: * | 7.0(3)I2(0.377), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.72) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu93214 | Title: | N3K/N9K: SNMP MIB for "show system switch-mode" CLI CMD Output |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Enhance CISCO-SYSTEM-EXT-MIB to add the following two objects to provide SNMP support for covering
"show system switch-mode" command output:
ciscoSystemSwitchingModeAdmin
ciscoSystemSwitchingModeOper
This enhancement (both CLI and SNMP) is available in NXOS software release 7.0(3)I2(1) and all the later releases.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 7.0(3), 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(0.571), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul66684 | Title: | no option to configure for entire range of ports in the breakout module |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Need an easy way of configuring range of ports for breakout module.
Conditions:
configure for breakout 40gig to 10gig.
Workaround:
configure for range of ports in groups of 4 breakout ports
Further Problem Description:
|
|
Last Modified: | 13-SEP-2015 |
|
Known Affected Releases: | 6.1(2)I1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv87987 | Title: | N9K: Add Support for ARP ACL's in CoPP Policy |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
The Nexus 9000 NX-OS does not support the ability to configure ARP access-lists in the CoPP policy that enable a match on the source IP address.
Conditions:
This feature applies to the CoPP policy.
Workaround:
All ARP traffic can be policed in the CoPP policy (default). We can also match on MAC the L2 mac address using a MAC access-list. We just don't have the ability to match on the source IP address.
Further Problem Description:
|
|
Last Modified: | 13-SEP-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.94) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv36696 | Title: | CDP information is not shown by VCENTER for AVS though it is seen by VEM |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
CDP information is not visible in vCenter for vmnics assigned to an AVS switch. Normal DVS works fine for those vmnics.
Conditions:
AVS is installed.
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 13-SEP-2015 |
|
Known Affected Releases: | 1.2(0.92a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur38727 | Title: | Setup Utility Should Enforce Minimum TEP Address Range Size |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
This is an enhancement request to enforce a minimum TEP address range size in the APIC Setup Utility.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: * | 1.0(1k) |
|
Known Fixed Releases: | 1.0(3.34), 1.1(0.403), 1.1(1j) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw40457 | Title: | dhcp relay does not add mod/port to dhcp request |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The Nexus 9k as dhcp relay only adds the Circuit ID and Vlan sub option in Option 82, not the Port and Slot information.
Conditions:
The Nexus 9k is a configured as a dhcp relay
Workaround:
There is no workaround
Further Problem Description:
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I1(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw03643 | Title: | Re-sync EP based on certain Tenant/AP/EPG on demand |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Ability to refresh EP based on certain Tenant/AP/EPG on demand using command line without having a need to quit and restart launch the script
For example, After intersite script is completed and sitting at ?intersite> ? prompt (using the same running-config"
Intersite > refresh ???tenant ?scale1? ???ap ?compliance? ???epg ?prod? (Refresh EP per tenant/ap/epg)
Conditions:
Prevent New EP refresh on demand
Workaround:
quit the intersite.py and re-launch the script
Further Problem Description:
Ability to refresh EP based on certain Tenant/AP/EPG on demand using command line without having a need to quit and restart launch the script
For example, After intersite script is completed and sitting at ?intersite> ? prompt (using the same running-config"
Intersite > refresh ???tenant ?scale1? ???ap ?compliance? ???epg ?prod? (Refresh EP per tenant/ap/epg)
Intersite > refresh ???tenant ?scale1? ???ap ?compliance? (Refresh EP per tenant/ap ? Includes all EP under All EPG under this application profile)
Intersite > refresh ???tenant ?scale1? (Refresh EP per tenant ? Includes all EP per Tenant )
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 1.1(1r) |
|
Known Fixed Releases: | |
|
|
| |
:
2013 Cisco and/or its affiliates. All rights reserved. 
DumpsPass4Sure approach to 350-501 Exam is truly impressive. The rich material and seamless interface set a high standard. Regular updates demonstrate a commitment to excellence, making DumpsPass4Sure an impressive choice for mastering 350-501 Exam Questions.
回复删除