| |
|
Alert Type: | Updated * |
Bug Id: | CSCty30696 | Title: | Changes in IFTMC for Flanker ASIC |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
F-Series linecard may experience a core of the IFTMC component, and generate a core file. This may also lead to a HAP (High Availability Policy) reset of the linecard.
Conditions:
Error in hardware index management.
Exact triggers for issue are not clear, so the fix is in the IFTMC component handling.
Workaround:
N/A
Fix is in 6.2(6) and later codes.
More Info:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 6.1(4a), 7.0(0)FT(0.1) |
|
Known Fixed Releases: * | 6.2(0.214)S0, 6.2(0.228)S0, 6.2(0.233)S9, 6.2(0.243)S3, 6.2(0.247)S0, 6.2(0.248)S0, 6.2(0.253)S0, 6.2(0.260)S0, 6.2(0.282)S0, 6.2(0.61)S16 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux60618 | Title: | BGP RR doesn't send update |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
If inter-as vpnv4 configuration is present in BGP config RR doesn't send update to RR-clients
Conditions:
inter-as vpnv4
Workaround:
no workaround
Further Problem Description:
.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.241), 7.0(3)I3(0.242), 7.0(3)I3(1), 7.3(0)D1(0.197), 7.3(0)HIB(0.3), 7.3(0)IZN(0.13), 7.3(0)N1(0.257), 7.3(0)N1(1), 7.3(0)ZD(0.224), 7.3(0)ZN(0.233) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux20846 | Title: | Nexus 6k: IGMP HAP Reset during "install all" upgrades with IGMPv3 |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
During an install upgrade of NX-OS in a VPC Nexus 5K/6k vPC, the peer switch may crash due to the IGMP process during pre-upgrade checks.
VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "igmp" (PID XXXX) hasn't caught signal 11 (core will be saved).
Conditions:
Seen on systems with IGMPv3 configurations and if switch has received IGMP v3 membership reports. This issue is only seen during upgrades or during IGMP process restarts and not during steady state.
Workaround:
Disable IGMP snooping globally on the vPC pair of switches prior to upgrade
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: * | 6.2(16)S16, 7.0(7)ZN(0.266), 7.0(8)N1(0.314), 7.0(8)N1(1), 7.1(3)ZD(0.61), 7.1(3)ZN(0.125), 7.1(4)N1(0.690), 7.1(4)N1(1), 7.3(0)D1(0.166), 7.3(0)GLF(0.44) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc94570 | Title: | N7k: Fabricpath traffic loss for unicast flooded traffic |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: * | Symptom:
Unidirectional North-South traffic does not flow through VPC+ ports in F2 modules
Conditions:
When the core ports and vpc+ edge ports are part of the same F2/F2E ASIC instance, the unknown unicast flood may be incorrectly pruned and not make it out of the vpc+ ports
Workaround(s):
Locate the vpc+ ports in a separate ASIC instance than the core ports.
The ports and the corresponding ASIC instances in a F2 card are as follows
--------------------
ASIC | ports
---------+---------
1 : 1-4
2 : 5-8
3 : 9-12
4 : 13-16
5 : 17-20
6 : 21-24
7 : 25-28
8 : 29-32
9 : 33-36
10 : 37-40
11 : 41-44
12 : 45-48
Issue affects F3 cards only if in the same VDC as F2 or F2E
Workaround:
Further Problem Description:
|
|
Last Modified: | 27-JAN-2016 |
|
Known Affected Releases: | 6.1(2), 6.2(5.27)S0 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu40239 | Title: | ARP traffic sent out on incorrect VLAN |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ARP traffic sent out on incorrect VLAN
Conditions:
++ Mixed chassis with F1 & M1 cards
Workaround:
1. Shut and no shut the SVI that is having problems, or
2. Disable glean fast-path via the config command ? no ip arp fast-path, or
3. Disable and reenable glean fast-path
4. Reload the switch.
Further Problem Description:
|
|
Last Modified: | 04-JAN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(13.11)S0, 6.2(14), 7.2(1)D1(0.65), 7.2(1)D1(1), 7.2(1)ZD(0.57) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur22754 | Title: | VLAN_MGR-2-CRITICAL_MSG: VLAN_MGR Event Seq. Timed Out; pvlan locked |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
VLAN mgr times out on PVLAN during deleting 2000 primary VLANs
Conditions:
To re-create, configure
RJ-N7K-1-new-vdc(config)# vlan 1000-3000
RJ-N7K-1-new-vdc(config-vlan)# mode fabricpath
RJ-N7K-1-new-vdc(config-vlan)# private-vlan primary
RJ-N7K-1-new-vdc(config)# no vlan 1000-3000
Workaround:
When there are 2000 primary vlans, and if all of them need to be deleted, the workaround is to delete 1000 vlans at once, instead of all the 2000 vlans at once. For example in the above sequence, the following configuration will go through fine:
RJ-N7K-1-new-vdc(config)# vlan 1000-3000
RJ-N7K-1-new-vdc(config-vlan)# mode fabricpath
RJ-N7K-1-new-vdc(config-vlan)# private-vlan primary
RJ-N7K-1-new-vdc(config)# no vlan 1000-2000
RJ-N7K-1-new-vdc(config)# no vlan 2001-3000
Further Problem Description:
|
|
Last Modified: | 06-JAN-2016 |
|
Known Affected Releases: | 6.2(10)S100, 7.3(0)D1(0.53) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.79), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux74096 | Title: | L2fm cores for pvlan config change from promise to trunk promise |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
L2fm cores for pvlan config change from promise to trunk promise
Conditions:
L2fm cores for pvlan config change from promise to trunk promise
Workaround:
L2fm cores for pvlan config change from promise to trunk promise
Further Problem Description:
L2fm cores for pvlan config change from promise to trunk promise
|
|
Last Modified: | 11-JAN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.40) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw01105 | Title: | DFA: multicast duplicate packets or loop on border leafs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Duplicate multicast packets seen in multicast receiver in fabric for outside fabric source.
Multicast loop packets seen for multicast receiver in fabric for inside fabric source.
Conditions:
Connection between fabric and external devices happend to 2 border leafs that see each other on a shared L2 segment, i.e. each border leaf sees the external router as well as the other border leaf as PIM neighbor.
Workaround:
Under investigation.
Further Problem Description:
N/A
|
|
Last Modified: | 11-JAN-2016 |
|
Known Affected Releases: | 7.1(2)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.639), 7.1(3)N1(1), 7.1(3)ZD(0.24), 7.1(3)ZN(0.47), 7.2(1)D1(0.88), 7.2(1)D1(1), 7.2(1)N1(0.315), 7.2(1)N1(1), 7.2(1)ZD(0.79), 7.2(1)ZN(0.77) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux06791 | Title: | SNMPWALK failed to display sxp learnt subnet-sgt entries |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Subnet-SGT entries are not displayed via SNMP walk.
Conditions:
CLI and SXP learnt subnet-sgt mappings are displayed in CLI but not via SNMP walk in 7.3.x.
Workaround:
None
Further Problem Description:
MIB changes are required to display the subnet-sgt entries. This cannot be accommodated in the current release.
Only Host-SGT(/32) entries will be displayed via snmpwalk.
|
|
Last Modified: | 11-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.146) |
|
Known Fixed Releases: | 7.3(0)D1(0.166), 7.3(0)GLF(0.44), 7.3(0)IB(0.122), 7.3(0)RTG(0.115), 7.3(0)SC(0.14), 7.3(0)ZD(0.181) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw91363 | Title: | VxLAN: oif leak seen for one BD |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
Multicast traffic is not routed to one egress interface, because its multicast adjacency is not properly programmed.
Conditions:
Not clear - seems with a new topology
Workaround:
Unknown
Further Problem Description:
Since the issue is not yet root caused, there is very limited info on how we end up with the issue, and if any workaround. It is pending further debug when the setup is available and issue reproduced.
|
|
Last Modified: | 11-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul22949 | Title: | Apex6: Crash @ mts_spin_lock_func when OIR spine |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Unexpected system reset during online insertion and remove (OIR) of spines, or during manual reloading of N7Ks.
Conditions:
In rare instances, this problem may occur when OIR spines or manually reloading N7Ks.
Workaround:
None.
Further Problem Description:
MTS sap release triggered by application cleanup needs to wait until it is safe to be released. However in rare circumstances, a deadlock can occur due to a signal interrupting the wait, causing kernel panic and system reset.
|
|
Last Modified: | 12-JAN-2016 |
|
Known Affected Releases: | 6.2(5.45)S2, 6.2(5.61)S0 |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.47), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)BF(0.104), 7.1(0)D1(0.171), 7.1(0)D1(0.282), 7.1(0)EV(0.116) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul57704 | Title: | 6.2.5.60.S2:if mgr crashed at im_get_seq_pld |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
on F3 card during vdc creation and rebinding interfaces ifmgr crash is observed.
Conditions:
ifmgr core
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 6.2(5.60)S2 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux67642 | Title: | FEX ports unavailable after FPC mod off, Switchover and FPC mod poweron |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
Doing a switchover without waiting for FEX to go offline after FEX module power off results in FEX interfaces stuck in offline state.
Conditions:
Doing a switchover without waiting for FEX to go offline after FEX module power off results in FEX interfaces stuck in offline state.
Workaround:
Wait for FEX to go offline after FEX module off before doing a switchover.
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.186) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun13397 | Title: | 6.2.6a.S12::System Sanity::Seeing L3/Multicast packet loss during ISSU |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
Seeing L3/Multicast packet loss during ISSU
Conditions:
Seen only on ISSU
Workaround:
None
Further Problem Description:
Seeing L3/Multicast packet loss during ISSU
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 6.2(6a)S12 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus96878 | Title: | Nexus7700 FEX interface link flap with FET-10G |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus7700 FEX interface may link flap with FET-10G
Conditions:
Nexus7706
N77-F348XP-23
Nexus2232TM
FET-10G
NXOS 6.2.10
Workaround:
Further Problem Description:
|
|
Last Modified: | 14-JAN-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(14), 7.2(0)D1(1), 7.3(0)D1(0.45) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.0(2)FIP(0.126), 7.2(2)D1(0.11), 7.2(2)D1(0.12), 7.2(2)D1(0.14), 7.2(2)D1(0.15), 7.2(2)D1(0.16), 7.2(2)D1(0.17), 7.2(2)D1(0.18), 7.2(2)ZD(0.16) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus97380 | Title: | plcmgr crash during OpenFlow extended sanity |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Crash in plcmgr.
Conditions:
Occurs sometimes during addition of OpenFlow matches to end of policy.
Workaround:
None known.
Further Problem Description:
|
|
Last Modified: | 14-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.402) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.1(0)ES(0.5), 7.3(0)D1(0.86), 7.3(0)DHB(0.32), 7.3(0)DX(0.16), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.37), 7.3(0)PDB(0.57), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud83785 | Title: | Reboot HSRP Active Communication Loss in Private Vlan hosts |
|
Status: * | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
Reloading the N7K which is the HSRP active caused the Private-Vlan Host communication to stop. Even after Nexus-1 is back online the communication doesn't start and the below work-around has to be applied.
Conditions:
Both the N7K are in vPC and below connected devices are also in vPC. Nexus 1 is the root of STP and HSRP Active.
Workaround:
The only tested work-around is to enable the "ip redirect" command on the SVI interface of Nexus-2 which has become the current HSRP active.
Further Problem Description:
|
|
Last Modified: | 14-JAN-2016 |
|
Known Affected Releases: | 6.1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv82966 | Title: | L3 DCI autoconfig: VRF stuck in Delete Holddown |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The VRF is stuck in RD changing state. BGP cannot add routes into the IPv4 routing table in that VRF.
Conditions:
When VRF is deleted and/or (re)created multiple times, or when there is remote L3VPN routes in that VRF when the VRF is being created.
Workaround:
Restart BGP and if needed also remove the remote L3VPN routes by using the in-bound route-map.
Further Problem Description:
|
|
Last Modified: | 19-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.78), 7.2(1)D1(1), 7.2(1)N1(0.306), 7.2(1)N1(1), 7.2(1)ZD(0.70), 7.2(1)ZN(0.69), 7.3(0)D1(0.171), 7.3(0)N1(1), 7.3(0)PDB(0.131), 7.3(0)RTG(0.70) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux02206 | Title: | Underlay mcast route is not programmed on peer-link inst after LC reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In vpc+vxlan F&L configuration, underlay multicast traffic from core may get dropped at forwarder. This is due to that derlay multicast route in core facing vrf is not programmed in peer-link instance.
Conditions:
Multicast route programmed in underlay core facing vpn has multiple instances, including peer-link. The vpn instance is affected by the LC reload - deleted and added back again
Workaround:
clear the affected route by "clear ip mroute x.x.x.x" will fix the issue.
Further Problem Description:
|
|
Last Modified: | 19-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.125) |
|
Known Fixed Releases: * | 7.3(0)D1(0.125), 7.3(0)D1(0.142), 7.3(0)D1(0.149), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)RTG(0.115), 7.3(0)SC(0.14), 7.3(0)ZD(0.167) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj48042 | Title: | N7K-OFF-DIAG:Sup 2:spine_diagdsp falure w. BIOS v.2.12 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
a
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.0(0)FR(0.5) |
|
Known Fixed Releases: * | 6.2(0)HS(0.10), 6.2(10)FM(0.3), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(0)KM(0.64), 7.3(0)DX(0.4), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum16110 | Title: | N6K: OIF on mroute not removed when interface is remotely shut |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A particular interface is not removed from the OIF list in mroutes when a remote shut for the same interface happens.
Conditions:
When a remote shut happens for a particular interface which is in the OIF list for a particular mroute, the interface does not get removed from the OIF list.
Workaround:
None
Further Problem Description:
A particular interface is not removed from the OIF list in mroutes when a remote shut for the same interface happens. This causes a problem as traffic gets forwarded immediately on actually bringing the link up
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 6.0(2)N2(2.43) |
|
Known Fixed Releases: * | 6.0(2)U6(5), 7.0(3)I3(0.271), 7.0(3)I3(1), 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)RTG(0.90), 7.3(0)SC(0.14), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux87360 | Title: | N77 - UDLD txrxloop but no err-disble - DX images only |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
UDLD TX-RX looped port not going to UDLD errdisabled state
Conditions:
Inserted loopback cable
Workaround:
Further Problem Description:
Works in D1 images - ports go into err-disabled and led blink Amber
### images that work:
n7000-s2-dk9.7.3.0.D1.0.197.bin.S0 : S0
### images with problem:
n7700-s2-dk9.7.3.0.DX.0.55.gbin.S1 : S1
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.55) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw82347 | Title: | PIM Assert Storm on pair of N6Ks with Egress VPC and ECMP in L3 Core |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
PIM Assert Storm between pair of Nexus 6000s in a VPC Pair with Egress VPC and ECMP on the L3 Core.
Both vPC peer elected as forwarder for a particular source over L3 core.
Conditions:
There was an EIGRP SIA event that caused both Switches to loose the ECMP Next Hop RPF to the RP and the Source of the traffic.
Workaround:
Restart the PIM Process on one of the Nexus 6Ks.
Further Problem Description:
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.271), 7.0(3)I3(1), 7.0(7)ZN(0.266), 7.0(8)N1(0.323), 7.0(8)N1(1), 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)RTG(0.113), 7.3(0)SC(0.14), 7.3(0)ZD(0.195) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus18893 | Title: | Crash due to a Kernel Panic at mts_sys_my_node_addr_get |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus device crashed due to a kernel panic. This can be determined by the outputs 'show system reset-reason' command:
----- reset reason for Supervisor-module 5 (from Supervisor in slot 5) ---
1) At 505949 usecs after Fri Dec 12 06:00:59 2014
Reason: Kernel Panic
Service:
Version: 6.2(2a)
The output of the `show logging onboard module 5 stack-trace` command displays functions from several CPUs. Usually the top CPU in the output is the one that had the issue. The following functions saw the issue in this case:
Logging time: Fri Dec 12 06:00:10 2014
1418382010:126475629 process sysinfo (7268), jiffies 0x13c4b55df
Oops
REGISTERS:
CPU: 8 Process: sysinfo (pid 7268) Tainted: P W
RIP: 0010:[] mts_sys_my_node_addr_get+0x36/0xa0 [klm_mts]
RSP: 0000:ffff88042c12dbd8 EFLAGS: 00010286
RAX: 0000000000000501 RBX: ffff880431030000 RCX: 0000000000000001
RDX: 00000000335edb01 RSI: 000000000000431c RDI: ffffffffa2cf93c0
RBP: ffff88042c12dbe8 R08: ffff88042c069b28 R09: 0000000000000002
R10: 000000022c12dc28 R11: 0000000000000000 R12: 00000000e7410020
R13: 0000000080044d1e R14: ffff880431030000 R15: 00000000e7410020
CALL TRACE:
CPU 8 Process: sysinfo (7268)
[] mts_sys_my_node_addr_get+0x36/0xa0 [klm_mts]
[] mts_syscall+0x419/0x8b0 [klm_mts] (64)
[] mts_compat_ioctl+0x7b/0x2890 [klm_mts] (736)
[] compat_sys_ioctl+0xfb/0x28e (112)
[] ia32_syscall_done+0x0/0x5 (131927355826352)
Conditions:
There is no particular events leading to this crash. This is an extremely rare case.
Workaround:
None Known. Will reload on single sup, switchover on dual sup.
Further Problem Description:
The Linux kernel detected the address in R12 (0x00000000e7410020) to be invalid. Instead of handling it gracefully, it caused an crash. Because it was a stack address, the chance of this address being invalid is almost zero.
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 6.2(2a), 6.2(8a) |
|
Known Fixed Releases: * | 6.1(2)I3(3.81), 6.1(2)I3(4), 6.2(10)E5, 6.2(12), 6.2(12)S14, 6.2(12.4)S0, 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(3)I1(0.209) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus02840 | Title: | IS-IS IPv6 MTR is not working |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IS-IS IPv6 MTR is not working
Conditions:
Enable multi-topology for IPv6 IS-IS, and there are DIS being elected on the IS-IS network.
Workaround:
Change the network type from broadcast to p2p. So that no pseudo-node LSP will be generated.
Further Problem Description:
|
|
Last Modified: | 22-JAN-2016 |
|
Known Affected Releases: | 6.2(12), 7.0(1) |
|
Known Fixed Releases: * | 6.2(14)E1, 6.2(16)S9, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.2(0)D1(0.396), 7.2(0)D1(1), 7.2(0)N1(1), 7.2(0)OTT(0.5), 7.2(0)PDB(0.345) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur34707 | Title: | Clipper IB packet drops due to persistent TF FPOE UC Index Error |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
The Ingress Buffer (IB) block of a SoC on a Nexus 7000 F2 module may become stuck and will not pass packets towards the fabric.
Conditions:
This has been seen with (but is not limited to) the following software and hardware:
- NX-OS version 6.2(8a) for the Nexus 7000
- Nexus 7000 F2 Series Linecards
- Nexus 7000 Supervisor 2
- Nexus 7000 Fabric 2
Workaround:
Reload of the module has addressed this so far
Further Problem Description:
As a result of the IB becoming stuck, there is push back internally and then towards the network, ultimately resulting in all further packets being dropped as input discards at the port level.
|
|
Last Modified: | 22-JAN-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03410 | Title: | Nexus 6.2.x OSPF taking long time in LSA generation |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
- Customer reported that there was a delay in LSA generation.
- The cost was increased at 03:42:36 but the LSA was generated at 03:43:20 which caused an impact for the customer as all the traffic moved to this router and cause congestion on the port-channel causing an impact for nearly 45 seconds.
- The first LSA was generated at the same time for the first port-channel but for the next 3 port-channels it throttled and took over 40+ seconds
Conditions:
> Info:
1. OSPF maintains a wheel with 600 slots in which LSAs will be inserted if they are to be generated and also tracks the current slot which is being processed. Lets say an LSA is to be generated after 100 msec, then it will be inserted in (current + 2) slot (1 slot equals 50 msec).
2. There is a common throttle timer which fires every 50 msec and increments the current slot. This is done by timer thread.
3. The flooding thread picks the LSA's from the current slot and generates the LSA's. Both these happen independently.
> Sequence of steps leading to problem:
In the customer's case, an LSA was to be generated after 5000 msec and hence was inserted at (current + 100) slot. Looks like the timer thread incremented the current slot before the flooding thread could process the LSA's in current slot.
This could happen if the order of thread execution is:
Lets say that the current slot is 199 and there is an LSA at 200.
Timer thread executes and increments current slot to 200.
Scheduler schedules some other OSPF thread for the next 50 msec or more. This means the throttle timer would have fired.
Scheduler schedules timer thread which will increment the current slot to 201.
Now, OSPF will have to wait for the current slot to reach 600, then cycle back, and then from 1 to 200 again. This will take 50 * 600 = 30000 msec or 30 sec.
Workaround:
Though the issue is timing related, using interface range command seems to not lead to the problem.
Further Problem Description:
|
|
Last Modified: | 22-JAN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(12)E6, 6.2(14.3)S0, 7.0(3)I2(1.19), 7.0(3)I2(2), 7.2(1)D1(0.79), 7.2(1)D1(1), 7.2(1)N1(0.307), 7.2(1)N1(1), 7.2(1)ZD(0.71), 7.2(1)ZN(0.70) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui99899 | Title: | HSRP standby learns VIP mac for end host in VPC setup w/ local proxy ar |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
In this particular case, we are not able to ping the servers from the N7K and as a result there is connectivity loss happening between the N7k and the servers.
The noticeable symptom is that the ARP entry for the server in the HSRP standby N7K is not correct and it is pointing the server IP to the svi VMAC instead of the host's own mac.
Conditions:
"local-proxy-arp" is enabled on the svi and the n7k(the HSRP standby) sends out an ARP request to some host in that vlan. Refer to "More Info" for explanation.
Workaround:
Further Problem Description:
Refer the primary bug CSCuh85353 for more details.
For this particular issue to summarize the relationship, there are 2 n7ks in vpc pair with HSRP configured on SVI and the "local-proxy-arp" is enabled on the svi. So, what's happening is that the n7k(the HSRP standby) sends out an ARP request to some host in that vlan and the other n7k(HSRP-active) already has the complete ARP entry for that particular host. The standby receives 2 responses in turn. The actual host responds with the own host mac. The HSRP active n7k replies to broadcast ARP requests for the host IP with virtual mac. The problem is that the arp response from the host(actual mac) reaches the standby N7k 'BEFORE' the arp response from the active n7k. Hence, the standby updates its arp table with the virtual mac from the latest arp response from active n7k with the HSRP vmac as sender. This inturn will break communication for hosts connected via vpc.
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: * | 6.0(2)N3(1), 6.1(4.75)S0, 6.1(5), 6.2(5)BF(0.29), 6.2(5.42)S0, 6.2(6), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)KM(0.37), 7.0(0)ZD(0.130) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub61661 | Title: | pktmgr crashed 3 times during ISSU to Freetown image |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
pktmgr crashed 3 times during ISSU to Freetown image
Conditions:
ISSU
Workaround:
No workaround
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0.200) |
|
Known Fixed Releases: * | 6.2(0.228)S0, 6.2(2), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun65741 | Title: | HMM Entry for locally connected host is not available |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
HMM local host DB is not updated. Issue was caused because of the CSCun57894 fix in AM.
Conditions:
When Vinci forwarding mode is configured under an SVI. Local hosts are not discovered by HMM as AM is not notifying HMM about the local adjacencies.
Workaround:
Remove the Vinci forwarding mode and reapply. But new adjacencies will not be discovered. To discover new adjacencies one must remove and reapply the forwarding mode again for every new adjacency.
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(1)ZN(0.204) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(1)N1(0.152), 7.0(1)N1(1), 7.0(1)ZD(0.149), 7.0(1)ZN(0.209), 7.1(0)D1(0.181), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)N1(0.230) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg90667 | Title: | OSPF service crashes @ip_get_secondary_count on restarting netstack |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When the netstack process crashed, existing BGP sessions may flap and routes may be re-learnt. This may cause traffic loss.
Conditions:
This only happens when the netstack process had crashed or was terminated ungracefully.
Workaround:
None.
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.1(0.288)S1, 6.1(2)S29, 6.2(0.166) |
|
Known Fixed Releases: * | 5.0(0)MP1(0.332), 5.2(1)S1, 5.2(1.3)S0, 6.1(0.143)S0, 6.2(0.228)S0, 6.2(2), 7.2(0)N1(1), 7.2(0)ZN(0.111), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq68578 | Title: | netstack crashed using devtest program |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Netstack process crash.
Conditions:
On configuring more than 255 global address per interface
Workaround:
Don't configure more than 255 address per interface
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.321), 7.1(0)ZD(0.288) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.303), 7.1(0)OTT(0.41), 7.1(0)PDB(0.249), 7.1(0)ZD(0.348), 7.1(0)ZN(0.451), 7.2(0)D1(1), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul98625 | Title: | Prefix present in (AM) sh ip arp but not in (URIB) sh ip route |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
unicast drops seen after reload access switches several times.
HB-L3EDC-CARMEL-2# sh plat afm info copp | grep glean
36 glean 128000 4687 8976371536 507761370
00
HB-L3EDC-CARMEL-2# sh plat afm info copp | grep glean
36 glean 128000 4687 8976593024 507943467
68
HB-L3EDC-CARMEL-2#
Conditions:
see eng notes
Workaround:
workaround on carmel-2
int po34000
shut/no sh
traffic will resume
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 7.0(2)UI(0.2) |
|
Known Fixed Releases: * | 7.0(0)BNZ(0.23), 7.0(0)N1(0.491), 7.0(0)N1(1), 7.0(0)ZD(0.208), 7.0(0)ZN(0.200), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60), 7.1(0)SDN(0.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug72466 | Title: | V6 ND/NA multicast packets are sent on backbone segment |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Vinci leaf will generate ND packet on core if isis fails to install adj.
Conditions:
ISIS should fail to install adj on vinci fabric
Workaround:
none
More Info:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0)PF(0.251) |
|
Known Fixed Releases: * | 6.0(2)N3(0.342), 6.0(2)N3(1), 6.0(2)N3(1.2), 6.0(2)N3(2), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)ZD(0.8), 7.0(1)N1(0.47), 7.0(1)N1(1), 7.1(0)ARP(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq48411 | Title: | iplus-291:vinci-FE:IPv6 host move failure- new leaf does not learn neigh |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IPv6 VM host move across leafs in TF mode may lead to traffic black-hole
Conditions:
During V6 host moves, RARP packet is generated by the hypervisor of the moved host towards the old leaf. On processing the RARP packet, old leaf must generate a L2 unicast but L3 multicast NS for the moved host towards the fabric destined for the moved host. This packet was not being sent out of the fabric facing port because of this bug. As a result, the new host may not be detected at the new leaf.
Workaround:
After VM moves, the new host IPV6 neighbor entry may have to be manually cleared so that upon next NS from the moved host, the moved host gets detected at the new leaf.
Further Problem Description:
In Vinci TF mode, when host is moved across leafs, then it may lead to IPv6 traffic black-hole for some time till the moved host is learnt in the IPv6 Neighbor table of the new leaf.
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 7.1(0)N1(0.291) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(1)ZD(0.256), 7.0(1)ZN(0.536), 7.0(4)N1(0.151), 7.0(4)N1(1), 7.1(0)D1(0.257), 7.1(0)OTT(0.34), 7.1(0)PDB(0.205), 7.1(0)ZD(0.305) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua56382 | Title: | ARP resolution is failing after the switch over |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
ARP resolution is failing after the switch over
Conditions:
After switchover
Workaround:
None
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0.166) |
|
Known Fixed Releases: * | 6.2(0.166)S0, 6.2(0.166)S4, 6.2(0.170)S0, 6.2(2), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue04915 | Title: | AM crashed on HMM restart |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0.112)S0 |
|
Known Fixed Releases: * | 6.0(2)N3(1), 6.2(0)PF(0.146), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)KM(0.37), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub45566 | Title: | icmpv6 is cored @ icmpv6_nd_add_adjacency after switchover |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
icmpv6 service is cored.
Conditions:
This issue is seen after switchover.
Workaround:
None
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: * | 6.2(0.200)S6, 6.2(0.206) |
|
Known Fixed Releases: * | 6.2(0.213)S2, 6.2(0.217)S14, 6.2(0.228)S0, 6.2(2), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo27488 | Title: | ipv6 forward command does not enable ipv6 on the i/f |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
v6 forwarding will not work on the core
Conditions:
Workaround:
Enable ipv6 address on fabric control segment
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 7.1(0)ZN(0.120) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.80), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)N1(0.130), 7.1(0)N1(1), 7.1(0)NF(0.28), 7.1(0)OTT(0.6), 7.1(0)PDB(0.115) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul80339 | Title: | netstack memory leak when changes are done to pbr |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Netstack cores observed on n7k.
Conditions:
PBR configuration should be present on the n7k and there should be changes to the pbr config. The changes can be one of the following :
1. Explicit changes
a) Change existing PBR policy ? Either match action and/or set action or change acl.
b) Do shut/no shut of interface on which policy applied.
2. Implicit changes
a) Interface which pbr is applied flaps ? may be because of STP dispute or BPDU loss etc
b) The next-hop goes under not reachable->reachable or reachable->not reachable->reachable churn.
Workaround:
none
Further Problem Description:
If PBR is modified periodically, there will be incremental memory leak which may eventually lead to memory exhaustion.
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: * | 5.2(9.278)S0, 6.0(2)U3(0.650), 6.0(2)U3(1), 6.1(4.104)S0, 6.1(4a)E2, 6.2(6), 6.2(6)S2, 6.2(6.13)S0, 7.0(0)BNZ(0.23), 7.0(0)N1(0.408) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj66487 | Title: | IPV6 /127 mask on p2p link not working in 6.2.2 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
IPV6 /127 point-to-point subnet mask not working in 6.2.2
Conditions:
Configure a /127 subnet on a point-to-point link.
Workaround:
Problem does not exist in 5.2.
Further Problem Description:
ND does not succeed, and the router pinging the neighbor with the subnet address (host bit 0) respond to his own icmp request.
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 6.2(0)HS(0.10), 6.2(5)BF(0.49), 6.2(5.52)S0, 6.2(6), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)ZD(0.141), 7.0(0)ZN(0.41), 7.0(1)N1(0.47), 7.0(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj16682 | Title: | acl applied on mgmt interface only works when remove/apply after reload. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
acl applied on mgmt interfaces fail to act, after realod
Conditions:
Once the n7k is reloaded, acl applied on mgmt interface wont work,
checked for acl that blocks telnet to mgmt ip,
telnet seens to be sucessfull after realod, though acl was there to block tcp connections
Workaround:
remove and apply the acl on the mgmt interface after relaod.
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(3), 6.2(8a) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S56, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.228), 7.1(0)EB(99.2), 7.1(0)NF(0.32), 7.1(0)OTT(0.27) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq52327 | Title: | IPv6 static route not seen in RIB after reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IPv6 static route configured using "ipv6 route " will not be on RIB (not seen in "show ipv6 route") after reload. The static route is seen in "show run" but "show ipv6 route" does not refect the static route to RIB.
IPv6 static route configured using "ipv6 route " does not have this problem but one configured using "ipv6 route " has this problem.
Conditions:
One of the trigger of the issue is reload of the box
Workaround:
We need to remove and re-add the ipv6 route
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.0(2)N1(1), 6.0(2)N2(1), 7.0(3)N1(0.125) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.278), 7.1(0)OTT(0.36), 7.1(0)PDB(0.228), 7.1(0)ZD(0.327), 7.2(0)D1(1), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus68473 | Title: | urib crash after running "clear ip route vrf xxx *" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
N7K running 6.2(8E10) crash on the urib process after clearing all routes in the VRF rib.
Conditions:
Clearing all routes in the RIB when there is high route count
Workaround:
Clear individual routes, instead of the entire table using *
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(8)E10 |
|
Known Fixed Releases: * | 6.2(13.4)S0, 6.2(14), 7.0(3)I1(1.201), 7.0(3)I1(2), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)SIB(99.109), 7.1(2)N1(0.569), 7.1(2)N1(1), 7.1(2)ZD(0.21) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug71873 | Title: | ip addr/ip route command fails in the second time configuration |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The second ip addr/ip route configuration will fail on pf_dev1.
Conditions:
Load with pf_dev1 images without ip configured. Configure ip addr/ip route, and then configure it again. The second configuration fails.
Workaround:
no
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0)PF(0.242) |
|
Known Fixed Releases: * | 6.2(0)PF(0.267), 7.0(0)BNZ(0.23), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.2(0)D1(1), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue97028 | Title: | 6VPE-EBGP, IPv6 ping to CE2 fails |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
On a 6VPE-EBGP scenario IPv6 ping to CE2 fails
Conditions:
6VPE is configured and the routes are all intact.
Workaround:
fix
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(1.42)S1 |
|
Known Fixed Releases: * | 6.2(1.54)S0, 6.2(2), 7.0(0.7), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo47544 | Title: | Netstack crash at ipv6_add_static_route in ipv6 static route add w/o VRF |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Netstack process crashes
Conditions:
This issue is observed only when adding static route vlan for extranet case with forward reference (where vrf is not created)
Workaround:
Configure the VRF first for extranet case and then add the static route vlan to avoid the crash
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(8)S33 |
|
Known Fixed Releases: * | 6.1(2)I3(1), 6.2(10), 6.2(10)FM(0.28), 6.2(10)NO(0.17), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo85450 | Title: | Nexus 5K/6000 crash with arp hap reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 5K/6000 switch might reload with following hap reset:
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 141764 usecs after Wed May 14 03:21:41 2014
Reason: Reset triggered due to HA policy of Reset
Service: arp hap reset
Version: 7.0(1)N1(1)
Conditions:
Gratuitious ARP storms are suspected as the trigger for this issue.
Workaround:
Identify source of ARP storm and stop it.
Further Problem Description:
|
|
Last Modified: | 27-JAN-2016 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(2) |
|
Known Fixed Releases: * | 6.0(2)A5(0.943), 6.0(2)A5(1), 6.0(2)U5(0.943), 6.0(2)U5(1), 6.2(10), 6.2(10)S40, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(1)ZD(0.248) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv95316 | Title: | Pixmc core being observed after insert new sup or reload chassis |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
After upgraded code, insert new sup or reload module generates PIXMC core
Conditions:
1. SPAN/ESPAN config is there on the switch
2. More than 128 PHY ports should be present in that VDC
Workaround:
Remove SPAN/ESPAN config before inserting new SUP/Module or during module reload. Later apply back the SPAN/ERSPAN config.
Further Problem Description:
|
|
Last Modified: | 27-JAN-2016 |
|
Known Affected Releases: | 6.2(14), 6.2(14)S25, 7.3(0)D1(0.79) |
|
Known Fixed Releases: | 6.2(16)S1, 7.3(0)D1(0.126), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.71), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux59918 | Title: | Profile conflict after vdc reload |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Profile conflict was seen after reload of vdc
Conditions:
issue is seen in scale config scenario, and copy r s and reload are done
Workaround(s):
no apply of profiles to be done by user
Workaround:
no apply xx to be done by user as workaround. This clears PPM state so that when HMM subsequently tries to apply profile, there will be no conflict.
Further Problem Description:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.179) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw94365 | Title: | Evaluation of N5K for NTP_October_2015 |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: * | Symptom:Cisco Nexus 5000 Series Switches includes a version of ntpd that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-7691; CVE-2015-7692; CVE-2015-7701; CVE-2015-7702; CVE-2015-7703; CVE-2015-7704; CVE-2015-7705; CVE-2015-7848; CVE-2015-7849; CVE-2015-7850; CVE-2015-7851; CVE-2015-7852; CVE-2015-7853; CVE-2015-7854; CVE-2015-7855; CVE-2015-7871
This product is affected by one of more of the listed CVE ids.
Conditions:
Please see Cisco Bug ID: CSCuw84708
Workaround:
Please see Cisco Bug ID: CSCuw84708
More Info:PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 6.4/5.3
http://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:L/Au:N/C:N/I:P/A:P/E:F/RL:OF/RC:C/CDP:N/TD:N/CR:L/IR:L/AR:L
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 7.2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv40883 | Title: | F3 unexpected reload after span session config |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After enable a span session for a Port-channel source in vPC with N77-F348XP-23 physical port in module 1 and destination port in module 6 (both modules N77-F348XP-23) a core crash is created for both modules. they are restored after reload crash reload.
Conditions:
I saw this problem by the very first time during a customer network troubleshooting.
I reproduced problem on CALO with the next conditions:
HW:
1 x N77-SUP2E
2 x N77-F348XP-23
1 x N77-C7706-FAB-2
1 x N77-C7709
2 VDCs were created , 1 for SPINE Fabric Path VDC 1 for LEAF Fabric Path VDC
Problem occurs on LEAF VDC just after we do 'no shut' under the monitor session config mode
problem was reproduced on 6.2(8a) and 6.2(10)
Workaround:
Further Problem Description:
Cores from 6.2(10)
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437208662_0x102_fln_fwd_usd_log.1178.tar.gz
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437208661_0x802_fln_fwd_usd_log.1178.tar.gz
Cores from 6.2(8a)
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437203676_0x102_fln_fwd_usd_log.1160.tar.gz
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437203675_0x802_fln_fwd_usd_log.1160.tar.gz
|
| Severity: error
| lcfln_n77 - Nexus 7700 platform running 6.2(10)S102 experienced a crash
| at 2015-07-18 08:37:42.
| The decoded stack traces are:
| 0x0ff4a4b0 usd_sse_process_msg
| 0x0ff4a4b0 usd_sse_process_msg ---> usd_sse.c:826
| 0x100673e8 fln_fwd_sse_hdlr ---> fln_fwd_services.c:9067
| 0x0ff5bf48 usd_handle_event ---> usdw_main.c:344
| 0x0ff5c4cc usd_loop ---> usdw_main.c:466
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(8a) |
|
Known Fixed Releases: * | 6.2(14), 6.2(14)S1, 6.2(14.3)S0, 7.2(1)D1(0.41), 7.2(1)D1(1), 7.2(1)ZD(0.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq31499 | Title: | N7K FEX satctrl hap reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
FEX attaching to N7K may crash:
1) At 659678 usecs after Thu Jul 31 09:03:30 2014
Reset Reason: Reset triggered due to HA policy of Reset (16)
Service (Additional Info): satctrl hap reset
Image Version: 6.2(8)
Conditions:
there is no trigger can be found for now.
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 6.2(8)S9 |
|
Known Fixed Releases: * | 6.1(2)I3(3.71), 6.1(2)I3(4), 6.2(0)FH(0.167), 6.2(10.19)S0, 6.2(12), 6.2(12)FT(0.27), 6.2(15.1)S0, 7.0(2)FG(0.38), 7.0(3)I1(1.99), 7.0(3)I1(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq18021 | Title: | SNMPset to community strings with special characters cause hap reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
NX-OS SNMPd process crashes with HAP reset.
Conditions:
Community string has leading ''%'' and ends with a number.
(however some other combination of special characters may cause this problem, we haven't seen them yet but can't exclude)
Workaround:
don't use leading % as a character. Better to avoid using special characters in RW communities or at least not as a leading characters
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via
normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 7.1(0)ZD(0.278) |
|
Known Fixed Releases: * | 5.2(1)N1(8.156), 5.2(1)N1(9), 6.0(2)N2(5.107), 6.0(2)N2(6), 6.2(16)S16, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(1)ZN(0.772), 7.0(6)N1(0.264), 7.0(6)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut17599 | Title: | N7K-F248XT-25E: Periodic PortLoopback Failures for Unknown Reason |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In some of the customer setups, we are seeing that the Port does not come up. Here is the unique symptom. IN this example, it for port 37:
syslog output:
PortLoopback test failure with failure reason 'Loopback test failed. Unable to analyze the reason for failure'
and further look at the module log below:
attach module <#>
show hardware internal phy event-history errors
2) Event:E_DEBUG, length:62, at 294454 usecs after Thu May 28 21:32:06 2015
[100] setEeeEnable: cmdComplete(37) FAILED rc 0xffffffff mode 0
3) Event:E_DEBUG, length:80, at 294135 usecs after Thu May 28 21:32:06 2015
[100] cmdComplete:Timeout on port 37 after 500 mSecs status 0x0001 31.400E 0x0002
Conditions:
- N7K-F248XT-25E
- Module errors as indicated in Symptoms indicate that PHY driver is timing out
Workaround:
1. We can reset the PHY of the port if this fix is not available as below:
attach module <#>
test hardware inter phy copper in port dev top reg 0x400e
In the output of the above command, ?Reg value = ? is it 0x0002 or 0x0000 ? Just make a note of it.
Below is the command to reset the port. Port number is Front panel port number here:
module-10# test hard inter phy copper out port dev pma reg 0x0000 0x8000
Verify if the port had come up or not.
or
Reloading the module would recover the ports (Secure a maintenance window and reload the module)
Further Problem Description:
This is a case of PHY HW is stuck in some state and this fix would recover the port by resetting it during the enable/disable/enable sequence.
This fix also provides a facility to reset the PHY Hw through the following CLI after attaching to the module:
Example:
module-10# test hardware internal phy port 37 op soft_reset
phy_clir_port_ops: port 6 opcode 4
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 6.1(5), 6.2(10) |
|
Known Fixed Releases: * | 6.2(16)S16, 7.2(1)D1(0.56), 7.2(1)D1(1), 7.2(1)ZD(0.49) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw25153 | Title: | Traffic loss during HSRP Recovery |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | HSRP is configured on 2 Nexus 7700, one is active and the other one is standby.
When the link on the active one is down, the standby one will take over the role of the active one. However, after the link is up, when the original active one try to take back the role, there will be a traffic loss of more than 1s. This issue occurs once in 30 trials.
Symptom:
HSRP is configured on 2 Nexus 7700, one is active and the other one is standby.
When the link on the active one is down, the standby one will take over the role of the active one. However, after the link is up, when the original active one try to take back the role, there will be a traffic loss of more than 1s. This issue occurs once in 30 trials.
Conditions:
Hsrp sessions over BFD and we need to keep on doing shut and no shut
Workaround:
No workaround is there for the drop. Its random.
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 6.2(13)S8, 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(16)S16, 7.2(2)D1(0.3), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZD(0.8), 7.2(2)ZN(0.7), 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)IB(0.95), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz59354 | Title: | cNTP ACL Does Not Continue Processing After Matching Deny Entry |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When an NTP ACL is configured for "peer", "serve", "serve-only", or "query-only" and a deny ACE is matched, the other NTP options are not checked.
For example:
ntp access-list peer 10
ntp access-list serve 11
ip access-list 10 permit host 192.168.1.1 any
ip access-list 10 deny ip any any
ip access-list 11 permit host 172.16.1.1 any
If the host matching ACL 11, 172.16.1.1, sends an NTP message it will be blocked by the "peer" ACL. However, it should be permitted by the "serve" ACL, but it is not.
Conditions:
Multiple NTP ACLs configured.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 5.2(4), 6.1(3)S5, 6.1(3)S6, 6.2(1.121)S0, 7.2(1)D1(1), 7.3(0)ZN(0.161), 7.3(1)N1(0.1) |
|
Known Fixed Releases: * | 6.1(2.30)S0, 6.1(4.97)S0, 6.1(5), 6.1(5.32)S0, 6.2(0.285), 6.2(1.149)S0, 6.2(2), 7.0(0)ZD(0.84), 7.0(1)ZD(0.3), 7.0(3)I2(0.315) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw95510 | Title: | MVPN flag missing after ospf,bgp,pim restart |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic loss due to PIM process not sending join towards upstream neighbor.
Show ip pim route internal detail vrf
command shows the RPF interface and RPF neighbor as null and 0.0.0.0 respectively.
But "show ip mroute" output shows the correct RPF interface and RPF neighbor.
Conditions:
When the command, "restart pim" is done, PIM process enables the protocol on the configured interfaces and
requests MRIB process to send all the routes also. In addition, it asks for all the RPF change notification also.
It is possible that when MRIB lets PIM of all the existing routes, PIM is yet to enable the protocol on certain interfaces and hence the RPF information is not set correctly due to which joins will not be propagated upstream causing data loss.
Workaround:
The workaround is to just "disable and enable " PIM protocol on the RPF interface.
Further Problem Description:
This problem usually occurs if there are large number of multicast routes present in the system and the user does a "restart pim". It is highly unlikely that the bug is seen under any other circumstances.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.131) |
|
Known Fixed Releases: * | 7.3(0)D1(0.162), 7.3(0)GLF(0.44), 7.3(0)IB(0.122), 7.3(0)IZN(0.13), 7.3(0)N1(0.216), 7.3(0)N1(1), 7.3(0)PDB(0.121), 7.3(0)SC(0.14), 7.3(0)ZD(0.177), 7.3(0)ZN(0.193) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux80559 | Title: | SSTE: BGP Remote PE4 routes are not redistributing into EIGRP after ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
pe-ce routes not redistributed to eigrp after issu.
Conditions:
Happens when bgp comes up before l3vpn and l3vpn doesn't send notification on coming up while performing issu.
Workaround:
Restart eigrp process after issu is done.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.194) |
|
Known Fixed Releases: * | 7.3(0)D1(1), 7.3(0)IZN(0.13), 7.3(0)N1(0.269), 7.3(0)N1(1), 7.3(0)ZD(0.236), 7.3(0)ZN(0.245), 7.3(1)D1(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux55826 | Title: | NXOS/BGP: routers not redistributed after ATTR and prefix list change |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Routes are not redistributed from BGP If prefix-list is changed after there has been update in route attribute. Also observed is that RIB route was not updated despite BGP update was processed and BGP route database showed updated route. There may be error messages such as "OSPF-3-RPM_LIB_API_FAILED: bgp_lookup_ext_attr() - failed in rpm_acquire_bgp_shmem_lock()"
Conditions:
Issue happen only if optional attribute MED previous set to value 0 has been removed from update (or vice versa). Issue will not happen there is only change in attribute value (MED 10 to MED 20 for example). So the condition is a very specific corner case of "med not set" not being distinguished from "med 0". Furthermore, the bgp route is redistributed into other protocol(s) via a route-map that tests on such attribute for this problem to occur. This is because route-map is trying to access the route through the stale handle stored in RIB.
Workaround:
Redistribution will be corrected after clear ip bgp . But this may be disruptive and requires knowledge of particular prefix to limit the impact. For 7.2 releases, enabling "feature fabric forwarding" can avoid this particular problem.
Further Problem Description:
This problem is similar to CSCum05295, but not related, and is strictly limited to the condition mentioned above.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 6.2(14), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 6.2(16)S3, 7.0(3)I3(0.272), 7.0(3)I3(1), 7.3(0)D1(0.194), 7.3(0)HIB(0.3), 7.3(0)IZN(0.13), 7.3(0)N1(0.249), 7.3(0)N1(1), 7.3(0)ZD(0.211), 7.3(0)ZN(0.225) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux59834 | Title: | Limit OTV data-group configuration to /24 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a Nexus 7xxx chassis when using F3 modules for OTV; if the OTV data-group range is configured with a larger subnet mask than /24, some multicast groups could fail to pass across the OTV.
Conditions:
Because the CLI allows for configuration of the data-group subnet larger than /24, the current threshold is exceeded. If the following occurs some multicast groups will fail across OTV:
1) Have a data-group range configured under the overlay with a subnet mask greater than /24.
2) Have experienced an AED failover event.
Workaround:
Limit the CLI data-group configuration to prevent configuration of a subnet larger than /24.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 6.2(14), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(1), 7.3(0)IZN(0.13), 7.3(0)N1(0.272), 7.3(0)N1(1), 7.3(0)ZD(0.240), 7.3(0)ZN(0.249), 7.3(1)D1(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw96276 | Title: | CVE-2013-4548 Vulnerability Nexus 7000 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco Nexus 7000 (N7K) Series Switch includes a version of the Open Secure Host (OpenSSH) protocol
that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2013-4548
This bug was opened to address the potential impact on this product.
Conditions:
Device with default configuration.
Workaround:
Not currently available.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6/5.7:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:M/Au:S/C:P/I:P/A:P/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2013-4548 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 5.2(8), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(15)S10, 7.3(0)D1(0.147), 7.3(0)GLF(0.43), 7.3(0)IZN(0.13), 7.3(0)N1(0.196), 7.3(0)N1(1), 7.3(0)PDB(0.112), 7.3(0)RTG(0.115), 7.3(0)SC(0.14), 7.3(0)ZD(0.164) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux28796 | Title: | OIL is not copied from (*,G) to (S,G) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On an intermediate hop router sometimes, the OIF list of *,G is not inherited into S,G entry correctly.
It happens in certain conditions such as this.
src---rtr1---rtr2- intf1----rtr3---rcvr
|
rp
rtr2 has a *,G entry with oif (intf1) towards rcvr.
when the source starts, the rtr2 receives a SG join from RP.
rtr2 create the SG entry with oif (intf2) only towards RP, instead of two OIFs. (intf1 and intf2)
Only after receiving a SG join the rtr3, does the intf1 gets added to the entry. This causes a traffic blackholing upto a minute.
Conditions:
This typically happens on a IHR only where the SG creation happens due to receiving a SG join and there is already a *,G entry with other oifs.
Workaround:
As such there is no workaround and the system correctly itself within a minute.
The other possible workaround is to change the topology. For example if we connect the RP router to the rtr3 in the above topology, the problem will no longer be seen.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(16)S16, 7.0(3)I3(0.271), 7.0(3)I3(1), 7.3(0)D1(0.166), 7.3(0)GLF(0.44), 7.3(0)IB(0.122), 7.3(0)IZN(0.13), 7.3(0)N1(0.220), 7.3(0)N1(1), 7.3(0)PDB(0.127) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw92095 | Title: | NXAPI: json "show monitor session" destination interfaces incomplete |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
some destination interfaces are missing from JSON format output of the "show monitor session" command in the NXAPI Sandbox
Conditions:
On Nexus 6004 running version 7.2(0)N1(1) or 7.2(1)N1(1), using the "show monitor session all" command in the NX-API SandBox, with JSON output format, not all the destinations will appear in the output but the last one.
Workaround:
Request the response in XML format.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(0)N1(1), 7.2(1)N1(0.9) |
|
Known Fixed Releases: * | 7.3(0)D1(0.175), 7.3(0)DX(0.56), 7.3(0)GLF(0.44), 7.3(0)IZN(0.13), 7.3(0)N1(0.229), 7.3(0)N1(1), 7.3(0)SC(0.14), 7.3(0)UCI(0.2), 7.3(0)ZN(0.206), 8.3(0)CV(0.292) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu13856 | Title: | N7K/N6k- NTPD Cores fill up /var/sysmgr/ |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
NTP creates repeated core files on Nexus switches
Conditions:
The ntpd crashes happen when there is ntp access-group attached with a matching access-list to restrict
which devices the switch listens to for ntp updates.
Workaround:
Remove the ntp access-group command
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.451), 7.2(0)D1(0.478), 7.2(0)D1(0.490) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)FFW(0.7), 7.0(0)HSK(0.474), 7.0(0)KM(0.138), 7.0(0)KMS(0.11), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.1(3)ZN(0.134), 7.1(3)ZN(0.135), 7.1(4)N1(0.699) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw51522 | Title: | Mac learnt on ES ID for host vpc+ port operating in individual mode |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a pair of nexus 7000 series switches configured for fabricpath vpc+, the mac address for an host vpc+ operating in individual mode may point to an incorrect interface on the non-parent nexus 7000, either pointing to the local vpc+ leg that is down, or to the fabricpath address for the emulated switch (ES ID.1.65535). Traffic destined for devices behind the host vpc+ ingressing the non-parent nexus 7000 will not reach its destination.
Conditions:
- This is seen in a host vpc+ configuration, a port-channel configured for vpc made of HIF interfaces residing on seperate FEXes, each connected to a single parent nexus 7000
- The port is running in standalone mode allowed by the configuration of no lacp suspend-individual on the port-channel and the absence of lacp configuration on the attached system.
Workaround:
Further Problem Description:
|
|
Last Modified: | 31-JAN-2016 |
|
Known Affected Releases: * | 6.2(10), 6.2(14), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(16)S1, 7.2(1)D1(0.99), 7.2(1)D1(1), 7.2(1)ZD(0.90) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv04106 | Title: | need "MAINTENANCE" as (special) reset-reason for GIR |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
while in Maintenance Mode, if the switch reloads because of any reason that is not part of handful that are covered under mmode today ,it should come back up in Maintenance mode.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.180), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.33), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), 7.3(0)D1(0.160), 7.3(0)DX(0.56), 7.3(0)GLF(0.44) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux57492 | Title: | Ip pim pre-build-spt not functioning correctly for SSM in VPC setup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Both the VPC peers do not send PIM joins to the Source on enabling "ip pim pre-build-spt" in PIM SSM over VPC setup.
Conditions:
This condition occurs only with PIM SSM
Workaround:
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.231) |
|
Known Fixed Releases: * | 7.3(0)D1(0.186), 7.3(0)IZN(0.13), 7.3(0)N1(0.243), 7.3(0)N1(1), 7.3(0)ZD(0.205), 7.3(0)ZN(0.220) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy04933 | Title: | Wrong timestamps in netflow data |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Wrong timestamps in netflow data
Conditions:
Unknown
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw90721 | Title: | LISP: RNH notifies for db RLOCs gone when coincide with map-cache RLOCs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On a LISP site with multiple eTRs, one of the eTRs shows an incorrect status of the locators of the rest of eTRs. As an example it may mark the locator as "down" but have a route to the locator.
Conditions:
In order to reach this state the eTR (that is also working as iTR) must receive a map-reply in which one of the locators is part of the database-mapping locator-set. The problem is that this map-cache will be rapidly removed, as it is considered local, which also removes RNH tracking for the affected locators.
An easy way to reproduce this problem is to issue a "lig self"
Workaround:
The only possible workaround now is to reapply the configuration of the affected database-mapping, so that RNH tracking is reinstated
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.6), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZD(0.11), 7.2(2)ZN(0.10), 7.3(0)D1(0.202), 7.3(0)IZN(0.13), 7.3(0)N1(0.264), 7.3(0)N1(1), 7.3(0)ZD(0.231) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh44088 | Title: | Need to prevent mrouter on ports on FEX HIFs due to PIM hellos |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a Nexus 2000 FEX connected to Nexus 5000/6000 switches, mrouter ports on FEX is not supported and can lead to unaccepted multicast behavior.
Conditions:
PIM router connected to FEX
Workaround:
Do not connect PIM router to FEX.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 5.2(1)N1(4), 6.0(2)N1(2a) |
|
Known Fixed Releases: * | 7.3(0)D1(0.185), 7.3(0)IZN(0.13), 7.3(0)N1(0.241), 7.3(0)N1(1), 7.3(0)ZD(0.203), 7.3(0)ZN(0.218) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv80499 | Title: | BGP flapping with same AS-PATH ACL matched in two or more route-map seqs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Multiple BGP sessions fail to establish after link flap on route refresh on N7K. The sessions cycle between Idle/Active/Closing
Conditions:
This is seen when N7K have outbound policy route-map matching the same as-path ACL in two or more sequences of the same route-map.
Some of the peers are sending upwards of 50K prefixes and in the same update-group as other peers sending 10 to 100 prefixes.
Link flap to one or some of the peers or route refresh(clear ip bgp * soft) is the trigger. This is mostly seen when aggressive timer is configured for multiple neighbors.
Workaround:
Match the as-path once in the route-map and use other attributes to match the prefixes in other sequences. Relax the bgp timers to accommodate the CPU spike due to the regex processing.
Further Problem Description:
|
|
Last Modified: | 31-JAN-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S102, 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: * | /bin/sh:, 6.2(16)S18, 7.0(3)I3(0.163), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.2(1)D1(0.78), 7.2(1)D1(1), 7.2(1)N1(0.306), 7.2(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua53069 | Title: | IPFIB information is incorrect for the BGP AS information |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Origin AS in FIB and RIB are different, which may result wrong NF export value.
N7K# show ip route 192.168.0.2 detail
< snip >
192.168.0.2/24, ubest/mbest: 1/0
*via 192.168.100.1, [20/0], 01:29:48, bgp-100, external, tag 2
client-specific data: 23
recursive next hop: 192.168.100.1/32
extended route information: BGP origin AS 1 BGP peer AS 2 <--- origin AS 1
N7K# show forwarding route 192.168.0.2 detail
< snip >
Prefix 192.168.0.2/24, No of paths: 1, Update time: Fri May 24 11:43:21 2013
Vobj id: 15 orig_as: 3 peer_as: 2 rnh: 192.168.100.1 <--- orig_as: 3
192.168.100.1 Ethernet9/13 DMAC: 000c.2982.8c93
packets: 0 bytes: 0
< snip >
Conditions:
This issue happens when some BGP routes have same next-hop.
N7K# sh ip bgp
BGP routing table information for VRF default, address family IPv4 Unicast
BGP table version is 223, local router ID is 20.0.0.1
Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best
Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist
Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath
Network Next Hop Metric LocPrf Weight Path
*>e192.168.0.1/24 192.168.100.1 0 2 4 5 i
*>e192.168.0.2/24 192.168.100.1 0 2 4 6 7 7 7 7 7 1 i
*>e192.168.0.3/24 192.168.100.1 0 2 4 6 7 7 7 7 7 1 i
*>e192.168.0.4/24 192.168.100.1 0 2 4 6 7 7 7 7 7 1 i
*>e192.168.0.5/23 192.168.100.1 0 2 4 8 3 i
*>e192.168.0.6/23 192.168.100.1 0 2 4 8 3 i
*>e192.168.0.7/23 192.168.100.1 0 2 4 8 3 i
*>e192.168.0.8/23 192.168.100.1 0 2 4 8 3 i
In this case, orig_as for all the routes above will be same on FIB.
The same value will be selected from one of 5, 1 and 3.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 06-JAN-2016 |
|
Known Affected Releases: | 6.1(1), 6.1(3) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5)FH(0.30), 6.2(5.44)S0, 6.2(6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf35758 | Title: * | NX-OS :Peer switch feature conflict for non vpc vlans |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Non vpc vlan on dedicated L2 trunk across VPC peers goes into STP blocking state when peer switch is enabled.
Conditions:
Peer switch is enabled.
STP priority is same for the non vpc vlans as required by peer switch recommendation.
Workaround:
Use different global root priority for the non vpc vlan assuming pseudo config is not in use for the non vpc vlan.
If pseudo config is in use then use different root priority under the pseudo config for non vpc vlan.
Further Problem Description:
|
|
Last Modified: | 06-JAN-2016 |
|
Known Affected Releases: | 5.2(7), 6.1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur22840 | Title: | xbow-scale: "Bad CRC" packets seen with Manual CTS after UTE triggers |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
When macsec is configured, we see dropped packets on some interfaces with Bad CRC signature. This is seen after switchover and when linerate exceeds stipulated limit for macsec.
Conditions:
1. MACSEC is enabled.
2. egress traffic rate exceeds the effective line rate for encrypted traffic.
3. Switchover is performed
Workaround:
Limit the traffic egressing out of Macsec ports to less than effective 10G linerate (including Macsec header overhead). This may be roughly 6.5G for 64B packets.
Enable global pause on the ports in questions.
Further Problem Description:
Traffic load exceeding 10G limit (including macsec header) is marked as Bad CRC in the transmit direction. Hence they get dropped on the peer receiving the packets.
|
|
Last Modified: | 06-JAN-2016 |
|
Known Affected Releases: | 6.2(10)S97 |
|
Known Fixed Releases: | 6.2(10)S101, 6.2(10.17)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.318), 7.1(0)EV(0.116), 7.1(0)OTT(0.47), 7.1(0)PDB(0.256) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus47263 | Title: | vPC suspension following reload with peer-link on F3 and PKA on M-Series |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Nexus 7000 pair in vPC will suspend all vPCs on the secondary when the operational primary is reloaded.
Conditions:
When the vPC peer-link is configured on an F3 series line card and the peer-keepalive is configured on an M series line card.
Workaround:
Configure the peer-keepalive on the F3 card or management interface. The management interface will only prevent this if running 6.2(10) otherwise use the F3 card.
Further Problem Description:
Related defect CSCun82155.
|
|
Last Modified: | 06-JAN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.79), 7.2(1)D1(0.64), 7.2(1)D1(1), 7.2(1)ZD(0.57) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux73273 | Title: | Mpls trigger for ELAM on F3 is not working |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Any of the mpls triggers will not catch labeled packets in ELAM (layer 2 or layer3)
module-1(fln-l2-elam)# trigger dbus mpls ingress if lbl
lbl0-eos lbl0-lbl lbl0-valid lbl1-ttl
lbl0-exp lbl0-ttl lbl1-exp
Conditions:
tbd
Workaround:
use any other ipv4 / ipv6 with lbl-lbl triggers to catch MPLS labelled packets.
for eg: trigger dbus ipv4 ingress if lbl0-lbl < >
Further Problem Description:
Issue is day one problem in F3 line cards only.
|
|
Last Modified: | 09-JAN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux70796 | Title: | CFD: CSCtr11247 - UDLD enabling CDP CFD failed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
"udld enable" command is not configurable on copper ports. This command is rejected with the message below -
"ERROR: UDLD is rejecting a config that is valid only for the copper port on: Ethernet3/31."
Conditions:
This command is working fine on fiber ports but not on copper ports.
Workaround:
no workaround.
Further Problem Description:
|
|
Last Modified: | 11-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.178) |
|
Known Fixed Releases: * | 7.3(0)D1(0.200), 7.3(0)ZD(0.228) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv44521 | Title: | Breakout ports getting UDLD-4-UDLD_SFP_TYPE_CHANGED from copper to fiber |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
The syslog message "UDLD_SFP_TYPE_CHANGED" is printed on the console for F3 breakout ports. There is no change in the SFP type but still syslog message is printed on the console.
N7K-2# sh logg logfile | i i UDLD-4-UDLD_SFP
2015 Jul 16 23:18:21 N7K-2 %UDLD-4-UDLD_SFP_TYPE_CHANGED: User changed SFP type on Ethernet1/1/1 from copper to fiber, default udld port configuration was applied, 'copy running-config startup-config' recommended
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 11-JAN-2016 |
|
Known Affected Releases: | 6.2(13.3) |
|
Known Fixed Releases: | 7.3(0)D1(0.107), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.55), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup57600 | Title: | packet drops when removing mac acl |
|
Status: * | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
minor packet loss when removing mac acl.
Conditions:
mac packet-classify is configured and statistics per-entry enabled.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 11-JAN-2016 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue63118 | Title: | Show mac address-table show incorrect VLAN |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
MAC address is shown incorrect VLAN on show mac-address table. Specifically, MAC addresses learnt from VLAN 2 and 3 are shown in VLAN 1002 and 1003.
Conditions:
The problem is first reported in 6.1(2)
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw76081 | Title: | 7.2(1)D1(1) S6::Loopback interfaces are going untested . |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
GOLD loopback (port loopback, rewrite engine loopback, internal port loopback) test failures with SUP 1 and multiple M1/M2 cards in chassis.
Conditions:
Chassis has a SUP1 and GOLD loopback tests running on multiple M1/M2 cards. Test fails when multiple runs are running in parallel but passed when started individually.
Workaround:
No workaround. You need to start the test individually to confirm it passes and you are hitting this bug and then disable the test to avoid getting warnings.
To start test individually
1. Disable diagnostic on all modules. - no diagnostic monitor module all
2. Check no test is running, if yes, wait for them to finish - show diagnostic internal port_lb info
3. Clear result and enable monitoring for failed module test -
diagnostic clear result module test
diagnostic monitor module test
4. When test finishes, check the result to confirm it passes.
show diagnostic result module test
5. Do this for all failed tests in chassis and the enable monitoring for remaining tests.
diagnostic monitor module all
no diagnostic monitor module test
Further Problem Description:
Sometimes on SUP 1 with multiple M1/M2 cards, loopback tests are failing when running in parallel. The cause is not known and issue is tracked using this bug.
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv90027 | Title: | NXOSv Interface ACL config should be blocked until supported |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
NXOSv (virtual) will allow interface ACL configs to be configured without error. But if applied to non management interfaces, they won't block traffic.
Conditions:
ONly applies to virtual NXOS (a.k.a. titanium)
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 7.2(1)D1(0.57) |
|
Known Fixed Releases: * | 7.2(1)D1(0.70), 7.2(1)D1(1), 7.2(1)ZD(0.62), 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.67), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw81067 | Title: | DFA: Multicast SG join state missing in BGP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
L3 multicast over DFA fabric may not be forwarded to some receivers connected behind DFA leaves
Conditions:
L3 multicast over DFA with receivers behind leaf switches
Workaround:
Clear the bgp mvpn table on DFA switches
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 7.1(2)N1(0.599) |
|
Known Fixed Releases: * | 7.1(3)N1(0.673), 7.1(3)N1(1), 7.1(3)ZD(0.44), 7.1(3)ZN(0.85), 7.2(2)D1(0.5), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZD(0.10), 7.2(2)ZN(0.9), 7.3(0)D1(0.178) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux80178 | Title: | SSTE: Error for ISIS topology changes during ISSU for BD Flood prog |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
PIXM syslog seen if there is any change in topo during ISSU
Conditions:
Topo change when LC ISSU going on.
Workaround:
No functional impact because ISSU done should automatically will recover.
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.194) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu39870 | Title: | NAM Module flooding accounting log |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
When a N7K-SM-NAM-9G-K9 Network Analysis Module is inserted into a chassis and powered up, it floods the accounting logs with unhelpful information:
Wed May 6 04:20:05 2015:type=start:id=vsh.5698:user=root:cmd=
Wed May 6 04:20:05 2015:type=stop:id=vsh.5698:user=root:cmd=
Wed May 6 04:20:07 2015:type=start:id=vsh.5714:user=root:cmd=
Wed May 6 04:20:08 2015:type=stop:id=vsh.5714:user=root:cmd=
Wed May 6 04:21:05 2015:type=start:id=vsh.5758:user=root:cmd=
Wed May 6 04:21:05 2015:type=stop:id=vsh.5758:user=root:cmd=
Conditions:
- Neuxs 7K with NX-OS 6.2(12) or other newer NX-OS
- This problem happens when the NAM module is powered on.
Workaround:
No workaround except to poweroff the NAM module.
Further Problem Description:
This is an issue for the accounting log that impacts TAC's ability to troubleshoot. This is a very serious issue. When the NAM module is inserted and powered up, it floods 4 empty accounting log messages every minute, which basically makes the "show accounting log" command useless to TAC. See below for an example of the flooding:
Wed May 6 04:20:05 2015:type=start:id=vsh.5698:user=root:cmd=
Wed May 6 04:20:05 2015:type=stop:id=vsh.5698:user=root:cmd=
Wed May 6 04:20:07 2015:type=start:id=vsh.5714:user=root:cmd=
Wed May 6 04:20:08 2015:type=stop:id=vsh.5714:user=root:cmd=
Wed May 6 04:21:05 2015:type=start:id=vsh.5758:user=root:cmd=
Wed May 6 04:21:05 2015:type=stop:id=vsh.5758:user=root:cmd=
|
|
Last Modified: | 19-JAN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 7.3(0)D1(0.188), 7.3(0)ZD(0.206) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh48163 | Title: | F3:: Show system internal iftmc hardware lif command is not available |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.0(0)FT(0.106) |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)FT(0.111), 7.1(0)D1(0.14), 7.2(0)D1(1), 7.3(0)DX(0.4), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr38849 | Title: | N7K: Policy stats do not work when Object-groups are used in ACLs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | QoS Policy stats do not work when object-groups are used in ACLs that define the class-maps.
Symptom:
packet count is 0 for object group acl's
Conditions:
when object groups are used
Workaround:
avoid use of object group if stats are critical .functionality of object group is not broken
Further Problem Description:
packet count is 0 for object group acl's match filters
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)FFW(0.11), 7.0(0)HSK(0.499), 7.3(0)DX(0.4), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf81607 | Title: | pre-qual-flanker:Missing member ports SI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Missing member port SI
Conditions:
If a port channel has 2 member ports one of the member ports does not have the SI programmed
Workaround:
No work around
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.0(0)FT(0.44) |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)FT(0.64), 7.0(0)FT(0.65), 7.1(0)D1(0.14), 7.1(0)D1(0.15), 7.2(0)D1(1), 7.3(0)DX(0.4), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui15370 | Title: | Intermittent CHASSIS-PS_INTR failure Emerson PS across all corners |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
During the diag test CHASSIS-PS_INTR test failure is seen intermittently across all corner conditions.
Conditions:
Diag Image Used:
diag-sup3dc3-el-6.2.0.238d1.046.gbin
diag-n7k-6.2.0.238d1.046.mzg
Failing Corners:
Failure seen at NT/NV, HT/NV, and LT/NV
Workaround:
Test was skipped to avoid further failure since the fix is not available at this time.
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 6.2(0.302)S24 |
|
Known Fixed Releases: * | 6.2(10)FM(0.3), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(0)KM(0.64), 7.3(0)DX(0.4), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw57347 | Title: | IS reachability TLV not suppressed while extended reachability TLV is |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LSPs do not contain TLV 22 under certain conditions - which is the correct behaviour - but TLV 2 is still advertised. This contradicts the intention of not advertising TLV 22.
Conditions:
IS-IS must be run with "metric-style transition", otherwise no TLV 2 is generated
Workaround:
No workaround known. The advice is to not use "metric-style transition" unless it is really necessary.
Further Problem Description:
|
|
Last Modified: | 22-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.121), 7.3(0.121) |
|
Known Fixed Releases: * | 6.2(14)E1, 6.2(16)S9, 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)RTG(0.90), 7.3(0)SC(0.14), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw34008 | Title: | F1 Fabricpath. Mac not learned when ASA switchover happens |
|
Status: | Open |
|
Severity: * | 3 Moderate |
Description: | Symptom:
Mac address not updated on F1 module when ASA switch over takes place.
Conditions:
It appears that if you configure both CE and FP ports on same ASIC on a F1 module (which is not supported, see CSCuq80956), removing mis-configuration does not clear static bit set for the MAC's learned before mis-config was cleared.
Only way to clear mac's with static bit set is to reload the module.
Workaround:
Reloading Module should clear incorrect mac learning
Further Problem Description:
|
|
Last Modified: | 23-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux63096 | Title: | CSCuw89606 and CSCut84448 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Bugid: CSCut84448
In this status, routing information is like below.
NX01 has routes to NX03 and NX04 for 10.x.x.x
NX03 has routes to NX01 and NX02 for 10.x.x.x
NX04 has routes to NX01 and NX02 for 10.x.x.x
As a result, there are loop between NX01-NX03 and NX01-NX04.
NX01 are advertising redistributed static route to NX03 and NX04.
NX01# show ip ospf database
snip
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.x.x.x NX01 2 0xXXXX 0x494 0
10.x.x.x NX02 238 0xXXXX 0xd42e 0
Bugid: CSCuw89606
On a Nexus, piping 'show ip route' or 'show ip static-route' to xml/json will not provide the next hop ip address.
Conditions:
Workaround:
Bugid: CSCut84448
When the ospf is restarted using 'restart ospf 1000' , the route that cause of looping is removed.
Routing information is like below.
NX01 has routes to NX03 and NX04 for 10.x.x.x
NX03 has routes to NX02 for 10.x.x.x
NX04 has routes to NX02 for 10.x.x.x
NX01 are not advertising redistributed static route to NX03 and NX04.
NX01# show ip ospf database
snip
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.x.x.x NX02 238 0xXXXX 0xd42e 0
Debug info : Process prefix 124.243.13.160/32 for type-7/type-5 translation
Bugid: CSCuw89606
On CLI, do not pipe to xml/json to see the next hop ip address.
On NXAPI, poll ascii and parse the output.
Further Problem Description:
|
|
Last Modified: | 25-JAN-2016 |
|
Known Affected Releases: | 8.3(0)CV(0.99) |
|
Known Fixed Releases: | 8.3(0)CV(0.277) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo70393 | Title: | PVLAN: In a trunk promiscuous port egress pkts on Native vlan are tagged |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PVLAN promiscuous trunk tags native vlans
Conditions:
PVLAN promiscuous trunk is configured with:
switchport private-vlan trunk native vlan X
Workaround:
do not configure native vlan on PVLAN trunks
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(8)S35 |
|
Known Fixed Releases: * | 6.1(2)I3(3.80), 6.1(2)I3(4), 6.2(10), 6.2(10)S42, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.257), 7.1(0)OTT(0.34), 7.1(0)PDB(0.205), 7.1(0)ZD(0.305) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo76512 | Title: | route leaking into global using static route not working without nexthop |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
connected route from a named vrf can be leaked into the default vrf using static routes with nexthop specified, but it does not work if next-hop is not specified.
Conditions:
This symptom is seen on Nexus 7000 Series Switch.
Workaround:
Use PBR based solution
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(8)IAS(0.22) |
|
Known Fixed Releases: * | 6.1(2)I3(2.19), 6.1(2)I3(2.43), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 6.2(10), 6.2(10)S27, 6.2(8)E1, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq78160 | Title: | netstack does not route ipv6 gw probe packets with source LL address |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Host machines marking HSRPv6 gateway as unreachable.
Conditions:
Host sends unicast NS probes to HSRPv6 IP in vpc or vpc+ scenario with source address as Link local. Such packets land on HSRP standby and needs to go over peer link to HSRP active.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S77, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.303), 7.1(0)OTT(0.41), 7.1(0)PDB(0.249), 7.1(0)ZD(0.348) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc12888 | Title: | A double free can occur in ipv6_fragment |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
When an incorrect length ipv6 packet is received and if it needs to be fragmented, it could lead to netstack crash.
Conditions:
Incorrect length ipv6 packet is recieved from a client.
Workaround:
none.
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 5.2(7.35)S0, 5.2(9), 6.1(2.24)S0, 6.1(4.1)S0, 6.1(5), 6.2(0.240)S0, 6.2(0.285), 6.2(2), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui33523 | Title: | line protocol down logical interface responds to ssh |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A ssh connection is established with a logical interface ( port-channel ) which is down.
Conditions:
The problem happens when the ssh packet causes an ICMP redirect message to be sent. I.E., the incoming and outgoing port are the same.
Workaround:
Disable 'ip redirects' on the interface that packet is entering.
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: * | 6.0(2)N3(0.342), 6.0(2)N3(1), 6.1(4.97)S0, 6.1(4a), 6.1(4a)S7, 6.1(5.32)S0, 6.2(0)HS(0.10), 6.2(2a), 6.2(2a)S14, 6.2(5.45)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh50150 | Title: | Unable to ping GLBP VIP when fabric path is enabled between N7K and N5K |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Downstream N5K with layer 3 daughter card is unable to ping GLBP VIP.
Conditions:
The occurs when N7K's are in a VPC configuration with GLBP as the FHRP. Fabric path is enabled with downstream leaf devices. The N5K must have a L3 daughter card installed for issue to recreate.
Workaround:
There are three known workarounds:
1. point leaf devices/end devices at physical IP address of the N7K(s).
2. Utilize HSRP as the FHRP
3. Add a static ARP entry on the N5K SVI
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 5.1(3)N1(1a), 5.2(1)N1(2a) |
|
Known Fixed Releases: * | 5.2(9.242)S0, 6.0(2)N3(1), 6.1(4.82)S0, 6.1(5), 6.2(0)HS(0.10), 6.2(5)BF(0.39), 6.2(5.52)S0, 6.2(6), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq46582 | Title: | ARP may fail for HSRP vip after vip is moved to another int |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ARP may fail for HSRP vip after vip is moved to another int. N7k may fail to send ARP reply on affected interface after the same HSRP vip config is moved to another interface. This is seen if the initial interface vip config is not first removed in the necessary order. Below debug ip arp event will show the affected HSRP active VIP not local, even though it is local on the device:
arp: arp_process_receive_packet_msg: Destination address is not local on
Conditions:
This can be seen if the initial vip config is left under the interface, and the same VIP is re-used under another interface
Workaround:
To clear the issue if it is seen, perform steps in below order:
- Admin down the new interface (the one that is affected)
- re-admin back up the original interface, re-assign the original interface with with the same ip and vip
- remove the original interface's vip
- remove the original interface's ip
- remove the original interface interface <<< Optional, you could aso just re-admin down the new interface at this point
- re-admin up the new interface
To prevent issue from occurring, perform steps in below order:
- When decommissioning an interface, ensure the below steps are performed in the below order:
- Remove the vip
- Remove the ip
- Shut the interface
- Remove the interface
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(8)E1 |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S66, 6.2(10.16)S0, 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.278), 7.1(0)OTT(0.36), 7.1(0)PDB(0.228) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul10396 | Title: | ARP entries not being displayed when specify the VRF name |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ARP entries are not being displayed from "show ip arp" command if the VRF name is specified
Conditions:
High Number of VLAN
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 5.2(7) |
|
Known Fixed Releases: * | 5.2(9.247)S0, 6.0(2)N3(0.344), 6.0(2)N3(1), 6.1(4.89)S0, 6.1(5), 6.2(0)HS(0.10), 6.2(5)BF(0.50), 6.2(5.71)S0, 6.2(6), 7.0(0)BNZ(0.23) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue66999 | Title: | debug ip packtrace + debug-filter causes bgp session to go down |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
'debug ip packtrace' will cause BGP sessions to flap.
Conditions:
debug-filter ip packet address
debug-filter ip packet direction inbound
debug-filter ip packet protocol tcp destination-port 179
debug-filter pktmgr interface
debug ip packtrace
Workaround:
Avoid using this debug facility except during maintenance windows when disruptions to production traffic have less of an impact.
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.1(2)E7 |
|
Known Fixed Releases: * | 6.1(4.38)S0, 6.1(5), 6.2(1.58)S0, 6.2(1.93), 6.2(2), 7.0(0.7), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue18444 | Title: | A packet is unable to reach HSRP VIP in other VRF |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
a packet destined HSRP VIP in other VRF gets dropped.
Conditions:
- When a N7K has multiple VRF instances
- a HSRP is running in one of VRF instances
- routes are leaked between VRF instances
Workaround:
none
More Info:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 5.2(1), 6.1(2), 7.0(1)N1(1) |
|
Known Fixed Releases: * | 5.2(9.115)S0, 6.0(2)U3(0.644), 6.0(2)U3(1), 6.1(4.37)S0, 6.1(4.97)S0, 6.1(5), 6.1(5.2)S0, 6.2(1.59)S0, 6.2(1.93), 6.2(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq73614 | Title: | N7K netstack crash when routing config change with track object |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
netstack crash while making ip route change with track object
Conditions:
track object was part of the route change, and track object flapping/change state
Workaround:
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(6a) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)E1, 6.2(10)S71, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.278), 7.1(0)OTT(0.36), 7.1(0)PDB(0.228) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud35832 | Title: | v6Relay: Require support to forward pkts as per client configuration |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0.269)S12 |
|
Known Fixed Releases: * | 6.0(2)N2(1), 6.2(1.12)S0, 6.2(1.42)S0, 6.2(1.47)S0, 6.2(2), 7.0(0.5), 7.0(0.6), 7.1(0)D1(0.14), 7.1(0)D1(0.15), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx75680 | Title: | Memory exhaustion due to ICMPv6 packets |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
NX-OS may run out of memory and possibly crash while processing ICMPv6 packets
Conditions:
IPv6 enabled and NX-OS processing ICMPv6 packet from the adjacent segment.
The issue is due to the increasing size of some of the local table in NX-OS which require additional memory
Workaround:
none
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.1/5.8:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2012-3064 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 6.2(1.35)S0, 6.2(2), 7.0(0.6), 7.1(0)D1(0.14), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua47950 | Title: | VLAN Header not stripped for Encaped PIM Hellos sent over PWs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Vlan header not stripped
Conditions:
When multicast packet is sent on Pseudowire
Workaround:
None
More Info:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0.1) |
|
Known Fixed Releases: * | 6.2(0.213)S3, 6.2(0.228)S0, 6.2(0.240)S0, 6.2(2), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub97946 | Title: | LACP member port stuck in the I-state |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LACP port-channel on the N7k is down. Member interfaces are in the I-state. For example,
Nexus7000-1# sh port-chann summary
Flags: D - Down P - Up in port-channel (members)
I - Individual H - Hot-standby (LACP only)
s - Suspended r - Module-removed
S - Switched R - Routed
U - Up (port-channel)
M - Not in use. Min-links not met
--------------------------------------------------------------------------------
Group Port- Type Protocol Member Ports
Channel
--------------------------------------------------------------------------------
10 Po10(SD) Eth LACP Eth7/6(I) <<<<<<
Conditions:
The other side is sending LACP PDUs but the N7k is not seeing it (using 'show lacp counters'). For example, the other side here is an N1k:
N1k-1-5# show lacp counters
LACPDUs Marker Marker Response LACPDUs
Port Sent Recv Sent Recv Sent Recv Pkts Err
---------------------------------------------------------------------
port-channel1
Ethernet3/4 157041 1 0 0 0 0 0
^^^^
N1k-1-5# show lacp counters
LACPDUs Marker Marker Response LACPDUs
Port Sent Recv Sent Recv Sent Recv Pkts Err
---------------------------------------------------------------------
port-channel1
Ethernet3/4 157044 1 0 0 0 0 0
^^^^
From the N7k:
Nexus7000-1# show lacp counters
LACPDUs Marker Marker Response LACPDUs
Port Sent Recv Sent Recv Sent Recv Pkts Err
---------------------------------------------------------------------
port-channel10
Ethernet7/6 5710 290 0 0 0 0 0
^^^
Nexus7000-1# show lacp counters
LACPDUs Marker Marker Response LACPDUs
Port Sent Recv Sent Recv Sent Recv Pkts Err
---------------------------------------------------------------------
port-channel10
Ethernet7/6 5710 290 0 0 0 0 0
^^^
Workaround:
Shutdown the N7k port-channel interface, wait for 5 seconds and then do a 'no shut'. Same works with the member interfaces also.
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.1(1) |
|
Known Fixed Releases: * | 5.2(9), 5.2(9)S18, 5.2(9.30)S0, 6.0(2)U2(1), 6.0(2)ZD(0.4), 6.1(2)E1, 6.1(3), 6.1(3)S12, 6.1(3.4)S0, 6.2(0.260)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum20852 | Title: | Iluka: hmm: am_find_adj_with_uuid: VINCI: No prot_count |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When HMM calls am_find_iod_by_uuid_and_name to get the gpc_iod we see a syslog returned by AM.
Conditions:
Syslog is seen when GPC is not available.
Workaround:
This is a harmless syslog msg and can be ignored.
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 7.0(0)N1(0.400) |
|
Known Fixed Releases: * | 7.0(0)BNZ(0.23), 7.0(1)N1(0.56), 7.0(1)N1(1), 7.0(1)ZD(0.111), 7.0(1)ZN(0.124), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60), 7.1(0)SDN(0.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj52700 | Title: | Additonal Next-hop appears when using /0 subnet Mask |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Additonal Next-hop appears for default route when using /0 subnet Mask.
Conditions:
When we have misconfigs, such as one shown below,
ip route 172.23.43.23/0 10.26.31.97 -> Note /0 subnet mask
Workaround:
Add the route manually by doing,
ip route 0.0.0.0/0 10.26.31.97
no ip route 0.0.0.0/0 10.26.31.97
Clear ip route * will make the route re-appear as,
0.0.0.0/0, ubest/mbest: 2/0
*via 10.26.31.65, [1/0], 00:00:03, static
*via 10.26.31.97, [1/0], 00:00:03, static
Although in config, i have only one default route which is "ip route 0.0.0.0/0 10.26.31.65".
(or)
Permanent fix is to remove the misconfigs,
Eg: no ip route 172.23.43.23/0 10.26.31.97
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 6.0(2)N3(0.358), 6.0(2)N3(1), 6.2(0)HS(0.10), 6.2(5)BF(0.59), 6.2(5.66)S0, 6.2(6), 7.0(0)BNZ(0.23), 7.0(0)ZD(0.155), 7.0(0)ZN(0.78), 7.0(1)N1(0.47) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx38379 | Title: | N7K: ip statistics on loopback interfaces not getting incremented |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:Counters on loopback interface are not incremented by ping.
Conditions:Ping to loopback interface with packet size more than the physical interface MTU, loopback interface input stats are incrementing.
Whereas Ping to loopback interface with packet size less than the physical interface MTU, loopback interface input stats are NOT incrementing.
Workaround:If the MTU is default value 1500, use ping option below
ping x.x.x.x packet-size 1473
More Info:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 5.0(3)U3(0.116), 6.1(4) |
|
Known Fixed Releases: * | 6.2(0.249)S0, 6.2(2), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh27510 | Title: | Software processed acl not applied after lc reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Egress policies/ACLs on interfaces(belonging to Line Card that is reloaded) would not be applied in software forwarding path post Line Card reload
Conditions:
When the Line Card is reloaded
Workaround:
Re-Apply ACL/policies on the affected interfaces post Line Card Reload
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: * | 6.2(1.118)S1, 6.2(5.41)S0, 6.2(8), 6.2(8)IA(1) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S82, 6.2(10.16)S0, 7.0(0)BNZ(0.23), 7.0(0)FVX(0.109), 7.1(0)BF(0.65), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq72316 | Title: | N7K:Static route leak w/ unconfig/config SVIs cause traffic black hole |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Traffic black hole
Conditions:
With Static route configure, unconfigure/configure the SVI.
Workaround:
1. unconfig global static route which is in problematic state
2. Clear any stale route still present globally
3. Config back global static route
Further Problem Description:
|
|
Last Modified: | 27-JAN-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(14), 6.2(8)E9, 6.2(8a), 6.2(8b) |
|
Known Fixed Releases: * | 6.2(10)E5, 6.2(16)S1, 6.2(8)E10, 7.0(3)I3(0.285), 7.0(3)I3(1), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.440), 7.2(0)D1(1), 7.2(0)FM(0.3) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux28164 | Title: | DOM not supported and cisco id empty for QSFP-40G-SR-BD SFP on MDS |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
DOM not supported for the optics QSFP-40G-SR-BD on MDS 9700 series.
Following show command will give the error message "DOM not supported"
show interface ethernet transceiver details
Conditions:
DOM is not supported on the MDS 9700 series.
Workaround:
No impact to the functionality. No workarounds.
Further Problem Description:
DOM not supported for the optics QSFP-40G-SR-BD on MDS 9700 series.
Following show command will give the error message "DOM not supported"
show interface ethernet transceiver details :
Sample output of the show command:
...
transceiver is present
type is QSFP-40G-SR-BD
name is CISCO-AVAGO
part number is AFBR-79EBPZ-CS1
revision is 01
serial number is AVM1820S231
nominal bitrate is 20600 MBit/sec per channel
Link length supported for 50/125um OM3 fiber is 100 m
cisco id is --
cisco extended id number is 220
cisco part number is 10-2945-01
cisco product id is QSFP-40G-SR-BD
cisco vendor id is V01
number of lanes 4
DOM is not supported
DOM is not supported
DOM is not supported
DOM is not supported
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.162) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw08846 | Title: | N7K 7.2 %VPC-2-L3_VPC_UNEQUAL_WEIGHT: |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
layer-3 peer-router. As soon as we configure this command we notice the following logs:
%$ VDC-1 %$ %VPC-2-L3_VPC_UNEQUAL_WEIGHT: Unequal weight routing is not supported in L3 over vPC. Please make sure both vPC peers have equal link cost configuration
- CPU utilization could be high due to MCECM process
Conditions:
when layer-3 peer-router is configured
Workaround:
Disable them using the command: "no layer3 peer-router syslog".
Note: It may be necessary to configure "layer3 peer-router syslog" before configuring "no layer3 peer-router syslog" in order to stop the logs.
Further Problem Description:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1), 7.2(0)ZN(99.27) |
|
Known Fixed Releases: | 7.2(1)D1(0.83), 7.2(1)D1(1), 7.2(1)ZD(0.75) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCui51401 | Title: | HW acl entries are not correct when having IPv6 RACL with BFD enabled |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Ipv6 BFD sessions go down when a IPv6 RACL is applied on the SVI where BFD is applied. BFD sessions applied alone seem to work fine
permit aces may not work as expected when ipv6 bfd and ipv6 RACL applied on same interface.
Conditions:
ipv6 bfd and ipv6 RACL applied on same interface.
Workaround:
don't use ipv6 bfd and ipv6 RACL together on same interface.
Further Problem Description:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 6.2(2)S21 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu47169 | Title: | Enhancements to GOLD corrective actions show commands |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
This is an enhancement for the GOLD (show diagnostic) CLI which will provide more information on the corrective actions that can be enabled though "diagnostic eem action conservative" command,
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 6.2(12), 6.2(8a) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.3(0)DX(0.44), 7.3(0)GLF(0.53), 7.3(0)UCI(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux01711 | Title: | N7k / N77k - Interface (HIF) counters on Nexus 2348 may be erroneous |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Fex 2348 report erroneous / false counters.
aur_l3_sw1# show int Eth101/1/2
Ethernet101/1/2 is up
admin state is up, Dedicated Interface
Hardware: 100/1000/10000 Ethernet, address: e0d1.732f.4903 (bia
e0d1.732f.4903)
Description: axe1fw01p
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
reliability 255/255, txload 255/255, rxload 255/255
Encapsulation ARPA, medium is broadcast
Port mode is access
full-duplex, 1000 Mb/s
Beacon is turned off
Auto-Negotiation is turned on
Input flow-control is off, output flow-control is on
Auto-mdix is turned off
Switchport monitor is off
EtherType is 0x8100
Last link flapped 6week(s) 4day(s)
Last clearing of "show interface" counters never
4 interface resets
Load-Interval #1: 30 seconds
30 seconds input rate 1481841587208 bits/sec, 371280410 packets/sec
30 seconds output rate 2333645761384 bits/sec, 438267561 packets/sec
input rate 1481.84 Gbps, 371.28 Mpps; output rate 2333.65 Gbps, 438.27
Mpps
This issue is seen when N7k / N77k is a parent switch. Fix on N5k / N6k is available via CSCuv29358
Conditions:
N2k-2348 fex
Workaround:
This is a cosemtic counter bug. please use show inter <> counters / show inter <> summary to get the exact counters values.
Further Problem Description:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.0(2)FIP(0.158), 7.2(2)D1(0.32), 7.2(2)D1(0.33), 7.2(2)D1(0.34), 7.2(2)D1(0.35), 7.2(2)D1(0.36), 7.2(2)ZD(0.47), 7.2(2)ZD(0.48), 7.2(2)ZD(0.49) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj56114 | Title: | Performance issues w/ Policy Propagation Facility (PPF) for netflow prog |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In Nexus7000 with netflow configuration, one or more following symptoms are observed:
Applying configs (e.g., "copy bootdisk:backup running-config") takes longer time.
E.g., 5 minutes (without netflow config) vs. 30 mins (with netflow configs)
As a result, control-plane protocols (like OSPF) takes longer time to converge.
Nexus7000 switch exporting netflow statistics even after configs are removed.
May report NFM-3-MONITOR_NOT_FOUND error messages.
ACL TCAMs in the hardware not updated even after netflow configs removed.
"show hardware access-list vlan X input statistics module Y" indicates netflow sampler/profile is still present in the hardware.
Saving the config with "copy run start" may report:
%NFM-4-NFM_DDB_WARNING: DDB warning: DDB Error:
Sampled netflow on F2 card does not collect or export any data.
Or, it exports with FlowSet ID not matching the Template ID.
Conditions:
The above-mentioned issues are seen in Sup1/Sup2E running 6.x releases.
Workaround:
Remove the netflow configs before applying configs to running-config.
After the system is completely up (and also Layer3 control-plane protocols like OSPF, HSRP etc.), re-apply the netflow configuration.
Please be aware that this may still take longer time but lesser impact with layer3 adjacency(s) active.
More Info:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: * | 5.2(4.84), 6.1(1)S53, 6.1(2), 6.1(2)S23, 6.1(3)S32, 6.2(14), 6.2(5)NF(0.1), 6.2(8)S16 |
|
Known Fixed Releases: | 6.2(5)NF(0.7), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)GI(0.5), 7.0(0)KM(0.37), 7.0(2)NF(0.3), 7.0(2)NGB(0.2), 7.0(2.1)NGB(0.11), 7.0(2.1)NGB(0.14), 7.0(2.1)NGB(0.16) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty67801 | Title: | SVI should not be allowed for vpls vlan |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
This is a feature request for SVI, where SVI creation has to fail if VFI is configured under a vlan, and vice-versa, VFI configuration under a vlan has to fail if corresponding SVI is created.
Conditions:
If both SVI and VFI are configured for a vlan at the sam time.
Workaround(s):
User has to be careful not to configure both SVI and VFI for a vlan at same time.
Workaround:
User has to be careful not to configure both SVI and VFI for a vlan at same time.
Further Problem Description:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: * | 5.2(0)LV1(0.274), 6.2(1.125)S6, 7.3(0)D1(1) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.166), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.80), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux98643 | Title: | MRIB-3-MALLOC_FAILED: Some S,G can't be programmed causing software punt |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Multicast traffic (S-->G) is being punted to the CPU because S,G mroute state is not created in software. This event occurs after MRIB malloc failure:
2016 Jan 19 00:29:53.216 n7k-vdc2 %MRIB-3-MALLOC_FAILED: mrib [8390] mrib_smalloc() failed for mrib_mpib_route_datatype
2016 Jan 19 00:29:53.578 n7k-vdc2 %MRIB-3-NO_SOURCE: mrib [8390] Unable to create source entry for (x.x.x.x/32, 239.y.y.y/32)
We may see Copp Violations for the class servicing this traffic type if the multicast traffic rate is high.
match exception ip multicast directly-connected-sources
match exception ipv6 multicast directly-connected-sources
Conditions:
m4route-mem usage exceeded the limit set for the VDC at some point.
Workaround:
Clear the mroute entries for "non existent" S,G:
clear ip mr data-created
Further Problem Description:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03144 | Title: | OpenSSH: Evaluation of Multiple OpenSSH CVEs for NX-OS |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Cisco Nexus Operation System (NX-OS), running on the Cisco Nexus 5000 Series Switches, Cisco Nexus 6000 Series Switches, Cisco Nexus 7000 Series Switches and Cisco MDS 9000 Series Multilayer Switches include a version of Open Secure Shell (OpenSSH) software that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-5600, CVE-2015-6563, CVE-2015-6564, CVE-2015-5352 and CVE-2015-6565
This bug was opened to address the potential impact on this product.
Conditions:
Device with default configuration.
Workaround:
Not currently available.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at
http://cve.mitre.org/cve/cve.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5600
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6563
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6564
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6565
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5352
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.9/6.9:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:M/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C&version=2.0
CVE ID CVE-2015-5600, CVE-2015-6563, CVE-2015-6564, CVE-2015-6565, CVE-2015-5352 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 6.2(12), 7.3(0)ZN(0.89) |
|
Known Fixed Releases: * | 6.2(15)S10, 6.2(16)S16, 7.2(1)D1(1), 7.2(1)N1(0.331), 7.2(1)N1(1), 7.2(1)ZD(0.98), 7.2(1)ZN(0.92), 7.2(2)D1(0.2), 7.3(0)D1(0.90), 7.3(0)EG(0.3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw85884 | Title: | N7K snmpd process seg fault crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
snmpd process may crash and trigger the hap reset:
`show system reset-reason`
----- reset reason for module 5 (from Supervisor in slot 5) ---
1) At 846639 usecs after Thu Oct 15 14:06:23 2015
Reason: Reset triggered due to HA policy of Reset
Service: snmpd hap reset
Version: 6.2(10)
Conditions:
this was observed on N7K running 6.2.10 code when snmp get on the non-existence FC port information.
Workaround:
unknown for now
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 6.2(10)S99 |
|
Known Fixed Releases: * | 6.2(16)S16 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux81204 | Title: | PBR doesn't work for additional SVI |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
PBR doesn't work for additional SVI
Conditions:
- Create SVIs and configure PBR for these SVI
- Trunk vlans are assigned to interface at the end. But PBR doesn't work.
- In this environment, all VLANs are explicitly trunked.
Workaround:
a. shutdown and no shutdown
b. allow trunk VLAN to interface before configure PBR to SVI
Further Problem Description:
- Policy is attached to a VLAN interface which is down
- VLAN is not part of any interface
- TCAM is allocated, Label attachment to interface fails and the internal vlan is not yet allocated
- Label will be allocated when VLAN L3 proto is up
- VLAN is attached to a trunk interface
- VLAN pre config notification is received
- Policy update is sent, Label attachment to interface fails and the internal vlan is not yet allocated
- L3 up notification is received, policy update is not sent as there is no change in the policy
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 6.0(2)N2(1), 7.2(1)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup81570 | Title: | npacl filter missing for line vty, also action logged is incorrect |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
committed into bender barnch
Conditions:
committed into bender barnch
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 29-JAN-2016 |
|
Known Affected Releases: | 6.2(10)S17 |
|
Known Fixed Releases: * | 6.2(14a)S3, 6.2(16)S16, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.228), 7.1(0)D1(0.233), 7.1(0)N1(0.280), 7.1(0)N1(0.290), 7.1(0)N1(1), 7.1(0)NF(0.32) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw55057 | Title: | urib not updating FIB when the RP has the same admin distance as AM |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
When customer does a IP change for the host in a vlan and check the route for the destination Nexus 7000 shows the best path as the LISP route which is expected but the FIB shows the route which is different than LISP route.
Conditions:
When customer does a IP change for the host in a vlan.
Workaround:
clear ip route is solving the issue.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 6.2(12), 6.2(14) |
|
Known Fixed Releases: * | 7.3(1)PIB(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur24212 | Title: | memory leak in dhcp_snoop process |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
dhcp_snoop process crashing due to a memory leak
Conditions:
If there are drops in relay packet due to interface error then memory leak happens for the process.
Interface error counter can be seen in show ip dhcp relay statistics(drop reasons)
Workaround:
If Interface Error can be identified and resolved then leak will no more happen.
Further Problem Description:
Usually this interface error happens if there are ACLs installed in line card for DHCP(relay or snoop) for a VLAN and there are no relay addresses configured on the respective SVI.
To confirm if DHCP traffic may be hitting SVIs where a DHCP relay isn't present, the following procedure can be used -
1) First, setup a debug logfile using the following command -
debug logfile DHCP
2) Next, enable the following debugs -
debug dhcp pkt-error
debug dhcp pkt-event
3) After letting the debugs run for 1-2 minutes, check the output of the logfile -
show debug logfile DHCP
In the debug output, we are specifically interested in looking for received DHCP traffic on a non-DHCP relay SVI. This output would look similar to the following -
2016 Jan 20 22:31:19.394043 dhcp_snoop: (PKT)RECIEVED packet type DHCP RELAY
2016 Jan 20 22:31:19.394053 dhcp_snoop: (PKT) DHCPINFORM on Intf Vlan255(268), phy (0), vlan 0, pvlan 0, vdc 0, vrf default
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.1(2)I3(2.39), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.6), 6.2(12)FT(0.5), 7.0(0)BZ(0.46), 7.0(0)HSK(0.357) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux55089 | Title: | N5K: EEM triggered by wrong event in case of using boolean "AND" logic |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N5K: EEM triggered by wrong event in case of using boolean "and" logic
Conditions:
1 and 2
1. use EEM tags to link some syslog events to EEM action.
2. use boolean "AND" logic to link 4 events to EEM action as follow.
tag ONE and TWO and THREE and FOUR happens 1 in 60
Workaround:
use tags less than 3 tags
Further Problem Description:
you can check EEM events history with a following command.
show event manager history events detail
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.191), 7.3(0)HIB(0.3), 7.3(0)IZN(0.13), 7.3(0)N1(0.247), 7.3(0)N1(1), 7.3(0)ZD(0.209), 7.3(0)ZN(0.223) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw74054 | Title: | Traffic outage issue on switch reload - multicast scale testbed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Under scale conditions, when the neighboring router is rebooting, it is possible that PIM and MRIB routes go out of sync and hence possible black holing of traffic for some receivers.
Conditions:
Under scale (like 25k-32k routes) conditions and the neighbor router is coming up after a cold reboot.
Under these conditions, PIM module does not update MRIB module about the correct OIF states.
"show ip pim oif-list" and "show ip mroute" will show different set of outgoing interfaces. This bug is due to incorrect processing of txlist used by PIM to update MRIB module.
Although this bug is rarely under less scale, it is still possible to get into this condition.
Workaround:
Use "clear ip mroute" command to clear out the problematic routes will fix the issue.
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1), 7.3(0.149) |
|
Known Fixed Releases: * | 7.3(0)D1(0.174), 7.3(0)GLF(0.44), 7.3(0)IZN(0.13), 7.3(0)N1(0.228), 7.3(0)N1(1), 7.3(0)SC(0.14), 7.3(0)ZD(0.189), 7.3(0)ZN(0.205) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux47285 | Title: | LISP: race condition LISP/RIB when programming FIB |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a LISP ESM deployment a host/VM that has been detected on one DC moves (EAST-WEST) accross the DCI. A map-cache for the host is installed on the original DC site to forward traffic to the new DC, however traffic is lost.
A detailed observation of the forwarding table reveals that the map-cache is not present in the forwarding table, but a punt route to the supervisor (that corresponds to the lisp null0 (away) route installed by lisp).
Conditions:
The origin of the problem is a race condition between LISP and uRIB were the order in which LISP writes the map-cache and away routes is not kept when writing down to forwarding.
Both the away route and the map-cache are installed in close time proximity to each other and end-up written in reverse order. The end result is that the away route is written later and overwrites the map-cache in the linecard.
Workaround:
Clearing the specific map-cache will solve the problem (it triggers a rewrite of the forwarding entry)
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.194), 7.3(0)HIB(0.3), 7.3(0)IZN(0.13), 7.3(0)N1(0.249), 7.3(0)N1(1), 7.3(0)ZD(0.211), 7.3(0)ZN(0.225) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv42487 | Title: | show tech-support fcoe needs to contain all pertinent FC information |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Enhance show tech-support fcoe so that it includes all FC pertinent information. This should be similar to the MDS show tech-support details
Conditions:
Applicable to the Nexus 7000 switch in the FCoE storage VDC.
Workaround:
Use individual show tech-support commands. For example:
show tech-support zone
show tech-support fcns
show tech-support fcdomain
show tech-support port
etc...
Further Problem Description:
None.
Resolution Summary:
show tech-support fcoe is renamed to show tech-support fcoe_mgr and continues to contain just fcoe manager information.
show tech-support fcoe will now contain a large amount of information specifically for troubleshooting FCoE related problems. It will include show tech-support fcoe_mgr and other FC/FCoE related show techs.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.148), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)IZN(0.13), 7.3(0)N1(0.197), 7.3(0)N1(1), 7.3(0)PDB(0.112), 7.3(0)RTG(0.115), 7.3(0)SC(0.14), 7.3(0)ZD(0.165) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux77347 | Title: | LISP: map-cache on the standby HSRP is not cleared when dyn host returns |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A pair of xTRs are setup in HSRP mode and both have their map-cache populated with an entry driving encapsulation of traffic to a dynamic host that is remote.
If this remote dynamic host becomes local, the xTR acting as Active in the HSRP pair correctly clears the map-cache entry, but the xTR acting as Standby fails to clear the map-cache entry.
Conditions:
xTRs are deployed in a DC in ESM single-hop mode with HSRP redundancy. In order to reach this status the two routers have changed HSRP role while the VM was "away". This leads to the standby router having the map-cache populated.
Workaround:
Clear the map-cache on the Standby HSRP
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.202), 7.3(0)IZN(0.13), 7.3(0)N1(0.263), 7.3(0)N1(1), 7.3(0)ZD(0.230), 7.3(0)ZN(0.239) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur56960 | Title: | VRRS pathway stuck in "Currently being removed" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
VRRS pathway stuck in "Currently being removed"
Conditions:
When we move from VRRS pathway to VRRP, VRRS pathway stuck in "Currently being removed" state for all slaves. Due to this error, we cannot configure the VIP when we try to move the slave to a vrrp group. The trigger of this issue is to remove the SVI completely.
Workaround:
Instead of removing the SVI completely, remove VRRS pathway config only.
Further Problem Description:
.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.190), 7.3(0)IZN(0.13), 7.3(0)N1(0.246), 7.3(0)N1(1), 7.3(0)ZD(0.208), 7.3(0)ZN(0.222) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux63641 | Title: | EEM script not being deleted from running-config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Nexus 5600 platforms on newer code can fail to purge the EEM script from the running-config in some cases.
Conditions:
Nexus 5600 running 7.2(1)N1(1) with EEM script configured
Workaround:
Performing a full write erase / reload is the only way to clear out the EEM script once and for all.
Further Problem Description:
Nexus 5600 platforms on newer code can fail to purge the EEM script from the running-config in some cases.
+ Add an EEM script
+ Do a copy run start
+ show startup EEM shows the script in the startup config
+ Reload the switch if you want. The EEM script is still in the running config.
+ Write erase (clear the startup config)
+ Remove the EEM scripts from the running-config
+ Copy run start
+ Reload
+ Result: The EEM script is still partially in the running-configuration!
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.2(1)N1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.202), 7.3(0)IZN(0.13), 7.3(0)N1(0.263), 7.3(0)N1(1), 7.3(0)ZD(0.230), 7.3(0)ZN(0.239) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux52081 | Title: | N7k: Spacing issue in show snmp community. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show snmp community.
Conditions:
show command/SNMP
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.142), 7.3(0)D1(0.190), 7.3(0)DX(0.40) |
|
Known Fixed Releases: * | 7.3(0)D1(0.198), 7.3(0)HIB(0.3), 7.3(0)IZN(0.13), 7.3(0)N1(0.258), 7.3(0)N1(1), 7.3(0)ZD(0.225), 7.3(0)ZN(0.234) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux09435 | Title: | N7K - MSDP SA information not exchange after reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Source Active messages not sent to MSDP peers after router reload.
The MSDP session is established, control messages exchanged periodically to keep state up, but SA not created/exchanged.
Conditions:
Anycast RP with MSDP implementation. Issue occurs after device reload with overlapping RP groups.
Workaround:
The issue clears and SA exchange resumes after MSDP process restart
restart msdp
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.156), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), 7.3(0)D1(0.156), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)IZN(0.13) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux20536 | Title: | WCCP configuration is missing on show run |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Problem is that if automatic backups are taken from the configuration those lines are missing.
-ssh to device
-sh startup-config > tftp://backupserver/backup_config
Symptom:
N7K1(config)# show running-config wccp
!Command: show running-config wccp
!Time: Wed Apr 8 15:10:24 2015
version 7.2(0)D1(1)
feature wccp
vrf context wan
ip wccp 61 password 0 AppNav redirect-list WCCP
Conditions:
None
Workaround:
None
Further Problem Description:
tested on previous versions are showing the configuration.
OTV2(config-vrf)# feature wccp
OTV2(config)# vrf context Wan
OTV2(config-vrf)# ip wccp 61 password 0 AppNav redirect-list WCCP
OTV2(config-vrf)# ip wccp 62 password 0 AppNav redirect-list WCCP
OTV2(config-vrf)# ex
OTV2(config)# show version | inc bin
kickstart image file is: bootflash:///n7000-s2-kickstart.6.2.10.bin
system image file is: bootflash:///n7000-s2-dk9.6.2.10.bin
OTV2(config)# show running-config | inc wccp
feature wccp
ip wccp 61 password 0 AppNav redirect-list WCCP
ip wccp 62 password 0 AppNav redirect-list WCCP
OTV2(config)# show running-config wccp
!Command: show running-config wccp
!Time: Sun Sep 2 04:29:07 2012
version 6.2(10)
feature wccp
vrf context Wan
ip wccp 61 password 0 AppNav redirect-list WCCP
ip wccp 62 password 0 AppNav redirect-list WCCP
OTV2(config)#
OTV2# show version | inc bin
kickstart image file is: bootflash:///n7000-s2-kickstart.6.2.12.bin
system image file is: bootflash:///n7000-s2-dk9.6.2.12.bin
OTV2# con t
Enter configuration commands, one per line. End with CNTL/Z.
OTV2(config)# vrf context Wan
OTV2(config-vrf)# ip wccp 61 password 0 AppNav redirect-list WCCP
OTV2(config-vrf)# ip wccp 62 password 0 AppNav redirect-list WCCP
OTV2(config-vrf)# ex
OTV2(config)# show running-config | inc wccp
feature wccp
ip wccp 61 password 0 AppNav redirect-list WCCP
ip wccp 62 password 0 AppNav redirect-list WCCP
OTV2(config)# show running-config wccp
!Command: show running-config wccp
!Time: Sun Sep 2 05:08:18 2012
version 6.2(12)
feature wccp
vrf context Wan
ip wccp 61 password 0 AppNav redirect-list WCCP
ip wccp 62 password 0 AppNav redirect-list WCCP
|
|
Last Modified: | 07-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui63830 | Title: | N7K - snmp slowness in vtpVlanTable in ciscoVtpMIB |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
Slowness observed during the walk of vtpVlanTable in ciscoVtpMIB.
Conditions:
The slowness is observed when vtpVlanTable mibwalk is performed.
Workaround:
None.
Further Problem Description:
The issue exists in NXOS software releases 5.1(x), 5.2(1-8), 6.1(1-4), 6.2(1-5).
The fix is available in NXOS software releases 5.2(10), 6.1(5), 6.2(6) and all the later releases.
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: * | 6.2(2)S0, 6.2(2)S27, 6.2(2)S31 |
|
Known Fixed Releases: | 5.2(9.245)S0, 6.0(2)A2(0.488), 6.0(2)A2(1), 6.0(2)U2(0.12), 6.0(2)U2(0.488), 6.0(2)U2(1), 6.0(2)U3(0.22), 6.0(2)U3(1), 6.1(4.84)S0, 6.1(5) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux83857 | Title: | Storm-control values revert to original values after overwrite removed |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
Configuring 'storm-control unicast level xx.xx' will change broadcast & multicast to this same level. When 'storm-control unicast level xx.xx' is removed we see the broadcast/multicast values stay at the old unicast level instead of reverting back to their original values.
Conditions:
Configuring storm-control for unicast/broadcast/multicast
Workaround:
re-configure storm-control levels
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv80855 | Title: | BGP Nexthop is not correct in the case of Multiaccess Networks |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
eBGP nexthop is not the third party address for the route that is learned via IGP on a multi-access network(eg. Ethernet).
Conditions:
eBGP peering on multi-access network, and routes are learned internally.
Basically, it's the "BGP Next Hop (Multiaccess Networks)" case in
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#bgpnexthop
Workaround:
Set an outbound policy map on the neighbor with "set ip next-hop unchanged".
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.0(3)I3(0.123), 7.0(3)I3(1), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2), 7.3(0)D1(0.178), 7.3(0)RTG(0.102), 7.3(0)SC(0.14), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux87685 | Title: | sh bgp l2vpn evpn vrf XXX does not show vrf name in output |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
N9k# show bgp l2vpn evpn 10.175.20.63 vrf RED
BGP routing table information for VRF default, address family L2VPN EVPN
The above link should specific the VRF name and not VRF default
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 18-JAN-2016 |
|
Known Affected Releases: | 7.0(3)I2(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum09975 | Title: | SSTE: show tech bfd throws error if size greater than 500M |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
When collecting a showtech from the Command Line Interface (CLI) on a N7K chassis with many Line Cards (LCs) which are of type "F3" the user can error message saying "No space left on device" in the volatile: disk.
Conditions:
Incomplete show tech ouput.
Workaround:
Need to collect the show tech output from the particular LC's for which error message is displayed.
Further Problem Description:
Whenever there is too many LC's plugged in, and the show tech output greater than 500M, the error message will be displayed "No space left on device".
Since only 500M is allocated.
|
|
Last Modified: | 18-JAN-2016 |
|
Known Affected Releases: | 6.2(6)S12 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.85), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua92729 | Title: | configure Order of show run vlan x is changed by feature dhcp |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
Order of configuration of interface vlan is changes by 'feature dhcp'
Conditions:
- confire 'feature dhcp', and then order of the configuration changes at interface vlan.
- To my knowledge, 'description' and 'no shutdown' is effected.
- This issue is no impact for system.
// before
interface Vlan4
description VLAN4 <<<<
no shutdown <<<<
ip address 10.32.192.9/29
ip router eigrp 1
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 tsbinternet
hsrp 4
preempt
priority 105
ip 10.32.192.14
// after
interface Vlan4
ip address 10.32.192.9/29
ip router eigrp 1
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 tsbinternet
hsrp 4
preempt
priority 105
ip 10.32.192.14
description VLAN4 <<<<
no shutdown <<<<
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 19-JAN-2016 |
|
Known Affected Releases: | 5.2(4), 5.2(7), 6.0(2), 6.1(2), 6.2(12) |
|
Known Fixed Releases: | 7.3(0)D1(0.79), 7.3(0)EG(0.3), 7.3(0)IB(0.67), 7.3(0)MMD(0.9), 7.3(0)OTT(0.32), 7.3(0)PDB(0.45), 7.3(0)RTG(0.68), 7.3(0)SC(0.14), 7.3(0)ZD(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq62069 | Title: | QSFP BiDi gives out bogus DOM info when DOM is not supported |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
When issuing "show interface transceiver det" on an interface with QSFP BiDI with 6.2.8a and later releases, the output contains all 0 or N/A. The output should be either removed or clarified to indicate that DOM is not supported for BiDi.
Conditions:
Using QSFP BiDi on n7k runnig 6.2.8a and later
Workaround:
Expected behavior, refer to the DOM compatible matrix:
http://www.cisco.com/c/en/us/td/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_8031.html#36364
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 6.2(8a), 7.3(0)DX(0.18) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.3(0)DX(0.40), 7.3(0)DX(0.41), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus53354 | Title: | N7K-OFF-DIAG:Pescara N7K 100: DSH can't start all dsps in BB |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
some dsp can't startup automatcially.
It need more time.
Conditions:
NTNV
Workaround:
init group need be refined
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.2(0)ZN(0.87) |
|
Known Fixed Releases: * | 6.2(10)CR(0.35), 7.0(0)BZ(0.46), 7.0(0)HSK(0.325), 7.1(320)MQ(0.60), 7.3(0)DX(0.4), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCun07048 | Title: | DOC Bug : F3: Passive Copper optics not supported in Non EDC ports |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
Symptom : QSFP passive copper (QSFP-H40G-CU1M, QSFP-H40G-CU3M, QSFP-H40G-CU5M) and copper breakout cables (QSFP-4SFP10G-CU1M, QSFP-4SFP10G-CU3M, QSFP-4SFP10G-CU5M) are not supported on the following modules:
? N7K-M206FQ-23L
? N7K-F312FQ-25
? N77-F324FQ-25
Conditions:
Conditions : This symptom lists the modules that do not support specific QSFP passive copper cables and copper breakout cables.
this is unsupported combination and there is no plan to support this type of combination.
Release notes of 6.2 and applies to ALL releases afterwards:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/release/notes/62_nx-os_release_note.html#pgfId-812507
Workaround:
Workaround : Use active optical cables (QSFP-H40G-AOC1M, QSFP-H40G-AOC3M, QSFP-H40G-AOC5M) and active optical breakout cables (QSFP-4X10G-AOC1M, QSFP-4X10G-AOC3M, QSFP-4X10G-AOC5M).
Further Problem Description:
|
|
Last Modified: | 22-JAN-2016 |
|
Known Affected Releases: | 6.2(8)FM(0.20) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua03954 | Title: | IPv6 SLAA Test case 3, 14 & 15 failed in Tahi testing |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
Send/sendto will fail.
Conditions:
Send and Send to will fail when outgoing Interface is specified, generally if the outgoing interface is specified then the stack should treat destination address as next-hop, which was not happening.
Workaround:
None.
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0.142)S0 |
|
Known Fixed Releases: * | 6.2(0.213)S0, 6.2(2), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj51882 | Title: | MSDC Quality Initiative: Fix critical SA warnings |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
N/A
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 7.0(1)ZD |
|
Known Fixed Releases: * | 6.0(2)N3(0.73), 6.0(2)N3(1), 7.0(0)BNZ(0.23), 7.1(0)BF(0.26), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60), 7.1(0)SDN(0.6), 7.1(0)ZDP(0.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud98183 | Title: | pkmgr doesn't cache the static rtr mac address |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0.302)S8 |
|
Known Fixed Releases: * | 6.2(0.304)S12, 6.2(1.3)S0, 6.2(2), 7.0(0.5), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuq58205 | Title: | N7K:6210:potential cmp memory leak |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Memory leak is seen in the cmpproxy process. The leak is seen here:
Nexus# show system internal cmpproxy mem-stats detail
.
.
Lib ID: 0x1
Mem stats for UUID : Non mtrack users(0) Max types: 113
--------------------------------------------------------------------------------
TYPE NAME ALLOCS BYTES
CURR MAX CURR MAX
.
.
85 [r-xp]/isan/plugin/0/isan/lib/libutils.so.0.0.0 224036 224036 85428540 85428540 <<<<<<<
.
.
--------------------------------------------------------------------------------
Total bytes: 85497944 (83494k)
--------------------------------------------------------------------------------
Conditions:
A Connectivity Management Processor (CMP) is enabled and is being used on a Sup1 for a Nexus 7K
Workaround:
None Known
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S66, 6.2(10.16)S0, 7.1(0)AV(0.38), 7.1(0)D1(0.263), 7.1(0)OTT(0.36), 7.1(0)PDB(0.205), 7.2(0)D1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux75576 | Title: | N7K Unable to admin/shut down interfaces at first attempt. |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
When shut down command is applied at interface config mode, the interfaces stays "up" at first attempt and only goes "down" at second attempt. Same issue with individual interface or interfaces in range.
Conditions:
Pre-configured port profiles with "no shutdown" entry included have been applied to affected interfaces.
Workaround:
Users have to try the "shut down" command again and succeed to shut down the interface at second attempt. Or the "no shutdown" entry has to be removed from the relevant port-profiles and applied back at the interfaces.
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCup79142 | Title: | no ip passive-interface eigrp cannot be removed from interface config |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
Once you enabled "passive-interface default" under router eigrp process, the "no ip passive-interface eigrp" or "ip passive-interface eigrp" won't go away from the interface configuration.
The interface configuration should not show either "no ip passive-interface eigrp <>" or "ip passive-interface eigrp<>" .
Conditions:
Once passive-interface is enabled.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 27-JAN-2016 |
|
Known Affected Releases: | 6.2(8)S23 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz50653 | Title: | OTV Enh: Clear OTV forwarding multicast counters |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Enhancement request to clear otv forwarding counters shown in
sh forwarding otv multicast route vlan 10 mod 7
Conditions:
Currently no way to clear these counters manually.
Workaround:
NA. Enhancement request
Further Problem Description:
|
|
Last Modified: | 28-JAN-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 7.3(0)DX(0.65), 7.3(0)UCI(0.2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy04233 | Title: | M3 l2-fwd and bridge driver need to handle asic error exception |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
When other apps/drivers declare an exception (catastrophic or hard-error level), l2-fwd and bridge drivers are not marking the corresponding instance as failure, although it is marked such in other drivers. This can lead to out of sync state/operations.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.64) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv03431 | Title: | NSSA non-ABR performing LSA7 to LSA5 translation |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: * | Symptom:
A non-ABR within an NSSA area shows the message "Perform type-7/type-5 LSA translation" when issuing the command "show ip ospf". Only ABRs should display this message.
Conditions:
Router1 is performing the ABR role in a Totally NSSA Area.
Router2 is performing the ASBR role in the same area.
Router2 is injecting external prefixes within the NSSA area
When the command "show ip ospf" is issued on Router2, the following outpout is shown
"
...
Perform type-7/type-5 LSA translation
...
"
Workaround:
Apply the command "area nssa translate type7 never "
Further Problem Description:
|
|
Last Modified: | 13-JAN-2016 |
|
Known Affected Releases: | 6.1(2), 7.1(1)N1(1) |
|
Known Fixed Releases: | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.54), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux54588 | Title: | Error disabled state for BootupPortLoopback test does not get cleared |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: * | Symptom:
Switch# diagnostic clear result module 1 ?
test Diagnostic test selection
Switch# sh diagnostic result module 1 test 11 de
Current bootup diagnostic level: complete
Module 1: 10 Gbps Ethernet Module
Diagnostic level at card bootup: complete
Test results: (. = Pass, F = Fail, I = Incomplete,
U = Untested, A = Abort, E = Error disabled)
______________________________________________________________________
11) BootupPortLoopback:
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
-----------------------------------------------------
. E . . . . . . . . . . . . . .
Port 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
-----------------------------------------------------
. . . . . . . . . . . . . . . .
While Portloopback test for the same port will be passing at every fresh run.
Conditions:
Test results are checked after a Line card reload.
Prior to LC reload, PortLoopback for port in question was "E" or "F"
Workaround:
Meanwhile, cu can clear test results using:-
diagnostic clear result module 1 test 11 >>>>>>bootup test ID
and then reload card and see if bootupportloopback test passes.
If you do not want to clear test results/reload card, then try to use the foll. CLI to know actual test results for bootupPortLoopback" test :-
show diagnostic result module 2 test 11 statistics
Current bootup diagnostic level: complete
Module 2: 10 Gbps Ethernet XL Module
Diagnostic level at card bootup: complete
______________________________________________________________________
11) BootupPortLoopback
______________________________________________________________________
Port No Packet TX Packet RX Packet Loss
______________________________________________________________________
1 4 4 0
2 4 4 0
3 4 4 0
4 4 4 0
5 4 4 0
6 4 4 0
7 4 4 0
8 4 4 0
9 4 4 0
10 4 4 0
11 4 4 0
12 4 4 0
SNIP
last column i.e. "Packet Loss" column should be "0" in a pass state for port in question.
Further Problem Description:
This is a cosmetic show cli issue with no effect on functionality of port. As long as portloopback test passes for the port, then that port should work.
|
|
Last Modified: | 14-JAN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv45421 | Title: | Multicast source address inverted in igmpv3 event-history log message |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: * | Symptom:
Incorrect SRC address in log IGMP event-history message:
#show ip igmp snooping event-history vlan
2015 Jul 15 15:00:48.128938 igmp [1663]: [1676]: SN: <405> Received v3 Group-source-specific query for 239.195.1.3 from 10.21.25.252 on Vlan405 (mrt 1 sec)
2015 Jul 15 15:00:48.128928 igmp [1663]: [1676]: SN: <405> Received a v3 GSS-Query for group 239.195.1.3 (source-count 1) on Vlan405 (mrt 1 sec) src0:225.253.203.91, srcN:225.253.203.91
Conditions:
N7k + IGMPv3 + IGMP snooping
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 7.3(0)D1(0.72), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.50), 7.3(0)SC(0.14), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub79046 | Title: | N7K-OFF-DIAG: PescaraCB-100 development |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
for new product development
Conditions:
for new product development
Workaround:
pescaraCB-100 is a new product, we create this ID for new product development
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 6.2(0.28) |
|
Known Fixed Releases: * | 6.2(0.225)S0, 6.2(0.237)S0, 6.2(0.240)S0, 6.2(0.273)S0, 6.2(0.282)S0, 6.2(0.287)S0, 6.2(0.293)S0, 6.2(0.294)S0, 6.2(0.298)S0, 6.2(5.7)S0 |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux94513 | Title: | Inaccurate temperature for 10Gbase-SR CISCO-AVAGO Rev B4 on M2 modules. |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Transceiver 10Gbase-SR CISCO-AVAGO Revision B4 showing inaccurate temperature .
switch# sh int ethernet 4/1 transceiver details
Ethernet4/1
transceiver is present
type is 10Gbase-SR
name is CISCO-AVAGO
part number is SFBR-7700SDZ
revision is B4
serial number is AGD1244434T
nominal bitrate is 10300 MBit/sec
Link length supported for 50/125um OM2 fiber is 82 m
Link length supported for 62.5/125um fiber is 26 m
Link length supported for 50/125um OM3 fiber is 300 m
cisco id is --
cisco extended id number is 4
number of lanes 1
SFP Detail Diagnostics Information (internal calibration)
----------------------------------------------------------------------------
Current Alarms Warnings
Measurement High Low High Low
----------------------------------------------------------------------------
Temperature -112.33 C ++ -90.50 C -2.50 C -92.50 C -127.50 C
Voltage 4.93 V 5.09 V 4.77 V 5.00 V 4.85 V
Current 65.79 mA -- 71.04 mA 67.04 mA 71.04 mA 67.04 mA
Tx Power 5.17 dBm -- 6.03 dBm 5.22 dBm 5.63 dBm 5.27 dBm
Rx Power 5.17 dBm ++ 6.09 dBm 5.18 dBm 5.65 dBm 5.22 dBm
Transmit Fault Count = 0
----------------------------------------------------------------------------
Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
Conditions:
this behavior is seen only on N7K-M224XP-23L line card.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 22-JAN-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv08280 | Title: * | GIR mode to isolate Multicast last hop router for V4 and V6 |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
GIR mode to isolate Multicast last hop router
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 06-JAN-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui02535 | Title: | CDP enhancement - specify source address |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * |
Symptom:
This bug is an enhancement request to provide CLI to configure source address for CDP frames.
Conditions:Workaround:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 6.2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua53916 | Title: | N7k: Dropped pkts on Active SUP EOBC-MAC Link should trigger switchover. |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
EOBC failure to all the line cards including Standby SUP.
Conditions:
In a rare scenario when the Link between EOBCSW and the MAC on the active Supervisor is taking CRC's
Workaround:
pull out active Supervisor.
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 5.1(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul46894 | Title: | N7k Enh: tac-pac should include "show tech l2fm" |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
This is an enhancement request to start collecting "show tech l2fm" as part of the tac-pac
Conditions:
Nexus 7000 switches
Workaround:
Execute "show tech l2fm" in addition to the tac-pac
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: * | 5.2(9), 6.1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun88187 | Title: | Add SNMP Support for "show hardware capacity forwarding" |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Need SNMP support for "show hardware capacity forward"
Conditions:
Running the older software
Workaround:
Upgrade to the new software
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 5.2(3a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw95874 | Title: | N7k OS Missing various EEM commands |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Nexus platform missing various EEM command running latest OS image.
Conditions:
Running Nexus platform with latest NX OS image is missing the following commands for EEM:
Current EEM commands on Nexus 7k:
N7KRow11Rack7(config-applet)# action 1 ?
Nexus based actions:
cli Configure a VSH CLI action
counter Specify the name of the counter
event-default Do default action for the event
forceshut Force the entire switch to shut down
overbudgetshut Shut down the specified LCs due to power over budget
policy-default Do default action(s) of the policy being overridden
reload Reload the system or a specific module
snmp-trap Send out an SNMP trap
syslog Generate a syslog message
Missing Commands:
add Add
append Append to a variable
break Break out of a conditional loop
cli Execute a CLI command
cns-event Send a CNS event
comment add comment
context Save or retrieve context information
continue Continue to next loop iteration
counter Modify a counter value
decrement Decrement a variable
divide Divide
else else conditional
elseif elseif conditional
end end conditional block
exit Exit from applet run
force-switchover Force a software switchover
foreach foreach loop
gets get line of input from active tty
handle-error On error action
help Read/Set parser help buffer
if if conditional
increment Increment a variable
info Obtain system specific information
mail Send an e-mail
multiply Multiply
policy Run a pre-registered policy
publish-event Publish an application specific event
puts print data to active tty
regexp regular expression match
reload Reload system
set Set a variable
snmp-trap Send an SNMP trap
string string commands
subtract Subtract
syslog Log a syslog message
track Read/Set a tracking object
wait Wait for a specified amount of time
while while loop
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 5.0(0)AM(0.1), 5.0(0.1), 5.0(0.11) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110), 7.1(0)AV(0.38), 7.1(0)D1(0.329), 7.1(0)D1(0.330), 7.1(0)EV(0.125), 7.1(0)EVN(0.18), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug91738 | Title: | N7K: IPv6 vpc/vpc+ keepalive support |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
This bug is not a software bug. This bug is an enhancement to request a new feature. This bug requests Nexus 7000 to support IPv6 for vPC/vPC+ keepalives. Currently, vPC/vPC+ keepalives only use IPv4.
Conditions:
none
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug84996 | Title: | ip arp inspection filter in OTV VDC does not work with Bank Chain enable |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
This is not a bug but an enhancement request.
After enabling bank chaining, when we try to enable ip arp inspection filter, we get the following error
OTV-VDC(config)# ip arp inspection filter HSRP_VMAC_ARP vlan 222,444
ERROR: Hardware programming failed. Reason: statistics configuration is not supported with certain feature combinations
Conditions:
Workaround:
Disable Resource pooling in Admin VDC and then apply ip arp inspection and then re-enable resource pooling
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 5.2(7) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum84151 | Title: | Allow simultaneous configuration of all created SVIs |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
NA
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj42305 | Title: | N7 SPAN- ability to span egress traffic sourced from SVI in fabric path. |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Customer is monitoring interfaces in a fabricpath environment, and pinging from one SVI to its HSRP peer, across the FP spine. Pings are successful, but the egress traffic is not appearing in the captures. Return traffic is showing up as expected.
Conditions:
normal operation.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 5.2(9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo27134 | Title: | Next-Hop of the iBGP update not changed Self when eBGP multipath enabled |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Unlike iOS and IOS-XR, in NX-OS, the BGP updates to iBGP neighbors not using Self IP as the next-hop for the prefixes that are eBGP multipath in the BGP table.
Conditions:
When eBGP multipath configured and learn/install the prefixes with multipath in BGP table
Workaround:
next-hop-self neighbor command can change the current behavior.
Further Problem Description:
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 5.1(5) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui51771 | Title: | support for manual CoPP configuration |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * |
Symptom:
After NX-OS upgrade, user should be able to configure CoPP manually.
Conditions:
Applicable to all NX-OS releases.
Workaround:
This bug is closed, as there are CLI options to update / add CoPP policies.
|
|
Last Modified: | 15-JAN-2016 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui99939 | Title: | N7K-OFF-DIAG : Pescara N7K-100 : Development |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Create code for product pescara N7K-100
Conditions:
Workaround:
Create code for product pescara N7K-100
Further Problem Description:
Create code for product pescara N7K-100
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.0(0)FR(0.5) |
|
Known Fixed Releases: * | 6.2(0)HS(0.10), 6.2(10)CR(0.3), 6.2(10)EC(0.12), 6.2(10)FM(0.3), 6.2(10)NO(0.19), 6.2(12)FM(0.6), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud96635 | Title: | Gibraltar:Feature mvrp |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Feature implementation
Conditions:
Feature implementation
Workaround:
Feature implementation
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 6.2(5.7), 7.0(0.1)S0, 7.0(0.5)S0 |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)KM(0.64), 7.0(0)MV(0.1), 7.0(0)MV(0.10), 7.0(0)MV(0.11), 7.0(0)MV(0.12), 7.0(0)MV(0.13), 7.0(0)MV(0.14), 7.0(0)MV(0.15) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux44200 | Title: | NXOS/ELAM - enhancement for F cards |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
ELAM enhancement
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux87506 | Title: | interface-vlan cores after using switch as vpc access switch , |
|
Status: * | Other |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
interface-vlan cores after using switch as vpc access switch ,
Conditions:
interface-vlan cores after using switch as vpc access switch ,
Workaround:
interface-vlan cores after using switch as vpc access switch ,
Further Problem Description:
interface-vlan cores after using switch as vpc access switch ,
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.197) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh10646 | Title: | gibt-mvrp project collapse into Gibraltar |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
this is an internal tracking ID for a source code merge
Conditions:
not a bug, tracking ID
Workaround:
N/A
More Info:
N/A
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 6.2(5.7), 7.0(0.7) |
|
Known Fixed Releases: * | 7.0(0)KM(0.64), 7.0(0.8)S0, 7.0(1)ZD(0.3), 7.1(0)D1(0.14), 7.1(0)D1(0.15), 7.2(0)D1(1), 7.3(0)DX(0.4), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc29276 | Title: | Cannot bring up FEX if switchport trunk native vlan is configured |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
If the native vlan of the fex-fabric port channel connecting to a FEX is not 1, the FEX cannot be brought online. Any fex-fabric interfaces should ignore any switchport trunk commands.
Conditions:
This bug applies to 5.2(7), 6.0(4), and 6.1(1).
Workaround:
Do not configure any switchport trunk commands in fex-fabric interfaces.
Further Problem Description:
|
|
Last Modified: | 20-JAN-2016 |
|
Known Affected Releases: | 6.0(4) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.3(0)DX(0.29), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux92142 | Title: | Nexus 7k/6k/5k-isolate ISIS In GIR/Maintenance-mode |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
GIR/Maintenance-mode isolate command need to remove switch from being in transit path
Conditions:
Applies to GIR/Maintenance-mode default isolate action. The shutdown option works fine as it stops the routing process entirely.
Workaround:
Isolate option do not currently work. shutdown option works fine and takes the device totally out of the forwarding path..
Further Problem Description:
|
|
Last Modified: | 21-JAN-2016 |
|
Known Affected Releases: | 7.2(0)RTG(0.107) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub88945 | Title: | Icmpv6 API to build Unsolicited NA PDU |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
ICMPv6 clients can not build un-solicited NA by using icmpv6 apis
Conditions:
none
Workaround:
none
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0.54)S0 |
|
Known Fixed Releases: * | 6.2(0.272)S0, 6.2(2), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub10429 | Title: | ARP-3-INVAL_HDR_HRD_TYPE error message should reference source MAC. |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
This is an enhancement request for the error message:
ARP-3-INVAL_HDR_HRD_TYPE arp [4716] Found incorrect hardware type in ARP header: 6
It would be easy if the error message would contain the MAC address.
Conditions:
Workaround:
Use ethanalyzer to determine the source of the packets:
ethanalyzer local interface inband display-filter "arp.hw.type == 6" limit-captured-frames 100000
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 5.2(7)S8, 6.0(4), 6.2(0.278)S8 |
|
Known Fixed Releases: * | 6.0(2)A5(0.980), 6.0(2)A5(1), 6.0(2)U5(0.980), 6.0(2)U5(1), 6.1(2)I3(1.36), 6.1(2)I3(1.44), 6.1(2)I3(2), 6.1(2)I3(2.5), 6.1(2)I3(3), 6.2(10) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud25394 | Title: | Netstack changes for Physical port vPC and FEX Active-Active |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0.278) |
|
Known Fixed Releases: * | 6.2(0.269)S13, 6.2(0.278)S11, 6.2(0.293)S0, 6.2(1.4)S0, 6.2(2), 7.0(0.5), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug32730 | Title: | H/W limitation with ND Control Packet over Fabric in Vinci |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
ARP/ND packet coming on core port will not switch to server side.
Conditions:
always
Workaround:
none
More Info:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.2(0)PF(0.223) |
|
Known Fixed Releases: * | 6.0(2)N3(0.342), 6.0(2)N3(1), 6.0(2)N3(1.2), 6.0(2)N3(2), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)ZD(0.8), 7.0(1)N1(0.47), 7.0(1)N1(1), 7.1(0)ARP(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb75872 | Title: | Need CLI to clear ip mroute statistics |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * |
Symptom:
Could not clear mcast statistics
Conditions:
all
Workaround(s):
no
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 4.2(2) |
|
Known Fixed Releases: * | 6.2(0.174)S0, 6.2(0.272)S0, 6.2(2), 7.0(1)ZD(0.3), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty91721 | Title: | N7K doesn't use it's configured IPv6 interfaces to source pings |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
N7K doesn't use it's configured IPv6 interfaces to source pings
Conditions:
This happens when you have two Nexus 7K's connected together and configure that link with the IPv6 address use-link-local-only command. If you have loopbacks configured on both N7K's with an IPv6 unicast address and your N7K's are learning each others routes via OSPFv3 or any other routing protocol; The N7k's will see the routes in the routing table, but when you try to ping your peer's IPv6 loopback address it will fail. However, if you source the ping from the loopback interface the ping works.
Does not follow RFC 3484 SAS correctly.
Workaround:
Configure the link between the N7K's with a IPv6 unicast address.
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.0(2)S9 |
|
Known Fixed Releases: * | 6.2(0.272)S0, 6.2(2), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx81322 | Title: | NXOS: "show ip interface" Enhancement To Add Applied ACLs |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The "show ip interface" and "show ipv6 interface" commands do not include applied inbound and outbound ACL's for IPV4 and IPv6 in the CLI or XML tags.
Conditions:
This only occurs when a user expects to see applied ACL inbound and outbound ACL's when using the "show ip interface" or "show ipv6 interface" CLI commands like in Cisco IOS Software.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 26-JAN-2016 |
|
Known Affected Releases: | 6.0(1) |
|
Known Fixed Releases: * | 6.2(0.178)S0, 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun41202 | Title: | Weak CBC mode and weak ciphers should be disabled in SSH server |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:SSH servers on Cisco Nexus devices may be flagged by security scanners due to the inclusion of SSH ciphers and HMAC algorithms that are considered to be weak.
These may be identified as 'SSH Server CBC Mode Ciphers Enabled' and 'SSH Server weak MAC Algorithms Enabled' or similar.
Conditions:This issue applies to Cisco Nexus 7000, Cisco Nexus 5000 and MDS 9000 series switches. SSH functionality is enabled by default in Cisco NX-OS. The current SSH server status is displayed using the show ssh server command.
Workaround:None.
More Info:If an SSH client configured to use weak ciphers is used to log in to a Cisco device with this fix, the login may fail. The following messages are logged in the switch syslog:
%DAEMON-2-SYSTEM_MSG: fatal: no matching cipher found: client 3des-cbc,blowfish-cbc server aes128-ctr,aes192-ctr,aes256-ctr - sshd[6542]
Reconfigure any SSH clients not to use weak ciphers like 3des-cbc or blowfish-cbc. DCNM uses SSH to manage Cisco devices and must be upgraded to at least Cisco NX-OS 7.2(1) to work with devices with this fix.
|
|
Last Modified: | 30-JAN-2016 |
|
Known Affected Releases: | 5.2(8g)S8, 6.2(10)S102, 6.2(13)S17, 6.2(2)S27 |
|
Known Fixed Releases: * | 5.2(8g), 5.2(8g)S9, 6.2(11c), 6.2(11c)S7, 6.2(13)FM(0.66), 6.2(13.1)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110), 7.1(0)AV(0.38) |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论