| |
Bug Id: | CSCup85771 |
Title: | Nexus 6000 resets SSH intermittently |
|
Description: | Symptom:
A java script is ran to fetch show run interface outputs from a windows machine.
Topology:
Nexus 6001---windows machine
The script establishes a SSH session to collect the outputs. After fetching 3 interface running configurations outputs through the script, the Nexus 6000 switch disconnects the ssh session.
packet capture on the management interfaces shows a RST packet sent from the switch towards the pc to disconnect the SSH session which is buggy.
This script works fine with 6.0(2)N1 code. The issue is seen only on 6.0(2)N2 versions.
Sample working & Non-working output:
Is session connected: true
exit-status: 0
!Command: show running-config interface Ethernet1/1
interface Ethernet1/1
description testing range
switchport mode trunk
switchport trunk allowed vlan 1
spanning-tree port type edge trunk
Non-working:
Is session connected: true
exit-status: -1
Please note that during non-working scenario the script can collect the outputs 3 times, but the 4th try fails because of the RST signal from Nexus 6000 which needs to be investigated.
Please find the attached Java script & outputs under the file name "labrecreate detailed" attached to the bug
Conditions:
seen only on 6.0(2)N2
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: | 5.2(1)N1(8.152), 5.2(1)N1(9), 6.0(2)N2(6.129), 6.0(2)N2(7), 7.0(1)ZN(0.683), 7.0(6)N1(0.194), 7.0(6)N1(1), 7.1(0)N1(0.402), 7.1(0)N1(0.404), 7.1(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCus66054 |
Title: | vPC designated forwarder does not have OIF programmed |
|
Description: | Symptom:
When tried simply reach steady state, the N6K vPC peers are not programming the designated forwarder OIF
Conditions:
VPC switches. Both the peers have same unicast routing metric back to the source, the vPC Primary is the designated forwarder
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut08643 |
Title: | N5K CoPP does not match router ISIS packets |
|
Description: | Symptom:
Router ISIS packets are not matched by the ISIS copp class and router ISIS packets will be hit by class defualt
Conditions:
none
Workaround:
Cannot add customer class map to N5K CoPP.
Can increase class default rate to allow more packets to the cpu
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a), 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(2)N1(0.559), 7.1(2)ZN(0.18), 7.2(0)AB(9), 7.2(0)N1(0.157), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.161), 7.3(0)N1(0.25), 7.3(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCun54576 |
Title: | Nexus6000: License grace period is shown after disabling grace period |
|
Description: | Symptom:
N96-OPTICS(config)# sh lic us
Feature Ins Lic Status Expiry Date Comments
Count
--------------------------------------------------------------------------------
ENTERPRISE_PKG No - Unused Grace 116D 17H
FC_FEATURES_PKG No - Unused Grace 119D 9H
--------------------------------------------------------------------------------
Under comments column, grace period is shown even when license is unused.
Conditions:
Always reproducible as per the problem statement
Workaround:
None
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 7.0(1)N1(0.115) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq61877 |
Title: | L2 Control frames (LACP/CDP/LLDP/CFS etc.) not egress out of the switch |
|
Description: | Symptom:
N5600 or N6k may potentially see no L2 Control PDU's like, LACP/CDP/STP/LLDP/CFS egress out of network ports.
Conditions:
Not exactly known, however in this case SUP ASIC packet buffers are seen stuck. Could be verified using CLI:
show hardware internal buffer info pkt-stats asic-num 0
SUP_HI/SUP_LO has cell count not moving
Workaround:
Not known so far. Possibly reload should clear the stuck buffers.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 7.0(3)N1(0.125), 7.1(0)N1(0.317) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui67441 |
Title: | N6K: sh fcs database vsan <> cause system reload |
|
Description: | Symptom:
Nexus 6000 switch configured for FCoE and large number of FLOGI sessions might reload after typing command show fcs database vsan <>
Conditions:
Large Number of FLOGI Sessions
Workaround:
None:
Further Problem Description:
The reload is due to core dump in FCS process.
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup45280 |
Title: | kernel panic in ethpm |
|
Description: | Symptom:
Kernel panic crashes in ethpm:
sc1-c08-6k1-1# show system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 359759 usecs after Fri Jun 3 14:52:27 2011
Reason: Kernel Panic
Service:
Version: 7.0(2)N1(1)
sc1-c08-6k1-1# show logging onboard stack-trace
Logging time: Fri Jun 3 14:52:25 2011
1307137945:79999999 process ethpm (3966), jiffies 0x2a17a30
invalid opcode
STACK
CPU 6
Process ethpm (3966)
Stack:
Call Trace:
[<801813fc>]page_remove_rmap+0xc6/0xfc
[<8017a4c3>]unmap_vmas+0x344/0x598 (116)
[<8017e2bb>]exit_mmap+0x68/0xe4 (40)
[<80128062>]mmput+0x33/0x86 (12)
[<8012b7b4>]exit_mm+0xe9/0xf1 (32)
[<8012cceb>]do_exit+0x1dd/0x745 (68)
[<8012d2b6>]do_group_exit+0x63/0x8a (20)
[<801358d1>]get_signal_to_deliver+0x2df/0x2f6 (48)
[<80102c33>]do_notify_resume+0x70/0x779 (220)
[<80103b2e>]work_notifysig+0x13/0x25 (-8112)
Conditions:
Unknown
Workaround:
None at this time
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut66989 |
Title: | vPC+ connected fex (2348TQ) black holing ingress traffic |
|
Description: | Symptom:
After the reload of one of the two vPC peers, ingress traffic to a vPC+ connected fed (in this instance N2K-C2348TQ-10GE) received from the connected Nexus 5k is not delivered to the target port.
Conditions:
vPC+ connected fex using QSFP-H40G-CU5M.
Workaround:
shutdown the port-channel loosing traffic on the affected Nexus 5k.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.15) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut83532 |
Title: | 5600 vPC Pair loops back unknown unicast packets |
|
Description: | Symptom:
MAC move notifications on switch connected to 5600 vPC pair.
Conditions:
Nexus 5600 in vPC, unknown unicast packets hitting the switch.
Workaround:
We can static the MAC addresses on the connected swtich(es) to avoid looping the frames in the network and losing flows when the flap occurs, but this is not a good option if the MAC moves under a normal network circumstance, e.g. Vmotions in a VMware environment.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.1(1)N1(0.512) |
|
Known Fixed Releases: | 7.0(7)ZN(0.131), 7.1(2)N1(0.543), 7.1(2)ZN(0.2), 7.2(1)N1(0.242), 7.2(1)N1(1), 7.2(1)ZN(0.8) |
|
|
| |
| |
Bug Id: | CSCut60043 |
Title: | N6004 - 40g transceivers have delay for link-up on module boot |
|
Description: | Symptom:
On Nexus 6004 chassis or module reload 40g interfaces can take up to 50 minutes to come online and forward traffic. Seen with QSFP-40G-LR and WSP-Q40GLR4L, though we do not expect it to be limited to just these transceivers
Conditions:
Reloading a chassis or LEM module that contains at least one 40g transceiver in a 6004 chassis
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 7.0(2)N1(1), 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo28747 |
Title: | N5K/6K: FWM core during ISSU |
|
Description: | Symptom:
A Nexus 5K/6K switch may experience FWM crash upon ND-ISSU in NX-OS 7.x.
This crash may be seen when we already have a 7.x image which is upgraded from either 5.x/6.x and are now trying to perform a Non-Disruptive ISSU to any post 7.0(0)N1(1) image.
Conditions:
FWM crash may be seen when a double step ISSU is performed on Nexus 5K/6K switches from a 5.x/6.x release to a 7.x and then another ISSU to a subsequent 7.0/7.1/7.2 release. This crash is seen only when multicast traffic/groups is present in the setup. This crash is not applicable to those customers who are running only unicast/broadcast traffic.
Possible upgrade scenarios
Following is a detailed list of scenarios in which this bug may/maynot be seen:
Scenario 1: Customer is currently using 5.x/6.x release and upgrading to 5.x+/6.x+
No issue.
Scenario 2: Customer is currently using 5.x/6.x release and upgrading to 7.0(x)/7.1(x)
The issue will not affect customers topology until and unless they upgrade to 7.0(x)/7.1(x). After the upgrade, Check whether the Switch has the issue from the CLI mentioned below [Section More-Info]. If the issue exists, Refer to Workaround or upgrade options [Section Workaround] mentioned below, based on customers agreement.
Scenario 3: Customer is currently using 5.x/6.x release and upgrading to 7.2(0)N1(1)-
In this case ND-ISSU is not supported. So this issue will not be seen.
But due to a limitation with Disruptive upgrade between 5.x/6.x to 7.2(0)N1(1) (Limitation - A direct upgrade between these images will lead to loss/mismatch of breakout configs), the customer should perform the upgrade by doing a fresh installation of 7.2(0)N1(1) - Write erase and reload freshly with 7.2(0)N1(1) image. Once the switch is up, reconfigure the switch with previous configs.
Scenario 4: Customer is currently using 7.0(2)N1(1) - 7.0(5)N1(1), has already performed Step1 ISSU(from 5.x/6.x to 7.x) and is now upgrading to higher 7.0(x)+/7.1(x)+
Check whether the Switch has the issue from the CLI mentioned below [Section More-Info]. If the issue exists, then ND ISSU will lead to crash. Refer to Workaround or upgrade options [Section Workaround] mentioned below, based on customers agreement.
Scenario 5: Customer is currently using 7.0(2)N1(1) - 7.0(5)N1(1), has already performed Step1 ISSU(from 5.x/6.x to 7.x) and is now upgrading to 7.2(0)N1(1)
In this case ND-ISSU is not supported. So this issue will not be seen.
But due to a limitation with Disruptive upgrade between 5.x/6.x to 7.2(0)N1(1) (A direct upgrade between these images will lead to loss/mismatch of breakout configs), the customer should perform the upgrade by doing a fresh installation of 7.2(0)N1(1) - Write erase and reload freshly with 7.2(0)N1(1) image. Once the switch is up, reconfigure the switch with previous configs.
Scenario 6: Customer is currently using 7.0(6)N1(1) or 7.1(0)N1(1), has already performed Step1 ISSU(from 5.x/6.x to 7.x) and is now upgrading to higher 7.x+:
Check whether the Switch has the issue from the CLI mentioned below [Section More-Info]. If the issue exists, then ND-ISSU will lead to crash. Refer to Workaround or upgrade options[Section Workaround] mentioned below.
Scenario 7: Customer has started from 7.x release and upgrading to 7.x+ (7.1.x +)
The issue will not be seen on the switch, if the customer has been using 7.x from the beginning and was not using 5.x/6.x before.
Workaround:
Workaround
CASE1: CE Network Setup
Disable IGMP snoop
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUL-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.1(0)N1(1), 7.1(1)N1(1), 7.2(0)N1(0.231) |
|
Known Fixed Releases: | 7.0(7)N1(0.69), 7.0(7)N1(1), 7.0(7)ZN(0.147), 7.1(2)N1(0.570), 7.1(2)ZN(0.30), 7.2(1)ZN(0.15) |
|
|
| |
| |
Bug Id: | CSCut71208 |
Title: | Unknown unicast packets coming from CE not punted to CPU |
|
Description: | Symptom:
pings towards SVI are not responded
Conditions:
currently unknown
Workaround:
start pinging from the affected chassis.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul77425 |
Title: | Nexus 5600/6000: vPC/vPC+ Constant MAC Flush/Learn at FWM |
|
Description: | Symptom:Packet loss can be observed in VPC/vPC+ environment when destination MAC constantly flush/learn. During this time MAC address at FWM cleared and learned again on the vPC secondary device:
Nexus# show platform fwm info mac MAC_ADDR 5 | inc Oper
Operation: Mac delete (10)
Operation: Mac create (9)
Operation: Peer sent; local down and mct learnt (2)
Operation: Mac delete PVRST flush sent to peer (46)
Operation: Mac delete due to hw/sw mismatch (37)
Operation: Mac delete (10)
Operation: Mac create (9)
Operation: Peer sent; local down and mct learnt (2)
Operation: Mac delete PVRST flush sent to peer (46)
Operation: Mac delete due to hw/sw mismatch (37)
Operation: Mac delete (10)
Operation: Mac create (9)
Operation: Peer sent; local down and mct learnt (2)
Operation: Mac delete PVRST flush sent to peer (46)
Operation: Mac delete due to hw/sw mismatch (37)
Operation: Mac delete (10)
Operation: Mac subjected to HW delete due to convert eror in new learn (54)
Operation: Mac subjected to HW delete due to convert eror in new learn (54)
Operation: Mac create (9)
Operation: Peer sent; local down and mct learnt (2)
Operation: Mac delete PVRST flush sent to peer (46)
Operation: Mac delete due to hw/sw mismatch (37)
Conditions:- MAC-address should be learned from vPC/vPC+
- Destination MAC of the traffic is vPC peer SVI interface
Workaround:Configuring command 'peer-gateway' under vPC domain might help for most cases. If this does not work, configure a static MAC addresses.
More Info:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(2), 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu46633 |
Title: | interface vethernet X enters interface range configuration mode |
|
Description: | Symptom:
When configuring "interface vethernet X", the configuration mode changes to interface range mode when it should change to interface mode.
Conditions:
Nexus5600# sh run | i i "system default switchport"
no system default switchport
Nexus5600#
Nexus5600# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Nexus5600(config)# int vethernet 7777
Nexus5600(config-if-range)# bind ?
^
% Invalid command at '^' marker.
Workaround:
Nexus5600(config)# system default switchport
Nexus5600(config)# no interface vethernet 7777
Nexus5600(config)# int vethernet 7777
Nexus5600(config-if)# bind ?
interface Interface
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu39895 |
Title: | Support for dhcp server & client in a non-default vrf topology |
|
Description: | Symptom:
In the DFA Network When the dhcp server CPNR in the non-default vrf and dhcp client in Non-default VRF Placed in different leaf switches . In such condition dhcp client in the non-default vrf not able to get the ip address form the dhcp server .
Conditions:
This issue seen when DHCP server CPNR & dhcp client are in different leaf switches.
Workaround:
Users can keep the dhcp server in Management VRF .
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.167) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv30009 |
Title: | N6K: Traffic blackhole due to MAC mis-programming in hw-stm table |
|
Description: | Symptom:
Traffic blackholed for certain flows. The following drops are observed incrementing on the egress ASIC -
N6K# sh plat fwm info asic-errors 1
BIG_DROP_EGRESS_INVALID_IF: res0 = 1971820 res1 = 0 [63] <<<<<
Conditions:
Nexus 6000 Series Switch running 6.0(2)N2(3).
Workaround:
Reload will clear the condition, please contact Cisco TAC prior.
Further Problem Description:
Trigger is unknown at this time.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu00391 |
Title: | N5K/6K: BCAST flag missing for FTAG 2 |
|
Description: | Symptom:
In a Nexus 5K/6K configured for vPC+, broadcast flag will be missing for FTAG 2 on the vPC+ switch which has affinity for FTAG2
5596A# sh platform fwm info l2mp ftag 2 hw
L2MP FTAG
--------------------------------------------------------------
ftag[0x9ed03e4] id: 2 (0x2)
Topology ID: 0 (0x0)
Ftag flags: MCAST ACTIVE <<------Broadcast Flag is missing
Is stale: FALSE
alternate: 0
ftag_ucast_index: 0
ftag_flood_index: 0
ftag_mcast_index: 65
ftag_alt_mcast_index: 80
rpf: (null)
ftag_mask[0xa54f62c]
Conditions:
Seen in switches where both vPC+ pair go VPC Active/Active due to VPC auto-recovery
Workaround:
Reload the switch in question
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)N1(1a), 7.1(1)ZN(0.120), 7.1(2)N1(0.541), 7.2(1)N1(0.251), 7.2(1)N1(1), 7.2(1)ZN(0.16) |
|
|
| |
| |
Bug Id: | CSCut74135 |
Title: | Fabricpath mode transit - control packets tagged with internal vlan 4041 |
|
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:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 15-JUL-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) |
|
|
| |
| |
Bug Id: | CSCuu85144 |
Title: | N6k HSRP VMAC wrong installed on Standby switch lead to traffic loss |
|
Description: | Symptom:
HSRP VIP is not reachable from Standby HSRP node
Conditions:
HSRP VMAC wrongly installed on Standby switch which leads to the traffic loss
Workaround:
Shut/no Shut of SVI interface
Further Problem Description:
# sh mac address-table vlan 2000
VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+------------------
* 2000 0000.0c07.acc8 static 0 F F sup-eth2
Here VMAC is installed on "sup-eth2" instead of MCT port channel.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N3(0.30) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv30675 |
Title: | N5k/6k -FP BCAST/MCAST broken on VPC edge ports after ftag change |
|
Description: | Symptom:
fabricpath network, spine (N7K), leaf switches (N6K).
Reachability to resources downstream of the vpc+ pair is impacted with intermittend connectivity.
Problem:
If the N7K changes the ftag root by means of setting the set-overload-bit always command,and then switch it back the leaf switch does not get the correct ftag member interfaces. I.e. the vpc member port-channel to the downstream device is no longer in the list and as such broadcasts, i.e. arp requests from the fp network, will not reach the downstream resouces anymore.
Conditions:
fabricpath network. vpc+ on the leaf switches to the downstream resouces.
Workaround:
shut/no shut the vpc port-channel to the downstream resource. Or alternative is to shut/no shut the vpc peer-link.
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup87465 |
Title: | Kernel panic in netstack |
|
Description: | Symptom:
Switch may reload due to a kernel panic in netstack
Conditions:
Not known at this stage
Workaround:
Not known at this stage
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus28101 |
Title: | N5K/6K: Inband TACACS traffic matched against exception-class in CoPP |
|
Description: | Symptom:
In a Nexus 5600/6000, TACACS/Radius traffic coming in on in band SVI interfaces hits class-exception class in Control plane policers.
Conditions:
TACACS/Radius used for access control and in band SVIs used for management Nexus 5600/6000. If there is violations in exception class, authentication failures can be seen due to this issue.
Workaround:
Use mgmt0 interfaces for managing Nexus 5600/6000 switches.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: | 6.0(2)N2(6.129), 6.0(2)N2(7), 7.0(1)ZN(0.726), 7.0(6)N1(0.227), 7.0(6)N1(1), 7.1(1)N1(0.468), 7.1(1)N1(1), 7.1(1)ZN(0.20), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuj46512 |
Title: | Nexus 6000 crash due to qd hap reset |
|
Description: | Symptom:
The Qos Daemon process (qd) on a Nexus 6000 witnesses a crash most commonly after executing the "show tech" command.
Conditions:
A noticeable trigger for this is seen to have occurred on the following command line which has been observed to create a nested loop, inadvertently resulting in a heartbeat timeout:
show platform software qd info counters
Workaround:
The introduction of a better implementation of the ECN feature in the hplus release and later versions is reported to have fixed this issue.
In other words, upgrade to 6.0(2)N2(1) or later.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 19-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus83723 |
Title: | VF- N6K: vlans on vpc legs went to err-dis state on bring up |
|
Description: | Symptom:
2 N6K switches in vpc with 2 dual homed fexes. The fex downstream legs are configured in port-channel. Vlans are configured on port-channel of vpc legs.
When we brough up everything with vlans, the vlan on port-channel of one of the vpc legs going to err-disabled state.
Conditions:
2 N6Ks in vpc with 2 dual homed fexes.
Fex , down stream legs are configured in a port-channels as below
3001 Po3001(SU) Eth LACP Eth101/1/7(P) Eth102/1/7(P)
3002 Po3002(SU) Eth LACP Eth101/1/8(P) Eth102/1/8(P)
Workaround:
The issue was resolved when I shut/no-shut port-channel of vpc leg, on which the vlans going to an err-disabled state.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu06261 |
Title: | N6k Vinic-Forwarding: Multicast failing to reciever after leaf reload |
|
Description: | Symptom:
Receiver off leaf failing to receive multicast traffic after leaf reload and after resending igmp joins.
Conditions:
Leaf reload with a multicast receiver hanging off of it.
Workaround:
Preform a shut/no shut on the VRF to which the impacted receiver belongs to.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv14546 |
Title: | spine is crashing in triggerShutNoShutSpineFacingInterface |
|
Description: | Symptom:
fwm crashes and cored in kokomo image on trigger "triggerShutNoShutSpineFacingInterface" on spine n6k box
Conditions:
vinci setup, spine n6k
Workaround:
Further Problem Description:
trigger involves shut;no shut of interface Ethernet1/2 which faces the spine n6k box
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.51) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu92452 |
Title: | Too many MTS flush generated when connecting VPC+ MST to legacy RPVST |
|
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:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu37102 |
Title: | N5K kernel Panic on AIPC driver causing crash |
|
Description: | N5696 crash due to a kernel panic
Symptom:
Conditions:
This has been seen on Nexus running 7.1(1)N1(1) and 7.0(6)N1(1)
Workaround:
Not known
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | 7.0(6)N1(1.4), 7.0(6)N1(2s), 7.0(7)N1(0.65), 7.0(7)N1(1), 7.0(7)ZN(0.141), 7.1(2)N1(0.575), 7.1(2)ZN(0.36), 7.2(1)N1(0.246), 7.2(1)N1(1), 7.2(1)ZN(0.12) |
|
|
| |
| |
Bug Id: | CSCum11052 |
Title: | mac address out of sync between two switches |
|
Description: | none
Symptom:
When mac aging time is set to 1 sec , there seems to be sync issue due to very low mac aging time if there are large number of mac since FWM takes time to process these macs.
Conditions:
Mac aging time below 50 secs
Workaround:
Currently we have not seen customers setting mac aging time to 1 sec. We tested and found out that mac aging time must be set to 50 sec and more to avoid sync and other flooding issues
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 7.0(1)N1(0.15) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv44148 |
Title: | Ports status "down (SFP not inserted)" although SFP present |
|
Description: | Symptom:
Port on a Nexus 6000 show as "down (SFP not inserted)".
Conditions:
Seen on Nexus 6001 running 7.0(2)N1(1).
Doing a reload doesn't solve the issue.
Workaround:
It seems the only way to get the ports up is to remove all power cables, and insert them back again.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut56369 |
Title: | ARP Ingress packets dropped due to 'BIG_DROP_SRC_VLAN_MBR' |
|
Description: | Symptom:
ARP Ingress packets dropped due to 'BIG_DROP_SRC_VLAN_MBR'
Conditions:
On a vpc+ setup having Iluka image 7.0(6)N1(1), it is observed that ARP ingress packets are dropped on FEX interface connected to PVLAN host when STP mode is changed from PVST to MST.
Workaround:
No workaround exits, should not change STP mode
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.258) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus39651 |
Title: | N6000/N5600: CRC errors on random 40 Gig port after reload |
|
Description: | Symptom:
Random 40 gig interfaces may see CRC errors after the module or switch is reloaded.
Conditions:
Issue seen on Nexus 6000/5600 40G ports.
Affects both 6.x and 7.x release.
Workaround:
Shut/no shut of the interface fixes the issue. This bug is resolved in NX-OS 6.0(2)N2(7), 7.0(6)N1(1) and 7.1(1)N1(1). Note the NX-OS needs to be upgraded on both the transmitting and receiving side for the bug to be cleared.
Further Problem Description:
Note CRC errors could occur for other reasons too such as bad cabling, stomping etc. Signature of this defect.
1)On the switch seeing the CRC errors, the errors are counted as RX_PKT_CRC_NOT_STOMPED
Spine-2# sh int ethernet 1/1 | inc CRC
0 runts 0 giants 445226948 CRC 0 no buffer
Spine-2# show hardware internal bigsur port ethernet 1/1 counters rx | inc CRC
RX_PKT_CRC_NOT_STOMPED | 445226948 | 445226948 | 4641
RX_PKT_CRC_STOMPED | 0 | 0 | 0
Spine-2#
On the other side of the link, the frames are not leaving corrupted.
2)If it is due to this bug, a shut/no shut of the interface will clear the problem.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: | 6.0(2)N2(6.130), 6.0(2)N2(7), 7.0(6)N1(1), 7.1(1)N1(0.477), 7.1(1)N1(1), 7.1(1)ZN(0.30), 7.2(0)N1(0.114), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuv18784 |
Title: | Extra conifigurations appearing on various interfaces in runn config. |
|
Description: | Symptom:
Observed extra configuration in running-config for interface vlan, port-channel sub-int, loopback and Ethernet sub-int.
Conditions:
Workaround:
No workaround exists.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 7.1(2)ZN(0.31), 7.2(1)ZN(0.8) |
|
Known Fixed Releases: | 7.0(7)N1(0.287), 7.0(7)N1(1), 7.0(7)ZN(0.167), 7.1(2)N1(0.587), 7.1(2)N1(1), 7.1(2)ZN(0.51), 7.2(1)N1(0.263), 7.2(1)N1(1), 7.2(1)ZN(0.27) |
|
|
| |
| |
Bug Id: | CSCut67164 |
Title: | [SS fex] rx queue-limit not working |
|
Description: | Symptom:
Rx queue-limit will not work as per configured value
Conditions:
Rx queue-limit will not work as per configured value
Workaround:
NA
Further Problem Description:
Rx queue-limit will not work as per configured value
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.149) |
|
Known Fixed Releases: | 7.2(0)N1(0.172), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.174) |
|
|
| |
| |
Bug Id: | CSCuv01812 |
Title: | N6k: port-security err-disables HIF after switch/fex reload |
|
Description: | Symptom:
HIF ports with port-sec show status as "err-disab" (Error disabled).
Following syslog is generated.
ETHPORT-5-IF_SEQ_ERROR: Error ("Address already secured") communicating with MTS_SAP_ETH_PORT_SEC for opcode MTS_OPC_ETHPM_PORT_PRE_CFG
Conditions:
switch reload or FEX reload
port-security configured on HIF ports
Workaround:
Ports must be shut/no shut to clear the error disable state.
Automated workaround:
event manager applet RESET_ERROR_DISABLED_POTRTS
event syslog pattern "Error disabled. Reason:Address already secured"
action 1.0 syslog priority notifications msg CLEARING_ERROR_DISABLED_PORT
action 1.1 cli command enable
action 1.3 cli command "conf t"
action 1.4 cli command "errdisable recovery cause all"
action 1.5 cli command "no errdisable recovery cause all"
action 1.6 cli command "errdisable recovery cause failed-port-state"
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 7.0(5)N1(1), 7.1(1)N1(1), 7.2(0)N1(1) |
|
Known Fixed Releases: | 7.0(7)N1(0.285), 7.0(7)N1(1), 7.0(7)ZN(0.163), 7.1(2)N1(0.576), 7.1(2)ZN(0.39), 7.2(1)N1(0.255), 7.2(1)N1(1), 7.2(1)ZN(0.21) |
|
|
| |
| |
Bug Id: | CSCur26244 |
Title: | Nexus 6000/5600 FCoE performance issue when in 40G Fabric mode. |
|
Description: | Symptom:
Slow FC or FCOE Performance with Nexus N6004, N5696Q, or N56128P.
Selective Retransmission Request (SRR) may be logged on host or storage.
Drops for no drop traffic on egress ports
Conditions:
Running default fabric-mode 40g AND using Nexus N6004, N5696Q, or N56128P platform.
Can also be seen with 10G fabric mode when traffic flow is high for a single class of traffic, and multiple ingress ports send data to the same egress port
Workaround:
Caveat:
Since this is a register change, it does NOT survive a reload
All upgrades have to be disruptive
Since it is a register change, recommend only experienced folks do these register changes.
Common Step:
Find the global asic number using ?show platform fwm info pif <>?
For 40G fabric mode, do the following:
1. Get the current register value using
show hardware internal bigsur asic registers match .*big_bmef_glb_CFG_glb_fi_addr_0
Register Name | Offset | Value
---------------------------------+----------+-----------
big_bmef_glb_CFG_glb_fi_addr_0 | 0x2800c | 0x8c43
NOTE: If the value is 0x8c7d already, then you have the fix. No need to make any changes listed below
2. Change the register using
debug hardware internal bigsur asic write-mem 0x2800c 0x8c7d
3. Verify the change with
show hardware internal bigsur asic registers match .*big_bmef_glb_CFG_glb_fi_addr_0
Register Name | Offset | Value
-----------------------------------+---------+-----------
big_bmef_glb_CFG_glb_fi_addr_0 | 0x2800c | 0x8c7d
For 10G fabric mode, do the following:
1. Get the current register value using
show hardware internal bigsur asic registers match .*big_bmef_glb_CFG_glb_fi_addr_0
Register Name | Offset | Value
---------------------------------+----------+-----------
big_bmef_glb_CFG_glb_fi_addr_0 | 0x2800c | 0x28c43
NOTE: If the value is 0x28c7d already, then you have the fix. No need to make any changes listed below
2. Change the register using
debug hardware internal bigsur asic write-mem 0x2800c 0x28c7d
3. Verify the change with
show hardware internal bigsur asic registers match .*big_bmef_glb_CFG_glb_fi_addr_0
Register Name | Offset | Value
-----------------------------------+---------+-----------
big_bmef_glb_CFG_glb_fi_addr_0 | 0x2800c | 0x28c7d
For changing buffer pool limits,
1. Check if the customer is using pool 1 & pool 2, from the output of ?show platform software qd info?
Sample output of ?show platform software qd info?
Fabric mode : 10G Fabric Mode
10G Port 40G Port
pool| total| xoff| xon| xcos| cls| total| xoff| xon| xcos| cls
uc 0| 100| 60| 30| 0| 01| 100| 60| 30| 0| 01
uc 1| 439| 106| 46| 0| 02| 926| 504| 224| 0| 02
uc 2| 0| 0| 0| 0| 01| 0| 0| 0| 0| 01
2. If 'total' shows a non-zero value for uc1 or uc2, then change the max buffer allocation for that pool.
Step 1: Check current value of pool max using
show hardware internal bigsur asic registers match .*big_bmef_pcl_CFG_p0_frh_uq_pool1_max
Register Name | Offset | Value
-------------------------------------------------------+-----
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.368) |
|
Known Fixed Releases: | 7.0(6)N1(0.276), 7.0(7)ZN(0.113), 7.0(7)ZN(0.156), 7.1(0)N1(0.388), 7.1(0)N1(1), 7.1(0)ZN(0.462), 7.2(0)N1(1), 7.2(0)ZN(0.91) |
|
|
| |
| |
Bug Id: | CSCur89241 |
Title: | N2K-C2348 FEX does not come up due to "SDP timeout/SFP Mismatch" |
|
Description: | Symptom:
A Nexus N2K-C2348TQ-10GE or N2K-C2348UPQ-10GE FEX connected to a Nexus 5K/6K parent might not come up at all or intermittently fail to come up after reloads. A show interface on the parent switch will indicate the FEX fabric interfaces to be in SDP timeout/SFP Mismatch state
N6K(config-if-range)# show int eth 1/21-28 brief
--------------------------------------------------------------------------------
Ethernet VLAN Type Mode Status Reason Speed PortInterface Ch #
--------------------------------------------------------------------------------
Eth1/21 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/22 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/23 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/24 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/25 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/26 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/27 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Eth1/28 1 eth fabric down SDP timeout/SFP Mismatch 10G(D) --
Conditions:
Seen in a N2K-C2348TQ-10GE or N2K-C2348UPQ-10GE FEX connected to a Nexus 5K/6K. This issue is resolved in NX-OS 7.1(1)N1(1)
Workaround:
Upgrade the parent N5K/6K to NX-OS 7.1(1)N1(1) and power cycle the the FEX few times with fabric connection to the parent in place. If the FEX does not come online contact TAC
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.412) |
|
Known Fixed Releases: | 7.0(7)ZN(0.108), 7.1(1)N1(1), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCus36208 |
Title: | PTPLC core due to mem leak |
|
Description: | Symptom:
PTPLC may crash unexpectedly.
Conditions:
This was first seen on a N6K running 7.0(2)N code.
Workaround:
Unknown at this point.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 7.0(2)N1(1) |
|
Known Fixed Releases: | 7.0(1)ZN(0.739), 7.0(6)N1(0.238), 7.0(6)N1(1), 7.1(1)N1(0.447), 7.1(1)N1(0.77), 7.1(1)N1(1), 7.2(0)AB(2), 7.2(0)N1(1), 7.2(0)VZN(0.7), 7.2(0)ZN(0.120) |
|
|
| |
| |
Bug Id: | CSCut35476 |
Title: | Bigsur FAULTY slot 0 asic 3, bigsur_stm_dma_monitor_timer_hdlr |
|
Description: | Symptom:
On a Nexus 6000/5600, an ASIC might get declared faulty and following log messages can be seen.
%USER-2-SYSTEM_MSG: Bigsur FAULTY slot 0 asic 3, bigsur_stm_dma_monitor_timer_hdlr - bigsurusd %BIGSURUSD-3-BIGSUR_SYSLOG_ERROR: EDMA update channel faulty on slot 0 asic 3
Several ports on the ASIC will be impacted due to this channel being stuck.
Conditions:
Seen on N6000/5600 during layer 2 instabilities such as L2 bridging loop.
Workaround:
If seen on a LEM, reload LEM. If seen on fixed switch, reload switch.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.134) |
|
Known Fixed Releases: | 6.0(2)N2(6.135), 6.0(2)N2(7), 7.0(6)N1(0.267), 7.0(6)N1(1), 7.1(1)N1(0.493), 7.1(1)N1(1), 7.1(1)ZN(0.46), 7.2(0)N1(0.162), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCut55653 |
Title: | interface-vlan info is not propagated to vPC leading to inconsistency |
|
Description: | Symptom:
We will not see interface-vlans (SVI) information not getting propagated to vPC resulting into SVI Type-2 vPC inconsistency
Conditions:
On a vPC pair switches (Nexus 5k/6k), have multiple SVIs (interface-vlans) configured and perform either one of the switch reload or MCT (vPC peer-link) flap.
Workaround:
There is no workaround for this issue.
Further Problem Description:
This being vPC type-2 consistency, we will not see any functionality impact and vPC remains up on both the vPC pair Nexus switches.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.144) |
|
Known Fixed Releases: | 7.2(1)N1(0.268), 7.2(1)N1(1), 7.2(1)ZN(0.32) |
|
|
| |
| |
Bug Id: | CSCuq46228 |
Title: | FWM hap reset at fwm_ds_trace_add() |
|
Description: | Symptom:FWM core happens at fwm_ds_trace_add() routine.
Conditions:If FWM trace buffer size is configured as 300MB,then this problem can occur
Workaround:Configure FWM trace buffer size as 20,40 or 80MB.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.291) |
|
Known Fixed Releases: | 7.1(0)N1(0.1), 7.1(0)N1(0.363), 7.1(0)N1(1), 7.1(0)ZN(0.438), 7.1(2)N1(0.2), 7.1(2)N1(1), 7.2(0)N1(0.2), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCut74244 |
Title: | [iluka MR5] Fex not coming up after ISSU ND |
|
Description: | Symptom:
Fex are not up in the secondary switch
Conditions:
Did a reload on the secondary switch before doing the ISSU ND.
Workaround:
Did shut / no shut on the up-link port.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 7.0(6)N1(0.6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue02576 |
Title: | N5K / N6K: port-profile service crash after VLAN changes |
|
Description: | Symptom:
Port-profile crash when VLAN topology is modified.
2013 Jan 11 17:46:45 SWITCH %SYSMGR-2-SERVICE_CRASHED: Service "port-profile" (PID 3599) hasn't caught signal 11 (core will be saved).
2013 Jan 11 17:46:45 SWITCH %SYSMGR-2-HAP_FAILURE_SUP_RESET: System reset due to service "port-profile" in vdc 1 has had a hap failure
This crash has also been seen in a FabricPath environment when issuing 'show platform fwm info l2mp ftag <>' for a non-existent ftag id.
In some cases, due to CSCue55816, there may not be any core file available for investigation.
The 'show process log' can be used to decode the stack and confirm whether this bug is being hit.
Conditions:
This is a corner case condition which has been seen in several situations, all of which involving changes to the VLAN topology.
- In a FabricPath environment, when moving VLAN(s) from one topology to another
- In a classical ethernet environment, when removing the access VLAN from a port
- After a reboot of a connected FEX, which triggers VLAN reprogramming on the parent switch
There are likely other, unknown triggers as well.
Workaround:
No known workaround.
Further Problem Description:
This issue is fixed in the version 5.2(1)N1(7) as it is found on 5.2(1)N1(5)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.0(2)N1(0.376), 6.0(2)N1(1) |
|
Known Fixed Releases: | 5.2(1)N1(5), 5.2(1)N1(6), 5.2(1)N1(7), 9.9(0)BS(0.13) |
|
|
| |
| |
Bug Id: | CSCuv25016 |
Title: | sh forwarding internal message counts - N6K/N5K switch reloads: fwm core |
|
Description: | Symptom:
fwm crashes and cored in iluka_ci image on trigger "sh forwarding internal message counts" on n6k box
consistently reproducible
Conditions:
Workaround:
Further Problem Description:
packet duplication occurring
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 7.0(7)N1(0.59) |
|
Known Fixed Releases: | 7.0(7)N1(0.288), 7.0(7)N1(1), 7.0(7)ZN(0.168) |
|
|
| |
| |
Bug Id: | CSCus18209 |
Title: | VLAN translation after Non-disruptive ISSU to 7.1(0)N1() image |
|
Description: | Symptom:
After a non disruptive ISSU, FEX fabric interfaces continuously flap after VLAN translation is configured on either an ST or AA FEX.
A "show interface" for the FEX fabric interface(s), that continually flap, indicates an (SDP timeout/SFP mismatch).
Conditions:
Non-disruptive ISSU to Iluka Plus release followed by VLAN translation configuration on a FEX fabric interface..
Workaround:
1) After non-disruptive ISSU, shut/no-shut the port on which the vlan translation needs to be configured.
2) Disruptive ISSU or clean reload.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.426), 7.1(0)N1(0.435) |
|
Known Fixed Releases: | 7.1(0)N1(0.438), 7.1(0)N1(1a), 7.1(0)ZN(0.533), 7.2(0)N1(1) |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论