| |
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: | 01-JUL-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.307) |
|
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: | 01-JUL-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: | 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: | 01-JUL-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)ES(0.18), 7.1(0)IB(120) |
|
|
| |
| |
Bug Id: | CSCut77413 |
Title: | APRIL 2015 NTPd Vulnerabilities |
|
Description: |
Symptom:This product includes a version of ntpd that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-1798 and CVE-2015-1799
Conditions:Device configured with NTP and NTP Key authentication.
ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234
ntp peer 1.2.3.4 key 1234
Affected version: 7.0(3)I1(1)
Fixed version: 7.0(3)I1(2) estimated CCO date 4/30/2015
Workaround:Not available.
More Info:PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 4.3/3.2
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:P/A:N/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: | 02-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(3a) |
|
Known Fixed Releases: | 7.0(3)I1(1.211), 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)ITI2(1), 7.0(3)ITI2(1.6), 7.0(3)IX1(1.93), 7.0(3)IX1(2), 8.3(0)CV(0.72) |
|
|
| |
| |
Bug Id: | CSCut07151 |
Title: | VxLAN EVPN DHCP Offer not sent to client |
|
Description: | Symptom:
DHCP fails when client and server are on VXLAN VRF
Conditions:
Client is connected to a leaf switch and the DHCP server is connected to another switch (VTEP) in the topology.
Issue is not seen when client and server is on the same switch.
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 7.0(3)I1(0.269), 7.0(3)I1(1) |
|
Known Fixed Releases: | 7.0(3)I1(1a), 8.3(0)CV(0.72) |
|
|
| |
| |
Bug Id: | CSCuu83343 |
Title: | Evaluation of fabric-apic 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.
Workaround:
Not available.
More Info:
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: | 07-JUL-2015 |
|
Known Affected Releases: | 1.0(4j) |
|
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: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.3) |
|
Known Fixed Releases: | 6.1(2)I3(4b), 7.0(3)I2(0.381), 7.0(3)I2(1), 8.3(0)CV(0.72) |
|
|
| |
| |
Bug Id: | CSCuu36916 |
Title: | ACI : ARP storm on l3out blocks ARP reponses to infra pool |
|
Description: | Symptoms:
The iStack does not provide adequately process a large volume of ARP messages and puts the processing to the CPU. This can cause the system to
appear to become unresponsive during an ARP-storm. The system will recover when the ARP-storm passes.
<B>Symptom:</B>
APIC unable to resolve ARP requests when there are a large number of ARP messages.
<B>Conditions:</B>
A large number of ARP messages must be present on the VLAN.
<B>Workaround:</B>
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 3.3/2.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 11.0(3f), 11.0(4) |
|
Known Fixed Releases: | 1.1(0.902a), 1.1(0.904), 1.1(1j), 1.1(2.24), 11.1(0.220) |
|
|
| |
| |
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: | 10-JUL-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)DEV1(1), 7.0(3)DEV1(1.5), 7.0(3)I2(0.424), 7.0(3)I2(1) |
|
|
| |
| |
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: | 10-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(1.53) |
|
Known Fixed Releases: | 7.0(3)DEV1(1), 7.0(3)DEV1(1.5), 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) |
|
|
| |
| |
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: | 10-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I1(3.4) |
|
Known Fixed Releases: | 7.0(3)DEV1(1), 7.0(3)DEV1(1.5), 7.0(3)I2(0.428), 7.0(3)I2(1) |
|
|
| |
| |
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: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-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)I2(0.439), 7.0(3)I2(0.449), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCuu21167 |
Title: | Policymgr is non-responsive for any new policy update after upgrade |
|
Description: | Symptom:
Policymgr is non-responsive for any new policy update and times out with error after upgrade from a prior version to 104h
Conditions:
vnsRsLIfCtxToBD (Device selection policy) relation from non-common tenant pointing to Bridge Domain (BD) in tenant common was created in a lower version and Policy-based upgrade was done from lower version to 104h
Workaround:
Please run the script cleanupRsLIfCtxToBD.py "after upgrade" by pointing it at your APIC ip address. Script can be obtained from AS folks or attached to this bug. To run the command you will need to set the PYTHONPATH pointing to egg files of the specific version. You will need python 2.7
PYTHONPATH=/tmp/867h/acicobra-1.1_0.867h-py2.7.egg:/tmp/867h/acimodel-1.1_0.867h-py2.7.egg /opt/cisco/aci/python2.7/bin/python cleanupRsLIfCtxToBD.py -H -P 443 -u admin -p -S
This script will delete and readd all the vnsRsLIfCtxToBD relations in your system. GraphInst might go to fault state and recover but no traffic disruption is expected.
After running the script, monitor the CPU utilization of PolicyMgr process to ensure it doesn't stay at a high value for sustained period of time.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 1.0(4) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCus83690 |
Title: | NTP prov config not getting pushed after leaf stateful reload 145a image |
|
Description: | Symptom:
NTP provider configuration may get removed from switch after stateful reload
Conditions:
This can happen after a switch reboot
Workaround:
Disassociate / reassociate the pod group to the date time policy.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 11.1(0.145) |
|
Known Fixed Releases: | 1.0(3.34), 1.1(0.668), 1.1(1j), 1.2(0.1), 2.0(0.2) |
|
|
| |
| |
Bug Id: | CSCut56623 |
Title: | When dscp is set at l3Out level, it is not pushed to the rules |
|
Description: | Symptom:
When a Layer 3 external network is configured with DSCP marking, it is not copied to a filter rule on the node.
Conditions:
Configure Dscp marking is l3Out level.
Workaround:
To work around the issue configure dscp marking at l3Out instance (l3extInstP)
Further Problem Description:
NA
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.766d) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCut30212 |
Title: | Config Import: "All requests to shard 4 timed out" policymgr crash |
|
Description: | Symptom:
When doing a config import, you will see parts of the import work, but it will overall never finish. In the Operational tab of the import, the process will continuously run until it spits out the error:
"All requests to shard 4 timed out"
Conditions:
config import on 1.1 in listed versions
Workaround:
Need to downgrade to get import to work or upgrade to fixed release
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.726c), 1.1(0.735b) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCut56639 |
Title: | dscp marking not happening for AEpg to l3instP rule |
|
Description: | Symptom:
When dscp marking is configured on external Epg, it is not copied to filter rule on node.
Conditions:
Configure external Epg with dscp marking.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.766d) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.867b), 1.1(0.872a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.750a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.706a), 1.1(0.766m) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.0(3i) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCuu40110 |
Title: | Fex not coming up with fabric L2 mtu size change |
|
Description: | Symptom:
FEX not coming up.
Conditions:
Fabric MTU is set below 1500.
Workaround:
Don't set fabric MTU below 1500.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.890a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.0(3f), 1.1(0.694a) |
|
Known Fixed Releases: | 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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.784) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.912a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.766j) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.0(4l), 1.1(0.839a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.0(3f) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCut62151 |
Title: | After delete, re-add config subnets are not leaked into Cons VRF |
|
Description: | Symptom:
The consumer endpoint group in one private network (fvCtx) is not able to communicate with service node in another private network (fvCtx) after deleting and re-adding the service graph from the contract.
Conditions:
The communication of the consumer endpoint group and the service node across the private networks requires route leaking the service node subnet to the consumer VRF. When deleting then re-adding the graph to the contract, the route leaking does not occur, which causes communication failure.
Workaround:
On the Bridge Domain (fv::BD class) attached with the graph, flap the "unicastRoute" property.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.766k) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.750d), 1.1(1j) |
|
Known Fixed Releases: | 1.2(0.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-JUL-2015 |
|
Known Affected Releases: | 1.0(3i), 1.1(0.737a) |
|
Known Fixed Releases: | 1.1 |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.768c) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-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.2(0.1), 2.0(0.2) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.696a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCuu05227 |
Title: | vxlan tunnels removed when ports are removed/added into pc config |
|
Description: | Symptom:
VXLAN tunnels are removed when ports are removed/added into the PC configuration.
Conditions:
Workaround:
vem restart
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 1.0(3.46a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.902a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-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.2(0.1), 2.0(0.2) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 11.1(0.152) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.768c) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 1.0(4k), 1.1(0.878), 1.1(0.882a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-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.1(1j), 1.2(0.1), 2.0(0.2) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.945a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.0(2m), 1.1(0.747a) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-2015 |
|
Known Affected Releases: | 1.0(2m), 1.0(3f) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 13-JUL-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.2(0.1), 2.0(0.2) |
|
|
| |
| |
Bug Id: | CSCut25587 |
Title: | ifav41: pconsResolver stuck at shard20 on leaf164 |
|
Description: | Symptom:
None of the contracts are downloaded to leaf.
Conditions:
This issue can happen only during stateless reload of a leaf, when leaf is registering for policies from APIC, and is more likely to happen in a scale configuration.
On leaf pconsResolver objects (there are 32, one per shard) should have triggerSt property set to completed. If triggerSt has a value different than complete, this issue has been hit.
Workaround:
Stateless reload leaf.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.718c) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCut68368 |
Title: | Scale:Traffic not hitting the proper rule after del/re-add of contract |
|
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.
This bug is on top of original issue fixed under bug id CSCut25657.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 1.1(0.185) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCut68375 |
Title: | STP BLK and forward change when one of VPC peer is down |
|
Description: | Symptom:
When using a Nexus 9508 and vPC peer-links created on different modules, the STP status of the vPCs change to BLK and then FWD when one of the modules is shut down.
- Nexus 9508
N9K-1 ======= N9K-2
| |
----vpc----------
N9372
VPC peer-link : 1/35,1/36,2/35,2/36 on both N9Ks
With the above topology, if the customer shutdown module 2 in N9508#1, N9508#2's Po212 STP status is changed BLK and then remained as BLK.
> > Po212 Desg BLK 1 128.4307 (vPC) P2p
To recover this, partner tried to do following thing on N9508#1.
> > - no spanning-tree vlan 16
> > - spanning-tree vlan 16
Additionally, after recovering this issue, partner tried to do shutdown the slot2 in N9508#1 several times..
then the #2 chassis port-channel STP status was changed BLK and then FWD by itself in short.
Conditions:
- Version : n9000-dk9.7.0.3.I1.1.bin
- Hardware : cisco Nexus9000 C9508
- Nexus 9508
N9K-1 ======= N9K-2
| |
----vpc----------
N9372
VPC peer-link : 1/35,1/36,2/35,2/36 on both N9Ks
Workaround:
None
Further Problem Description:
N/A
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(2), 6.1(2)I3(4), 7.0(3)I1(1) |
|
Known Fixed Releases: | 6.1(2)I3(4.3), 6.1(2)I3(4a), 6.1(2)I3(5), 7.0(3)I1(1b) |
|
|
| |
| |
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: | 14-JUL-2015 |
|
Known Affected Releases: | 7.0(3)I1(1.168) |
|
Known Fixed Releases: | 7.0(3)I2(0.376), 7.0(3)I2(1), 8.3(0)CV(0.72) |
|
|
| |
| |
Bug Id: | CSCuu42733 |
Title: | APIC with different image in existing cluster causes inconsistent state |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 1.1(0.895a), 1.1(0.897a), 1.1(1.90a), 1.1(1j) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 16-JUL-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.8) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCuv34249 |
Title: | contract filters do not get deleted all the times |
|
Description: | Symptom:
There is traffic which should not be allowed between EPG's
Conditions:
Previously there was a filter to allow that traffic and that filter was removed from the contract
Workaround:
- Disassociating the contract that used to contain the filter and associate it again to the consumer and provider EPG resolves the issue.
- Touch clean and reboot the leaf also fixes the issue.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 16-JUL-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), 6.1(2)I3(4.4), 6.1(2)I3(5), 7.0(3)I1(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: | 17-JUL-2015 |
|
Known Affected Releases: | 1.1(1j) |
|
Known Fixed Releases: | 1.2(0.1) |
|
|
| |
| |
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: | 17-JUL-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: | 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: | 20-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I2(3), 7.0(3)I1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut85550 |
Title: | deletion of BD subnet did not deleted route on leafs |
|
Description: | Symptom:
The static route definitions are not deleted after removing a public subnet.
Checking "show ip route vrf all" | egrep "x.x.x.x" shows the subnet is present in the routing table of the leaves while a particular subnet has already been removed from the Bridge Domain.
Conditions:
This issue occurs only if the subnet is created as public.
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 1.0(3l), 1.1(0.766o) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 20-JUL-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: | CSCut49345 |
Title: | default route 0.0.0.0/0 failed to be programed into bcm T2 |
|
Description: | Symptom:
default route 0.0.0.0/0 failed to be prograde into Broadcom T2 chipset after isis flapping, which lead to all the traffic to outside ACI was droped.
Conditions:
This issue may happen when isis adjacency flapping between leaf and spine, routing information will be updated to T2 chipset but in some cases, the default route 0.0.0.0/0 will be failed to write into T2.
Workaround:
Disable all the ports that connected to this leaf from spine on GUI, then enable it. After routing information updated, default route will be programed properly.
Further Problem Description:
You will see below message from mnt/ifc/log/show_tech_info/show-tech-tor-lc.gz
4107743 378787. 03/19/2015 12:31:49.954: pt inserted v4 prefix 0.0.0.0/0 @0xc32fb578
4107744 378788. 03/19/2015 12:31:49.954: Req to create vobj with 1 paths
4107745 378789. 03/19/2015 12:31:49.954: Created vobj at 0xa135c38
4107746 378790. 03/19/2015 12:31:49.954: Allocd vobj dbel at 0xa0658c4 with hash 2000366087
4107747 378791. 03/19/2015 12:31:49.954: inserted vobj dbel at 0xa0658c4, hash 2000366087
4107748 378792. 03/19/2015 12:31:49.954: ufibpd_insert_vobj():154: Adding vobj
4107749 378793. 03/19/2015 12:31:49.954: ufib_platform_insert_vobj():548:[ERROR] failed to install vobj in hardware
4107750 378794. 03/19/2015 12:31:49.954: ufib_v4_bulk_v1_route_update():1324:[ERROR] add route failed for %s, error %s
4107751 378795. 03/19/2015 12:31:49.954: ufib_v4_bulk_v1_route_update():1326:[ERROR] 0.0.0.0/0
4107752 378796. 03/19/2015 12:31:49.954: ufib_v4_bulk_v1_route_update():1327:[ERROR] E_VOBJ_HW_INSTALL
4107753 378797. 03/19/2015 12:31:49.954: ufib_ufdm_v4_route_update():513:[ERROR] bulk route update failed, error:%s
4107754 378798. 03/19/2015 12:31:49.954: ufib_ufdm_v4_route_update():514:[ERROR] E_VOBJ_HW_INSTALL
But all the route information seems to be good when you show ip route vrf all on that leaf.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 11.0(2m) |
|
Known Fixed Releases: | 11.0(3k), 11.1(0.181) |
|
|
| |
| |
Bug Id: | CSCuv33239 |
Title: | Loose-node not created after receiving conflicting LLDP mgmt IPs |
|
Description: | Symptom:
Loose node is initially created, but quickly deleted on specific leaf node.
Conditions:
Following port-channel bringup, leaf node momentarily received conflicting LLDP mgmt IPs for links within a port-channel.
Workaround:
Shut / No shut of the affected port-channel.
Clear reload of switch
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 11.1(1j) |
|
Known Fixed Releases: | 1.1(1.114a), 1.1(1.119), 1.1(1n) |
|
|
| |
| |
Bug Id: | CSCur70425 |
Title: | CDP frames tagged with Vlan 1, default native vlan changed on trunk |
|
Description: | Symptom:
When changing the native vlan on a trunk port the peer device does not see the CDP neighbor anymore when configured as L3 port.
The issue can also be seen when configured in port channel between two devices. Issue is also seen on Nexus 7000 switch in 6.2.x based release.
Conditions:
Native vlan changed on a trunk port connecting to a Layer 3 port. The issue can be seen when connecting a Nexus device to another non-Nexus IOS device.
Workaround:
none
Further Problem Description:
Issue is about CDP packets are getting tagged with vlan tag of 1.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(1) |
|
Known Fixed Releases: | 7.0(3)I1(0.157), 7.0(3)I1(1) |
|
|
| |
| |
Bug Id: | CSCuv11991 |
Title: | Cisco Nexus 9000 Series ACI Mode Switch Access Control Vulnerability |
|
Description: | Summary
A vulnerability in the cluster management configuration of the Cisco Application Policy Infrastructure Controller (APIC) and the Cisco Nexus 9000
Series ACI Mode Switch could allow an authenticated, remote attacker to access the APIC as the root user.
The vulnerability is due to improper implementation of access controls in the APIC filesystem. An attacker could exploit this vulnerability by
accessing the cluster management configuration of the APIC. An exploit could allow the attacker to gain access to the APIC as the root user and
perform root-level commands.
Cisco has released software updates that address this vulnerability. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150722-apic
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 8.5/7.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:S/C:C/I:C/A:C/E:H/RL:OF/RC:C
CVE ID CVE-2015-4235 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: | 1 Catastrophic |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 11.0(1b), 11.0(1c), 11.0(1d), 11.0(2j), 11.0(2m), 11.0(3f), 11.0(3i), 11.0(3k), 11.0(3m), 11.0(4) |
|
Known Fixed Releases: | 11.0(4o), 11.1(1j) |
|
|
| |
| |
Bug Id: | CSCuu72094 |
Title: | Cisco APIC Access Control Vulnerability |
|
Description: | Summary
A vulnerability in the cluster management configuration of the Cisco Application Policy Infrastructure Controller (APIC) and the Cisco Nexus 9000
Series ACI Mode Switch could allow an authenticated, remote attacker to access the APIC as the root user.
The vulnerability is due to improper implementation of access controls in the APIC filesystem. An attacker could exploit this vulnerability by
accessing the cluster management configuration of the APIC. An exploit could allow the attacker to gain access to the APIC as the root user and
perform root-level commands.
Cisco has released software updates that address this vulnerability. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150722-apic
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 8.5/7.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:S/C:C/I:C/A:C/E:H/RL:OF/RC:C
CVE ID CVE-2015-4235 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: | 1 Catastrophic |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 1.0(1e), 1.0(1h), 1.0(1k), 1.0(1n), 1.0(2j), 1.0(2m), 1.0(2n), 1.0(3f), 1.0(3i), 1.0(3k) |
|
Known Fixed Releases: | 1.0(3o), 1.0(4o), 1.1(1j), 1.2(0.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: | 23-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(4a) |
|
Known Fixed Releases: | 6.1(2)I3(4b), 7.0(3)DEV1(1), 7.0(3)DEV1(1.5), 7.0(3)I2(0.435), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCuv46644 |
Title: | Enhancement: Need per filter DSCP marking on ACI Fabric |
|
Description: | Symptom:
Need ability to mark dscp value based in the traffic type (L4 port and protocol) on traffic.
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 11.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.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(4) |
|
Known Fixed Releases: | 7.0(3)I2(0.490), 7.0(3)I2(0.494), 7.0(3)I2(1) |
|
|
| |
| |
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: | 24-JUL-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.9) |
|
Known Fixed Releases: | 11.0(4k), 11.1(0.236) |
|
|
| |
| |
Bug Id: | CSCut77409 |
Title: | APRIL 2015 NTPd Vulnerabilities buildenv 1.30 |
|
Description: | Symptom:
This product includes a version of ntpd that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-1798 and CVE-2015-1799
This bug has been opened to address the potential impact on this product.
Conditions:
Using symmetric keys for the peers increases vulnerability.
Affected Versions
1.0(2m)
1.0(3k)
Expected Fixed Version
1.1(1)
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: 4.3/3.2
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:P/A:N/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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 1.0(3m) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv37825 |
Title: | arp packets looped back through vpc leg of peer when TCN |
|
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:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(4b), 7.0(3)I1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
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:
Avoid configurations that expose the vulnerabilities.
Exposure is possible with configurations using features nxapi, vmtracker, or onep; configuration using ldap or fabric database with enable-ssl options will also be exposed.
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: | 25-JUL-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), 8.3(0)CV(0.72) |
|
|
| |
| |
Bug Id: | CSCuv35406 |
Title: | Nexus 9300 does not learn MAC addresses on FEX HIF ports |
|
Description: | Symptom:
Nexus 9300 switches may not learn MAC addresses on FEX HIF ports
Conditions:
Nexus 9300 running 7.0(3)I1(2) with FEX attached.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: | 7.0(3)I1(2.4), 7.0(3)I1(3), 7.0(3)I2(0.487), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCuv48565 |
Title: | SSTE: Traffic drops post unshutting nve intf on the secondary vpc peer |
|
Description: | Symptom:
Traffic drop
Conditions:
shut / unshut of nve interface on the perational secondary vpc peer.
Workaround:
NA
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.486) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv24988 |
Title: | ACI contract missing for static path with ondemand policy via VPC in EPG |
|
Description: | Symptom:
Server has a VPC link to a couple of leaf, only one of leaf has the configured contract deployed, but the rules is not found from the other leaf when the problem happen. The configuration would work from beginning. The rule used to be programmed in both leaf but was incorrectly deleted from one VPC leg.
From the policyelement log, svc_ifc_policyelement.log for example.
4079||15-07-08 20:54:55.583+00:00||fv||DBG4||co=doer:0:0:0xf0e19:9,dn=uni/epp/fv-[uni/tn-TestTenant/ap-TestAppPro/epg-TestEPG]||No end-points left; unprogramming rules||../dme/svc/policyelem/src/gen/ifc/beh/imp/./fv/AREpPBI.cc
But if we issue "show system internal epm vlan EPG-ENCAPVLAN", there are active EP there.
Conditions:
The server connects to a couple of leaf switches via VPC.
The static path over the VPC is configured under the EPG which could be associated with physical domain or VMM domain.
The policy immediacy of the static path is set as "on demand"
Workaround:
Workaround:
1. If they can avoid policy download set to lazy on the EPG, then we wont have this issue.
2. Clear task on that vlan should trigger the delete of all eps. Or
3. Delete add of EPG would also work as a workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 11.1(1j) |
|
Known Fixed Releases: | 11.1(1.268), 11.2(0.28) |
|
|
| |
| |
Bug Id: | CSCus29812 |
Title: | binding entry got deleted for dhcp release through stp BLK port |
|
Description: | Symptom:
when interface is in stp block state and dhcp snoop is configured on the vlans of this interface, then dhcp pkts coming from that vlan cannot be blocked by STP, it will still be sent to dhcp process.
Conditions:
interface is in STP block state and one or some vlans on that interface is configured with dhcp snoop
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 7.0(3)I1(0.206) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu51335 |
Title: | 9464PX Ports 14 & 16 doesnt work with GLC-T Transcievers |
|
Description: | Symptom:
Link doesnt come up with Port 14 or Port 16 on 9464PX card with GLC-T Transceivers
Conditions:
9464PX card with GLC-T Transceivers on port 14 or port 16
Workaround:
Insert GLC-TC transceivers on port 13 and 15 and configure them to be same speed as that of what is desired for port 14 and port 16. Now, port 14/16 should start working.
Further Problem Description:
Disabling auto-neg through bcm-shell might bring up the link, but actual traffic doesnt go through. Not specific to 3.4 software version, even older software versions have the problem.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(4), 7.0(3)I1(1.251), 7.0(3)I2(0.333) |
|
Known Fixed Releases: | 6.1(2)I3(4b), 7.0(3)I1(2.4), 7.0(3)I1(3), 7.0(3)I2(0.346), 7.0(3)I2(1), 8.3(0)CV(0.72) |
|
|
| |
| |
Bug Id: | CSCus64597 |
Title: | STP core on BPDU guard enabled port flaps and Hap reset |
|
Description: | Symptom:
When a BPDU guard enabled port receives a BPDU the port is put to error disabled.
Under this condition a STP process core is seen and the box could reload due to hap reset,
if the condition is persistent
Conditions:
Workaround:
Disable BPDU guard
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(3) |
|
Known Fixed Releases: | 6.1(2)I3(3a), 7.0(3)I1(0.269), 7.0(3)I1(1), 7.0(3)I2(0.101), 7.0(3)I2(0.97T), 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: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-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) |
|
|
| |
| |
Bug Id: | CSCuv48602 |
Title: | SSTE: Routes not seen in the neighbors for 5 mins after Spine SSO |
|
Description: | Symptom:
Traffic drop after SSO
Conditions:
SSO
Workaround:
NA
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.486) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu97734 |
Title: | Flapping "reverse port filter" creates a stale rule |
|
Description: | Symptom:
Traffic is still allowed even though it is expected to be blocked
Conditions:
Flapping "reverse port filter" 3 or more times.
Workaround:
Non-disruptive workarounds:
1. Remove and re-apply the contract
2. Remove the filter association from the subject and re-apply
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 11.1(1j) |
|
Known Fixed Releases: | 1.1(1l), 1.2(0.1) |
|
|
| |
| |
Bug Id: | CSCuv46792 |
Title: | N9K - Loops DHCP Packet on Spanning-tree Blocked Port |
|
Description: | Symptom:
High cpu in dhcp_snoop and pktmgr
Excessive drops in the DHCP CoPP class
Control plane instability
Conditions:
N9K acting as DHCP Relay agent with a link in Spanning-tree Alternate Blocking State
Workaround:
Shut down the Alternate Blocking port or prune the vlan which the loop is occurring in from this interface
Further Problem Description:
This bug is tracking the looping of DHCP relayed packets on a Nexus 9000 on an interface that is in ALT BLK state for spanning-tree in the client VLAN.
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(2), 6.1(2)I3(4b), 7.0(3)I1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur49241 |
Title: | Buffer Boost ACL take Precidence over vPC redirect ACL |
|
Description: | Symptom:
L3 switched packets that need to cross a vPC peer-link will be dropped with the buffer boost feature enabled under certain circumstances.
Also Port-channel consistency will fail.
sh consistency-checker membership port-channels
Checks: Trunk group and trunk membership table.
Consistency Check: FAILED
Conditions:
Local interface of vPC is down. So traffic after L3 switch need to cross vPC peer link to remote vPC "UP" on peer.
Only for 9564TX/9564PX/9536PQ and TOR -N9K-C93128TX N9K-C9396PX
Workaround:
Disble buffer boost on for vPC which do not have "UP/Active" link
Core-9508-1(config)# int port-channel 101
Core-9508-1(config-if)# no buffer-boost
Core-9508-1(config-if)# end
sh port-ch sum
101 Po101(SD) Eth LACP Eth2/1(D) Eth3/1(D)
Note: Making changes in config for buffer-boost will bounce the interface.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I2(2b), 6.1(2)I3(1) |
|
Known Fixed Releases: | 6.1(2)I3(1.44), 6.1(2)I3(2), 6.1(2)I3(2.5), 6.1(2)I3(3) |
|
|
| |
| |
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: | 28-JUL-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: | CSCuv06108 |
Title: | %IPFIB-SLOT1-4-UFIB_ROUTE_CREATE: Unicast route create failed for VRF |
|
Description: | Symptom:
%IPFIB-SLOT1-4-UFIB_ROUTE_CREATE: Unicast route create failed for VRF message will be in syslog
Conditions:
As part of the above syslog following error should be seen:
Error: Internal error(-1)
Workaround:
To clear the condition reload of the specific slot reporting the error is necessary.
If it is a ToR, the ToR has to be reloaded.
Further Problem Description:
This is seen only on T2 instances operating in ALPM mode
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(4), 6.1(2)I3(4b) |
|
Known Fixed Releases: | 6.1(2)I3(4.6), 6.1(2)I3(4b), 6.1(2)I3(5), 7.0(3)I1(2.5), 7.0(3)I1(3), 7.0(3)I2(0.456), 7.0(3)I2(0.487), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCuv20065 |
Title: | EVPN External routing BGP EVPN OSPF redistribution fail on 7.0(3)I1(2) |
|
Description: | Symptom:
BGP Evpn redistribute into OSPF failed after upgrading to 7.0(3)I1(2)
Conditions:
7.0(3)I1(2)
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 7.0(3)I1(2z) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 29-JUL-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: | CSCut15554 |
Title: | TOR interface get stuck DIAG_PORT_LB-2-REWRITE_ENGINE_LOOPBACK_TEST_FAI |
|
Description: | Symptom:
%DIAG_PORT_LB-2-REWRITE_ENGINE_LOOPBACK_TEST_FAIL: Module:2 Test:RewriteEngine Loopback failed 10 consecutive times. Faulty module: Error:Loopback test failed. Packets lost on the SUP in the receive direction.
Switch will stop processing traffic.
Switch will declare him self as STP root even if it is not configured to be a root.
Conditions:
Certain 1Gig/10Gig interface stuck in Rx direction. Result of huge pause frames received from connected device.
Workaround:
Nexus9396X-1(config-if-range)# bcm module 1 "0:port xe TxPAUse=off RxPAUse=off"
Further Problem Description:
Even Diags are failing this is not a HW issue.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(2) |
|
Known Fixed Releases: | 7.0(3)I1(1.125), 7.0(3)I1(2) |
|
|
| |
| |
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: | 29-JUL-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: | 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:
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:
Avoid configurations that expose the vulnerabilities.
Exposure is possible with configurations using features nxapi, vmtracker, or onep; configuration using ldap or fabric database with enable-ssl options will also be exposed.
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: | 29-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(4a), 7.0(3)I1(2) |
|
Known Fixed Releases: | 7.0(3)DEV1(1), 7.0(3)DEV1(1.5), 7.0(3)I2(0.432), 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: | 30-JUL-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) |
|
|
| |
| |
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: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 11.0(4m) |
|
Known Fixed Releases: | 11.1(1.266) |
|
|
| |
| |
Bug Id: | CSCuv47053 |
Title: | N9K crashed due to Fatal Module Error, generated bcm_usd core |
|
Description: | Symptom:
Nexus 9000 may crash and generate a bcm_usd core. The reset-reason shows 'Reset Requested due to Fatal Module Error'.
----- reset reason for module 1 (from Supervisor in slot 1) ---
1) At 524536 usecs after Fri Jul 17 13:36:09 2015
Reason: Reset Requested due to Fatal Module Error
Service: System manager
Version: 6.1(2)I3(2)
NVRAM logs:
%KERN-2-SYSTEM_MSG: [11487991.904152] usd process 5947, uuid 779 (0x30b) failed to send heartbeat - kernel
%SYSMGR-SLOT1-2-SERVICE_CRASHED: Service "bcm_usd" (PID 5947) hasn't caught signal 6 (core will be saved).
%SYSMGR-SLOT1-2-LAST_CORE_BASIC_TRACE: fsm_action_become_offline: PID 4755 with message Could not turn off console logging on vdc 1 error: mts req-response with syslogd in vdc 1 failed (0xFFFFFFFF) .
%SYSMGR-SLOT1-2-LAST_CORE_BASIC_TRACE: core_client_main: PID 16522 with message filename = 0x102_bcm_usd_log.5947.tar.gz .
%MODULE-2-MOD_DIAG_FAIL: Module 1 (Serial number: XXXXXXXXXXX) reported failure due to Service on linecard had a hap-reset in device DEV_SYSMGR (device error 0x30b)
Conditions:
Not known
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.1(2)I3(2) |
|
Known Fixed Releases: | 6.1(2)I3(4.8), 6.1(2)I3(5) |
|
|
| |
| |
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-JUL-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)I1(2.5), 7.0(3)I1(3), 7.0(3)I2(0.350), 7.0(3)I2(1), 8.3(0)CV(0.72) |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论