| |
|
Alert Type: | Updated * |
Bug Id: | CSCut74135 | Title: | Fabricpath mode transit - control packets tagged with internal vlan 4041 |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: * | Symptom:
On a Nexus 6000/5600 running fabricpath , when fabricpath mode transit is configured, the switch is sending control packets like CDP, LACP, ISIS tagged with internal VLAN ID 4041.
This causes a switch like N7K drop the packet. None of the protocols are able to negotiate and come up
Conditions:
Command fabricpath mode transit is configured.
Workaround:
Disable transit mode and reload the switch.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.269), 7.1(1)N1(0.508), 7.2(0)N1(0.147) |
|
Known Fixed Releases: | 7.0(1)ZN(0.780), 7.0(6)N1(1), 7.0(7)ZN(0.156), 7.1(1)N1(0.511), 7.1(1)N1(1), 7.1(1)ZN(0.67), 7.2(0)N1(0.167), 7.2(0)N1(0.180), 7.2(0)N1(1), 7.2(0)ZN(0.170) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCun26512 | Title: | dhcp relay support with URPF cause DROP at INGRESS using customer topo |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
dhcp relay support with URPF cause DROP at INGRESS using customer topo
Conditions:
configuring DHCP Relay and URPF on interface vlan 363 on the N6K-14a and N6K-14b switches, if the DHCP Discover (client broadcast) arrived at N6K-14b (Active HSRP), then the DHCP Relay will forward the DHCP discover packet from N6K-14b as uni-cast (using DHCP Relay) to N5K48-2 and then to the DHCP server, then the DHCP server could uni-cast a Offer back through N5K48-1 and over to N6k-14a, then these offers has to be forwarded to the N6K-14b since URPF is configured on the DHCP Discover was send from N6K-14b.
The issue is, if this is the route that was traversed for the DHCP Offer, then once the DHCP Offers are send back to N6K-14b over the MCT, the MCT (VPC10) drops the DHCP Offers.
Workaround:
no
Further Problem Description:
|
|
Last Modified: | 08-SEP-2015 |
|
Known Affected Releases: | 7.0(1)N1(0.103) |
|
Known Fixed Releases: | 7.0(2)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCut37784 | Title: | [iluka MR5]FEX: Satmgr Module time out during the ISSU upgrade |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Straight through Fex took long time to come up after ISSU upgrade
Conditions:
Disruptive issu between illuka MR5 image.
Workaround:
no
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuq16392 | Title: | DN5672UP crash due to fwm hap reset |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
N5672UP running 7.0(5)N1(1) crashed due to fwm hap rest
Conditions:
After performing ISSD to 7.0 release.
Workaround:
Before performing ISSD, run following commands on the switch. This will delete the fwm global PSS config and will forcefully do a true stateless reboot from fwm POV-
show platform fwm info pss config_global delete
copy r s
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.0(6)N1(1.4), 7.1(0)N1(0.266) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCur44729 | Title: | mac address is out of sync on vpc peers after HSRP flap |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:This is a timing issue while sending traffic when issuing the command "clear mac address-table dynamic" simultaneously on vpc peers creates a sync issue where one or more macs may not be deleted on both switches.
If traffic restarts on the same macs, then the switches should resync without issue.
Conditions:Appears with over 10000 macs in the system, and while traffic is running, and "clear mac address-table dynamic" is used almost simultaneously on both vpc peers.
During this period a mac might be deleted, but then gets a new learn notification from the peer, then skips deleting this mac.
Workaround:We suggest to stop traffic completely before clearing the mac tables and this issue shouldn't be seen. Also waiting about 5 seconds between issuing the clear command on peers should give them time to process the delete messages before anything goes wrong.
If hitting this issue, then using "clear mac address-table dynamic" on the switch that has extra mac should delete it properly.
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.379) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv37294 | Title: | 2248: Packets getting Blackholed in the HIF VPC port-channel |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Packets will get black holed in the HIF VPC Port-channel
Conditions:
1) FEX 2248
2) 55xx based Platforms
3) Running 7.0(6)N1(1)
Workaround:
1) Keep one single HIF port in the HIF port-channel.
2) If there are more ports in port-channel, Change the hashing by shutting down ports on HIF side.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.1) |
|
Known Fixed Releases: | 7.0(7)N1(0.288), 7.0(7)N1(1), 7.0(7)ZN(0.173), 7.1(3)N1(0.619), 7.1(3)N1(1), 7.1(3)ZN(0.25), 7.2(1)N1(0.283), 7.2(1)N1(1), 7.2(1)ZN(0.48) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCur50810 | Title: | vpc_simultaneous_reload failed due to missng flogi in npv switch |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In FCoE scale test scenario, some VFCs don't come up after simultaneous reload of both VPC peers.
Conditions:
VFCs don't come up because the eth port / PO they are bound to are in VLAN ErrDisable state.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.379) |
|
Known Fixed Releases: | 7.0(2)FIP(0.6), 7.1(0)N1(0.419), 7.1(0)N1(1), 7.1(0)ZN(0.492), 7.1(1)N1(0.34), 7.1(1)N1(1), 7.2(0)N1(1), 7.2(0)VZN(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul02903 | Title: | Enh: U2rib timesout on response from DCEFIB causing delayed ftag update |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:Seeing large convergence times for multicast traffic in a fabricpath topology.
Conditions:Can happen when there are changes in ftag tree. Ftag tree can change whenever a switch part of the ftag tree goes down, or if any of the L2MP core link part of the ftag tree goes down.
Workaround:None
More Info:When an ftag tree path is changing, ftag route needs to be updated on all the switches part of the ftag tree. Some times this update takes longer than 10 seconds. This long delay in ftag programming can cause traffic drops for multicast flows in the L2MP cloud. Traffic does recover once the ftag route programming is completed on all the switches.
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(2), 6.0(2)N2(3) |
|
Known Fixed Releases: | 6.0(2)N2(5.94), 6.0(2)N2(6), 6.0(2)N3(0.73), 7.0(0)N1(0.381), 7.0(0)N1(0.73), 7.0(0)N1(1), 7.1(0)ZN(0.183) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu58776 | Title: | Fwm core happened While doing ND-ISSU from IPLUS-MI-1 to Janjuc-221 |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Fwm core happened While doing ND-ISSU from 7.1x or 7.0x release to 7.2(0)N1(1).
It can also happen from 7.0x to 7.1x.
Conditions:
After performing ND-ISSU if in the pre issu image -
MCT link flapped(in case of vpc+ only) .
NIF (interface connected to active-active fex)port flapped (in case of both vpc and vpc+)
Workaround:
clear multicast groups via -
clear ip igmp snooping group * all
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.221) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu30807 | Title: | FWM hap reset @ fwm_fwim_delete_lif while poweroff the module. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
FWM Crash
Conditions:
During powering off GEM module
Workaround:
No workaround
Further Problem Description:
FWM is trying to get the bigsur_asic_version during the port cleanup but the crash was due to the fact that the module was already cleaned up
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.195) |
|
Known Fixed Releases: | 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.3(0)N1(0.80), 7.3(0)N1(1), 7.3(0)ZN(0.78) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCur34233 | Title: | 100G port channels limited to 5 ports, cli blocked for more than 5 |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
Observed a FWM crash when you configured port-channel with 12 member link. Each member link with 100G link.
Conditions:
Each 100G is linked 3 40G ports internally. so when its crossed more than 5 link we will hit the fwm crash. This is expected behavior. Because bigsur will support only 16 links max. This is system limitation.
Workaround:
no
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.370) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuq99189 | Title: | N96EF: PCS not getting completed on some of the links with AOC cables |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
We are hitting the link issue with N96EF switch with ACO cable. So far the issue happened with 2 sets of ports with AOC 1m and AOC 3m
The PCS is not getting completed in both these cases. Attached is the DFE log.
Conditions:
From Iluka MR3:
- N96EF chassis will support both RevB and CR LEMs
- N96EFCR chassis will only support CR LEMs
Workaround:
No
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.0(4)N1(0.164) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv97386 | Title: | egress traffic dropped: qinq-xlate-table missing "Ig" entry |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
Inter VLAN traffic loss, found QinQ table mis-programmed.
Conditions:
Switch is configured via DCNM, not clear on exact trigger, submitter would do frequently VRF addition/deletion operation, for deletion he would go via manually also.
Workaround:
No workaround, system came up properly after switch reload.
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.94) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCun77758 | Title: | Output of ip dhcp relay statistics does not display Discover and Request |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The 'show ip dhcp relay statistics' displays incorrect values for the Discover, Request packets received.
Conditions:
In any box with DHCP relay enabled this issue will be seen
Workaround:
no work arounds.
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur78132 | Title: * | N2K - Input Align-Err on FEX Host Interfaces |
|
Status: | Open |
|
Severity: * | 2 Severe |
Description: | Symptom:
Input Align-Err increases on FEX HIF ports which is not-connected.
This is a cosmetic issue.
NEXUS# show int e101/1/1-32 counters errors
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth101/1/1 0 0 0 0 0 0
Eth101/1/2 0 0 0 0 0 0
Eth101/1/3 4 2 0 6 0 0 <--- ###
Eth101/1/4 0 0 0 0 0 0
Conditions:
using N2K-C2232TM-10GE
port is not-connected but it was up.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCup70305 | Title: | queuing policy on hif not working for l2 mcast traffic |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | happens only on output direction when multiple multicast groups congest at one hif port(N2H direction),
issue does not happen for input direction and 30g l2 mcast on a 40g link is not a common use case.
Symptom:
when issue happens traffic is flowing thru but may not follow the rate ratio from the output queuing policy.
Conditions:
when multiple multicast group traffic (30G rate here), from N2H direction over 40G NIF link, congest one HIF port.
and output queuing policy applied to this HIF port, either via system qos or via per interface qos policy.
Workaround:
avoid multiple multicast group traffic congest one hif port and apply output queuing policy on this port.
Further Problem Description:
none
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.0(3)N1(0.106) |
|
Known Fixed Releases: | 7.3(0)N1(0.3), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCur94462 | Title: | IPLUS_420: Service not responding while unconfiguring vlan and vpc |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
FWM crash seen when FEX NIF PO is unconfigured. Subsequent config commands fail with "Service not responding"
Conditions:
From Switch to Fex, a standalone NIF is configured in addition to regular NIF PO.
Workaround:
Remove Standalone NIF between Switch and Fex.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.420) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu92452 | Title: | Too many MTS flush generated when connecting VPC+ MST to legacy RPVST |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Too many MTS flush messages generated when connecting VPC+ MST to legacy RPVST, if multiple switches are connected at the same this can lead to instabilities of the VPC+ pair
Conditions:
Connecting VPC+ MST to legacy RPVST switches
Workaround:
Use RPVST on VPC+ instead of MST
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: * | 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.3(0)BZN(0.47), 7.3(0)N1(0.95), 7.3(0)N1(1), 7.3(0)ZN(0.89) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun50553 | Title: | Higher re-covergence time when VPC+ switch comes back after a reload. |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Higher re-covergence time when VPC+ Nexus 600x, 55xx switch comes back after a reload.
Conditions:
VPC+ and HSRP is configured on Nexus 600x, 55xx running NX-OS 7.0(0)N1(1). The re-covergence time corresponds to "delay restore interface-vlan" timer in VPC config. Default is 10 seconds and hence by default loss unto 10-12 seconds can be seen.
Workaround:
Reduce "delay restore interface-vlan" timer to 1 second.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.0(0)N1(1.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsv81694 | Title: | Flap on dynamic-learn port removes the auto-learn static mac entry. |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Problem Summary:
Auto-learn Static mac entry is removed if the port on which same mac address is dynamically learned is flapped. Static mac address is removed from software as well as hardware.
Description:
- Configure a static mac address w/ auto-learn on port1, say Ethernet 1/1
- Send packets, say from IXIA, on another port port2, say Ethernet 1/2 with same src mac address.
- Mac address is learned on port2 (Ethernet 1/2).
- shut/no shut port2 (Ethernet 1/2)
- The expected behavior is to restore the static mac address w/ src port as port1 (Ethernet 1/1).
However, the actual behavior is that the mac address is removed from both software and hardware tables (even though the show running-config shows the mac address on port1).
Workaround:
- Re-add the static mac entry (in the above example, on port Ethernet 1/1) through the CLI.
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 4.1(2)N1(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuq79866 | Title: | Auto config is pulling random vlan for untagged traffic on trunk port |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:A random vlan is getting set for auto-config when during auto-configuration of the native vlan while sending untagged traffic.
Conditions:Auto-config has to be enabled, along with "switchport trunk native vlan <>" on the port. The profile for auto-config must move vlans from CE mode to Fabricpath. It is during this change to fabricpath the vlan is going down and packets come in on a random vlan, as there is not a native vlan up to be learned on.
Workaround:You can clear the unwanted profile entry with "clear fabric database host dot1q "
More Info:Once native vlan is in Fabricpath mode, this problem shouldn't be seen. It is during the transition the vlan goes down the issue will be seen.
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.318) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsx80410 | Title: | N5K System reboots when # STP instances >> 3140 |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Problem summary:
If the number of STP instances on an N5K system (comprising attached FEXes) exceeds the recommended limit of 3140, then N5K switch may not be able to handle the high number of STP instances and may reboot.
Workaround:
None. Just reduce the number of STP instances to not exceed the recommended limit of 3140.
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 4.0(1a)N2(0.196) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv83438 | Title: | Fwm memleak: acl_install_uninstall |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Memleak
Conditions:
during init
Workaround:
none
Further Problem Description:
none
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.3(0.83) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw05570 | Title: | fwm_trace_log file takes up disk space under /volatile |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
fwm_trace_log file takes up disk space under /volatile
Conditions:
- when execute tac-pac, but fail by "No space left on device"
N5K-A# tac-pac
gzip: stdout: No space left on device
vsh_system returned 256
- There is large fwm_trace_log in volatile:
N5K-A# dir volatile:
135790592 Aug 03 19:29:42 2015 fwm_trace_log
17417372 Aug 03 19:34:41 2015 vim_trace_log
Usage for volatile://sup-local
153374720 bytes used
3911680 bytes free
157286400 bytes total
Workaround:
1.Delete the fwm trace file from /volatile, if it is already created using
delete volatile:fwm_trace_log.tar.gz
2.Clear the trace buffer using
debug platform fwm logging clear_trace_buffer
3.Disable fwm logs using
show platform fwm info trace disable
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 7.0(3)N1(1), 7.0(5)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut49415 | Title: | Logging Levels are lost after first reload post Non-Disruptive ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
User modified logging levels will be lost after reload (manual or otherwise) post a successful ND-ISSU.
Conditions:
Reload the switch after a successful ND ISSU.
Workaround:
Issuing "copy r s" manually after successful ND-ISSU and before reload will make sure the user modified logging levels are retained post reload.
Further Problem Description:
This is happening as during the ND-ISSU process the logging levels are set to default and restored back at the end. After restoring, the logging levels are part of running config and still not copied to the start-up config.
|
|
Last Modified: | 13-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.631), 7.1(3)N1(1), 7.1(3)ZN(0.38), 7.3(0)N1(0.118), 7.3(0)N1(1), 7.3(0)ZN(0.109) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus97195 | Title: | Nexus 5K/6k - FEX HIF port down delay when FEX Fabric member links down |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
FEX Host Interfaces (HIF's) may take ~6-8 seconds to go down, while the Network Interfaces (NIF's) have already gone down.
This may cause extended packet loss as the connecting devices still have link operational with the FEX host ports which has lost it's uplink Network interfaces to parent N5k/6k switch.
Conditions:
When a shutdown for all physical member ports for the FEX Fabric Port-channel is performed.
Traffic loss happens as downlink devices in vPC or in NIC teaming (Active/Standby) would continue sending traffic towards this FEX which has no uplinks available causing blackholing of traffic. Once the host interfaces are down, neighboring device detects link down and moves traffic to redundant link.
Workaround:
If idea is to isolate the FEX, shutdown the FEX Fabric PO instead of physical members or poweroff the FEX.
Issue is not seen with reload of the switch or shutdown of FEX Fabric Port-channel.
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 7.0(2)N1(1), 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.620), 7.1(3)N1(1), 7.1(3)ZN(0.27), 7.2(1)N1(0.304), 7.2(1)N1(1), 7.2(1)ZN(0.68) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut55133 | Title: | N5672: cant't save config after configuring vlan mapping more than 200 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
when we configure vlan mapping more than 200 vlan , we can't save config . and error output .
Nexus5672 %SYSMGR-3-CFGWRITE_SRVFAILED: Service "vlan_mgr"failed to store its configuration (error-id 0x40480005).
Nexus5672 %SYSMGR-2-CFGWRITE_ABORTED: Configuration copy aborted.
Nexus5672 %SYSMGR-3-CFGWRITE_FAILED: Configuration copy failed (error-id 0x401E0000).
Conditions:
when configure vlan mapping more than 200.
Workaround:
once copy to flash and then copy runconfig to startconfig
copy run bootflash:running-config
copy bootflash:running-config startup-config
Further Problem Description:
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.1(2)N1(0.556), 7.1(2)N1(1), 7.1(2)ZN(0.15), 7.2(0)N1(1), 7.2(1)N1(0.17), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu62888 | Title: | N5K/N6K ISIS Neighbor with network type p2p adjacency not coming up |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On a nexus 5000/6000 series switch, ISIS Neighbor with network type p2p is not coming up with routers running IOS-XR
Conditions:
None
Workaround:
None
Further Problem Description:
None
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.3(0)BZN(0.47), 7.3(0)ZN(0.103) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut53085 | Title: | mmap error for port-channel services |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show port-channel internal event-history all
mmap: Cannot allocate memory
show port-channel internal event-history errors
mmap: Cannot allocate memory
nexus# show tech-support details >bootflash:techfile1
mmap: Cannot allocate memory
#tac-pac bootflash:///showtech
mmap: Cannot allocate memory
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: * | 7.1(3)N1(0.623), 7.1(3)N1(1), 7.1(3)ZN(0.30), 7.2(1)N1(0.240), 7.2(1)N1(1), 7.2(1)ZN(0.6) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw10467 | Title: | need to add "no nego auto" when connecting N6K to M1 with 1000base-LH |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Continuous link flaps when connecting N6K to a M1 interface using 1000base-LH SFP
Conditions:
connecting N6K to a M1 interface using 1000base-LH SFP
Workaround:
Hardcode speed and duplex and add "no negotiate auto"
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu67017 | Title: | N6K/N56xx CoPP arp/ipv6-nd policy CIR set to 8000 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
CIR for arp/ipv6-nd policy is set at 8000.
Customized arp policy does not affect this value.
Conditions:
Upgrade to 7.0(6)N1(1) or 7.1(1)N1(1)
Workaround:
To modify ARP copp policer CIR, copp-system-class-icmp-echo needs to be modified.
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.125), 7.1(2)N1(0.560), 7.1(2)N1(1), 7.1(2)ZN(0.21), 7.2(0)N1(1), 7.2(1)N1(0.29), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuj75434 | Title: | DHCP Relay do not work for secondary vlans for both IPv4 and IPv6 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
DHCP relay is configured on the switch and private vlan is used. DHCP worked fine before. But after upgrade, DHCP client from secondary vlan do not get ip address. It seems from ethanalyzer the switch did receive the discover packet but did not relay it.
Conditions:
upgrade from 5.2(1)N1(4) to 6.0(2)N2(1).
Workaround:
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(2) |
|
Known Fixed Releases: | 7.0(2)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul00229 | Title: | N6K - PIM Registers Misclassified as PIM Hellos by COPP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The default COPP policy on a Nexus 6K acting as a multicast RP will incorrectly
classify all incoming PIM register packets as PIM hello packets.
Conditions:
If a high rate of registers is received, PIM hellos will be dropped causing all PIM neighbors to be lost because The default COPP policy on a Nexus 6K acting as a multicast RP will incorrectly
classify all incoming PIM register packets as PIM hello packets
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(2) |
|
Known Fixed Releases: * | 7.0(7)ZN(0.108), 7.1(2)N1(0.551), 7.1(2)N1(1), 7.1(2)ZN(0.10), 7.2(0)N1(1), 7.2(1)N1(0.3), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv77922 | Title: * | FEX 2348UPQ Fan speed constantly fluctuating |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: * | Symptom:
FEX 2348UPQ in 5600/6000 seeing subtle vibration due to fan speed fluctuation.
Conditions:
FEX 2348UPQ in 5600/6000
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 01-OCT-2015 |
|
Known Affected Releases: | 7.2(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw05533 | Title: | fwm_trace_log file takes up disk space under /workspace |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
fwm_trace_log file takes up disk space under /workspace
Conditions:
- when execute tac-pac, but fail by "No space left on device"
N5K-A# tac-pac
gzip: stdout: No space left on device
vsh_system returned 256
- There is large fwm_trace_log in volatile:
N5K-A# dir volatile:
135790592 Aug 03 19:29:42 2015 fwm_trace_log
17417372 Aug 03 19:34:41 2015 vim_trace_log
Usage for volatile://sup-local
153374720 bytes used
3911680 bytes free
157286400 bytes total
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv27541 | Title: | N6k DFA: No Mac on BD not seen |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
profile pulled through autoconfig using data trigger not aging out after virtual machine going out of vlan.
no mac on BD is not received from FWM to HMM.
Conditions:
image - kokomo n6000-uk9.7.3.0.N1.0.43.bin
setup - 2 layer vpc of n6k switches
network - ethernet virtual private network
Workaround:
Further Problem Description:
Auto-pull was done for vlan 801 on Peer #1. The host (2LayerVPC) was on eth 103/1/31. The host MAC is long gone, but there does not seem to be a "lazy aging" timer running on that vlan on either vpc switch. And the profile is still active.BD 800 not empty.Lazy timers unable to delete profile.
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.43) |
|
Known Fixed Releases: * | 7.3(0)N1(0.150), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur39762 | Title: | Nexus 5600: FWM hap reset with "sh hardware internal bigsur asic x eye" |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Nexus 5600 might experience an FWM hap reset when hidden command show hardware internal bigsur asic 0 eye-measurements is issued.
Conditions:
Hidden command show hardware internal bigsur asic 0 eye-measurements is issued on a Nexus 5600
Workaround:
Do not issue the hidden command show hardware internal bigsur asic 0 eye-measurements
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.632), 7.1(3)N1(1), 7.1(3)ZN(0.40), 7.2(1)N1(0.318), 7.2(1)N1(1), 7.2(1)ZN(0.80), 7.3(0)N1(0.118), 7.3(0)N1(1), 7.3(0)ZN(0.110) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw07732 | Title: | N5k Post-7.1(0)N1(1a) BPDU Guard Triggered When Operationally Disabled. |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
BPDU Guard is not operationally enabled but continues to trigger.
Conditions:
1. Enable BPDU Guard on the port level (spanning-tree bpduguard enable) for the N5k and allow it to be triggered.
2. Remove BPDU Guard from the port level (no spanning-tree bpduguard enable).
3. BPDU Guard will continue to trigger even though it is operationally disabled:
N5k# show spanning-tree internal info all | begin Ethernet1/1 | inc oper|drop|oper | head line 12
oper_portfast 1 <-----
oper_networkport 0
oper_p2p 1
oper_bpdufilter 0
oper_bpduguard 0 <------
oper_loopguard 0
bpdufilter_drop_in 0
bpduguard_drop_in 0
err_dropped_in 0
oper_portfast =TRUE oper_p2p =TRUE
oper_loopguard =FALSE oper_bpdufilter=FALSE
oper_bpduguard =FALSE oper_networkport=FALSE <-------
!
BGL14-1.D.06-N5k-1# 2001 Sep 26 00:25:15 BGL14-1.D.06-N5k-1 %$ VDC-1 %$ %STP-2-BLOCK_BPDUGUARD: Received BPDU on port Ethernet1/1 with BPDU Guard enabled. Disabling port.
Workaround:
Workarounds:
*Reload the switch.
OR
*Configure the offending interface with "spanning-tree bpduguard disable" syntax.
Further Problem Description:
Platform tested: Nexus 5600 Post-7.1(0)N1(1a) (N5K-C56128P)
This trigger occurs in a very specific scenario where an attached device has a single VLAN allowed on the trunk that is not on the allowed list of VLAN's (or is misconfigured as an access port on the attached device).
This typically happens when a non-Cisco device such as a blade switch is connect to the N5k in a multi-tenant enviroment where service provider does not have control over the attached device.
Prior to the BPDU enhancments 7.1(0)N1(1a) a BPDU recieved on a non-allowed VLAN was ignored. However on 7.1(0)N1(1a) and later this BPDU from the disallowed VLAN should trigger BPDU Guard when it is operationally enabled either globally (and interface is operationally port-fast) or on the port level.
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw07725 | Title: | N5k Post-7.1(0)N1(1a) BPDU Guard Not Triggered On Disallowed VLAN |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
BPDU Guard is globally and operationally enabled but does not trigger on disallowed VLAN .
Conditions:
SW01-[Ten1/1]-----[Eth1/1]-N5600k
N5k# show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: VLAN0100-VLAN0101
Port Type Default is disable
Edge Port [PortFast] BPDU Guard Default is enabled <----BPDU guard enabled globally.
Edge Port [PortFast] BPDU Filter Default is disabled
Bridge Assurance is enabled
Loopguard Default is disabled
Pathcost method used is short
STP-Lite is enabled
N5k# show spanning-tree internal info all | begin Ethernet1/1 | inc oper|drop|oper | head line 7
oper_portfast 1 <-----
oper_networkport 0
oper_p2p 1
oper_bpdufilter 0
oper_bpduguard 1 <-----
oper_loopguard 0
bpdufilter_drop_in 0
*Ethernet1/1 on the N5k is operationally portfast and, therefore, BPDU Guard is active.
*The attached device is sending BPDU's but these are ignored. Post Nexus 5600 7.1(0)N1(1a) the BPDU's should trigger BPDU guard.
SW01#show spanning-tree interface tenGigabitEthernet 1/1 detail
Port 1 (TenGigabitEthernet1/1) of VLAN0001 is designated forwarding <---- Note attached port is operationally forwarding.
Port path cost 2, Port priority 128, Port Identifier 128.1.
Designated root has priority 32769, address c471.feb6.f340
Designated bridge has priority 32769, address c471.feb6.f340
Designated port id is 128.1, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 25, received 0 <---------Note sent 25.
Workaround:
Workarounds:
*Enabling BPDU Guard on the interface level will trigger the expected behavior.
Further Problem Description:
Nexus 5600 Post-7.1(0)N1(1a) (N5K-C56128P)
This trigger occurs in a very specific scenario where an attached device has a single native VLAN allowed on the trunk that is the only the allowed VLAN on the sending device (or is misconfigured as an access port on the attached device). This VLAN is not on the allowed VLAN list on the connected Nexus port.
This typically happens when a non-Cisco device such as a blade switch is connected to the Nexus 5600 in a multi-tenant environment where the service provider does not have operational control over the attached device. This can create a loop in the data plane.
Prior to the BPDU enhancements on Nexus 5600 7.1(0)N1(1a) a BPDU received on a non-allowed VLAN was ignored. However on 7.1(0)N1(1a) and later this BPDU should trigger BPDU Guard when it is operationally enabled either globally (and interface is operationally port-fast) or on the port level.
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.642), 7.1(3)N1(1), 7.1(3)ZN(0.50), 7.3(0)N1(0.131), 7.3(0)N1(1), 7.3(0)ZN(0.120) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCur11793 | Title: | Host entries for member-links not cleaned up once portchannel is up |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
The port channel member links are shown as data-snooping ports.
However, the baseline behaviour is such that For packets coming in on the PC, the Port-channel should be the only the data snooping port displayed and not its member links.
The issue is that the member links of Port-channel are also reported as associated ports.
Conditions:
This occurs during switch reload, when the member ports come up before the port-channel is applied.
Workaround:
No Workaround
More Info:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.349) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur88420 | Title: | iplus-408: fabric database host not aged out on vPC pair |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:Fabric database host cleanup may not happen as expected upon aging out the hosts.
Conditions:When both vpc peer has orphan host attached
Workaround:Issue following CLI to clear the host database.
- clear fabric database host
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.408) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur11378 | Title: | fwm hap reset with %FWM-2-FWM_ASSERT_FAILURE |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
On Nexus 5500 series, Service "fwm" hap reset with %FWM-2-FWM_ASSERT_FAILURE
Conditions:
FWM Crash happens when following sequence of events happen:
1. non-disruptive ISSU performed in VPC pair with all interfaces shut.
2. After ISSU, enable any of core interfaces.
3. Disable the core interface which was enabled in step[2]. Crash will be hit at [3].
Workaround:
Do not shut all interfaces before initiating ISSU.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | 7.0(1)ZN(0.768), 7.0(6)N1(0.260), 7.0(6)N1(1), 7.1(0)N1(0.1), 7.1(0)N1(0.374), 7.1(0)N1(1), 7.1(0)ZN(0.448), 7.2(0)N1(0.2), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj22176 | Title: | traffic loss on vPC trunk with 1K vlans after the reload of vPC+ primary |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
On a Nexus 5000 vPC+ pair, reloading the primary vPC switch causes up to 4-5 seconds of traffic loss during the vPC reconvergence.
Conditions:
Nexus 5000 vPC+ pair is part of a FabricPath domain with 1000 FabricPath vlans configured in the vlan database and 1000 vlans permitted on the vPC trunk allowed vlan list.
Workaround:
Reducing the number of allowed vlan list on the vPC trunk reduces the traffic loss time.
Further Problem Description:
Problem:
MCECM will reinit all vpc's on secondary after reload because the previous_comp_check is failure. This reinit is causing some traffic loss because the remote end may have already started to pump in the traffic when the port are up for the first time.
Fix:
Since MCECM will reinit all vpc's on secondary when they are brought up for the first time after reload, we should fail the first bringup in the bundle_member_bringup sequence before the port is tx & rx enabled if there is a reinit pending. This fix only works for LACP po
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 5.2(1)N1(5), 6.0(2)N1(2a) |
|
Known Fixed Releases: | 7.0(1)ZN(0.705), 7.0(1)ZN(0.715), 7.0(1)ZN(0.719), 7.0(6)N1(0.210), 7.0(6)N1(0.218), 7.0(6)N1(0.221), 7.0(6)N1(1), 7.1(0)EVN(0.18), 7.1(0)N1(0.344), 7.1(0)N1(0.358) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu14960 | Title: | Static MAC configuration only allows +-1000 characters |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Configuration of a static MAC address with a long list of interfaces is cut off after approx. 1000 characters.
Conditions:
This is seen when configuring a long command for a static MAC which lists a lot of interfaces.
Workaround:
There is no known workaround at this time.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.7), 7.1(1)N1(0.8) |
|
Known Fixed Releases: | 7.1(3)N1(0.619), 7.1(3)N1(1), 7.1(3)ZN(0.26), 7.3(0)ZN(0.68) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq76685 | Title: | N5K: slow convergence with lots of VLANs trunked |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
When a vPC port got shut, the time to switchover the path from vPC port to vPC peer-link increases along with the number of configured VLANs on those ports.
The same thing happens when the vPC port becomes UP again.
Conditions:
Example Topology:
[R1]
shut -> / \ <= vPC port
[ N5K-1 ] === [ N5K-2 ] <= vPC peer
|
[R2]
Traffic Flow : R2 -> N5K-1 -> R1
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.0(3)N1(0.99) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut46788 | Title: | Nexus 5600: Logon prompt not correct when hostname begins with number |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Incorrect hostname at logon prompt when it starts with number.
Symptom:
When the hostname of the switch starts with a number, instead of alphabet the login prompt or the prompt after exiting command prompt does not reflect correct switch hostname.
For example-
change the hostname to "1TEST" and exit.
1TEST# exit
User Access Verification
H1-AA06-5672-A login: <------------- This host name was previous hostname starting with alphabet.
Conditions:
When the hostname of the switch starts with a number, instead of alphabet the login prompt or the prompt after exiting command prompt does not reflect correct switch hostname.
Workaround:
None
Further Problem Description:
None
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 7.0(5)N1(1), 7.3(0.28) |
|
Known Fixed Releases: * | 7.0(7)N1(1), 7.0(7)ZN(0.108), 7.1(1)ZN(0.107), 7.1(2)N1(0.529), 7.1(2)N1(1), 7.2(0)N1(1), 7.2(1)N1(0.5), 7.2(1)N1(1), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh47208 | Title: | Collect additional FWM debuging outputs |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:This is an enhancement bug to have additional FWM debugging capabilities to troubleshoot MAC sync issues.
Conditions:This DDTS is an enhancement, asking the business unit for help with improving the debugging capabilities with FWM.
Workaround:Not applicable to this DDTS.
More Info:Not applicable to this DDTS.
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 5.2(1)N1(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur23755 | Title: | edge-port config does not work w/o mac addr-table loop-detect port-down |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
"mac address-table loop-detect port-down edge-port" does not work until "mac address-table loop-detect port-down" is configured as well.
Conditions:
loop conditions (mac-moves) seen on the host ports and one configures "mac address-table loop-detect port-down edge-port" to shut only the edge port.
Workaround:
Ensure "mac address-table loop-detect port-down" is configured in addition to "mac address-table loop-detect port-down edge-port" for the edge port to be effective.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N2(5), 7.0(4)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuq88206 | Title: | Increase FCF MAC Allocation for Nexus 6004 Platform to 48 |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Currently the FCF MAC allocation for port-channel on the Nexus 6004 is limited to 16. resulting in an FCoE port-channel not coming up.
Conditions:
AT&T reached this 16 limit resulting in an FCoE port-channel not coming up
Workaround:
No
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.1(0)EVN(0.18), 7.1(0)N1(0.357), 7.1(0)N1(1), 7.1(0)ZN(0.433), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.2(0)N1(0.2), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur17586 | Title: | Add Show Trunk Protocol command to show tech-support output. |
|
Status: * | Other |
|
Severity: | 6 Enhancement |
Description: | Symptom:
show trunk protocol is not listed in show tech-support output.
Conditions:
issuing show tech-support
Workaround:
issue from CLI
#show trunk protocol
Further Problem Description:
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu67165 | Title: | pss runtime oifl not showing correct info |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
pss runtime oifl not showing correct info vi command "show platform fwm info pss runtime_oifl".
Conditions:
while running show command.
Workaround:
none.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.3(0)N1(0) |
|
Known Fixed Releases: | 7.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.3(0)ZN(0.79) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv39838 | Title: | CLI to dump all SGs in a system |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
None. This is an enhancement to introduce new CLI.
Conditions:
while running commands. show-tech.
Workaround:
none.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.3(0)N1(0) |
|
Known Fixed Releases: | 7.1(3)N1(0.622), 7.1(3)N1(1), 7.1(3)ZN(0.29), 7.3(0)N1(0.75), 7.3(0)N1(1), 7.3(0)ZN(0.73) |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论