| |
|
Alert Type: | Updated * |
Bug Id: | CSCur78132 | Title: | N2K - Input Align-Err on FEX Host Interfaces |
|
Status: | Fixed |
|
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: | 31-OCT-2015 |
|
Known Affected Releases: | 6.0(2)N2(4) |
|
Known Fixed Releases: * | 7.1(3)N1(0.674), 7.1(3)N1(1), 7.3(0)N1(0.160), 7.3(0)N1(1), 7.3(0)ZN(0.148) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun69004 | Title: | Nexus 5K/6k sends untagged BPDUs on vPC when leg on vPC Primary is down |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
switch connected via a vPC will see the following STP state:
Switch# show spanning-tree interface port-channel 17
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg BKN*1 128.4112 P2p *PVID_Inc
VLAN0200 Desg BKN*1 128.4112 P2p *PVID_Inc
VLAN0500 Desg BKN*1 128.4112 P2p *PVID_Inc
Conditions:
Two Nexus switches running 7.0(0)N1(1)
vPC leg on vPC Primary is down
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 07-OCT-2015 |
|
Known Affected Releases: | 7.0(0)N1(1.1) |
|
Known Fixed Releases: * | 7.0(1)N1(0.154), 7.0(1)N1(1), 7.1(0)N1(0.120), 7.1(0)N1(1), 7.1(0)ZN(0.239), 8.3(0)CV(0.163) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun10615 | Title: | N6k - Software MAC learning of SVI MAC in HW table |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IP/ARP connectivity affected as a result of Dynamic learning of SVI MAC on Nexus 6000 switch. This may lead to black-holing of traffic.
Conditions:
SVI MAC (BIA) is seen coming from the network due to a network loop. Not all type of packets would cause MAC table to updated as Dynamic for a System MAC. So far is seen to be happening with DHCP packets.
Workaround:
Clearing of MAC (clear mac address-table) removes such entry and connectivity is restored. However if a DHCP packet with SMAC as SVI is looped/reflected again we'll have the same condition.
Further Problem Description:
Example, when in problem state:-
sh int vlan x
Hardware is EtherSVI, address is 0000.0000.0001
sh mac address-table address 0000.0000.0001
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link
VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+------------------
* X 0000.0000.0001 dynamic 1800 F F Po10 >>>> learning from network
|
|
Last Modified: | 07-OCT-2015 |
|
Known Affected Releases: | 6.0(2)N2(3), 7.0(0)N1(0.527) |
|
Known Fixed Releases: * | 6.0(2)N2(5.97), 6.0(2)N2(6), 7.0(0)N1(0.106), 7.0(0)N1(1), 7.0(1)ZN(0.497), 7.0(4)N1(0.133), 7.0(4)N1(1), 7.1(0)ZN(0.224), 8.3(0)CV(0.163) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv72180 | Title: | auto-config profile stuck in PPM Del Wait |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PPM issue is seen after multiple repeated auto-config failures. We see some MTS message stuck in the queues for a long time
`show fabric database host summary`
Number of instances applied : 14
Number of VDP hosts : 0
Recovery Timeout Value : 30 minutes
Cleanup Timeout Value : 15 minutes
VDP Add Suppression Timeout : 2 minutes
Profiles checked for aging : 30 minutes
`show fabric database host detail`
Active Host Entries
flags: L - Locally inserted, V - vPC+ inserted, R - Recovered, X - xlated Vlan
VLAN VNI STATE FLAGS PROFILE(INSTANCE)
501 30006 Profile Active LV vlNameNetworkL2Profile(instance_def_501_3)
Displaying Data Snooping Ports
Interface Encap Flags State
Eth1/11 501 L Profile Active
502 30001 Profile Active LV vlNameNetworkL2Profile(instance_def_502_150)
Displaying Data Snooping Ports
Interface Encap Flags State
Eth1/11 502 L Profile Active
Eth192/1/4 502 L Profile Active
503 30002 PPM del wait vlNameNetworkL2Profile(instance_def_503_4)
Got no hosts for this profile
504 30010 Profile Active L vlNameNetworkL2Profile(instance_def_504_5)
Displaying Data Snooping Ports
Interface Encap Flags State
Eth1/35 504 L Profile Active
Eth182/1/6 504 L Delete Holddown
505 30009 Profile Active L vlNameNetworkUniversalTfProfile(instance_def_505_1)
Displaying Data Snooping Ports
Interface Encap Flags State
Eth182/1/8 505 L PPM del wait
707 20707 Profile Active V vlNameNetworkL2Profile(instance_def_707_2)
Got no hosts for this profile
4055 20002 Profile Active LV defaultNetworkUniversalTfProfile(instance_def_4055_25)
Displaying Data Snooping Ports
Interface Encap Flags State
Eth192/1/3 4055 L Profile Active
Eth192/1/48 4055 L Profile Active
4058 20003 Profile Active LV defaultNetworkUniversalTfProfile(instance_def_4058_28)
Displaying Data Snooping Ports
Interface Encap Flags State
Eth192/1/41 4058 L Profile Active
4060 20001 Profile Active V defaultNetworkUniversalTfProfile(instance_def_4060_39)
Got no hosts for this profile
Conditions:
7.1(0)N1(1a)
Workaround:
Reload the switch
Further Problem Description:
|
|
Last Modified: | 27-OCT-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.122) |
|
Known Fixed Releases: | 7.1(3)N1(0.630), 7.1(3)N1(1), 7.1(3)ZN(0.37), 7.2(2)N1(1), 7.3(0)N1(1), 7.3(0)ZN(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv91507 | Title: | Migrating Fex from N7K to N6K/N5K may result in the FEX failing to boot |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
A FEX which is attached to an N7K running 6.2(12) or 7.2(0)D1(1) may fail to boot when moved to a Nexus 6K or Nexus 5K:
08/21/2015 00:51:59.593386: Module register received
08/21/2015 00:51:59.594388: Image Version Mismatch
08/21/2015 00:51:59.595438: Registration response sent
08/21/2015 00:51:59.595794: Requesting satellite to download image
08/21/2015 00:53:52.981356: Image preload failed.
08/21/2015 00:54:00.132452: Deleting route to FEX
08/21/2015 00:54:00.141675: Module disconnected
08/21/2015 00:54:00.143718: Module Offline
08/21/2015 00:54:00.152157: Deleting route to FEX
08/21/2015 00:54:00.159062: Module disconnected
08/21/2015 00:54:00.161167: Offlining Module
Conditions:
Issue has been observed on 2248TP-E FEX conencted to F3 line card on N7K.
Workaround:
On 5K/6K running 7.2, the issue can be corrected by unplugging and plugging the cable back in at the FEX uplink.
Further Problem Description:
Migrating Fex from N7K to N6K/N5K may result in the FEX failing to boot
|
|
Last Modified: | 14-OCT-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw30036 | Title: | Incorrect BGP-3-BADPEERAS: error log after reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Following the reload of a 6001, BGP neighborship can not be established due to BGP-3-BADPEERAS:. However neighbor is sending the correct ASN.
Conditions:
Reload - 7.1(0)N1(1a)
Workaround:
Remove the BGP configuration and add back.
Further Problem Description:
Neighbor will not come up due to a bad peer AS error. However, the configurations are correct and it was working fine until the N6001 was reloaded. Somehow the N6K thinks the AS should be 65004 even though it is configured as 65001. Please see below.
N6K3
2015 Sep 15 08:41:38 N6K3-DMZ_Agg1 %BGP-3-BADPEERAS: bgp-32496 [5112] VRF default, Peer 10.10.45.4 - bad remote-as, expecting 65004 received 65001.
router bgp 32496
neighbor 10.10.45.4 remote-as 65001
bfd
ebgp-multihop 5
address-family ipv4 unicast
send-community
soft-reconfiguration inbound
address-family ipv6 unicast
soft-reconfiguration inbound
N6K3-DMZ_Agg1# sho run | inc 65004
N6K3-DMZ_Agg1#
N6K3-DMZ_Agg1# sho run | inc 65001
neighbor 10.10.45.4 remote-as 65001
N6K3-DMZ_Agg1# sho ip bgp neigh 10.10.45.4
BGP neighbor is 10.10.45.4, remote AS 65004, ebgp link, Peer index 2
BGP version 4, remote router ID 0.0.0.0
BGP state = Idle, down for 11:20:31, retry in 00:00:13
BFD live-detection is configured
External BGP peer might be upto 5 hops away
Last read 00:00:48, hold time = 180, keepalive interval is 60 seconds
Last written never, keepalive timer not running
Received 580 messages, 0 notifications, 0 bytes in queue
Sent 581 messages, 580 notifications, 0 bytes in queue
Connections established 0, dropped 0
Connection attempts 299
Last reset by us 00:00:48, due to bad peer AS error (65001)
N3K1
2015 Sep 15 12:39:13.275680 bgp: 65001 [3619] (default) EVT: Received NOTIFICATION bad peer AS error (0) from 10.10.35.1
router bgp 65001
neighbor 10.10.35.1 remote-as 32496
bfd
ebgp-multihop 5
address-family ipv4 unicast
send-community
soft-reconfiguration inbound
address-family ipv6 unicast
This is from the show bgp event-history cli:
2015 Sep 15 08:51:50.607335 bgp 32496 [5112]: [10672]: Calling callback 'show_ip_bgp_neighbors_cmd' for 'show ip bgp neighbors 10.10.45.4'
2015 Sep 15 08:41:32.967718 bgp 32496 [5112]: [5173]: Callback 'clear_ip_bgp_cmd' returned 0
2015 Sep 15 08:41:32.967587 bgp 32496 [5112]: [5173]: Calling callback 'clear_ip_bgp_cmd' for 'clear ip bgp 10.10.45.4'
2015 Sep 15 08:41:12.457012 bgp 32496 [5112]: [5173]: Callback 'debug_ip_bgp_debug_cmd' returned 0
2015 Sep 15 08:41:12.452985 bgp 32496 [5112]: [5173]: Calling callback 'debug_ip_bgp_debug_cmd' for 'debug ip bgp all'
2015 Sep 15 08:34:10.741997 bgp 32496 [5112]: [8021]: Callback 'show_bgp_summary_cmd' returned 0
2015 Sep 15 08:34:10.741453 bgp 32496 [5112]: [8021]: Calling callback 'show_bgp_summary_cmd' for 'show ip bgp summary vrf all'
2015 Sep 14 21:31:19.091014 bgp 32496 [5112]: [5173]: No command registered for command '_cli_debug_done_cmd'
2015 Sep 14 21:31:19.088906 bgp 32496 [5112]: [5173]: No command registered for command '_cli_debug_filter_done_cmd'
2015 Sep 14 21:31:19.087377 bgp 32496 [5112]: [5173]: Callback '_cli_send_my_command' returned 0
2015 Sep 14 21:31:19.087372 bgp 32496 [5112]: [5173]: Callback '_cli_done_command' returned 0
2015 Sep 14 21:31:19.087328 bgp 32496
|
|
Last Modified: | 14-OCT-2015 |
|
Known Affected Releases: | 7.1(0)N1(1) |
|
Known Fixed Releases: * | 7.3(0)N1(0.159), 7.3(0)N1(1), 7.3(0)ZN(0.147) |
|
|
| |
| |
|
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: | 07-OCT-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.43) |
|
Known Fixed Releases: * | 7.3(0)N1(0.150), 7.3(0)N1(1), 7.3(0)ZN(0.138) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun50553 | Title: | Higher re-covergence time when VPC+ switch comes back after a reload. |
|
Status: | Fixed |
|
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: | 08-OCT-2015 |
|
Known Affected Releases: | 7.0(0)N1(1.1) |
|
Known Fixed Releases: | |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论