| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy96311 | Title: | IPFIB-2-FIB_ADJ_TABLE_FULL Log Created When FIB Table Isn't Full |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
This behavior will result in the below log message and the punting of all traffic to the CPU potentially crashing the device.
2012 Mar 15 14:55:59 hostname %IPFIB-2-FIB_ADJ_TABLE_FULL: FIB Adjacency table is full
Conditions:
When the same adjacency entry is added to the adjacency table, which consist of an software cache and an matching hardware entry. Two entries will be allocated in the software cache but only one will be added as an hardware entry. The repetition of this behavior will result in exhausting the software entry space of 64Kb were there will still be free space within the hardware adjacency table to create new entries.
This behavior isn't visible via the [sho ip fib adjacency] command as the output won't display a full table. To verify this issue the software/hardware adjacency table will need to be compared to each other. As these tables should be close to an 1-on-1 representation of each other.
show hardware internal libsdk mtc l3 sw-adj-tbl-cache valid-only | count ---->To view the software cache in which the table will become full at 65535 entries.
show hardware internal libsdk mtc l3 adj-tbl all valid-only | count ---->To view the hardware entry table.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: | 6.0(2)A6(2) |
|
Known Fixed Releases: * | 6.0(2)A6(5.253), 6.0(2)A6(6), 6.0(2)A8(0.344), 6.0(2)A8(0.346), 6.0(2)A8(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv54592 | Title: | Additional secondary IPv6 addresses removed on upgrade to Camden |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: * | Symptom:
In 6.X and previous NXOS versions the "secondary" keyword is required to add multiple IPv6 addresses to an interface as with the IPv4 behavior. In 7.X NXOS versions, the "secondary" keyword is no longer needed to match RFC. When upgrading from 6.X to 7.X code, the IPv6 secondary keywords will be removed correctly in order to maintain all IPv6 addresses configured on interfaces.
Conditions:
In 6.X and previous NXOS versions the "secondary" keyword is required to add multiple IPv6 addresses to an interface as with the IPv4 behavior. In 7.X NXOS versions, the "secondary" keyword is no longer needed to match RFC. When upgrading from 6.X to 7.X code, the IPv6 secondary keywords will be removed correctly in order to maintain all IPv6 addresses configured on interfaces.
Workaround:
In 6.X and previous NXOS versions the"secondary" keyword is required to configure multiple IPv6 address on an interface. Starting in 7.X NXOS code, the secondary keyword is no longer needed.
Further Problem Description:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(0.495) |
|
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), 8.3(0)CV(0.248), 8.3(0)KMS(0.31), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv33390 | Title: | MSDP timers should match (S,G) state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Currently in NX-OS, MSDP timers rely on the generation of Null-Registers on the RP to keep the SA state active. Even if the (S,G) expiry timer is increased and the source stops sending, the SA will eventually time out due to inactivity from the source as the Null-Registers will stop even though the (S,G) is still active.
Conditions:
This is the default behavior in NX-OS.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.0(2)A4(3) |
|
Known Fixed Releases: * | 6.0(2)A6(6), 6.0(2)A7(2), 6.0(2)A8(0.334), 6.0(2)A8(0.337), 6.0(2)A8(1), 6.0(2)U8(0.334), 6.0(2)U8(0.337), 6.0(2)U8(1), 7.0(3)F1(0.228), 7.0(3)I4(0.3) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw10613 | Title: | CAMDEN_GLDN:"neutron_usd " core is seen on QI with build 601 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus might crash due to neutron_usd process.
Conditions:
Neutron is the component which is using the USB for internal communication. The defect in the USB library might cause this issue.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(0.601), 7.0(3)I3(1), 7.0(3)IM3(1.40) |
|
Known Fixed Releases: | 7.0(3)I4(0.90), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz30306 | Title: | N3K: Crashed at Service "iftmc" after upgrade to dublin plus image |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
After upgraded to the latest nxos.7.0.3.I4.0.91.bin image on Paris, the crashed happened
copy core:2011 Jan 9 15:11:01 Paris %$ VDC-1 %$ %SYSMGR-SLOT1-2-SERVICE_CRASHED: Service "iftmc" (PID 15587) hasn't caught signal 11 (core will be saved).
2011 Jan 9 15:11:01 Paris %$ VDC-1 %$ %SYSMGR-SLOT1-2-HAP_FAILURE_SUP_RESET: Service "iftmc" in vdc 1 has had a hap failure
Conditions:
after the crash, the system start rebooting
here is the console for the system:
telnet 172.22.150.17 2033
Term server pass is "cisco"
currently running the last stable image: 7.0(3)IDP5(0.42)
Workaround:
reBoot to back to the previous image build 7.0(3)IDP5(0.42)
the system is stable now
Further Problem Description:
log file and core file in the attachment
Log and core file locates at:
/auto/cores/fjw/CSCuz30306
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.0(3)I4(0.91) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur04934 | Title: | Nexus 3000/3500 - Product evaluation for CVE-2014-6271 and CVE-2014-7169 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptoms:
This product includes Third-party Software that is affected by the
vulnerabilities identified by the following Common Vulnerability and
Exposures (CVE) IDs:
CVE-2012-3410
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 highest Base and Temporal CVSS scores of all vulnerabilities
tracked by this bug as of the time of evaluation are 4.6:
http://tools.cisco.com/security/center/cvssCalculator.x?version=2.0&vector=AV:L/AC:L/Au:N/C:P/I:P/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.
CVE ID CVE-2012-3410 have been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be
found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 06-APR-2016 |
|
Known Affected Releases: | 6.0(2)U4(1), 7.0(99.1)ZZ, 7.2(0.1)PR(0.1), 9.5(1)N1(7.8) |
|
Known Fixed Releases: | 5.0(3)U5(0.214), 5.0(3)U5(1j), 6.0(2)A3(3.80), 6.0(2)A3(3.82), 6.0(2)A3(4), 6.0(2)A4(1.21), 6.0(2)A4(2), 6.0(2)A5(0.918), 6.0(2)A5(0.920), 6.0(2)A5(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy69477 | Title: | Packet drops due to FCS-Err (CRC) for multicast traffic |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Between 2 Nexus 3500, multicast traffic which is switches from a source to the link between the 2 nexus 3500 may result in a very low amount of CRC error'ed frames being received by the receiving nexus 3500.
Conditions:
The issue has a lower frequency when non-port-channel interfaces are used.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 6.0(2)A6(2) |
|
Known Fixed Releases: * | 6.0(2)A6(4.2), 6.0(2)A6(4.3), 6.0(2)A6(5.253), 6.0(2)A6(6), 6.0(2)U6(4.2), 6.0(2)U6(4.3), 6.0(2)U6(6.253), 6.0(2)U6(7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy57375 | Title: | 10Gbase-SR SFPs not coming up on Nexus 3548-X |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
10Gbase-SR SFP transceivers might become stuck in "link not connected" state on Nexus 3500-X devices;
At the same time the affected interfaces do recognize that the transceivers are installed, and even a good Rx/Tx power signal could be seen in "show interface transceiver detail" outputs;
This issue could be seen only on N3500-X devices, non-X N3500 devices are not affected;
Conditions:
The issue could be seen on N3500-X devices running NX-OS versions 6.0(2)A6(5a) and 6.0(2)A7(2)
Workaround:
Downgrade to the unaffected 6.0(2)A6(4a)
Further Problem Description:
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.0(2)A6(5), 6.0(2)A7(2) |
|
Known Fixed Releases: * | 6.0(2)A6(4.2), 6.0(2)A6(5.246), 6.0(2)A6(5a), 6.0(2)A6(6), 6.0(2)A7(1.64), 6.0(2)A7(2a), 6.0(2)A8(0.337), 6.0(2)A8(1), 6.0(2)U6(4.2), 6.0(2)U6(5a) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz10567 | Title: | Nexus 3000 - GLC-T comes online only on 100m |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
GLC-T SFP inserted into N3K-C3064PQ-10GX doesn't come up with speed set auto/1000
Conditions:
unknown
Workaround:
unknown
Further Problem Description:
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.0(2)U6(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy38921 | Title: | Evaluation of nexus-3000 for glibc_feb_2016 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco Nexus 3016 series switches
Cisco Nexus 3048 series switches
Cisco Nexus 3064 series switches
Cisco Nexus 3132 series switches
Cisco Nexus 3172 series switches
may includes a version of glibc that is affected by the vulnerability identified by one or more of the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-7547
And disclosed in http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160218-glibc
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent.
Affected devices running a version of NX-OS software numbered as 6.0(2)Ux(x) or 5.0(3)Ux(x) are NOT affected by this vulnerability.
Devices running a version of NX-OS labeled 7.0(3)I2(x) or 7.0(3)I3(1) prior to the first fixed version are affected.
Cisco has reviewed and concluded that this product is affected by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-7547
Workaround:
Not available.
Further Problem Description:
Nexus 3000 is not affected in any release based off of 5.0(3)Ux(x) or 6.0(2)Ux(x) as these releases are on GLIBC version 2.8 which is not affected.
Nexus 3000 running unified code with Nexus 9000 7.0(3)I2(x) is affected and the fix for CSCuy36553 provides the fix for Nexus 3000 also in these releases.
There are SMU patches for these releases that have been published for both Nexus 3000 and Nexus 9000.
For more details on the SMU patches, refer to SMU release notes at:
7.0(3)I2(2a)
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/release/notes/70322a_patch_nxos_rn.html
7.0(3)I2(2b)
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/release/notes/70322b_patch_nxos_rn.html
Additional details about those vulnerabilities can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 10.0/9.5
http://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:U/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2a), 7.0(3)I2(2b), 7.0(3)I3(1) |
|
Known Fixed Releases: * | 7.0(3)I2(2b), 7.0(3)I2(2c), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum55820 | Title: | Nexus 3172 Not Creating Any S,G Entries |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus 3172 not creating any S,G entries.
Conditions:
Multicast routing is configured on the device. Device is both a first-hop router for multicast sources, in addition to having attached receivers.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: * | 6.0(2)U2(1), 7.0(3)I4(0.86) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz09640 | Title: | ERSPAN-Source with header-type 3 stops working after interface flap |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Captured traffic is no longer received on the ERSPAN destination device after an interface flaps on the ERSPAN source Nexus 3500 switch.
Conditions:
ERSPAN-Source session configured with header-type 3 and IP reachability to the ERSPAN destination is done using a non-default VRF on a Nexus 3500 switch.
The flapping interface has to be part of the interfaces configured in the monitor session.
Workaround:
Shut/no shut on the ERSPAN-Source session can be used to temporary recover from this issue.
Further Problem Description:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: | 6.0(2)A7(2) |
|
Known Fixed Releases: * | 6.0(2)A6(5.253), 6.0(2)A6(6), 6.0(2)A8(0.360), 6.0(2)A8(1), 6.0(2)U6(6.253), 6.0(2)U6(7), 6.0(2)U8(0.360), 6.0(2)U8(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy92412 | Title: | N3500 crashed during Regex configuration. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After regex configuration changes switch crashed with "vshd hap reset".
Conditions:
Regex configuration changes.
Workaround:
Not using regular expressions.
Further Problem Description:
n/a
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: | 6.0(2)A7(2) |
|
Known Fixed Releases: * | 6.0(2)A6(5.253), 6.0(2)A6(6), 6.0(2)A8(0.343), 6.0(2)A8(1), 6.0(2)U6(6.253), 6.0(2)U6(7), 6.0(2)U8(0.343), 6.0(2)U8(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy64495 | Title: | N3K // RBAC | Json // fail |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
error when logging with a role that is limited to " | json"
/isan/bin/nxpython: can't open file '/isan/bin/pipejson': [Errno 13] Permission denied
Conditions:
N3K with roles configured with | json. and login to the switch using this role
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: | 6.0(2)U6(5) |
|
Known Fixed Releases: * | 6.0(2)A6(5.253), 6.0(2)A6(6), 6.0(2)U6(6.253), 6.0(2)U6(7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz00736 | Title: | netconf get for "show boot" fetches no output |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
netconf get for "show boot" fetches no output
Conditions:
netconf get for "show boot"
affects all pre-camden codes.
Workaround:
use scripts to manually collect "show boot" output.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.0(2)U6(6) |
|
Known Fixed Releases: * | 6.0(2)A6(5.253), 6.0(2)A6(5.254), 6.0(2)A6(6), 6.0(2)A8(0.352), 6.0(2)A8(0.353), 6.0(2)A8(1), 6.0(2)U6(6.253), 6.0(2)U6(6.254), 6.0(2)U6(7), 6.0(2)U8(0.352) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv59159 | Title: | LLDP DCBX TLV disable does not move interface to operational OFF state |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Using "no lldp tlv-select dcbxp" on interfaces that are operational ON for PFC will only result in one side going to operational OFF while other side stays operational ON
Conditions:
Workaround:
Force mode to OFF instead of AUTO at interface level on both ends
Further Problem Description:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: | 6.0(2)U3(7.99) |
|
Known Fixed Releases: * | 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut95639 | Title: | Adding basic show commands to feature show techs (N3K) |
|
Status: | Open |
|
Severity: * | 3 Moderate |
Description: | Symptom:
some commands are missing in feature show tech which causes BDB/BORG data analysis automation to fail
Conditions:
all
Workaround:
na
Further Problem Description:
|
|
Last Modified: | 18-APR-2016 |
|
Known Affected Releases: | 6.0(2)U6(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy61171 | Title: | N3000 routing hash does not work with SVI in-interface option |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Keyword "in-interface" is not really required for n3000 and n3100 to provide routing hash result.
Symptom:
"show routing hash" command could result in error message on T2/T+ N3000 platforms when in-interface option is provided.
Conditions:
"show routing hash" used with "in-interface" option on T2/T+ based N3000 platforms.
Workaround:
Skip the "in-interface" option in "show routing hash" command.
Further Problem Description:
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(1) |
|
Known Fixed Releases: * | 7.0(3)I4(0.80), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue68402 | Title: | QOS:Incorrect MTU in show queuing int after changing network-qos |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Changing other parameters in network-qos class-map, MTU gets changed.
Conditions:
This issue happens when other parameters are changed in a network-qos class-map
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 6.0(2)U1(1) |
|
Known Fixed Releases: * | 6.0(2)U3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux02122 | Title: | Loss of control plane with high Memory utilization on 3k - no core |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Memory utilization increased from 62% to 78% over the last 3-months. The memory is leaking in the FWM process:
Nexus# show process memory
PID MemAlloc MemLimit StkSize RSSMem LibMem StackBase/Ptr Process
----- -------- ---------- ------- ------- ------- ------------- ---------
.
.
3380 421928960 931326668 86016 458145792 78491648 ffbab540/ffffffff fwm
In the example above we see the RSSMEM (holding memory) for the fwm process is at 458145792. Looking in more detail, we find that the memory is being held by FWM_MEM_fwm_temp_t:
Nexus# show platform fwm mem-stats detail
.
.
Private Mem stats for UUID : Forwarding manager Daemon(652) Max types: 371
--------------------------------------------------------------------------------
TYPE NAME ALLOCS BYTES
CURR MAX CURR MAX
41 FWM_MEM_fwm_temp_t 1560000 1560002 299520000 299524016
When memory got above 78% the switch became unresponsive. Initially SNMP access was lost. Then, L2 forwarding loop was observed. Nothing coming out of console serial port. Upon reload the switch came back fine.
Conditions:
When "show mac address-table" or "show mac address-table static" is executed,
Workaround:
Not to execute "show mac address-table" or "show mac address-table static"
Further Problem Description:
Each iteration was found to be leaking around 96KB of memory.
Issue not present in NXOS 7.x
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 6.0(2)U5(2) |
|
Known Fixed Releases: * | 6.0(2)A6(4.4), 6.0(2)A6(5.183), 6.0(2)A6(5a), 6.0(2)A6(6), 6.0(2)U6(4.183), 6.0(2)U6(4.4), 6.0(2)U6(5), 6.0(2)U6(5a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux02274 | Title: | N3172TQ - "no negotiation auto" fails to bring port in 100Mbps |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N3172TQ switch may fail to bring port UP with speed 100Mbps when Auto negotiation is disabled.
Conditions:
Enabled Auto-negotiation on N3100
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(1), 7.0(3)I3(0.75) |
|
Known Fixed Releases: * | 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts58414 | Title: | route-map removed from running-config when set community modified |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * |
Symptoms:
Configuring 'no community' in route-map results in removing the route-map from running configuration.
Conditions:
Always
Workaround:
Delete the route-map and re-configure the route-map.
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 5.0(3)U2(1) |
|
Known Fixed Releases: * | 5.0(3)U2(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf90234 | Title: | show tech ip pim is not included in show tech ip multicast |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show tech ip multicast or show tech multicast does not include show tech ip igmp snooping and show tech ip pim. It gives a syntax error
n3k2# show tech multicast | be "show tech-support ip pim"
Syntax error while parsing 'show tech-support ip igmp snoopingshow tech-support
ip pim'
`show tech-support routing ip multicast`
`show running-config routing ipv4 multicast`
!Command: show running-config routing ipv4 multicast
!Time: Thu Mar 28 17:02:24 2013
version 5.0(3)U5(1d)
`show ip mroute vrf all`
IP Multicast Routing Table for VRF "default"
(*, 232.0.0.0/8), uptime: 00:01:05, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
`show routing ip multicast vrf all bitfield`
IP Multicast Routing Table for VRF "default"
-------------------SNIP-----------------------------------------------
n3k2# show tech ip multicast | be "show tech-support ip pim"
Syntax error while parsing 'show tech-support ip igmp snoopingshow tech-support
ip pim'
`show tech-support routing ip multicast`
`show running-config routing ipv4 multicast`
!Command: show running-config routing ipv4 multicast
!Time: Thu Mar 28 17:06:37 2013
version 5.0(3)U5(1d)
`show ip mroute vrf all`
IP Multicast Routing Table for VRF "default"
(*, 232.0.0.0/8), uptime: 00:05:19, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
--------------------------------------SNIP--------------------------------------
Conditions:
Workaround:
Please get show techs ip pim and show tech ip igmp snoooping along with show tech ip multicast
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 5.0(3)U5(1d) |
|
Known Fixed Releases: * | 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy76055 | Title: | Upgrade from A1(1d) to IMR4 and deleting static nat rule fails |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:After the upgrade from A1(1d) to A6(5), some of nat-rules can't be deleted.
Conditions:there should be some nat-rules existing on device and upgrade should be done from A1(1d) to A6(5).
Workaround:1. do 'no feature nat'
2. and 'copy r s'
3. reload and reconfig new nat-configurations.
|
|
Last Modified: | 06-APR-2016 |
|
Known Affected Releases: | 6.0(2)A6(5) |
|
Known Fixed Releases: | 6.0(2)A6(5.252), 6.0(2)A6(6), 6.0(2)A8(0.337), 6.0(2)A8(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy90656 | Title: | Routes are not purged from rib after bgp table-map filter is applied |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
Routes are not removed from RIB after table-map filter is applied on BGP process
Conditions:
Add table-map filter on BGP
Workaround:
Clear ip route * will fix the issue. New routes learnt via BGP will go through the table-map as expected.
|
|
Last Modified: | 03-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux69836 | Title: | N3K: v6 RIP Neighborship doesn't come up over tunnel interface |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
RIPng neighborship won't come-up between peers when configured above Ipv4 tunnel.
Conditions:
When RIPv6 is configured above IPv4 tunnel.
Workaround:
Avoid using RIPng above IPv4 tunnel (Other IGRP protocol can be used such as EIGRP,OSPF,IBGP)
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.216) |
|
Known Fixed Releases: * | 7.0(3)I3(1.12), 7.0(3)I3(1.7), 7.0(3)I3(2), 7.0(3)I4(0.115), 7.0(3)I4(0.6), 7.0(3)I4(1), 7.0(3)IED5(0), 7.0(3)IED5(0.19) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub35279 | Title: | Netconf may crash upon receiving crafter payload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom
Crash in NX-OS NetConf Process
Symptom:
Conditions:
An authenticated session, sends a crafted NetConf Payload to the device.
Workaround:
None.
Further Problem Description:
After a NetConf process crash, if the NetConf client reconnects the NetConf agent will be restarted.
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.8:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:S/C:N/I:N/A:P/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2012-3942 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: | 01-APR-2016 |
|
Known Affected Releases: | 5.0(3)U5(1) |
|
Known Fixed Releases: * | 6.0(2)A8(0.345), 6.0(2)A8(1), 6.0(2)U8(0.345), 6.0(2)U8(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy03757 | Title: | Specific SNMP GET request causes 'snmpd' and 'licmgr' services to crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Cisco NX-OS Software-based devices contain a buffer overflow vulnerability in the SNMP subsystem.
An authenticated, remote attacker can exploit the vulnerability by submitting a malicious SNMP
query via UDP port 161 to trigger a buffer overflow condition in the SNMP and License Manager
components of the device. Successful exploitation could allow the attacker to execute arbitrary
code with elevated privileges.
SNMP is disabled by default and must be explicitly configured by an administrator. Because SNMP
is primarily a UDP-based protocol, no TCP three-way handshake is required to exploit this vulnerability,
and the malicious request could contain a spoofed origin. The attacker must know the configured
community strings for SNMP version 1 and version 2. Exploitation also requires a valid username
and password when a device is configured for SNMP version 3.
This vulnerability can be triggered via SNMP over IPv4 and SNMP over IPv6.
Conditions:
The NX-OS device is configured for SNMP.
Workaround:
The SNMP community string should be secure.
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 9/7.4:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:S/C:C/I:C/A:C/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2013-1179, CVE-2013-1180 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: | 01-APR-2016 |
|
Known Affected Releases: | 7.0(7)ZN(0.265) |
|
Known Fixed Releases: * | 6.0(2)A8(0.345), 6.0(2)A8(1), 6.0(2)U8(0.345), 6.0(2)U8(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz37102 | Title: | clock protocol ptp requirement for ptp operation |
|
Status: | Open |
|
Severity: * | 3 Moderate |
Description: | Symptom:
ptp corrections out of acceptable 2-3 digits range when "clock protocol ptp" is not configured.
Conditions:
Enable ptp on interfaces, without "clock protocol ptp".
Workaround:
Enable "clock protocol ptp" globally.
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 6.0(2)A7(0.10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz25317 | Title: | N3048 does not allow 10M speed interface configuration |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"speed 10" configuration is not available on RJ45 ports of Nexus 3048.
Conditions:
Always
Workaround:
"speed auto" advertises 10M, 100M and 1000M speeds. If the partner port support only 10M speed, it auto negotiate to 10M speed. However, there will be no option to force speed 10M on N3048.
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2c) |
|
Known Fixed Releases: | 7.0(3)I4(0.101), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy55754 | Title: | Nexus 3000 running 7.0(3)I2(2b) floods multicast traffic |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Nexus 3000 running 7.0(3)I2(2b). Multicast gets flooded to all ports on a vlan
Conditions:
this only occurs when the router with the host port does not have a (*,G) for the group
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2b) |
|
Known Fixed Releases: * | 7.0(3)I4(0.111), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz43841 | Title: | 100G transceiver links up in 10G if port is already in breakout mode |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
When the QSFP port is in 10g-4x breakout map mode with 100G transceiver inserted, the 4 member ports can sometimes detect false link up and sometimes flap continuously.
Conditions:
The issue will happen only when the port is first configured in 10g-4x mode and then 100G transceiver is plugged in. If the 100G transceiver is already present, then breakout to 10g-4x mode will not be allowed.
Workaround:
100G transceiver does not support 10g-4x breakout mode. Therefore, the unsupported configuration has to be reverted manually.
switch(config) # no interface breakout module 1 port 49 map 10g-4x
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.0(3)I4(0.109) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy40542 | Title: | DPLUS_N3K: Diff's on runn & startup with lldp configs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Previous releases showed difference between running configuration and startup configuration for LLDP, even after running configuration is saved to startup configuration. This issue is fixed now.
Symptom:
Display issue
Conditions:
When LLDP is configured
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.0(3)IDP3(1.135) |
|
Known Fixed Releases: | 7.0(3)IDP3(1.149), 7.0(3)IED5(0), 7.0(3)IED5(0.19) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz17880 | Title: | N3K/N9K IPv6 BFD echo does not work even enabled for ospfv3 Session |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
BFD IPv6 Sessions does not working in Echo mode, when BFD IPv6 Session end-point address is Link-local.
Conditions:
BFD IPv6 Sessions does not working in Echo mode, when BFD IPv6 Session end-point address is Link-local.
Issue seen for OSPFv3 BFD Sessions.
Issue seen even with "bfd echo-interface loopback" configuration.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(2b) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz40585 | Title: | Incorrect DSCP marking for ERSPAN packets |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Incorrect DSCP marking for ERSPAN packets
Conditions:
Setting DSCP for ERSPAN
Workaround:
use equivalent TOS values
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.0(2)U6(5) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut13672 | Title: | Disable LLFC CLIs on N3K platform |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | When the device was booted up with 'flowcontrol [receive on/ send on] " on some interfaces, some control protocols and data traffic wasnt flowing fine on the ports, the solution was to remove the "flowcontrol send on" or "flowcontrol receive on"
Symptom:Some control protocols like ARP and data traffic does not flow on some of the ports in the system.
Conditions:When device is booted up with "flowcontrol receive on"/"flowcontrol send on"" on some interfaces, some control protocols like ARP and data traffic doesn't flow fine on these ports
Workaround:remove "flowcontrol send on"/"flowcontrol receive on" CLI on these interafces.
option 1)
configure dummy policy and remove it.
policy-map type queuing XXX
class type queuing class-default
bandwitdh percent 100
queue-limit dynamic 7
system qos
service-policy type queueing output xxx
no service-policy type queueing output xxx
Or
option 2)
Remove the config line and reload the switch.
More Info:When the device was booted up with 'flowcontrol [receive on/ send on] " on some interfaces, some control protocols and data traffic wasnt flowing fine on the ports, the solution was to remove the "flowcontrol send on" or "flowcontrol receive on"
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.0(2)U5(1) |
|
Known Fixed Releases: | 6.0(2)U5(1.36), 6.0(2)U5(2), 6.0(2)U6(0.100), 6.0(2)U6(1), 7.0(3)I2(0.604), 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.37) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz43747 | Title: | "interface breakout module 1" cli stops at first 100G port |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
"interface breakout module 1" cli command does not breakout all 40G ports if there are any 100G transceivers present
Conditions:
This issue will be seen when we have a mix of 40G and 100G transceivers present in QSFP ports.
For example, let us assume port 49, 50 and 52 has 40G transceivers, and port 51 has 100G transceiver.
"interface breakout module 1" command does breakout successfully on ports 49 and 50. But it will fail on port 51 and the command stops without breaking out port 52.
Workaround:
An easy workaround is to apply "interface breakout" for each port individually, like,
switch(config)# interface breakout module 1 port 49 map 10g-4x
switch(config)# interface breakout module 1 port 50 map 10g-4x
switch(config)# interface breakout module 1 port 52 map 10g-4x
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.0(3)I4(0.109) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz27398 | Title: | "show lldp neighbor details" doesn't list all neighbors |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
"show lldp neighbor details" doesn't list all neighbors
Conditions:
Exact trigger not known. When cusotmer performed this validation this behavior is noticed on nodes running 6.0(2)U5(2).
Workaround:
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 6.0(2)U5(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz14818 | Title: | Allow breakout of 3264Q to 4x10G instead of 2x10G |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
This enhancement request is filed to allow break out of 3264Q ports to 4x10GB until the 128 port maximum is hit.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 12-APR-2016 |
|
Known Affected Releases: | 7.0(3)EV(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuq21095 | Title: | Akamai: Camden 2.4 N3000 need to support snmp dot1qTpFdbTable |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
snmpwalk on dot1qTpFdbTable returns error
SNMPv2-SMI::mib-2.17.7.1.2.2 = No Such Object available on this agent at this OID
Conditions:
snmpwalk on dot1qTpFdbTable
Workaround:
No workaround
Further Problem Description:
dot1qTpFdbTable does not seem to be currently supported.
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 6.0(2)U4(0.841) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz23076 | Title: | HSRP holdtimer doesn't reset upon receiving HSRP hello |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
Conditions:
HSRP running between N3548
Workaround:
none
Further Problem Description:
HSRP command " show hsrp interface " displays incorrect expiry value for HSRP peer due to which user will think that HSRP is going to flap.
Example
if we have HSRP timers configured to 4 and 1.
show hsrp interface command will show that PEER is sending a HSRP hello within 3-3.5 seconds.
The expiry timer even goes to 0.757000 seconds.
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.0(2)A6(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv97195 | Title: | n3048 : cannot boot tftp or boot usb from loader prompt |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
1. The n30xx platform fails to boot tftp: from the loader prompt unless a reboot command is executed from the loader prompt first.
2. The usb device is not recognized from the loader prompt.
Conditions:Normal conditions.
Workaround:1. Execute the reboot command from the loader prompt prior to the tftp. When the reboot completes and execution returns to the loader prompt, the boot tftp: command will be successful.
|
|
Last Modified: | 24-APR-2016 |
|
Known Affected Releases: | 7.0(3)I2(0.585) |
|
Known Fixed Releases: | |
|
|
| |
没有评论:
发表评论