| |
|
Alert Type: | Updated * |
Bug Id: | CSCux24542 | Title: | FCoE FLOGI from NPV switch gets LS_RJT due to solicit not done |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: * | Symptom:FCoE FLOGI from NPV switch gets LS_RJT due to FIP solicitation not done. The LS_RJT contains:
Reason Code: 0x09 - "Unable to perform command"
Reason Explanation: 0x29 - "Insufficient Resources for Login"
Conditions:Occurs when there is an FCoE NPV to NPIV link only.
Workaround:There are two known workarounds:
1 - Connect the devices involved into the NPIV switch itself.
2 - Change the NPV-NPIV link to a trunking connection where the port VSAN is a higher numbered VSAN than the VSAN being used by the devices. This should cause the NPV switch to choose that new higher numbered VSAN to do the FLOGI that brings the link up. Now the devices that FLOGI across that link using their VSAN without FLOGI failures.
More Info:The problem occurs when there are two (or more) devices logging into the NPIV switch from the NPV switch. Both devices do the FIP solicitation and get the FIP Advertisement. The first device successfully logs in and then logs out before the second device logs in. Now, the second device sends in its FLOGI and it gets rejected because the NPIV switch turned off the indication that the FIP solicitation was done.
Resolution Summary:
The code has been modified to not turn off the "FIP Solicitation done" indication on the NPIV switch when processing the LOGO if there are other devices FLOGI'd in on the same VSAN. If the connection between the NPV switch and NPIV core switch is carrying more than one VSAN(trunking), and there is at least one FLOGI on another VSAN when the LOGO occurs, then the NPV switch will initiate a FIP Solicitation. However, this is existing function and has been unmodified.
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 6.0(2)N1(2a), 7.0(7)N1(1) |
|
Known Fixed Releases: | 7.1(3)ZN(0.136), 7.1(4)N1(0.701), 7.1(4)N1(1), 7.2(2)N1(0.355), 7.2(2)N1(1), 7.2(2)ZN(0.39), 7.3(0)IZN(0.13), 7.3(0)N1(0.236), 7.3(0)N1(1), 7.3(0)ZN(0.213) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCut03484 | Title: | Kernel Panic - vaor.c:read_from_sysconf2: Read CMOS_POAP_CFG: 0 |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 5K/6K could reload due to a kernel panic
Conditions:
This has been seen on Nexus running 7.1(1)N1(1) and 7.0(6)N1(1)
Workaround:
Please refer to workaround for CSCuu37102
Further Problem Description:
|
|
Last Modified: | 03-MAY-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.97) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz85110 | Title: | vsh crashes @ create_snmpv3_user_after_aaa_authenticate |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Affected Nexus device must be managed by an automated system. The issue has been identified to arise when Data Center Network Management tool is used in particular.
Conditions:
Affected Nexus device must be managed by an automated system.
Workaround:
sable the automated management system operation on the affected Nexus device.
Further Problem Description:
N/A
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: * | 7.2(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo79180 | Title: | copy run start fails: Service "flogi" failed to store its configuration |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
A "copy run start" can fail with the following message:
2014 May 10 00:01:23 N5548UP SYSMGR-3-CFGWRITE_SRVTIMEOUT Service "flogi" failed to store its configuration in the timeout period
2014 May 10 00:01:23 N5548UP SYSMGR-2-CFGWRITE_ABORTED Configuration copy aborted.
2014 May 10 00:01:26 N5548UP SYSMGR-3-CFGWRITE_FAILED Configuration copy failed (error-id 0x401E0045).
Conditions:
N/A
Workaround:
Reload the switch
Further Problem Description:
All flogi related CLIs cannot execute. The mts buffers for fport_server process indicate a number of pending messages on its receive queue
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.296), 7.1(4)N1(0.830), 7.1(4)N1(1), 7.2(2)N1(0.438), 7.2(2)ZN(0.146), 7.3(1)N1(0.367), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux10337 | Title: | N2348TQ tiburon fex devices crash repeatedly |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
N2348TQ fex device resets unexpected.
Conditions:
No additional symptoms are known at this point in time.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 7.1(1)N1(1), 7.3(0)N1(0.46), 7.3(0)N1(0.47), 7.3(0)N1(0.50) |
|
Known Fixed Releases: * | 7.0(3)I2(2e), 7.0(7)ZN(0.266), 7.0(8)N1(0.313), 7.0(8)N1(1), 7.1(3)N1(2.3), 7.1(3)N1(3), 7.1(3)ZN(0.128), 7.1(4)N1(0.693), 7.1(4)N1(1), 7.2(2)N1(0.345) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz42053 | Title: | N5K Crash in ethpm Due to Memory Leak in libutils.so.0.0.0 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 5K may experience a crash in the ethpm process. This crash is cuased by a memory leak within this process. The reset reason will show the following:
Reason: Reset triggered due to HA policy of Reset
System version: 7.0(7)N1(1)
Service: ethpm hap reset
Conditions:
Unknown at this time.
Workaround:
Unknown at this time.
Further Problem Description:
|
|
Last Modified: | 30-MAY-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.295), 7.1(4)N1(0.829), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw53377 | Title: * | WCCP process crash |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
WCCP process crash when wccp appliance disconnected and core generated
Conditions:
when wccp appliance disconnected/ reconnected
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 26-MAY-2016 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)N1(0.307), 7.0(7)ZN(0.266), 7.0(8)N1(1), 7.1(3)ZN(0.115), 7.1(4)N1(0.689), 7.1(4)N1(1), 7.2(2)N1(0.339), 7.2(2)N1(1), 7.2(2)ZN(0.22), 7.3(0)IZN(0.13) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCus67475 | Title: | FCNS cores due to fcns hap reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
FCNS server process crashes unexpectedly
Conditions:
Whenever the corrupted fc frame is received by name server process during the registration process, the fcns process crashes.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 25-MAY-2016 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | 7.1(3)ZN(0.284), 7.1(4)N1(0.819), 7.1(4)N1(1), 7.2(2)N1(0.430), 7.2(2)N1(1), 7.2(2)ZN(0.138), 7.3(1)N1(0.358), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy03675 | Title: | Nexus crash in FCS process |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Crash on nexus device due to FCS process
Conditions:
Customer is using fabric channel.
Multiple IP addresses are sent as part of Platform registration request to FCS process on Nexus Switch from a HP Blade server.
Workaround:
There is no workaround as such , except to disable the Platform registration feature on the server.
Further Problem Description:
The trigger for this issue is that "Platform registration" was enabled on HP Blade server connected to N56K switches.
Multiple IP addresses sent from the server during platform registration , of which few were duplicate IP addresses , caused the crash.
This would impact the customers using N5K,N6K,N7K switches.
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 7.1(3)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.278), 7.1(4)N1(0.812), 7.1(4)N1(1), 7.3(1)N1(0.359), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz52401 | Title: | Evaluation of nexus-5000-all for OpenSSL May 2016 |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: |
Symptom:
This product includes a version of OpenSSL that is affected by the vulnerability identified by one or more of the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2016-2108 CVE-2016-2107 CVE-2016-2105 CVE-2016-2106 CVE-2016-2109 CVE-2016-2176
And disclosed in https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160504-openssl
This bug has been opened to address the potential impact on this product.
Cisco has analyzed the vulnerabilities and concluded that this product may be affected by the following vulnerabilities:
Memory corruption in the ASN.1 encoder CVE-2016-2108
Padding oracle in AES-NI CBC MAC check CVE-2016-2107
EVP_EncodeUpdate overflow CVE-2016-2105
EVP_EncryptUpdate overflow CVE-2016-2106
ASN.1 BIO excessive memory allocation CVE-2016-2109
This product is not affected by the following vulnerability:
EBCDIC overread CVE-2016-2176
Conditions:
Exposure is not configuration dependent.
Workaround:
None
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base CVSS score as of the time of evaluation is: 5.1
https://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:H/Au:N/C:P/I:P/A:P/E:ND/RL:ND/RC:ND
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
The score reflects the maximum score for all the vulnerabilities mentioned in this bug information
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: | 11-MAY-2016 |
|
Known Affected Releases: | 7.3(0)ZN(0.258) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv61110 | Title: | N5K/N6K: Errors when modifying vlan allowed list in port-profile on FEX |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a Nexus 5000 or 6000 Series Switch, modification to an existing vlan allowed list in a port-profile can cause other VLANs in that list to be briefly removed and reconfigured. In vPC deployments, the peer will show vlans were suspended with "Reason: Vlan is not configured on remote vPC interface." This is immediately followed by the vlans being removed from the suspended state and should not cause any packet loss.
Conditions:
When the vlan allowed list within a port-profile exceeds 80 characters (including all text in the command) and the port-profile is inherited by a FEX HIF on 7.x code.
Workaround:
Use vlan ranges (-) to ensure the command does not exceed 80 characters in the running config or manually apply the config to the FEX HIF instead of via port-profile.
Further Problem Description:
|
|
Last Modified: | 10-MAY-2016 |
|
Known Affected Releases: * | 7.0(5)N1(1), 7.0(7)N1(1), 7.1(1)N1(1), 7.1(3)N1(1), 7.2(0)N1(1) |
|
Known Fixed Releases: | 7.1(3)ZN(0.125), 7.1(4)N1(0.690), 7.1(4)N1(1), 7.2(2)N1(0.347), 7.2(2)N1(1), 7.2(2)ZN(0.30) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz59603 | Title: | 'switchport trunk allowed vlan add' command causes VFC interface flaps |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptom:The 'switchport trunk allowed vlan add' command causes VFC interface flaps.
Conditions:An issue seen when the configuration changes done by using a Port-profile.
Workaround:Don't use the Port-Profile feature to configure Ethernet interfaces.
More Info:
|
|
Last Modified: | 10-MAY-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux72134 | Title: * | Vlan not getting programmed as vn-seg capable |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
dot1q based auto-config doesn't work after bootup or reload of the switch with "system fabric global-mobility-domain detectable-vlans " configured.
Conditions:
"system fabric global-mobility-domain detectable-vlans " configured on the switch
Workaround:
Remove the configure "no system fabric global-mobility-domain detectable-vlans " then add it back using "system fabric global-mobility-domain detectable-vlans "
Further Problem Description:
dot1q based auto-config doesn't work after bootup or reload of the switch with "system fabric global-mobility-domain detectable-vlans " configured.
It doesn't work as xlate-vlan-table is not getting populated for vlan entries and causing no auto-detection of these VLANs.
Please use following command to check the xlate-vlan-table.
show platform fwm info xlate-vlan-table 0 vlan-id
For example for vlan 100 it should contain the following entry which is missing during problem state.
statefarmleaf# show platform fwm info xlate-vlan-table 0 vlan-id 100
Number of xlate containers pending PSS: 0
Dir Xlate-idx Key-vlan Res-vlan Ref-count Masked Location is_l2_if
Eg 5 103 100 1 no 2.1772.0 1
Ig 5 100 103 1 no 2.3745.0 1
|
|
Last Modified: | 05-MAY-2016 |
|
Known Affected Releases: | 7.1(1)ZN(91.99) |
|
Known Fixed Releases: | 7.1(3)N1(4), 7.1(3)ZN(0.180), 7.1(4)N1(0.728), 7.1(4)N1(1), 7.3(1)N1(0.34), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz40720 | Title: | Crash with L2MP and ECMP configured |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
A crash loop is seen. The FWM process crashes causing a hap-reset
Conditions:
This issue happens when the CRC8g polynomial hash is used for load-balance:
port-channel load-balance ethernet source-dest-port CRC8g
Workaround:
Using a polynomial hash other than CRC8g will prevent the issue. Currently the available hash types are CRC8a through CRC8h.
Removing the config completely will revert back to the default which is source-destination-mac using CRC8a as the polynomial hash. So using default will prevent the issue as well.
Further Problem Description:
|
|
Last Modified: | 05-MAY-2016 |
|
Known Affected Releases: | 7.0(6)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw24856 | Title: | N5K vsh core on "show run" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Nexus 5000 VSH process crashed when performing a 'show run'
Conditions:
This issue was first seen on an N5k running 7.1(1)N1(1)
Workaround:
Unknown at this time.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.293), 7.1(4)N1(0.827), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz80290 | Title: | N5K Syslog suspend timer not recovering if logs generated continously |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Sending logs to Syslog server may fail if continuous messages are being generated. This is caused by a forwarding suspension timer which resets on every log being generated.
Conditions:
Nexus 5k running any release before 7.x.
Seems that increasing logging levels too much (above level 4-5) can trigger this suspend timer problem.
Workaround:
Take care of existing conditions that keep generating continuous messages. If the messages are not generated for at least 30 seconds, the system will recover.
Further Problem Description:
|
|
Last Modified: | 29-MAY-2016 |
|
Known Affected Releases: | 5.2(1)N1(9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy91379 | Title: | Nexus 5K crash at dleft_sprint_table_info |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N5596 crash while running show platform fwm info dleft-table lif-vlan-mbr command
Conditions:
This has been seen on nexus 5K platform running 7.0(6)N1(1)
Workaround:
None at this time
Further Problem Description:
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 7.0(6)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.269), 7.1(4)N1(0.803), 7.1(4)N1(1), 7.2(2)N1(0.419), 7.2(2)N1(1), 7.2(2)ZN(0.127), 7.3(1)N1(0.329), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud78818 | Title: | Emulex CNA can not flogi to N5K/N4k combination,qlogic works fine |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Emulex CNA in a ibm blade center will not connect to a N4K/N5K with fcoe
Conditions:
Workaround:
Use a qlogic cna
Further Problem Description:
|
|
Last Modified: | 05-MAY-2016 |
|
Known Affected Releases: | 5.2(1)N1(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu78140 | Title: | Mem Leaks in VLAN MGR after vlan create deletes |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Creating and deleting VLAN in a range multiple times may leaks Memory
Affected process is VLAN MGR
from show vlan internal mem-stats detail command
123 [r-xp]/isan/plugin/0/isan/lib/libutils. 86475 86477 6572511 6572629 <-- first capture
123 [r-xp]/isan/plugin/0/isan/lib/libutils. 89534 89536 6804995 6805113 <-- 2nd capture
123 [r-xp]/isan/plugin/0/isan/lib/libutils. 113216 113218 8604827 8604945 <-- 3nd capture
Conditions:
Creating and deleting VLAN in a range multiple times may leaks Memory
Affected process is VLAN MGR
Workaround:
None, This issue is resolved now
Further Problem Description:
|
|
Last Modified: | 05-MAY-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.221) |
|
Known Fixed Releases: | 7.1(3)N1(0.633), 7.1(3)N1(1), 7.1(3)ZN(0.41), 7.3(0)N1(0.125), 7.3(0)N1(1), 7.3(0)ZN(0.114) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz23976 | Title: | DHCP Snooping not working correctly if broadcast flag is set |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
DHCP Snooping does not forward DHCP replies to DHCP client properly if broadcast flag is set;
No such issue is seen if broadcast flag is not set on the packets;
Conditions:
The issue is seen if DHCP Snooping is enabled in the vlan of DHCP client;
This is seen for DHCP packets sent by DHCP Relay to the DHCP client in case broadcast flag is set on the packets;
Workaround:
Disable DHCP Snooping
Further Problem Description:
|
|
Last Modified: | 07-MAY-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.273), 7.1(4)N1(0.807), 7.1(4)N1(1), 7.3(1)N1(0.340), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd58322 | Title: | n5k: cpmCPUTotal5minRev OID returns out of range value |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: * | Symptom:
out of range values obtained when polling the cpmCPUTotal5minRev snmp oid belonging to CISCO-PROCESS-MIB. Values returned by the nexus 5000 SNMP engine can be more than 100% when this oid is pulled at different intervals.
Conditions:
This is seen when polling the cpmCPUTotal5minRev oid under the CISCO-PROCESS-MIB on a nexus 5000 running 4.1(3)N2(1) code
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 09-MAY-2016 |
|
Known Affected Releases: | 4.1(3)N2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz02878 | Title: | Nexus 5000 ethpm crash |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Nexus 5000 observed a crash on ETHPM process upon reload
Conditions:
Reload upgrade was done on 12 Nexus 5000 switches , however only one of these switches observed this crash
Workaround:
Further Problem Description:
|
|
Last Modified: | 27-MAY-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz80449 | Title: | N5K: Kernel panic at mts_q_entry_unlink |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
N5K kernel panic observed. The call trace from 'show logging onboard stack-trace' will show:
Call Trace:
[]mts_q_entry_unlink+0x17b/0x400 [klm_mts]
[]do_recv_msg+0xbe/0xb00 [klm_mts] (100)
[]mts_sys_recv+0xa88/0x1670 [klm_mts] (208)
[]mts_syscall+0x280/0x890 [klm_mts] (36)
[]mts_syscall_unlocked+0x1b/0x30 [klm_mts] (16)
[<8019adbb>]vfs_ioctl+0x27/0x6c (24)
[<8019b040>]do_vfs_ioctl+0x240/0x24c (44)
[<8019b0b5>]sys_ioctl+0x69/0x84 (28)
[<80103a92>]system_call_done+0x0/0x4 (-8112)
Conditions:
Unknown at this time.
Workaround:
None at this time.
Further Problem Description:
|
|
Last Modified: | 26-MAY-2016 |
|
Known Affected Releases: | 7.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy27650 | Title: | N5K kernel panic seen with e1000_get_hw_semaphore_generic |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N5K will experience a kernel panic due to a CPU lockup.
%KERN-0-SYSTEM_MSG: [8348809.761281] BUG: soft lockup - CPU#2 stuck for 11s! [events/2:29] - kernel
The call trace will show that this is related to the e1000 drivers
Conditions:
Unknown at this time
Workaround:
None at this time
Further Problem Description:
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.3), 7.0(7)N1(1a), 7.1(3)ZN(0.296), 7.1(4)N1(0.830), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq45360 | Title: | LinkUP SNMP Trap not sent on LinkUp events for FEX Fabric Port-Channel |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LinkUP SNMP Trap(Enterprise=1.3.6.1.6.3.1.1.5.4) not sent on LinkUp events for FEX Fabric Port-Channel.
Conditions:
When linkup the fabricport on N5K , only trap for physical interface is sent out and link up event for fabric port-channnel is not sent out .
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 30-MAY-2016 |
|
Known Affected Releases: * | 5.2(9)N1(1), 7.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy89816 | Title: | 4-way HSRP not supported on Nexus 5k/6k switches |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:4-way HSRP is not supported on Nexus 5000/6000 switches in vPC domains.
Conditions:
N5k/6k switches running NX-OS releases prior to 7.1(4)N1(1).
Workaround:- Switches can be supported in Active-Standby Setup.- If there are 4 switches in FHRP in vpc, then switches will actively forwarding traffic when they are in following state
Active-Standby on one vpc pair
Listen-Listen on other vpc pair.
- The switches do not support Active-Listen and Standby->Listen State.- Use Anycast HSRP
More Info:Changes have been incorporated in NX-OS release 7.1(4)N1(1), 7.2(2)N1(1), 7.3(1)N1(1) to support all combinations of HSRP states in a 4-WAY FHRP setup.
|
|
Last Modified: | 24-MAY-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz68056 | Title: | logging server vrf changes to vrf default after ND-ISSU |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
The logging server vrf configuration changes from vrf management to vrf default after non-disruptive upgrade from 7.0(4)N1(1) to 7.1(3)N1(2) on Nexus 5596UP.
The config before upgrade:
logging server 172.16.1.1
The config after upgrade:
logging server 172.16.1.1 5 use-vrf default
Conditions:
ND-ISSU on Nexus 5596UP
Workaround:
Reconfigure the logging server with correct vrf.
logging server 172.16.1.1 5 use-vrf management
Further Problem Description:
|
|
Last Modified: | 23-MAY-2016 |
|
Known Affected Releases: | 7.1(3)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq27661 | Title: | N5k/6k - DHCP offers might not get relayed in Fabricpath topologies |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:In a Nexus 5500/5600/6000 switches in fabricpath environment, broadcast DHCP offers might not get relayed under certain conditions.
Conditions:Fabricpath setup with DHCP relay configured on more than 1 switch. DHCP offer sent as broadcast follows multi-destination tree and hits another Relay agent in the setup. Instead of forwarding the offer down the multi-destination path DHCP offer is redirected to CPU and dropped.
Workaround:Enable DHCP relay only on 1 switch in FP setup.
More Info:Problem was resolved through CSCuj46069 in past, however issue could be seen in some corner cases and this bug provides a complete fix.
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 5.2(1)N1(7.136), 6.0(2)N2(5) |
|
Known Fixed Releases: | 5.2(1)N1(7.140), 5.2(1)N1(8a), 6.0(2)N2(5.80), 6.0(2)N2(6), 7.0(1)ZN(0.706), 7.0(6)N1(0.211), 7.0(6)N1(1), 7.1(0)N1(0.1), 7.1(0)N1(0.289), 7.1(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy44608 | Title: | N5K -Multiple Issues with "snmp-server source-interface informs" command |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Issue 1 :
********
"snmp-server source-interface traps" command isn't displayed either in running or in start-up when "snmp-server source-interface informs" is configured.
Issue 2 :
********
soure-interface is not listed under inform notification when "snmp-server source-interface informs mgmt0" is confgured
Issue 3 :
********
Informs notification doesnt points to right source interface
Conditions:
"snmp-server source-interface informs" command is configured
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 02-MAY-2016 |
|
Known Affected Releases: | 7.2(1)N1(1) |
|
Known Fixed Releases: * | 7.3(1)D1(0.57), 7.3(1)N1(0.344), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz75333 | Title: | N5K | FEX Port-channel Link UP Trap not generate |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
When FEX Port-Channel goes off line, customer is able to see down trap by command "show system internal snmp event-history pktdump" but not able to see up trap once Fex Port-Channel come up.
Conditions:
When FEX Port-Channel goes off line, customer is able to see down trap by command "show system internal snmp event-history pktdump" but not able to see up trap once Fex Port-Channel come up.
- FEX Port-channel Link UP Trap not generate
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 7.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug84290 | Title: | False transceiver alarm error messages on nexus 5000 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
On a nexus 5000, the following issues are observed:
- False positive alarms are reported for interfaces. The alarms for each interface clear shortly after.
- Alarms can also be raised for ports that don't have a cable connected, but can be seen for connected interfaces as well with no actual alarm in "show interface transceiver det".
- In the output of ''show interface transceiver det', when the warning threshold is crossed for a value, the system marks it as -- (alarm) and not - (warning).
Example :
ETHPORT-3-IF_SFP_ALARM Interface Ethernet1/1, High Temperature Alarm cleared
ETHPORT-3-IF_SFP_ALARM Interface Ethernet1/1, Low Temperature Alarm cleared
ETHPORT-3-IF_SFP_ALARM Interface Ethernet1/1, High Tx Power Alarm cleared
ETHPORT-3-IF_SFP_ALARM Interface Ethernet1/1, Low Tx Power Alarm cleared
ETHPORT-3-IF_SFP_ALARM Interface Ethernet1/1, High Rx Power Alarm cleared
ETHPORT-3-IF_SFP_ALARM Interface Ethernet1/1, Low Rx Power Alarm cleared
ETHPORT-3-IF_SFP_ALARM Interface Ethernet1/1, High Current Alarm cleared
ETHPORT-3-IF_SFP_ALARM Interface Ethernet1/1, High Voltage Alarm cleared
ETHPORT-3-IF_SFP_ALARM Interface Ethernet1/1, Low Voltage Alarm cleared
Conditions:
The issue occurs while running 5.2(1)N1(4).
Workaround:
There is no way to prevent the messages from appearing.
If the messages need to be masked out, set the logging level to 2 or lower.
Further Problem Description:
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 5.2(1)N1(4) |
|
Known Fixed Releases: | 5.2(1)N1(5) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug07482 | Title: | Memory leak at ppm with switch profile configured |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Memory leak in the Port Profile Manager / PPM_MEM_char
The leak can be monitor with following command:
sh system internal port-profile mem-stats detail | in PPM_MEM_char
Conditions:
Switch configure with switch-profile, each time we do "sh runn"
Workaround:
no workaround
Further Problem Description:
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 6.0(2)N1(1), 6.0(2)N1(2) |
|
Known Fixed Releases: | 5.2(1)N1(5), 6.0(2)N1(2a), 6.0(2)N2(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus22583 | Title: | Changing the port type doesn't remove the configuration from startup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Changing the port type will not remove the configuration from startup configuration even after "copy run start" is performed.
Conditions:
Performing the port type change. Detail will be provided later.
Workaround:
None
Further Problem Description:
Configuration should have been removed during the port type change and shouldn't re-apply automatically when the port type change is revert it back.
|
|
Last Modified: | 17-MAY-2016 |
|
Known Affected Releases: | 5.2(1)N1(3) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.276), 7.1(4)N1(0.810), 7.1(4)N1(1), 7.2(2)N1(0.423), 7.2(2)N1(1), 7.2(2)ZN(0.131), 7.3(1)N1(0.352), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus92726 | Title: | N5K link flaps with HP StoreEasy x5530 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On a nexus 5500 series switches, 10GE links connected to an HP StoreEasy x5530 may flap until going to errdisabled state.
Conditions:
- This is seen on ports of N2K-C2232PP-10GE fex module as well as on nexus 5000 chassis ports.
- This is seen on version later than 5.2(1)N1(1), links are not flapping on earlier NX-OS versions such that 5.1(3).
Workaround:
A debouce timer value of 300ms and higher stabilizes the links
Further Problem Description:
|
|
Last Modified: | 30-MAY-2016 |
|
Known Affected Releases: | 5.2(1)N1(4), 5.2(1)N1(8a), 6.0(2)N2(6), 7.1(0)N1(1), 7.3(0)N1(0.140) |
|
Known Fixed Releases: * | 5.2(1)N1(9.184), 5.2(1)N1(9.185), 5.2(1)N1(9a), 7.1(3)ZN(0.222), 7.1(3)ZN(0.278), 7.1(4)N1(0.762), 7.1(4)N1(0.812), 7.1(4)N1(1), 7.3(1)N1(0.339), 7.3(1)N1(0.357) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua39096 | Title: | TACACS+ missing header length check |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Cisco Nexus devices contain a vulnerability within the TACACS subsystem that could allow an unauthenticated, remote attack to crash the TACACS process. This could result
in an unexpected process restart.
The vulnerability exists due to a failure to properly limit the maximum message size that will be allocated for a TACACS message. An attacker that could place themselves
between an affected device and the AAA server, and knows the MD5 authentication token, could respond to a AAA request from an affected device with a malicious packet.
When processed the affected device may try to allocate a buffer that is larger than the available memory resulting in a core of the process.
Conditions:
Cisco Nexus devices running an affected version of NX-OS software and configured to preform TACACS authentication.
Workaround:
None.
Further Problem Description:
The TACACS process will be restarted by the device, but may result in a temporary denial of service condition.
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.6:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2012-4137 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: | 13-MAY-2016 |
|
Known Affected Releases: | 5.1(3)N1(1a) |
|
Known Fixed Releases: | 5.2(1)N1(8.153), 5.2(1)N1(9), 6.0(2)N2(6.124), 6.0(2)N2(7), 7.0(1)ZN(0.699), 7.0(6)N1(0.207), 7.0(6)N1(1), 7.1(3)ZN(0.187), 7.1(4)N1(0.734), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux95821 | Title: | show tech-support fcoe needs to contain all pertinent FC information |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Enhance show tech-support fcoe so that it includes all FC pertinent information. This should be similar to the MDS show tech-support details
Conditions:
Applicable to the Nexus 5000/5600/6000 switches using FC and/or FCoE.
Workaround:
Use individual show tech-support commands. For example:
show tech-support zone
show tech-support fcns
show tech-support fcdomain
show tech-support port
etc...
Further Problem Description:
None.
Resolution Summary:
show tech-support fcoe will now contain the following commands:
show switchname
show inventory
show interface
show topology
show logging log
show logging nvram
show accounting log
show tech-support snmp
show tech-support ha
show tech-support cli
show tech-support cdp
show tech-support issu
show tech-support clis
show tech-support pltfm-config
show tech-support flogi
show tech-support pfstat
show tech-support cfs
show tech-support fcdomain
show tech-support fcs
show tech-support acl
show tech-support port-channel
show tech-support fc2
show tech-support port
show tech-support fc
show tech-support fcoe_mgr
|
|
Last Modified: | 13-MAY-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: | 7.1(3)ZN(0.243), 7.1(4)N1(0.778), 7.1(4)N1(1), 7.2(2)N1(0.407), 7.2(2)N1(1), 7.2(2)ZN(0.107), 7.3(1)N1(0.325), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux55515 | Title: | OpenSSH: Evaluation of Multiple OpenSSH CVEs for NX-OS |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Cisco Nexus 5000 Series Switches includes a version of Open Secure Shell (OpenSSH)
that is affected by the vulnerabilities identified by the following Common
Vulnerability and Exposures (CVE) IDs:
CVE-2015-6565, CVE-2015-6564, CVE-2015-6563, CVE-2015-5600, CVE-2015-5352
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 8.5/7:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:N/C:P/I:N/A:C/E:F/RL:OF/RC:C&version=2.0
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
|
|
Last Modified: | 16-MAY-2016 |
|
Known Affected Releases: | 7.0(7)ZN(0.262) |
|
Known Fixed Releases: | 5.2(1)N1(9.175), 5.2(1)N1(9a), 7.0(7)ZN(0.266), 7.0(8)N1(0.314), 7.0(8)N1(1), 7.1(3)ZD(0.81), 7.1(3)ZN(0.173), 7.1(4)N1(0.724), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui89609 | Title: | Doc: Clarification with regards to FCoE VLAN on peer links |
|
Status: * | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Doc bug to add more clarification to our Nexus 5K configuration guide, as to whether the FCoE VLAN should be trunked across VPC peer-links or not.
Conditions:
FCoE configuration.
Workaround:
FCoE VLANs should not be trunked across VPC peer-links.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 4.1(3)N2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz59030 | Title: | Nexus 5000 chap protocol actually does PAP |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
When chap is enabled, does pap instead.
Conditions:
-N5K-C5672UP
TAC lab recreate and CU version
-version 7.0(3)N1(1)
GDP lab recreate
7.2(1)N1(1)
Workaround:
use MSChap
Further Problem Description:
When CHAP (not MSCHAP) is enabled in the switch, it attempts to do PAP authentication. The password passed back is not the attribute three password as called out in the rfc.
https://tools.ietf.org/html/rfc2865#page-8
-
|
|
Last Modified: | 10-MAY-2016 |
|
Known Affected Releases: | 7.0(3)N1(1), 7.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut29819 | Title: | User role hierarchy not working correctly, deny overrides permit |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
User is a member of multiple roles and the role hierarchy is not working as designed.
When the user logs in and tries to execute a command that was permitted in one role and denied it another it fails. That does not follow the rule:
If you belong to multiple roles, you can execute a combination of all the commands permitted by these roles. Access to a command takes priority over being denied access to a command. For example, suppose a user has RoleA, which denied access to the configuration commands. However, the users also has RoleB, which has access to the configuration commands. In this case, the users has access to the configuration commands.
Conditions:
role name A_SERVER_ADMIN
rule 70 permit command show cdp neighbor
rule 60 permit command show vlan
rule 50 deny command configure
rule 40 permit command show mac address-table
rule 30 permit command show running-config interfa
rule 20 permit command show port-profile
rule 10 permit command show inter
vlan policy deny
interface policy deny
vrf policy deny
username admin password 5 role network-admin
username admin role A_SERVER_ADMIN
When logged in with the userid "admin" the user was unable to create a virtual interface:
conf t
interface vfc x
The interface was not created.
Workaround:
Log in with a userid that has only the network-admin role or a role that does not have "interface policy deny".
Further Problem Description:
When the interface creation fails, there is no error message.
The accounting log shows "success" but if you try to display the virtual interface or bind it to a physical interface you will get an error message that says the virtual interface does not exist.
|
|
Last Modified: | 03-MAY-2016 |
|
Known Affected Releases: * | 5.2(1)N1(7), 7.0(2)N1(1), 7.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw96661 | Title: | N5K not able to suppress Sev5 syslog messages related with connected FEX |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Configuring syslog levels and can't suppress syslog message for the following message
%LLDP-FEX102-5-SERVER - adds or removals
(config)# logging level fex ?
config)# logging level lldp ?
<0-7> 0-emerg;1-alert;2-crit;3-err;4-warn;5-notif;6-inform;7-debug
The same issue is observed with the following message:
%LACP-FEX101-5-LACP_SUSPEND_INDIVIDUAL: LACP port Ether
net101/1/2(0x1f640040) of port-channel port-channel1(0x16000000) not receiving a
ny LACP BPDUs suspending (individual) port
It is observed even when the logging level is 1 for all the facilities. Thus it does not depend on the severity level, it is always present.
Conditions:
LLDP hosts go online/offline. LACP link is bounced.
syslog configured
Workaround:
none
More Info:
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 5.1(3)N1(1), 5.1(3)N2(1) |
|
Known Fixed Releases: * | 5.2(1)N1(6), 6.0(2)N2(4.59), 6.0(2)N2(5), 7.0(0)N1(0.368), 7.0(0)N1(1), 7.0(0)ZN(0.88), 7.1(0)ZN(0.281), 7.2(0)ZN(0.111), 7.3(1)D1(0.46), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux05255 | Title: | Interface running-configuration may incorrectly show 'shutdown' |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
On a Nexus 5000, the running-configuration and startup-configuration may incorrectly show a port as 'shutdown'.
The actual interface status is correct and is also correct after a reload.
Conditions:
This is seen when applying a port-profile on an interface while it is in 'shutdown' state and a 'no shutdown' is applied afterwards.
Workaround:
In case the issue is observed, using 'show running-config expand-port-profile' will show the correct configuration.
To clear the issue, remove the port-profile and re-apply it after unshutting the port.
Further Problem Description:
|
|
Last Modified: | 17-MAY-2016 |
|
Known Affected Releases: | 7.1(2)N1(0.3), 7.2(1)N1(0.9) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.281), 7.1(4)N1(0.816), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue41816 | Title: | "sh hardware internal fc-mac <> port <> statistics" clear enhancement |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
When using show hardware internal fc-mac port port statistics command there is no way to reset the statistics.
Conditions:
Applies to all Nexus 5000, 5600 and 6000 switches.
Needed when monitoring FC interfaces for issues.
Workaround:
None at this time.
Further Problem Description:
None.
Resolution Summary:
The following new command was added to clear the fc-mac statistics on one or all ports:
clear hardware internal fc-mac slot statistics all-ports|port port
|
|
Last Modified: | 17-MAY-2016 |
|
Known Affected Releases: | 5.1(3)N1(1a), 6.0(2)N3(0.256) |
|
Known Fixed Releases: | 7.1(3)ZN(0.256), 7.1(3)ZN(0.273), 7.1(4)N1(0.791), 7.1(4)N1(0.807), 7.1(4)N1(1), 7.2(2)N1(0.408), 7.2(2)N1(0.421), 7.2(2)N1(1), 7.2(2)ZN(0.115), 7.2(2)ZN(0.129) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux76712 | Title: | FC interface disabled due to 'bit error rate too high' when rate is low |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
A Fibre Channel interface is disabled and has the following status even though the bit error rate of the interface is below the threshold specified in the Fibre Channel standards:
show interface
fcx/y is down (Error disabled - bit error rate too high)
The following type of syslog messages are logged for the interface:
show logging log
%PORT-5-IF_DOWN_BIT_ERR_RT_THRES_EXCEEDED: %$VSAN v%$ Interface fcx/y is down (Error disabled - bit error rate too high)
Conditions:
This issue applies to all FC interfaces on the Nexus 5000 and Nexus 6000 models.
show platform software fcpc event-history errors
Event:E_DEBUG, length:102, at 571407 usecs after Tue Jan 5 05:33:02 2016
[102] CREDITMON_EVENT_ERR_COUNT, if_index 1105000: cur=0x2acfd01e76de prev=0x2acfd01e76dd occurances=3
If the time between occurances=1 to occurances=15 for the interface if_index is greater than 5 minutes, then this bug has been hit.
Workaround:
shut and then no shut the fc interface to recover.
Further Problem Description:
Even though the rate of bit errors on the affected link may not have been at as high as the rate specified in the Fibre Channel standards, there were still bit errors occurring. This causes the interface to be error disabled prematurely. However, persistent bit errors on a link are undesirable and the problem should still be corrected.
To find the fc interface, use the if_index
show system internal fcfwd idxmap interface-to-port | i 1105000
01105000 fc3/6 | 105| 0| 05| 01 | 02 | 05 | 0101| 00 | 00
Resolution Summary:
Occurrences counter is reset to zero after 5 minutes of error free frames.
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: | 7.3(1)N1(0.303), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut29391 | Title: | CLI command to create a VFC is denied but does not generate an error |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
When trying to bind an ethernet interface to VFC interface for FCoE, the following message occurs:
ERROR: fcoe_mgr: VFC not present (err_id 0x42070006)
Conditions:
Configuring a new VFC for FCoE connectivity the following sequence of commands are entered:
switch(config-if)# int vfc x
switch(config-if)# bind interface ethernet x/xx
ERROR: fcoe_mgr: VFC not present (err_id 0x42070006)
Workaround:
Check the user role and make sure that it has permission to create a virtual ( VFC ) interface.
The root cause of the problem is that the user role being used for the console session did not allow an interface to be created. However, no error message was issued and it looked like the VFC was created successfully.
(1)Check to see if the VFC is being created with "show interface vfc x"
(2)Check the user role for the user ID that tried to create the VFC.
(3)Log in with a user role that has authority to create an interface or change the user role to give it authority to create an interface and retry the operation.
Further Problem Description:
Example of user role being used with "interface policy deny".
role name SERVER_ADMIN
rule 70 permit command show cdp neighbor
rule 60 permit command show vlan
rule 50 deny command configure
rule 40 permit command show mac address-table
rule 30 permit command show running-config interfa
rule 20 permit command show port-profile
rule 10 permit command show inter
vlan policy deny
interface policy deny
vrf policy deny
username admin password 5 role network-admin
username admin role SERVER_ADMIN
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: * | 5.2(1)N1(7), 7.0(2)N1(1), 7.9(0)ZD(0.4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz74203 | Title: | Syslog messages are not being sent to the configured syslog server |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
Syslog message are not being sent to the server
"show logging info" output shows "temporarily unreachable" , although Ping to syslog-sever is fine.
Running the ethanalyzer proves that the syslogs are not generated from teh CPU to the configured server.
DO7010A# ping 10.141.32.177 vrf management
PING 10.141.32.177 (10.141.32.177): 56 data bytes
64 bytes from 10.141.32.177: icmp_seq=0 ttl=123 time=1.262 ms
64 bytes from 10.141.32.177: icmp_seq=1 ttl=123 time=0.753 ms
64 bytes from 10.141.32.177: icmp_seq=2 ttl=123 time=1.18 ms
64 bytes from 10.141.32.177: icmp_seq=3 ttl=123 time=0.72 ms
64 bytes from 10.141.32.177: icmp_seq=4 ttl=123 time=0.843 ms
--- 10.141.32.177 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.72/0.951/1.262 ms
DO7010A#
DO7010A# sh logging info
Logging console: enabled (Severity: critical)
Logging monitor: enabled (Severity: debugging)
Logging linecard: disabled
Logging timestamp: Milliseconds
Logging loopback : disabled
Logging server: enabled
{10.141.32.177}
This server is temporarily unreachable <<<<<
server severity: notifications
server facility: local7
server VRF: management
Conditions:
Workaround:
Run the following commands in order to fix the issue .
(config)# no logging server 10.141.32.177 5 use-vrf management facility local6
(config)# logging server 10.141.32.177 5 facility local6
(config)# logging source-interface loopback 0
Configuring logging source-interface will open UDP/syslog socket(514).
(config)# logging server 10.141.32.177 5 use-vrf management facility local6
(config)# no logging source-interface loopback 0
UDP/syslog socket(514) is being closed.
Further Problem Description:
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 6.0(2)N2(7) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx08942 | Title: | Certain CISCO-FINISAR FC SFPs send low voltage to syslog when shutdown |
|
Status: | Terminated |
|
Severity: | 5 Cosmetic |
Description: * | Symptom:
Certain fibre-channel SFPs will show a low TX warning in syslog even when not connected/shutdown
2011-12-22 07:40:02 Local7.Error : 2011 Dec 22 07:40:02 EST: %PORT-3-IF_SFP_ALARM: Interface fc1/36, Low Tx Power Warning cleared
2011-12-22 07:40:02 Local7.Error : 2011 Dec 22 07:40:02 EST: %PORT-3-IF_SFP_ALARM: Interface fc1/36, Low Tx Power Alarm cleared
2011-12-22 07:40:02 Local7.Warning : 2011 Dec 22 07:40:02 EST: %PORT-4-IF_SFP_WARNING: Interface fc1/36, Low Rx Power Warning cleared
2011-12-22 07:40:02 Local7.Error : 2011 Dec 22 07:40:02 EST: %PORT-3-IF_SFP_ALARM: Interface fc1/36, Low Rx Power Alarm cleared
Conditions:
Fibre-channel SFP is shutdown or not connected
Workaround:
none; this is cosmetic
Further Problem Description:
|
|
Last Modified: | 17-MAY-2016 |
|
Known Affected Releases: | 5.1(3)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux97078 | Title: | N5k: speed for veth ports becomes 'unknown' after upgrade |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: * | Symptom:
N5k: speed for veth ports in 'show interface status' becomes 'unknown' after upgrade.
Conditions:
After upgrade NX-OS to 7.0(7)N1(1).
Workaround:
Not available at this moment.
Further Problem Description:
This output is just a cosmetic issue.
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz50286 | Title: | Data Sheets does not show full transceiver compatibility for N5K |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Data Sheet: http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-series-switches/data_sheet_c78-618603.html?cachemode=refresh and Compatibility matrix:http://www.cisco.com/c/en/us/td/docs/interfaces_modules/transceiver_modules/compatibility/matrix/10GE_Tx_Matrix.html does not state the Active Optical Cables as supported on the N5k.
Conditions:
N5k running latest code
Workaround:
Data Sheet and Compatibility matrix needs to add the SFP-10G-AOCxM as supported on the N5k
Further Problem Description:
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 5.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCui25749 | Title: | N5k 5.2.1 Upgrade Behaviour |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
While upgrading from 4.x to 5.x, IGMP snooping was enabled for all the VLANs even if on the previous version IGMP snooping was disabled for few of the vlans.
Conditions:
Upgrading the switch from 4.2 to 5.2 version.
Workaround:
Further Problem Description:
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 5.2(1)N1(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur22079 | Title: | Cisco Nexus 2K Fabric Extender Software Default Credential Vulnerability |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
A vulnerability in the Cisco Nexus 2000 Series Fabric Extender could allow an unauthenticated, local attacker to log in to the system shell with the privileges of the root user.
The vulnerability is due to a missing password for the root user account on the affected system. This account is created at installation and cannot be changed or deleted without impacting the functionality of the system. An attacker could exploit this vulnerability by physically connecting to the affected system. An exploit could allow the attacker to access the system with the privileges of the root user.
Conditions:
A physical connection to the device and a non-standard cable is required to exploit this vulnerability.
Workaround:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.9/6.6:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:M/Au:N/C:C/I:C/A:C/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2016-1341 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
Further Problem Description:
Fix Version:
This problem will be addressed in NXOS release 8.3.0
|
|
Last Modified: | 27-MAY-2016 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(1)N1(3), 7.0(4)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur48104 | Title: | fcoe fcf mac address should not be checked out for non fcoe port-channel |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
In our current fcoe implementation we check out a fcf mac address from a pool of fcf mac addreses when a
ethernet port-channel is created.
Regardless if we bind a vfc interface to this port-channel or not.
This imposes unnecessary restrictions to the fcoe configuration / implementation.
Conditions:
fcoe with ethernet port-channels
Workaround:
bind vfc interfaces to physical ethernet interfaces and not ethernet port-channels whenever possible.
Further Problem Description:
|
|
Last Modified: | 08-MAY-2016 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: * | 8.3(0)CV(0.427), 8.3(0)SPB(0.42) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup08285 | Title: | Interface erased by 'default' causes commit/verify error in config-sync. |
|
Status: | Other |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Unable to apply new configuration to interface using switch-profile (config-sync) even if the interface is without configuration. The switch-profile complains about "Following commands failed mutual-exclusion checks".
Conditions:
Interface was already configured in regular config-mode and got its configuration cleared by 'default' command.
Workaround:
Do not use the 'default' command to clear interface configuration. Instead, use the "no " for all configuration applied.
Further Problem Description:
|
|
Last Modified: | 05-MAY-2016 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy69670 | Title: | Nexus Priority Flow Control 'Off' when Interface is 'Up' |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
"Pkts discarded on ingress" increment for qos-group 1 (FCoE) from the output of:
show queuing interface
...snip
Ethernet1/1 queuing information:
TX Queuing
qos-group sched-type oper-bandwidth
0 WRR 50
1 WRR 50
...snip
qos-group 1
q-size: 79360, HW MTU: 2158 (2158 configured)
drop-type: no-drop, xon: 20480, xoff: 40320
Statistics:
Pkts received over the port : 8000000
Ucast pkts sent to the cross-bar : 6000000
Mcast pkts sent to the cross-bar : 0
Ucast pkts received from the cross-bar : 3000000
Pkts sent to the port : 2000000
Pkts discarded on ingress : 1000000
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
Ethernet and vFC interfaces are up/trunking:
show interface brief
Eth1/1 10 eth access up none 1000(D) --
Eth1/2 10 eth access up none 1000(D) --
...snip
vfc11 100 F on trunking Eth1/1 TF auto
vfc12 100 F on trunking Eth1/2 TF auto
For the associated Ethernet interfaces PFC is operationally off:
show interface priority-flow-control
============================================================
Port Mode Oper(VL bmap) RxPPP TxPPP
============================================================
Ethernet1/1 Auto Off 50 1000000
Ethernet1/2 Auto Off 1000 1000000
There are no errors in syslog.
If the Ethernet interface is "up" and the vFC interface bound to the Ethernet interface is "up"/"trunking" then PFC should be operationally "on". If PFC is operationally "off" for these interfaces we need to add an error in syslog stating the same.
Conditions:
All switches using FCoE.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 26-MAY-2016 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: * | 7.1(3)ZN(0.291), 7.1(4)N1(0.825), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo96392 | Title: | configure "syslog" server via Device Manager in N5K failed - VRF |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
configure Syslog server via Device Manager on Nexus 5000 failed with error below.
" syslogd: Configuration Failed, due to unknown VRF ?
CLI works.
Conditions:
Use Device Manager to configure syslog.
Workaround:
Use CLI for now. Filing it for enhancement.
Further Problem Description:
|
|
Last Modified: | 18-MAY-2016 |
|
Known Affected Releases: * | 6.2(5)MD, 7.3(0.360) |
|
Known Fixed Releases: | |
|
|
| |
没有评论:
发表评论