| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy88547 | Title: | RISE CLI exits config mode for DIRECT & VPC mode |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
When user issues create a rise direct or rise vpc mode service, the cli exits the config mode
Conditions:
When user issues create a rise direct or rise vpc mode service,
Workaround:
No known workaround
Further Problem Description:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(1), 7.3(0)DX(0.124), 7.3(1)D1(0.14) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.127), 7.3(0)DX(1), 7.3(0)TSH(0.99), 7.3(0)UCI(0.30), 7.3(1)D1(0.26), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl77076 | Title: | Applying large egress acl triggers control-plane instability |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
Ospf and Lacp flaps when Applying Large Acl's on Egress direction.
Conditions:
Apply Large Acl's in the egress direction.
Workaround:
None
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(5), 5.0(5)E1, 5.1(3), 5.1(3.17) |
|
Known Fixed Releases: * | 5.0(5)E1, 5.1(10.1)S0, 5.1(3)S11, 7.1(0)ZD(0.16), 7.1(0)ZD(0.23), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc83165 | Title: | SNMP crash due to mutex lock assert fail in 4.2(2a) |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: |
Problem/Description:
Both Nexus 7000 and Nexus 5000 boxes will crash on snmpd pid.
Workaround:
Software upgrade
Further Actions:
gather show tech details and engage Cisco TAC.
Other:
`show cores`
Module-num Instance-num Process-name PID Core-create-time
---------- ------------ ------------ --- ----------------
1 1 snmpd 3870 Oct 2 10:30
Look for this in the output of
show logging nvram:
%SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 3870) hasn't caught signal 11
(core will be saved).
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(2a) |
|
Known Fixed Releases: * | 4.2(1)N2(1), 4.2(3), 4.2(3.19), 4.2(4), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth89291 | Title: | 2nd IPv6 static route missing from config |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: |
Symptom:
When you add a 2nd of the same ipv6 static route to a configuration but
pointing to a different
interface the 2nd IPv6 static route is missing from the running and startup
config, but the route
will be in the routing table.
Conditions:
Configuration entered
vrf context test1
ip route 0.0.0.0/0 Ethernet1/9.803 10.174.28.161
ip route 0.0.0.0/0 Ethernet1/1.802 10.174.28.165
ipv6 route 0::/0 fc00::226:98ff:fe01:9841 Ethernet1/1.807
ipv6 route 0::/0 fc00::226:98ff:fe01:9ec1 Ethernet1/9.805
When you do a show run one of the IPv6 routes is missing from the config but
is in the routing table.
NEC-7010# sh run | beg "vrf context test1"
vrf context test1
ip route 0.0.0.0/0 Ethernet1/9.803 10.174.28.161
ip route 0.0.0.0/0 Ethernet1/1.802 10.174.28.165
ipv6 route 0::/0 fc00::0226:98ff:fe01:9ec1 Ethernet1/9.805
< missing 2nd ipv6
static router
upon reload of the box you will lose the 2nd ipv6 static router
Workaround:
None:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4), 5.0(3.51)S0 |
|
Known Fixed Releases: * | 4.2(6)S50, 4.2(7.45)S0, 5.0(3)S43, 5.0(3.51)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth76379 | Title: | OSPF MTS buffer leak |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Problem:
Under certain conditions, OSPF internal message queue could fillup,
and could eventually prevent further messaging into OSPF until the condition
is cleared by a reload or supervisor switchover.
Symptom:
When the internal messaging queue is full, and there is a large amount of
update coming into OSPF, it is possible that OSPF neighborship will not be
formed with this router.
Workaround:
Remove any SNMP context configuration mappings to vRFs
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 4.2(7.38)S0, 4.2(7.39)S0, 5.0(3)S34, 5.0(3)S36, 5.0(3.43)S0, 5.1(0.193)S0, 5.1(0.194)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts00210 | Title: | nxos/ospf: ABR router generating type 3 default into area 0 |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
Type-3 default GW summary route is send to Area 0 from ABR (even not range command used)
Conditions:
Issue could happen ONLY if there is stub areas configured and there is type-5 default route in database. If both of this conditions are not met issue could not be triggered.
This issue could be triggered by flap of ospf neighbors as interface flaps, module reload or clear ip ospf neighbor. Probability that this issue happen is higher if more neighbor flap at the same time.
Issue is not happen at each flap
Workaround:
Filter 0.0.0.0/0 to be redist to area 0
Configuration Example:
ip prefix-list area0-in seq 5 deny 0.0.0.0/0
ip prefix-list area0-in seq 10 permit 0.0.0.0/0 le 32
route-map area0-in-remove permit 10
match ip address prefix-list area0-in
router ospf 1
area 0.0.0.0 filter-list route-map area0-in-remove in
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2), 5.0(2a) |
|
Known Fixed Releases: * | 5.1(10.40)S0, 5.1(5)S3, 5.2(2)S15, 5.2(2.13)S0, 6.0(0.31)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj56845 | Title: | n7k/NXOS: Instability with 6k S,G entries when RPF change |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
When RPF change there can be observed IGMP/netstack can take 100% cpu, VPC keepalive lost, VPC inconsistent due to BPDU timeout on various vlans, crash of netstack, and other processes usually snmp, vpc and switchover.
Conditions:
This could happen when system has VPC and more than 5000 S,G entries change RPF from one interface to the other.
Workaround:
This workaround is valid only on when VLAN with receivers are in VPC and rest of interfaces VLAN/L3 are pint to point with only one PIM neighbor.
Workaround is add this entry to the COPP:
class-map type control-plane match-any rpf-fail
match exception multicast rpf-failure
class rpf-fail
police cir 16 kbps bc 100 ms conform drop violate drop
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(6) |
|
Known Fixed Releases: * | 4.2(7.102)S0, 5.1(2)S11, 5.1(2.9)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk36830 | Title: | Snmpd doesn't respond after KERNEL-2-SYS-MSG started appearing. |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptoms:
In Nexus7000, SNMP process stop responding after reporting KERNEL-2-SYS-MSG messages.
Conditions:
This issue is seen in Nexus7000 running 5.x releases.
Workaround:
None.
This issue should be fixed in 5.2(1) or later releases.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(0.137), 5.2(0.154), 5.2(0.154)S11, 5.2(0.41), 5.2(0.84) |
|
Known Fixed Releases: * | 5.2(0.176)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz92775 | Title: | VTP packets might get duplicated in vPC environments |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
If you have a vPC environment where you have two Cisco Nexus 7000 Series switches running in VTP transparent mode and a Catalyst switch running in VTP server or client mode with pruning enabled, in rare situations, traffic may stop between the Cisco Nexus 7000 switches and the Catalyst switch. This is caused by VTP packet floods from the Nexus 7000 switches to the Catalyst on both port-channel links.
Conditions:
You may see this symptom when you are in vPC mode and the Catalyst switch is running in VTP server or client mode with pruning enabled
Workaround(s):
To completely workaround this problem you will need to turn off the VTP feature.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(5) |
|
Known Fixed Releases: * | 4.2(1), 4.2(1.7), 4.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto63457 | Title: | Polling ospf mib causes crash and system reset |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptoms:
A Nexus 7000 may crash and failover due to snmpd. The following error will be
seen in the logs:
%SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID ) hasn't caught signal 11
(core will be saved).
Conditions:
Seen when polling OSPF MIBs on Nexus running 5.1(2) or 5.1(3). Crash is random
and not related to the amount of time spent polling the device, or a specific
OSPF MIB.
Workaround
No workaround at this time.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(9)S9, 5.1(3), 5.2(0.270)S7 |
|
Known Fixed Releases: * | 4.2(8)S18, 4.2(8.67)S0, 5.1(10.1)S0, 5.1(3)E5, 5.1(4)S0, 5.2(0.270)S13, 5.2(1)S6, 5.2(1.8)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub20644 | Title: | cdp core dump in 5.0.3 |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
cdp show commands (eg. "show cdp neighbors detail") are causing cdp module to crash.
Conditions:
In scale setup(switch having >500 ports) cdp show commands can crash because of the buffer overflow.
Work Around:
Use the cdp show commands where specific interface name can be given. Avoid using "show cdp neighbors detail" on a scale setup.
Releases/Platforms affected:
All NxOS releases prior to 5.2(9)
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3)S45, 6.1(1), 6.1(2) |
|
Known Fixed Releases: * | 5.2(9), 5.2(9)S58, 5.2(9.105)S0, 6.0(2)A1(1c), 6.0(2)N2(5.93), 6.0(2)N2(6), 6.0(2)U1(3), 6.0(2)U2(1), 6.1(1.61)S0, 6.1(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz10518 | Title: | Nexus got dot1x hap reset |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
We saw N5K-C5548UP using n5000-uk9.7.3.0.N1.1a.bin had a hap reset:
Reason: Reset triggered due to HA policy of Reset
System version: 7.3(0)N1(1a)
Service: dot1x hap reset
Conditions:
Not known
Workaround:
Not known
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1 |
|
Known Fixed Releases: * | 7.1(3)ZD(0.153), 7.1(3)ZN(0.313), 7.1(4)N1(0.846), 7.1(4)N1(1), 7.3(0)N1(0.5), 7.3(0)N1(1a), 7.3(0)UCI(0.39), 7.3(1)DX(0.32), 7.3(1)FTO(0.7), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw86978 | Title: | F2E 6.2.(14) upgrade fail %VMM-2-VMM_SERVICE_ERR: VDC1: Service SAP |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
upgrade fail with error message
%$ VDC-1 %$ %VMM-2-VMM_SERVICE_ERR: VDC1: Service SAP Aclmgr SAP
for slot 3 returned error 0x41040069 (Sufficient free entries are
not available in TCAM bank) in if_bind sequence
and interfeces are removed , not shown in show interface though show module status is ok state.
`show module`
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 0 Supervisor Module-2 N7K-SUP2 active *
3 48 1/10 Gbps Ethernet Module N7K-F248XP-25E ok
* this terminal session
`show vdc membership`
Flags : b - breakout port
---------------------------------
vdc_id: 0 vdc_name: XXXXXXXXX interfaces:
vdc_id: 1 vdc_name: XXXXXXXXX interfaces:
*Ethernet3/1 *Ethernet3/2 *Ethernet3/3
*Ethernet3/4 *Ethernet3/5 *Ethernet3/6
*Ethernet3/7 *Ethernet3/8 *Ethernet3/9
*Ethernet3/10 *Ethernet3/11 *Ethernet3/12
*Ethernet3/13 *Ethernet3/14 *Ethernet3/15
*Ethernet3/16 *Ethernet3/17 *Ethernet3/18
*Ethernet3/19 *Ethernet3/20 *Ethernet3/21
*Ethernet3/22 *Ethernet3/23 *Ethernet3/24
*Ethernet3/25 *Ethernet3/26 *Ethernet3/27
*Ethernet3/28 *Ethernet3/29 *Ethernet3/30
*Ethernet3/31 *Ethernet3/32 *Ethernet3/33
*Ethernet3/34 *Ethernet3/35 *Ethernet3/36
*Ethernet3/37 *Ethernet3/38 *Ethernet3/39
*Ethernet3/40 *Ethernet3/41 *Ethernet3/42
*Ethernet3/43 *Ethernet3/44 *Ethernet3/45
*Ethernet3/46 *Ethernet3/47 *Ethernet3/48
Conditions:
F2E module
6.2.(14)
Workaround:
reduce the number of SVI
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 6.2(8.13), 7.3(0)D1(0.165) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.2(2)D1(0.44), 7.2(2)ZD(0.135), 7.3(0)D1(0.190), 7.3(0)D1(1), 7.3(0)ZD(0.208), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv23184 | Title: | Mac is egress learnt pointing to index in different VDC on M |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
Mac is pointing to wrong DI in different VDC. Packet may leak between VDC.
Conditions:
Have a linecard in the admin VDC and configure some port channels not necesarily on this port-channel.
Move all ports of this LC at once to another VDC.
Workaround:
reload LC
Further Problem Description:
If you see that the DI is in same VDC OR is missing then this bug is not a match.
|
|
Last Modified: | 23-JUN-2016 |
|
Known Affected Releases: * | 6.1(3), 6.2(14)FB(0.78), 6.2(8a), 6.2(8b) |
|
Known Fixed Releases: | 6.2(13.9)S0, 6.2(14), 7.2(1)D1(0.17), 7.2(1)D1(1), 7.2(1)ZD(0.13) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz71568 | Title: | Action operation is not working for EEM in IPLUS_MR4_811 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
EEM action is not working
Conditions:
With EEM config
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(4)N1(0.811) |
|
Known Fixed Releases: * | 7.1(3)ZD(0.140), 7.1(3)ZN(0.290), 7.1(3)ZN(0.313), 7.1(4)N1(0.824), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue05555 | Title: | FEX: Service "satctrl" crashed on fex after multiple switchovers |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
"satctrl" service might crash on FEX device after several switchovers.
Conditions:
This appears to happen during switchover scenario.
Some timers might not be getting cleaned-up in the right manner during switchover scenarios.
This may manifest in freeing a bad timer, which could lead the FEX device to the crash.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.1(2), 6.1(3)S32, 6.1(3)S39, 6.1(4), 6.1(4a)S20, 6.2(1.36)S3 |
|
Known Fixed Releases: * | 6.1(0)FE(0.49), 6.1(0)FE(0.50), 6.1(4.144)S0, 6.1(5), 6.2(0)FH(0.140), 6.2(0)HS(0.10), 6.2(2a), 6.2(2a)S7, 6.2(5.45)S0, 6.2(5.7)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun92129 | Title: | VPLS::sh int pw - throwing invalid range |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
'show interface pseudowire ' throws Invalid range error for dynamically created pseudowire and traffic loss is observed for the particular AC.
Conditions:
After script doing Enable/Disable feature BGP or Delete/Re-add BGP Config on a PE router, the pseudowire interface on a bgp signalled vfi on remote PEs.
Workaround:
No known workaround, other than to restart the PEs
Further Problem Description:
This is seen on automated script testing. Also not reproducible in all testbeds and sometime needs multiple iteration of the triggers to see the issue.
|
|
Last Modified: | 18-JUN-2016 |
|
Known Affected Releases: | 6.2(10)FM(0.7), 6.2(8)S14, 7.1(0)ZD(0.143) |
|
Known Fixed Releases: * | 15.4(2)S2, 15.4(2.17)S0.11, 15.4(3)M2.1, 15.4(3)M3, 15.4(3)M3.1, 15.4(3)S, 15.4(3)SN1a, 15.5(0.16)T, 15.5(0.16.1)CG, 15.5(0.20)PI27a |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul35819 | Title: | BPDUGuard not Activated on Disallowed Edge Trunk VLANs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BPDUs from a remote device do not activate BPDUGuard on an edge trunk port.
Conditions:
- Remote device misconfigured as an access port
- VLAN on access port is not in the allowed VLAN list of the edge trunk
Workaround:
Configure both sides of the link correctly as either trunks or access interfaces.
Further Problem Description:
A loop can occur on redundant connections when the untagged access side traffic loops into the native VLAN on the trunk side of the link. The loop can be prevented by not allowing the native VLAN on the link.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 6.0(2)A4(0.810), 6.0(2)A4(1), 6.0(2)U4(0.810), 6.0(2)U4(1), 6.1(2)I3(1.26), 6.1(2)I3(2), 6.2(10), 6.2(10)EC(0.10), 6.2(10)FM(0.18), 6.2(10)NO(0.19) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup16103 | Title: | N7k: Copp fails to rate limit Pause frames from Hosts on 2248TP type FEX |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Pause frames from Host reach the 7K CPU
Conditions:
Issue seen when host is connected to FEX N2248TP and host is sending a PAUSE storm
Affects both 6.2(6a)/6.2(8)
Workaround:
Offending host generating pause frames can be taken offline.
Further Problem Description:
Issue reported:
=========
Pause frames from FEX front panel (HIF) ports, end up at the SUP on N7K.
Observation:
=========
* On FEX type N2248TP, Pause frames are not handled correctly. Even with Rx flow-control enabled on the interface, pause frames are being forwarded upstream to the N7K instead of being consumed on the FEX.
* For all other FEX types including the latest N2248PQ, Pause frames are consumed at the FEX if Rx flow-control is enabled.
Potential Impact:
===========
* If volume of pause frames generated from the servers connecting to the FEX is EXTREMLY HIGH, then control path to the SUP can get congested
** Other control plane traffic destined to SUP can be dropped
Common case:
=========
* Pause frames volume is typically not so high in a real network to really congest SUP
* If there are malicious servers which are generating such high volume of traffic, those servers need to turned off.
Desired (Can be tracked as a separate enhancement requests):
============================================
1. Presently, Rx flow-control is not enabled by default for FEX HIFs. Behavior is documented.
*** Desired that Rx flow-control be enabled by default
2. Even if flow-control is not enabled, quench the pause frames at the MAC layer.
*** Must be tracked with FEX hardware/platform team (SAVTG)
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.2(6a), 6.2(8) |
|
Known Fixed Releases: * | 7.1(2)N1(0.574), 7.1(2)N1(1), 7.1(2)ZN(0.35), 7.1(3)ZN(0.313), 7.2(0)N1(0.172), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.174), 7.3(0)N1(0.25), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu21286 | Title: | n5548UP - Kernel panic while doing ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
While ISSU was in process, kernel panic occurred and the box got reloaded.
fc-scale-n5548UP# sh system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 1937 usecs after Tue May 5 20:42:01 2015
Reason: Kernel Panic
Service:
Version: 7.2(0)N1(1)
Conditions:
ISSU is happening
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.192) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)FFW(0.7), 7.0(0)HSK(0.474), 7.0(7)ZN(0.266), 7.0(8)N1(0.319), 7.0(8)N1(1), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.1(3)ZD(0.83), 7.1(3)ZN(0.178) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue56335 | Title: | N7k - snmpd core dumps during vlanTrunkPortVlansXmitJoined mibwalk |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
snmpd process core dumps during vlanTrunkPortVlansXmitJoined mibwalk
Conditions:
Normal Operations with SNMP polling of vlanTrunkPortVlansXmitJoined in CISCO-VTP-MIB.
Workaround:
Disable SNMP polling on vlanTrunkPortVlansXmitJoined.
Further Problem Description:
The issue exists in NXOS software releases 5.1(x), 5.2(1-9), 6.1(1-4) and 6.2(1).
Fixes had been integrated into NXOS software releases 5.2(10), 6.1(4a), 6.2(2) and later releases.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(7), 5.2(9) |
|
Known Fixed Releases: * | 5.2(9.191)S0, 6.0(2)A2(0.465), 6.0(2)A2(1), 6.0(2)U2(0.12), 6.0(2)U2(0.465), 6.0(2)U2(1), 6.0(2)U3(0.22), 6.0(2)U3(1), 6.1(4.97)S0, 6.1(4a) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq55749 | Title: | HSRP MGO: Slave may enter Init due to 'No Master for Slave' |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When using HSRP MGO an attempt to configure a new HSRP follow group may result in this group being stuck in the Initial state with HSRP reporting a reason of "No Master for Slave".
Conditions:
HSRP MGO is configured and some HSRP follow groups are deleted from running config after which a supervisor switchover is performed.
Workaround:
Delete all affected stuck follow groups. Delete and reconfigure master group. Reconfigure follow groups.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.2(8)S11 |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S92, 6.2(10.16)S0, 6.2(8)E10, 7.1(0)AV(0.38), 7.1(0)D1(0.289), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.363), 7.1(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo77566 | Title: | OTV Overlay Interface stuck at "Cleanup in Progress" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Under certain sequence of events, OTV Overlay Interface goes into a stuck state showing "Cleanup in Progress".
Once in this stuck state, delete/re-configuration of Overlay interface does not recover this, below error message is seen:
"Overlay in delete holddown, reject command"
Conditions:
Issue seen on N7k / Sup2 / 6.2(2)
Issue seen to carry over through ISSU to 6.2(6a).
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 18-JUN-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S3, 6.2(10.5), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.178), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)N1(0.220), 7.1(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq55557 | Title: | VxLAN: vPC fails to send triggered PIM hello |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Temporary Traffic loss
Conditions:
A newly come up L3 interface A. has DR-delay timer configured, B. Provides better route to a multicast source or Rendezvous Point (in case of shared tree forwarding). The multicast tree gets changed and thus if a stream is already flowing, gets affected temporarily.
Workaround:
Remove DR-delay timer for this interface.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.221) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.261), 7.1(0)D1(0.262), 7.1(0)N1(0.326), 7.1(0)N1(1), 7.1(0)OTT(0.34), 7.1(0)PDB(0.208), 7.1(0)RTG(0.40) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo89198 | Title: | post SSO fabric_mcast process is not running on the new active sup |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
configure 'ip multicast fabric-forwarding' causes stdby goes to init
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.136), 7.1(0)D1(0.146) |
|
Known Fixed Releases: * | 7.1(0)D1(0.161), 7.1(0)D1(0.162), 7.1(0)D1(0.163), 7.1(0)FC(0.2), 7.1(0)IF(99.16), 7.1(0)NF(0.28), 7.1(0)OTT(0.4), 7.1(0)PDB(0.110), 7.1(0)VXE(0.2), 7.1(0)ZD(0.215) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup19027 | Title: | N7K Dual SUP lost configurations after power up |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The N7K SUP1 had the configuration saved and was powered down. When the N7K was then powered up it came up with no configuration. The startup-configuration had been corrupted due to an abnormal termination when it had been previously saved.
Conditions:
When the "copyrunning-config startup-config" was entered it was terminated abnormally either the user entering CNTRL-C or the connection to the N7K, for example via SSH, being terminated before the "copy" was complete.
Workaround:
The configuration must be restored manually.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(7) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S64, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.195), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)IF(99.16), 7.1(0)N1(0.245) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup67732 | Title: | N7K: some mroutes leftover on some vrfs on ingress PE under MVPN scale |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Some mroute state left over on some vrf contexts after multicast traffic and joins were stopped
Conditions:
When 200 vrfs are configuration and over 200 groups per vrfs are injected to FHR PE router
Workaround:
No workaround
Further Problem Description:
We are unable to allocate memory for 50k routes and that is the cause of stale routes between different modules.
|
|
Last Modified: | 18-JUN-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.179) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S70, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.243), 7.1(0)N1(0.303), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty86291 | Title: | MTS buffer exhaustion with sequential add of large vlans. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Memory leak .
Conditions:
The condition can trigger if huge number of Vlans along with name are created without range command. Basically using script or copying some thing from note pad to Nexus7000 in config mode.
For Example.
conf t
vlan 2000
name D-Lan-n7000
vlan 2001
name D-Lan-n7001
vlan 2002
name D-Lan-n7002
vlan 2003
----Snip-----
vlan 2297
name D-Lan-n72297
vlan 2298
name D-Lan-n72298
vlan 2299
name D-Lan-n72299
vlan 2300
name D-Lan--n72300
end
Workaround:
To avoid this problem first creat just Vlans using range command as follows.
Config t
vlan 2000-2300
Make sure L2 Vlans are created.
After that one can cut and paste Vlan name config from txt file.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(3a), 5.2(4.68), 6.0(4) |
|
Known Fixed Releases: * | 5.2(1)N1(6.93), 5.2(1)N1(7), 5.2(4.70)S0, 6.0(2)N2(4.60), 6.0(2)N2(5), 6.1(0.268)S0, 7.0(1)ZN(0.550), 7.0(4)N1(0.157), 7.0(4)N1(1), 7.1(0)N1(0.301) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo71613 | Title: | IPLUS 152: ISSU ND upg -> bin - FEX module preload failed |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ISSU ND from upg to bin FEX image preload is failing
Conditions:
ISSU upgrade
Workaround:
bin to upg worked fine
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)N1, 7.1(0)N1(0.273), 7.1(0)N1(0.347), 7.1(0)N1(0.348), 7.1(0)N1(0.349), 7.1(0)N1(0.372) |
|
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.312), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.1), 7.1(0)N1(0.384), 7.1(0)N1(1), 7.1(0)OTT(0.45) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq20222 | Title: | SMU 7.1: adjust timeout for all services to handshake across all VDCs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Service isis_l2mp failed to start with binary from a SMU. Then the symlink is reverted back to restart service (using old binary)
Conditions:
when activate a SMU
Workaround:
no Work around
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.196) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.233), 7.1(0)N1(0.290), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.179), 7.1(0)RTG(0.22), 7.1(0)ZD(0.285) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo28456 | Title: | N7K: ospf select wrong next-hop when redistribute route in NSSA area |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
External routes in OSPF are installed over a NSSA area (instead of backbone area).
Conditions:
In case, there is reachability of OSPF external prefixes in both NSSA area and the backbone area, OSPF will install routes over those prefixes over the NSSA area.
Example topology:
area 0
N7K-1-----------N7k-2--lo1
(ABR) (ABR/ASBR)
| |
| area 1 |
| nssa |
| |
4948-1----------4948-2
The problem only occurs if one of the links between the ABRs is in the backbone
area and another is in a NSSA area. Only releases 6.2.x/7.0.x are affected by this, and prior releases are unaffected.
Workaround:
There are the following workarounds for this bug:
(1) Configure a lower-cost, normal non-backbone area adjacency between the 2 ABRs.
(2) Configure the link between the 2 ABRs as P2P, and add a multi-area link.
For example, in the topology below, the link between the 2 N7K ABRs is P2P and both in area0, and multi-area 10 at the same time.
Multi-area 10
--------------------
| area 0 |
N7K-1-----------N7k-2--lo1
(ABR) (ABR/ASBR)
| |
| area 1 |
| nssa |
| |
4948-1----------4948-2
Further Problem Description:
|
|
Last Modified: | 19-JUN-2016 |
|
Known Affected Releases: | 6.2(2a) |
|
Known Fixed Releases: * | 6.1(2)I3(1.21), 6.1(2)I3(1.22), 6.1(2)I3(2), 6.2(10), 6.2(10)CM(0.28), 6.2(8)TS(0.28), 6.2(9.3)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.191) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud63229 | Title: | BGP memory status Severe Alert upon config restoration |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BGP memory status Severe Alert upon config restoration
Conditions:
BGP memory status Severe Alert upon config restoration
Workaround:
No workaround
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 6.2(0.232)S0, 6.2(0.287)S8, 6.2(0.287)S9, 6.2(0.294)S4, 6.2(0.294)S7, 6.2(0.304), 6.2(1.10), 6.2(1.10)S3, 6.2(1.23)S3, 6.2(1.5)S2 |
|
Known Fixed Releases: * | 6.2(0)FH(0.13), 6.2(1.18)S0, 6.2(1.23)S4, 6.2(1.25)S1, 6.2(1.27)S0, 6.2(1.28)S0, 6.2(1.38)S0, 6.2(2), 7.0(0.6), 7.1(0)D1(0.14) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva14035 | Title: | ITD scale of 128 nodes 32 services would result show comds not working |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
india30-gg# sh itd brief
B: ERROR: send failed with errno = 90
ERROR:
Conditions:
india30-gg# sh itd brief
B: ERROR: send failed with errno = 90
ERROR:
Workaround:
india30-gg# sh itd brief
B: ERROR: send failed with errno = 90
ERROR:
Further Problem Description:
india30-gg# sh itd brief
B: ERROR: send failed with errno = 90
ERROR:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 7.3(1)DX(0.59) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus26870 | Title: | December 2014 ntpd CVEs for Nexus 5k/6k/7k/MDS |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The following Cisco products:
NEXUS 7000
NEXUS 6000
NEXUS 5000
MDS
include a version of NTPd that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-9293
CVE-2014-9294
CVE-2014-9295
CVE-2014-9296
This bug has been opened to address the potential impact on this product.
Conditions:
This issue is configuration dependant and applies only when the following command is configured:
feature ntp
All prior versions of NX-OS are affected.
Workaround:
1. If the upstream mgmt0 device supports uRPF then ensure it is configured.
2a. Filter incoming NTP queries and restrict them to trusted NTP server addresses only by using the ntp access-group configuration command.
2b. For affected platforms that do not support the ntp access-group command, configure an inbound ACL for trusted NTP server addresses to the NTP port (UDP port 123) on mgmt0.
Further Problem Description:
All previously released versions of SAN-OS and NX-OS software are affected. The fix will be delivered for currently supported releases as follows:
Nexus 50xx:
NX-OS 5.2 release - a to be determined release
Nexus 55xx, 56xx
NX-OS 7.0 release - first fixed release is 7.0(6)N1(1), available in Apr 2015
Nexus 60xx:
NX-OS 7.0 release - first fixed release is 7.0(6)N1(1), available in Apr 2015
Nexus 7xxx:
NX-OS 6.2 release - first fixed release is 6.2(12), released on 03 Feb 2015
MDS:
NX-OS 5.2 release - first fixed release is 5.2(8f), released on 20 Feb 2015
NX-OS 6.2 releases:
- 6.2(9b), released on 01 Apr 2015
- 6.2(11b), released on 02 Mar 2015
- 6.2(13), to be released in June 2015
There are no fixed MDS NX-OS releases that are FICON certified yet. There will not be any fixed releases for software trains that are past the end of software maintenance support.
A Cisco Security Advisory has been published to document this vulnerability at:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141222-ntpd
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 7.5/7.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:P/A:P/E:H/RL:U/RC:C
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: | 21-JUN-2016 |
|
Known Affected Releases: | 6.0(3), 6.2(13)FM(0.8), 6.2(9)S32, 6.2(9a)S5, 7.2(0)ZD(0.1), 7.2(0)ZN(0.4), 7.9(0)ZD(0.4), 8.0(0.1), 9.9(9) |
|
Known Fixed Releases: * | 5.2(1)N1(8.155), 5.2(1)N1(8.158), 5.2(1)N1(9), 5.2(8f), 5.2(8f)S9, 6.0(2)N2(6.132), 6.0(2)N2(6.133), 6.0(2)N2(7), 6.2(11b), 6.2(11b)S4 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut89986 | Title: | N77: module in failure state after power cycle due to BFDC hogging CPU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
With L2 fabricpath BFD on one side is up and the peer side is not applied or delay in applying the BFD config, but link is up, then the BFDC process on the LC will hog the CPU and line card will be reset.
Conditions:
L2 Fabricpath BFD configured on one side and other side is not configured or configuring with some delay
Workaround:
Remove the L2 Fabricpath BFD configurations on all the switches.
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.472), 7.2(0)D1(0.475), 7.2(0)D1(1.1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.49), 7.2(2)ZD(0.141), 7.3(0)D1(0.175), 7.3(0)D1(0.178), 7.3(0)D1(0.179), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz18973 | Title: | M3: aclqos crash with many match keywords in single ACE |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
aclqos crash & module might go to failure state
Conditions:
When an ACE in an access-list is having more number of keywords to match is applied on an interface. (More than 14, including keyword and value) Ex:
deny udp any any range 1 65535 dscp 63 packet-length range 100 9210 flow-label 545 log
permit tcp any range 1234 4321 any range 2345 5432 dscp 63 ack fin rst syn urg psh established
Workaround(s):
None
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.141) |
|
Known Fixed Releases: * | 7.3(1)DX(0.61), 7.3(1)DX(0.62) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo77146 | Title: | port-profile crashed while reloading leaf vdc |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ppm crashes while vdc is reloaded
Conditions:
reload vdc
Workaround:
no
Further Problem Description:
ppm crashes while vdc is reloaded.
Customer may not see it, as it depends on timing.
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.136) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.136), 7.1(0)D1(0.143), 7.1(0)D1(0.147), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.94), 7.1(0)ZD(0.194) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw98364 | Title: | F3: OTV broadcast/smac route PSSing wrong inst bitmap for tcam |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Broadcast packets in OTV environment can experience mis-forwarding such as drops or loops.
Conditions:
The problem can happen in 6.2.14 and earlier if there is IPFIB restart or ISSU. Here is an example of a scenario.
1) In 6.2.10, broadcast route is inserted in inst 0. Inst_bitmap = 0x1.
2) There is inst bitmap update which will add the the broadcast route to inst 1. The correct bitmap is 0x3 but we PSSed bitmap 0x2.
3) ISSU to 6.2.12 or ipfib is restarted. FIB recovers bitmap 0x2 for broadcast route.
4) Broadcast route is deleted due Overlay down for example. FIB will only delete the broadcast route from inst 1. There is stale entry in inst 0.
5) Overlay comes up and broadcast route is added back again. However, on inst 0, we will have 2 entries. Let's say that the new entry is programmed at lower priority. Packets will hit the stale entry resulting in misforwarding. If new entry is programmed at higher priority, then there is no misforwarding but the stale entry is still there.
Workaround:
Reload the modules with the stale entries. ISSU to the NXOS release where this issue is resolved will not recover from the broken state and module reload will still be required.
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 6.2(16)S32, 7.3(0)D1(0.137), 7.3(0)DX(0.90) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S10, 6.2(16)S29, 6.2(16)S41, 7.2(2)D1(0.16), 7.2(2)ZD(0.20), 7.3(0)D1(0.173), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.122) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy73277 | Title: | Mac Addresses at last 2 ports on FEX are out of range in allocated ones |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Mac Addresses at last 2 ports on FEX are out of range in allocated ones
Conditions:
Use FEX
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(2)FIP(0.199), 7.0(2)FIP(0.200), 7.0(2)FIP(0.201), 7.2(2)D1(0.59), 7.2(2)D1(0.61), 7.2(2)ZD(0.150), 7.2(2)ZD(0.153), 7.3(1)D1(0.52), 7.3(1)D1(0.54), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun50901 | Title: | Service (FEX) "satctrl" (PID 1723) hasn't caught signal 9 (no core) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
N7K FEXs might crash with below errors without save core dump
2014 Mar 3 08:18:25 DALS_SW1_C7009_MDF-Production SYSMGR-FEX109-3-BASIC_TRACE core_copy: PID 1476 with message Core not generated by system for satctrl(0). WCOREDUMP(9) returned zero .
2014 Mar 3 08:18:25 DALS_SW1_C7009_MDF-Production SYSMGR-FEX109-2-SERVICE_CRASHED Service (FEX) "satctrl" (PID 1723) hasn't caught signal 9 (no core).
2014 Mar 3 08:18:25 DALS_SW1_C7009_MDF-Production SYSMGR-FEX109-2-HAP_FAILURE_SUP_RESET System reset due to service "satctrl" in vdc 1 has had a hap failure
Conditions:
normal operation but signal 9 might be related to memory leak. memleak would be a separate issue and need root cause to confirm.
Workaround:
unknown at this time
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 6.2(0)FH(0.152), 6.2(0)HS(0.10), 6.2(10), 6.2(10)EC(0.23), 6.2(10)FM(0.20), 6.2(10)NO(0.19), 6.2(8), 6.2(8)S16, 6.2(8.3)S0, 6.2(9)FM(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy11493 | Title: | Errors ""tlvu_table_convert_tlv_to_indv_field" when issuing startup |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Seeing errors when issuing a 'show startup' after upgrading to 7.2(0)D1(1).
Conditions:
Not known.
Workaround:
None at this time.
Further Problem Description:
|
|
Last Modified: | 23-JUN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1), 7.2(2)D1(0.60) |
|
Known Fixed Releases: * | 7.2(2)D1(0.71), 7.2(2)ZD(0.144), 7.3(1)DX(0.54), 7.3(1)DX(0.63) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut18721 | Title: | gbr_422: urib core at urib_chlist_segv_handler |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
urib crashes and since it is not restartable, the crash will result in reload of the switch in single SUP scenario or will result in SSO when dual SUP is present.
Conditions:
Inter VRF case where routes in one VRF are pointing to next hops in different VRF.
Workaround:
no workaround
Further Problem Description:
This issue mainly happens when routes are being flapped in large scale by BGP due to multiple restart or some other reasons or repeated execution of "clear ip route *".
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.422), 7.2(0)D1(0.444) |
|
Known Fixed Releases: * | 6.2(10)E8, 6.2(12)E1, 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.28), 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) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva19190 | Title: | MP-BGP peer receive widthdraw MPLS label(524288) from N7K |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
MP-BGP peer receive widthdraw MPLS label(524288) from N7K
Conditions:
TBD
Workaround:
TBD
Further Problem Description:
|
|
Last Modified: | 23-JUN-2016 |
|
Known Affected Releases: | 7.3(1)DX(0.57) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq77481 | Title: | ipfib crash at lfib_pi_get_cnh_adj_with_vpn_label after noshut core int |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IPFIB crash while shutting the core interface
Conditions:
With MPLS core and 6 IGP paths in the system
Workaround:
Further Problem Description:
|
|
Last Modified: | 23-JUN-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.255), 7.3(0)DX(0.64) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.2(2)D1(0.60), 7.2(2)ZD(0.152), 7.3(0)DG(0.3), 7.3(0)DX(0.86), 7.3(0)DX(1), 7.3(0)EG(0.14), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz44008 | Title: | Nexus reboot __inst_001__isis_fabricpath crash |
|
Status: | Open |
|
Severity: * | 2 Severe |
Description: | Symptom:
Nexus 5500 running 7.0(5)N1(1) reset in __inst_001__isis_fabricpath crash
Conditions:
Crash seen while calling the following API - vni_sbmp_new
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 9.9(9.9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 28-JUN-2016 |
|
Known Affected Releases: | 7.2(0)N1(1), 7.2(1)N1(0.9) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)D1(0.175), 7.3(0)D1(1), 7.3(0)DG(0.3), 7.3(0)DX(0.56), 7.3(0)DX(1), 7.3(0)EG(0.14), 7.3(0)GLF(0.44), 7.3(0)IZN(0.13), 7.3(0)N1(0.229) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz25546 | Title: | SSTE: LISP Process crash during continuous process restart |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
lisp process crashes due to continuously restarting the lisp process using cli, even before the lisp process is allowed to properly come up
Conditions:
continous process restart from cli
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: * | 7.3(1)DX(0.58), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva23832 | Title: | ERROR msg shows load balance cmd required while its already configured |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
india-30-gg2(config-itd)# no sh
ERROR: load-balance method can be src ip or dst ip when user ACL is configured
india-30-gg2(config-itd)#
ERROR: load-balance method can be src ip or dst ip when user ACL is configured
india-30-gg2(config-itd)#
Conditions:
india-30-gg2(config-itd)# no sh
ERROR: load-balance method can be src ip or dst ip when user ACL is configured
india-30-gg2(config-itd)#
ERROR: load-balance method can be src ip or dst ip when user ACL is configured
india-30-gg2(config-itd)#
Workaround:
india-30-gg2(config-itd)# no sh
ERROR: load-balance method can be src ip or dst ip when user ACL is configured
india-30-gg2(config-itd)#
ERROR: load-balance method can be src ip or dst ip when user ACL is configured
india-30-gg2(config-itd)#
Further Problem Description:
india-30-gg2(config-itd)# no sh
ERROR: load-balance method can be src ip or dst ip when user ACL is configured
india-30-gg2(config-itd)#
ERROR: load-balance method can be src ip or dst ip when user ACL is configured
india-30-gg2(config-itd)#
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(1)DX(0.59) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux30775 | Title: | ipfib crash during ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ipfib on F2 module may crash during ISSU
Conditions:
F2 module has some VRF with no local member ports before ISSU.
Workaround:
Unknown.
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.157), 7.3(0)DX(0.141) |
|
Known Fixed Releases: * | 7.2(2)D1(0.72), 7.2(2)D1(0.73), 7.2(2)ZD(0.164), 7.3(0)D1(0.175), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.191) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg90112 | Title: | N7k Linecard is reset due to "Metro fatal interrupt in device 79" |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:Linecards, in Nexus 7000 systems
may be reset with the following messages.
Nexus 7000
%MODULE-2-MOD_DIAG_FAIL: Module reported failure on ports 8/2-8/2
(Ethernet) due to Metro fatal
interrupt in device 79 (device error 0xc4f00202)
Conditions:This issue can occur when an n7k linecard is responsible for SPAN replication
and Multicast replication (ie you have PIM and SPAN enabled).
1) Overlapping SPAN sessions can increase the chance of running into the issue
as shown below.
- Overlapping source vlan/interface, configured in tx or both directions, in 2
separate SPAN sessions.
Example:
monitor session 1 source vlan 11 - 20
monitor session 2 source vlan 11 - 20 (or any vlans that are in the session 1)
2) High # of OIFs for a specific multicast group with SPAN configured for any
of these OIFs. This has been observed with approx 60+ OIFs.
To determine if a linecard is susceptible, use the following commands.
Nexus7000# attach mod 2
module-2# sh hardware internal version
-------------------------------------------------
Name InstanceNum Version
-------------------------------------------------
Octopus 1 0.4
Octopus 2 0.4
Sotra 1 186.3
Sotra 2 186.3
Metropolis 1 0.3 <<<<<< version is irrelevent
Metropolis 2 0.3
Metropolis 3 0.3
Metropolis 4 0.3
Workaround:The only true workaround if you are hitting the described conditions, is to not have tx SPAN of multicast. You can do this by only using the "rx" option for the span source, or you can use the multicast best-effort command which disables tx span for mcast.
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/system_management/configuration/guide/sm_nx_os_cg/sm_14span.html#pgfId-1309359
You may decrease the chances of running into the issue (if you're hitting the scenario with 2 SPAN sessions) via the following
respectively:
- Do not use overlapping SPAN sessions
or
- Use Virtual SPAN session
http://www.cisco.com/en/US/partner/docs/switches/datacenter/sw/4_2/nx-os/system_management/configuration/guide/sm_14span.html#wp1214731
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun73067 | Title: | WCCP redirect policy config fails/ Vlan addition fails |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:#1 Attempted deletion of WCCP policy fails. Further additions of policy may hit the error "Invalid operation".
#2 Another possible symptom for this bug is the inability to create/add/delete VLAN's. Following message may appear in the logs:
%VLAN_MGR-2-CRITICAL_MSG: Switchport Configuration Failed for msgid <> rrtoken <>
Config parser may print this message:
ERROR: Configuration Failed with Error: Failure Returned from Policy Server
Conditions:An aborted WCCP configuration must have occurred in the past.
or
ISSU to 6.2(2) or a later release
Workaround:Reloading the switch will resolve this.
More Info:Bug is first fixed in 6.2(8) NX-OS release however ISSU from a prior release to 6.2(8) or a higher release may still see problem. A reload ensures states are corrected and subsequent ISSU will not see this problem if already running 6.2(8) or a higher release.
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: | 6.2(7.19)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(8), 6.2(8)S8, 6.2(8.5) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy77657 | Title: | BGP did not update the NH of all MAC routes in l2rib |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BGP did not update the NH of all MAC routes in l2rib
Conditions:
mac routes via bgp evpn.
Workaround:
There's no workaround. To recover:
Shut bgp neighbor ; wait for all mac-routes to be removed; re-establish bgp neighbor.
Clear bgp all * will not work.
Further Problem Description:
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: * | 7.0(3)IAB3(0.102), 7.3(1)PIB(0.24) |
|
Known Fixed Releases: | 7.0(3)I4(0.62), 7.0(3)I4(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy85875 | Title: | Moved host route does not get installed in HW in LISP IGP Assist in ASM |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Really low performance is seen when traffic is sent to this host. All packets get punted up to the Supervisor in order to resolve the adjacency and will be subject to rate-limiting.
Conditions:
LISP ASM w/ IGP Assist deployment on N7k's running 7.2 code or above
And we are changing the LISP AD from the default value to prevent routing loops
When the host moves from his home network, to the away network, the issue is seen.
Workaround:
AD of LISP should be kept at 240
Increase the AD of the IGP/BGP to higher than 240 to avoid routing loops
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 7.2(2.1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.2(2)D1(0.78), 7.2(2)N1(0.459), 7.2(2)N1(1), 7.2(2)ZD(0.166), 7.2(2)ZN(0.167), 7.3(1)DX(0.3), 7.3(1)FTO(0.7), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu38580 | Title: | F2/F2e: High latency and congestion |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Applicable to all F2 (Clipper/Clipper CR) based cards.
Congestion seen on ingress traffic on some/all of the ports. This is because, frames are stuck in the IB caused due to bad acos to ccos table.
To confirm if the issue is due to bad table, please compare the acos to ccos mapping in the below commands
show hardware internal qengine inst x vq acos_ccos_4cl/acos_ccos_8cl
compare it with the ccos mapping in
show hardware internal qengine inst x table fr_dcx4q_oq_ccos/fr_dcx8q_oq_ccos
if the acos to ccos mapping are different, then the Credit Loop logic will affected and frames will be stuck in the IB resulting in congestion on the ingress ports.
Conditions:
Do ISSU and then VDC reload (VDC containing ports from F2 LC).
This is because, the shadow memory in our Qengine driver was corrupted during ISSU and VDC reload causes a shadow refresh to the HW.
Workaround:
1. Reload the line card
OR
2. Reload the chassis
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.506) |
|
Known Fixed Releases: | 6.2(13.4)S0, 6.2(14), 7.0(0)BZ(0.71), 7.0(0)FFW(0.7), 7.0(0)HSK(0.474), 7.2(0)CF(0.11), 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)ZD(0.202), 7.2(1)PIB(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva24715 | Title: | Nexus Anycast HSRP crashes when VLAN string is more than 1000 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus crashes when inputting a very large number of VLANS
Conditions:
Inputting vlans in an Anycast HSRP group with a string length exceeding 1000.
Workaround:
Reduce the amount of vlans to a string length below 1000.
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 8.3(0)CV(0.527) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva22248 | Title: | show system internal lim counters dynamic -> lim hap reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
show system internal lim counters dynamic
will cause a unexpected reload of the switch. lim hap reset is shown as reset reason afterwards.
Conditions:
None, normal operations
Workaround:
none, do not use the command
show system internal lim counters dynamic
Further Problem Description:
none
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 7.3(1)DX(0.47) |
|
Known Fixed Releases: * | 7.1(3)ZD(0.165), 7.1(3)ZN(0.328) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl45411 | Title: | 154_S6: Traffic loss after SSO |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic loss after SSO
Conditions:
Check Description
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(0.154), 5.2(0.180) |
|
Known Fixed Releases: * | 5.2(0.211)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth69876 | Title: | n7k: STP/ISSU - BPDU not generated during switchover in vpc primary |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:When switchover is done, STP is not able to generate BPDUs on time.
This leads to ports getting blocked by loopguard on directly connected switches.
Conditions:
Workaround: None.
Further Problem Description: Debugs shows that Nexus does not generate BPDUs
for all vlans for about 6 seconds on switchover.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(3), 4.2(4) |
|
Known Fixed Releases: * | 4.2(6)S44, 4.2(7.40)S0, 5.0(3)S37, 7.1(0)ZD(0.16), 7.1(0)ZD(0.23), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc82869 | Title: | N7k Crash due to PIM while bouncing Peer-Link |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Two n7k connected via port-channel and have VPC configured between them...When we shut Po interface on the primary VPC , the box crashes due to PIM process and a core dump is generated.
Conditions:
vpc is configured between and we need to bounce the interface port-channel .
Workaround:
None
Further problem:
1)When we shut the port-channel between the boxes , the box generates a core dump which is related to PIM
2)when we perform unshut of the port-channel , the box again generates core dump related to PIM and during this time the Cu is not able to ping VDC (Cu has 4 VDC configured) till the dump is completed.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(2a) |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.19), 4.2(4), 5.3(0.167)S0, 6.0(0.2)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj73415 | Title: | RIP crash at rip_ipv4_pkt_debug_message during UDP port reconnaisance |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
Cisco NXOS based devices contain a denial of service vulnerability within the Routing Information Protocol (RIP) service engine. An unauthenticated,
remote attacker with the ability to submit a malformed RIPv4 or RIPv6 message to port UDP/520 could cause the RIP service engine to restart. This
may result in a temporary inability for the device to pass traffic to a destination populated in the route table by RIP.
Conditions:
Cisco devices running an affected version of NXOS software and configured to utilize RIP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 5/3.9:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=&version=2.0
dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4091 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-4091
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: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: * | 5.0(0)MP1(0.420), 5.1(1.49)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt62040 | Title: | Service "mrib" hasn't caught signal 11 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus switch may experience an unexpected reboot or supervisor switchover. The following log message may be observed immediately prior to the event.
%SYSMGR-2-SERVICE_CRASHED: Service "mrib" (PID xxxx) hasn't caught signal 11 (core will be saved).
The reset reason will be recorded as 'mrib hap reset'.
`show system reset-reason`
----- reset reason for Supervisor-module 5 (from Supervisor in slot 5) ---
1) At 721817 usecs after Mon May 19 02:39:40 2014
Reason: Reset triggered due to HA policy of Reset
Service: Service "mrib" in vdc 3 hap reset
Version: 5.2(1)
2) At 239978 usecs after Fri May 16 04:03:53 2014
Reason: Reset triggered due to HA policy of Reset
Service: Service "mrib" in vdc 3 hap reset
Version: 5.2(1)
3) At 335983 usecs after Tue May 13 21:22:37 2014
Reason: Reset triggered due to HA policy of Reset
Service: Service "mrib" in vdc 3 hap reset
Version: 5.2(1)
4) At 549835 usecs after Thu May 8 14:13:04 2014
Reason: Reset triggered due to HA policy of Reset
Service: Service "mrib" in vdc 3 hap reset
Version: 5.2(1)
Conditions:
OTV must be enabled.
The crash occurs when an invalid value is accessed during an SNMP walk (GetNext request) of the multicast RIB (MRIB).
Workaround:
Turn off SNMP MIB walk/get for multicast RIB.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(1)N1(1), 5.2(2.73)S0, 6.0(2)S7, 6.1(0.130)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw53967 | Title: | N7k-reg: MSDP peers failed to established due to TCP read Error |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When msdp tries to come up between an IOS router and an Nexus 7000, the Nexus
resets the tcp connection with the router during the 3-way handshake and debug
output shows the following:
msdp: [12427] (default-base) msdp_connect_main(): open peer, tid 0xb1255b90
netstack: [3279] (default) Send packet on Ethernet3/9 (mbuf_prty 2):
s=10.10.10.1 d=10.20.10.1, nh=10.30.10.2 , proto=6 (tcp), sport=16503,
dport=639, seq=28c96878, ack=0, off=a00, window=4000, chksum=9222, urp=0,f
msdp: [12427] (default-base) connect() returned Operation now in progress
msdp: [12427] (default-base) connect() returned Operation already in progress
msdp: [12427] (default-base) connect() returned Operation already in progress
msdp: [12427] (default-base) connect() returned Operation already in progress
msdp: [12427] (default-base) connect() returned Operation already in progress
msdp: [12427] (default-base) msdp_open_peer() connect() 10.20.10.1 default
Operation already in progress
msdp: [12427] (default-base) msdp_connect_main(): EXIT, tid 0xb1255b90
Conditions:
The TCP 3-way handshake at the beginning of MSDP peering between a 4900M and
an Nexus 7k is takes more time than expected by the Nexus. In the NX-OS MSDP
implementation, after triggering the 3-way handshake, we wait for 1 ms for it
to complete. If the handshake is not complete, we try the same operation in
loop for 5 times. After 5 such iterations if the 3-way handshake is not complete, we
retry after the MSDP reconnect interval.
Workaround(s):
None.
The issue has been fixed by increasing the wait-time to 50 ms and loop count
to 50.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(3), 6.0(2) |
|
Known Fixed Releases: * | 5.2(3.27)S0, 6.0(2)S25, 6.1(0.170)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsw48988 | Title: | N7K: MSDP learnt routes are deleted periodically with spt-infnity on LHR |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | PIM Sparse-mode RP deletes MSDP learnt route every 210sec when SPT-infinity is configured on the last hop router.
Workaround is to remove SPT-infinity configuration on the Last hop router.
Detailed description
================
Source
|
R1 (first-hop-router)
/ \
/ \
/ \
R2----------R3 (RP, MSDP Peer)
\ /
\ /
\ /
R4 (LHR, spt-infinity)
|
Receiver
Source is connected to R1 and receiver is connected to R4. R2 and R3 are PIM SM RP and MSDP peers. Spt-infinity is configured on R4, hence shared tree is built to the RP. Receiver registers with R3. Source registers with R2. R3 learns S,G information via MSDP SA messages. Traffic flows from R1->R3->R4.
Every 210sec, we see PIM deleting the mroute on R3. R3 in turn send a prune message to R1 and it will remove the OIF from the S,G. R3 learns about the S,G via MSDP SA messages and rebuilds the mroute. Traffic starts flowing from R1->R3->R4 again and this cycle continues.
Prior to the fix for this bug, expected behavior was like this;
1. If Source is directly connected, (S,G) will be expired if there are no data activity for ~3 min.
2. If Receiver is directly connected, (S,G) will be expired if there are no data activity for ~3 min.
3. For all other cases, (S,G) will be expired by PIM unless it's refreshed by periodic JP message or any other means. We don't rely on data activity here.
We were hitting case 3 above. Since spt-infinity is configured on the LHR, JP message from R4 does not contain S,G info. As per the current design, there are no ways for MSDP to refresh a route in PIM database. Hence PIM forcefully deletes the route and this causes MRIB and MSDP to delete it. MSDP learns this route again through SA message and reinstalls in MRIB. The same cycle goes on and on.
Fix is to keep the S,G state active on all transit routers as long as there is data activity and the OIF list is not empty.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.0(4) |
|
Known Fixed Releases: * | 4.1(3), 4.2(0.118), 4.2(0.122), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr23609 | Title: | snmpd core after vdc config |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom
Nexus 5000/7000 switch crash due to snmpd process
Condition
Doing SNMP polling to a nexus switch. This crash is due to a memory corruption.
Workaround
N/A
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(1)S56, 5.2(1.53)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz62065 | Title: | NXOS: Port allocation failure when bring up the VDC from suspended stat |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Caused and fixed between releases when changing RM interaction.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(0.214), 4.2(0.239), 4.2(1) |
|
Known Fixed Releases: * | 4.2(0.239), 4.2(0.241), 4.2(1), 4.2(1.11), 4.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr41315 | Title: | OSPF Process Crash during SPF calculation |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
OSPF Cores unexpectedly while running SPF
Conditions:
All of the following happen at the same instant:
SPF runs on the router
The OSPF database contains an LSA which has reached max age without the LSA ever being explicitly set to max age, and the LSA has not yet been removed from the OSPF database, OR a configuration command removes an LSA
This LSA is used during the SPF calculation to reach some route.
This problem would happen inconsistently as it involves a race condition in addition to the conditions listed above.
These conditions could happen after a router came back from a 30-60 minute reboot, and SPF ran on a different router in between when this other router learns an LSA for a connection to the rebooted router and when it receives the refreshed or explicitly max-aged LSA from the rebooted router, and this happens at the exact time that one of the LSA from before the reboot has reached max age but not aged out.
Any router can trigger this with their self-originated LSA, but only routers running affected code can be impacted.
Workaround:
If a LSA never reaches max age this problem does not happen. Upgrading to unaffected code by ISSU or making sure the router is back online before any of its LSA reach max age will avoid this scenario because the router will refresh its LSA, or max-age them as soon as it is back online.
If a LSA reaches max age and the router that generated it is not reachable through OSPF, the problem will not be seen. Shutting down OSPF for long enough to have all of the router's LSA age out and then continue with an upgrade to unaffected code will also avoid this problem.
More Info:
It is rare, but this problem can also happen if OSPF configuration commands are executed on a router that is running affected code where these commands remove LSAs at the same exact time SPF is running and using these LSA to determine the best path to a route.
The following show command will show the age of all LSA currently in OSPF database for all processes in ascending order:
show ip ospf database | sed 's/^[0-9.]*[ ]*[0-9.]*[ ]*//' | sed 's/[ ]*[0-9a-fx]*[ ]*[0-9a-fx]*[ ]*[0-9]*[ ]*$//' | egrep '^[0-9]+$' | sort -g
If there are LSA between 1800 and 3600 seconds, wait until they have aged out before powering back up any routers. If there are many LSA constantly at lower ages compared to higher ages, there might be some flapping happening which will cause SPF to run more often. Wait until it stabilizes or investigate further before doing any OSPF related configuration.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(5)E2, 5.2(1)S61 |
|
Known Fixed Releases: * | 5.2(1)S73, 5.2(1.62)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto09063 | Title: | OSPF self-generated LSA may be created with wrong mask (/0) or segfault |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Following switch reload, OSPFv2/v3 may incorrectly self-generate LSA with incorrect mask (/0) or a segmentation fault may occur (OSPFv3)
Conditions:
In order to encounter this issue, the self-generated LSA must have been learned in adjacent routers prior to triggering action. Incorrect LSA mask will only be generated if the router receives it's own self-generated LSA from a peer (during DBD exchange) at the same time that the self-generated LSA is being created on the router (interface coming online). The most likely trigger for these conditions is a switch reload or a LC reset (with multiple peers).
Issue does not occur frequently due to the convergence of multiple states in a very short time window.
Workaround:
Since the self-generated LSA must already exist in the OSPF area before reload, risk of encountering this issue can be reduced by removing component routes from the area (shutting all non-area0 interfaces). All adjacent routers should max-age the entry and it will not be included in DBD exchange on peer bring-up.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(3), 5.2(0.237) |
|
Known Fixed Releases: * | 5.1(5)E2, 5.2(1)S51, 5.2(1.51)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb81932 | Title: | vrf test-ntp stuck in holdown state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
vrf stuck in holdown state
Conditions:
configure and unconfigure a VRF
Workaround(s):
none
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(1), 4.2(2) |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.7), 4.2(4), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr15613 | Title: | Memory leak in isis when adjacencies are brought up & torn down |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ISIS process memory leak detected when ISIS adjacencies are lost and restored
Conditions:
Running ISIS level 1 in the network.
Network outages or neighbor devices lost/restored occur.
Workaround:
Load the debug plugin, locate the isis process and restart it using kill:
From CLI:
load bootflash:dplug_supdc3_cmp.5.2.1.gbin
ps -ef | grep isis
kill -9
exit (from debug plugin)
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(1)S55, 5.2(1.53)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk32991 | Title: | ACLMgr is causing the Global Sync to hang between Active/Standby Sup |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Redundancy is unresolved ; show redundancy shows "HA snchronization in progress"
Conditions:
After EPLD upgrade and switchover the standby is stuck in powered-up and unable to sync with Active.
Workaround:
Reload the Switch to clear the mts buffers.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: * | 5.1(2)S1, 5.1(2.2)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn79238 | Title: | Observing Mcast Traffic Loss after both the vPC Peer switchover |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Mcast Traffic Loss after 4Mins and 11sec from the switchover completion time period.
Conditions:
This problem is only seen in if switchover is done on both VPC peers
Workaround:
Do not do switchover on both peers at the same time. There are no work arounds.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(6), 5.1(3), 5.2(0.222) |
|
Known Fixed Releases: * | 5.2(0.259)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud69928 | Title: | N7K: Received Duplicate DBD packets cause 7K to increase sequence number |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
N7K may incorrectly increment its DBD sequence number by 2 instead of 1 when it receives
duplicate DBD packets. This will cause the neighboring device to detect a bad sequence number
and reset the neighbor relationship to extart state.
Conditions:
N7K is Master in the Neighbor relationship. N7K sends a DBD with relative sequence number of 1:
Neighbor <--------seq 1------- N7K
Neighbor echos DBD with sequence number of 1 as per RFC but it sends one or more duplicates:
Neighbor ----------seq 1-------> N7K
Neighbor ----------seq 1-------> N7K
N7K should discard the duplicate packets but in some instances it may incorrectly increment the
relative sequence number buy 2 instead of 1:
Neighbor <-------seq 3--------- N7K
This will cause the neighbor to detect a bad sequence number and send a DBD with the I bit set
which will move the state machine from exchange to exstart:
Neighbor ----------seq 2(I bit set)----- N7K
Workaround:
Eliminate the duplicate DBD packets.
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 2.9/2.5:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:M/Au:N/C:N/I:N/A:P/E:ND/RL:OF/RC:C&version=2.0
No CVE ID has been assigned to 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: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(5) |
|
Known Fixed Releases: * | 5.2(9), 5.2(9)S26, 5.2(9.50)S0, 6.0(2)A1(1), 6.0(2)N2(1), 6.0(2)U1(1), 6.1(3), 6.1(3)S30, 6.1(3.44)S0, 6.2(1.93) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg50959 | Title: | Core on OSPF while restarting ospf process |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
System running with 4.2.4 will crash if it is configured for OSPF and OSPF
process is manually restarted.
Conditions:
This crash may only get triggered if the Nexus has OSPF neighbors which are not
configured for Graceful restart.
Workaround(s):
If we have OSPF neighbors for Nexus7000 which are not configured for Grace
Full start then avoid manually restarting the OSPF.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2) |
|
Known Fixed Releases: * | 5.1(0.146)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua97463 | Title: | OSPF default-information originate behave inconsistantly |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Under OSPF process, we configured " default-information originate always route-map xxx ", when we tried to remove "always" key word in following two way, both shows the configuration doesn't match the OSPF real behavior:
1. If we do "no default-information originate always", then the configuration shows "default-information originate route-map xxx ", but when we remove the whole "default-information originate route-map xxx", it shows the route-map mismatch.
2. Instead of step 1, we do "default-information originate route-map xxx ", the configuration still shows "default-information originate always route-map xxx ", but OSPF behave as "always" is removed.
These behaviors made our OSPF test result total invalid and confused, as the OSPF configuration is just different than its behavior.
Conditions:
none
Workaround:
none
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(5)E2, 5.2(1), 5.2(7), 6.0(3), 6.1(2)S41 |
|
Known Fixed Releases: * | 5.2(9), 5.2(9)S11, 5.2(9.21)S0, 6.0(2)N2(1), 6.1(3), 6.1(3)S5, 6.1(3.10)S0, 6.1(3.23), 6.2(0.213)S0, 6.2(0.228)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta98990 | Title: | u6rib service exits with mbest loop |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a Nexus 7000 the u6rib service may exit, causing the system to
reload or perform a stateful switchover.
Conditions:
This can occur when an IPv6 MP-BGP Multicast session is established,
and an "mbest" route is installed into the u6rib which causes a
routing loop.
Workaround:
Since routing loops are useful, a route-map could be configured in BGP
to block the route being learnt from the peer.
Alternative remove the route from the network, or disable the IPv6
Multicast MP-BGP session.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(1.50), 4.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta94572 | Title: | IPv4 routes stuck in pending state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a Nexus 7000 system running, the IPv4 routes may be permanently
marked with a "pending" status, meaning that they are not being pushed
to the FIB and the hardware.
Conditions:
This can happen under a rare circustance when an internal error
occurs, possibly, but not exclusively after an ISSU.
Workaround:
No known workaround.
If a secondly supervisor is installed, perform a stateful switchover,
or if not, perform a reload.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(1), 4.2(1.47), 4.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth39080 | Title: | N7K: Slow OSPF Convergence when VDC comes back up |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Packet loss is observed when VDC becomes online.
Conditions:
When the reload vdc command is issued, packet loss is observed when the line card comes online.
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: * | 5.0(5)S6, 5.1(0.205)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsy53158 | Title: | u6rib loop detection causes heartbeat failure |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 7000 supervisor may restart unexpectedly with a u6rib HA
policy reset, and, if installed, switchover to the standby supervisor.
The reset reason can be checked with the following command:
show system reset-reason
----- reset reason for Supervisor-module 5 (from Supervisor in slot 5) ---
1) At 993856 usecs after Wed Mar 18 12:06:17 2009
Reason: Reset triggered due to HA policy of Reset
Service: u6rib hap reset
Version: 4.1(3)
It is also likely that a syslog will be generated for the detected
loop:
%U6RIB-3-RNH_LOOP_ERROR: u6rib [] Number of prefixes forming rnh loop exceeds 128
Flagging route 2001:db8::/32 from client "bgp-109"
with nh fe80::1 rnh 2001:db8:1::1/128 as causing rnh loop
A further syslog may be generated for an internal structural error:
%U6RIB-3-STRUCT_ERROR: u6rib [] ...
Conditions:
This issue can occur when an IPv6 route loop is detected in the IPv6
RIB.
Workaround:
Currently none.
Further Problem Description:
If a transient route loop is generated in the supervisor, the NX-OS
IPv6 RIB detects this loop and removes the path causing the loop from
the RIB.
When the route loop is broken, the original path can be reinstalled.
It is this action that causes the reset of the supervisor.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(3) |
|
Known Fixed Releases: * | 4.1(5), 4.2(0.183), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd11399 | Title: | returned oid value for ospf traps is wrong |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The problem reported in CSCtd11399 was that OSPF was sending out traps with an extra digit (2) in the OIDs. For instance, the ospfTxRetransmit trap would show up with an OID of .1.3.6.1.2.1.14.16.2.2.10 instead of .1.3.6.1.2.1.14.16.2.10, the originate LSA trap would show up with an OID of 1.3.6.1.2.1.14.16.2.2.12 instead of .1.3.6.1.2.1.14.16.2.12, and so on.
Conditions:
Always, Prior to 4.2.3.
Impact:
The implication of this bug is that, SNMP traps monitoring applications would not be able to identify the traps.Any action being performed based on these would therefore be impacted, i.e., not triggered at all.
Workaround(s):
Unfortunately, there is no workaround for the problem. A fix for this problem has already been committed into 4.2.3.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.25), 4.2(4), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq32783 | Title: | snmpd asserts on length validation check when receiving malformed reques |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms:.
snmpd process in a system running NX-OS software may crash due to corrupted SNMPv2c set request.
Conditions:
The SNMP process handles a malformed set request.
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 4/3.3:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:S/C:N/I:N/A:P/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2011-2051 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: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(0.907)S4 |
|
Known Fixed Releases: * | 5.2(1)S26, 5.2(1.31)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz98098 | Title: | HSRP flap during switchover with default HSRP timers |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
HSRP group states may flap during switchover.
Conditions:
You may see this symptom, when there are a few hundred L3 interfaces with HSRP groups configured on the switch. The flaps may continue for a few seconds after switchover.
Workaround(s):
If larger values of timers are configured for the HSRP groups, the flaps may not occur.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(3) |
|
Known Fixed Releases: * | 4.2(0.239v), 4.2(0.242), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsx42110 | Title: | DC3:Ospf adj flap between 7200 and Nexus |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
OSPF flaps between 7200 and Nexus.
Conditions:
When redistributed routes were flapping very frequently, 7200 was flushing and re-originating the type-5 external LSAs. If the flap is fast enough , the 7200 would re-originate and flush the LSA before the N7K got a chance to delete the higher sequence numbered maxAged LSAs from it's LSDB.
Workaround:
Configure on the 7200 side under the OSPF process:
limit retransmissions dc disable non-dc disable
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.0(4) |
|
Known Fixed Releases: * | 4.1(3), 4.1(4), 4.2(0.155), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsw75873 | Title: | prefix length of group address is not same as configured in bidir |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:rp-address command doesn't properly work for IPv6
Conditions: Problem is introduced and fixed in the same release.
Workaround: No workaround is needed as the problem is introduced and fixed in the same release.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(0.120) |
|
Known Fixed Releases: * | 4.2(0.122), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh20873 | Title: | IPV6 default route URIB and UFIB inconsistency cause traffic drop |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In the customer testing setup, there are eBGP ECMP for IPv6 default route, which works fine at stable mode, but upon any path fail, the URIB and UFIB shows inconsistent, and UFIB point to th epath which is already down which cause traffic blackholed.
Conditions:
NONE
Workaround:
"clear ipv6 route 0::0/0" will cause default route reprogrammed, and can clear the issue.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3)U5(1f) |
|
Known Fixed Releases: * | 5.0(3)U5(1f), 5.2(1)N1(6), 6.0(2)N2(1), 6.0(2)U1(1a), 6.0(2)U1(2), 6.2(1.137)S0, 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz19966 | Title: | IGMP OIFs not removed from non-DF when ASM group changes to BiDir |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom: IGMP installing groups on non-DF when group changes from ASM to Bidir
Conditions: This happens only when group-range changes from ASM->Bidir mode
Workaround: Restart of IGMP should fix the issue.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(0.184) |
|
Known Fixed Releases: * | 4.2(0.219), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj13303 | Title: | CoPP not applied to modules after ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Control-plane policing may not be applied in hardware. To verify this, software shows CoPP active when executing 'show policy-map inteface control-plane'.
The command 'show system internal qos copp config' returns:
switch# show system internal qos copp entries
slot 1
====
CoPP policy is not in effect!!
switch#
Conditions:
The conditions for this issue are currently unknown
Workaround:
There is no workaround
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 5.1(1.31)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl97751 | Title: | urib core after clear ip route with 250vrf & 100k routes |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
URIB process crash resulting in supervisor switchover in a dual-sup nexus router, or reload of a single-sup nexus router.
Conditions:
This crash happens upon a "clear ip route *" command on a VRF which has imported/exported routes from other VRF in an extranet vpn scenario.
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(0.180) |
|
Known Fixed Releases: * | 5.2(0.180)S15, 5.2(0.212)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta76648 | Title: | NSSA router doesn't do ECMP if prefix is advertised by multiple routers |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A NSSA internal router does not do ECMP with identical type-7 default LSAs.
Conditions:
When more than one NSSA border router injects default route into OSPFv3 NSSA area via the
'area nssa default-information-originate'
command, NSSA internal router chooses only one path with the highest router ID.
Workaround(s):
Currently there is none.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(2.9), 4.2(3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf17554 | Title: | Default route not injected in OSPF after a reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Upon a reload, the default route may not be injected into ospf in some vrfs.
Conditions:
Using vrf lite and the command "default-information originate" under the ospf process, the default route may not be injected into the ospf process after a reload for some vrfs.
Workaround:
If there is redundancy in the network, this problem will cause little impact. To workaround this problem, under the ospf process, remove the command, "default-information originate" and then reapply it.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(4), 4.2(4.39), 4.2(5), 5.0(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCte72124 | Title: | N7k: EIGRP routes in "Pending State" for VRFs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
Nexus 7000 may have routes installed in the unicast routing table for
different VRFs and global table that are marked in a "pending"
state. This means that the routes are in the urib, but have not been
pushed down the the FIB and are not programmed in HW
Conditions:
Current condition is believed to be link flap of route advertised by EIGRP nei.
After a link flap, you will see the route as follows:
192.168.210.10/32, ubest/mbest: 1/0, pending <<<<<<
*via 192.168.10.2, Eth10/1.10, [90/128512], 00:00:20, eigrp-200, internal
n7k#
Workaround:
clear ip route on the n7k is the only current workaround.
Further Problem Description:
This problem can only occur when the routing table receives an update
for the exact same route in different VRFs in the same update message
from the client, e.g.:
EIGRP->URIB msg1:
default: 192.168.210.10 via 192.168.10.2, pref etc
DMZ: 192.168.210.10 via 192.168.10.2, pref etc
OUTSIDE: 192.168.210.10 via 192.168.10.2, pref etc
i.e. the route must change in multiple VRFs at the exact same time,
and be the only route changing at that time, i.e. this would not cause
the issue:
EIGRP->URIB msg1:
default: 192.168.210.10 via 192.168.10.2, pref etc
default: 192.168.211.10 via 192.168.10.2, pref etc
DMZ: 192.168.210.10 via 192.168.10.2, pref etc
DMZ: 192.168.211.10 via 192.168.10.2, pref etc
OUTSIDE: 192.168.210.10 via 192.168.10.2, pref etc
OUTSIDE: 192.168.211.10 via 192.168.10.2, pref etc
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(4), 4.2(4.23), 4.2(5), 5.0(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl91665 | Title: | N7K MSDP SA-out-filter intermittently blocks entire SA from being sent |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Conditions:
Workaround(s):
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(6) |
|
Known Fixed Releases: * | 5.1(10.1)S0, 5.1(3)S9, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz22390 | Title: | Local routes not installed in RIB after ISSU upgrade |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a device running NX-OS, after performing an ISSU upgrade, or a
system switchover, local and direct routes may be missing from the
routing table.
Conditions:
This can occur when there is a VRF in the system, for example the
management VRF, that is in the administratively shutdown mode, and
this shutdown VRF has an interface with IP address configuration.
Workaround:
There are a number of workarounds to this issue, but to fix the
inconsistent state, for each "Up" VRF that is affected, the operator
can repopulate all routes in the VRF by entering the following
command:
clear routing *
To avoid the issue, for each shutdown VRF, the
operator can administratively shutdown all the interfaces that are
within that VRF.
Alternatively, if the shutdown VRF is not needed, it can be removed
from the system. If the shutdown VRF is needed, it could be removed
from the administratively down state with
no shutdown.
Further Problem Description:
When a switchover or ISSU is performed, all the IP address
configuration routes are sent to the unicast RIB.
This may be sent as a single "message" within the NX-OS system.
If this message erroneously contains routes for a VRF that is
shutdown, the unicast RIB is currently not liberal in what it accepts,
and thus drops the entire message, i.e. ignores all the routes,
including those for VRFs that are not shutdown.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(4), 4.2(0.214) |
|
Known Fixed Releases: * | 4.2(0.219), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr88815 | Title: | S,G is not populated when *,G exist for OTV core multicast group |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
1. Reload one of N7K box contains core vdc and otv vdc
2. after reload, one of other site's ED can't establish OTV ajd with reloade box's vdc
3. Onf of other site's ED has *,G for otv core multicast group and s,g for other ED but no s,g for reloaded ED.
Conditions:
Reloading N7K.
Workaround:
clear ip mroute or shut/no shut on overaly interface
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(4) |
|
Known Fixed Releases: * | 5.2(2)S16, 5.2(2.14)S0, 6.0(0.31)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz45157 | Title: | NetStack crashed after restarting PIM with 2k (S,G) routes on 256 OIFs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom: Netstack crash with restart of PIM
Conditions: This problem was introduced by a commit in 4.2 and has been fixed in the same release. So, one should not see this crash if box is upgraded to 4.1(5) or 4.2
Workaround: This problem was introduced by a commit in 4.2 and has been fixed in the same release. So, one should not see this crash if box is upgraded to 4.1(5) or 4.2
Further Problem Description: None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(0.196) |
|
Known Fixed Releases: * | 4.2(0.224), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug32189 | Title: | BGP process fail due to constant Socket (43/-1) accept: Bad file descrip |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BGP process fail due to constant Socket (43/-1) accept: Bad file descriptor
BGP-3-SOCKCREATE bgp-6000 [4524] Cannot create socket for peer 1.1.1.1.: Bad file descriptor, stats: 60029780/880562/60910228/8747920/8462770
Conditions:
Workaround:
NONE
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.1(0)AE(0.27) |
|
Known Fixed Releases: * | 5.0(3)U5(1f), 6.0(2)N2(1), 6.1(4), 6.1(4)S16, 6.1(4.66)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud54837 | Title: | All Ipv6 static routes missing from RIB after "clear ipv6 route *" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom
Static IPv6 routes pinned to interface are missing in the routing table
Condition
When all the IPv6 routes are deleted using "clear ipv6 route *" CLI, all the routes are deleted and reinserted. However, IPv6 static routes pinned to an interface are not reinserted.
Workaround
The affected static routes should be deleted and reconfigured.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N1(0.362) |
|
Known Fixed Releases: * | 6.2(0.313)S0, 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj59752 | Title: | *,G multicast entries was corrupted after SUP OIR |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After system switchover, some *,G got corrupted and missing the RPF interface because of that when the traffic was stopped, some of the entries are failed to come up.
7010-GS-1# show ip mroute | in Null p 2
(*, 226.1.1.9/32), uptime: 02:26:54, igmp pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Conditions:
This only happened on system Switchover
Workaround:
Clear ip mroutes *
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3)E3, 5.2(0.1), 5.2(0.154)S6 |
|
Known Fixed Releases: * | 5.1(1.66)S0, 5.2(0.174)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf61304 | Title: | NX-OS : RPF on mroute incorrectly pointing to the RP for (S,G) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On the Turn around router running NX-OS, RPF on mroute incorrectly pointing to the RP for (S,G)
Conditions:
RP on a stick set-up. mostly seen in cases that have slow sources. on the turn around router running NX-OS, the incoming interface on the (S,G) points towards the RP instead of towards the Source, packet flow stops in this state. Clearing the mroute fixes
the issue. But the Mroute randomly goes back to this state.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3)N2(2a), 5.2(1)N1(3), 6.0(2)N1(2) |
|
Known Fixed Releases: * | 5.0(3)U5(1f), 5.2(1)N1(5), 6.0(2)N1(2a), 6.0(2)N2(1), 6.0(2)U1(1), 6.2(1.83)S0, 6.2(2), 7.0(1)N1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth40877 | Title: | NxOS: OSPF DR not sending out network LSAs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom
OSPF does not advertise Network LSAs
Conditions
There are a few possible triggers for this - one is doing a shut/no shut on the interface. Adjacency flaps can also cause this issue
Workaround
This can be recovered by doing a shut/no shut on the interface
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3), 5.1(0.227), 5.1(0.236), 5.2(0.1) |
|
Known Fixed Releases: * | 5.0(0)MP1(0.368), 5.0(5)S12, 5.1(1)S12, 5.1(1.1)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr70572 | Title: | LISP: map-notify not forwarded in the interface in esm mode |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The data-driven-SMR may not get generated from the ESM LISP site when it has multiple XTRs in the ESM subnet.
Conditions:
In the ESM Site(SITE1) where there are two XTRs (in the same subnet) connected via OTV to other LISP site.
SITE 1 SITE 2
XTR A XTR B XTR C
| VLANX | |
------------------- <------OTV-------> ---
|
VM1---------------------------------->VM1
- When the dynamic-eid is discovered in SITE2, the XTR in SITE2 registers dynamic eid with mapping database.
- Upon registration Mp-Server sends a Map-Notify to SITE1 (Last registerer). One of the XTR in SITE1 receives the message from Map-server.
- The XTR which receives the map-notify installs the /32 NULL0 route but does not send the multicast map-notify. Hence the other XTRs in the site are not updated.
- Now if a LISP en-capped packet is received at the site by XTR which does not have /32 NULL0, then it does not generate data-driven-SMR.
Workaround:
None. The traffic flow is not disrupted due to this.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(2)S2, 5.2(2.3)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq89762 | Title: | netstack crash at tcp_client_tlv_to_socks |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Netstack process crash may be seen that decodes to failing in the tcp_client_tlv_to_socks function
In some circumstances, if Netstack has crashed previously due to another software defect, this may trigger a switchover or chassis reset
Conditions:
This issue occurs when attempting to close a TCP socket
Workaround:
None
More Info:
N/A
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(3)E5, 5.2(1), 5.2(1)S31 |
|
Known Fixed Releases: * | 5.2(3.1), 5.2(3.42)S0, 6.0(0.13)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd59280 | Title: | Fail to generate intra-area LSA from the IPv6 loopback interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
OSPFv3 Fails to generate intra-area LSA from the IPv6 loopback interface in
case there are no ipv4 addresses on the interfaces after a restart.
Conditions:
There shouldn't be any v4 addresses on the loopback interfaces.
Workaround(s):
Configure a v4 address on a loopback interface.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(3), 4.2(4), 5.0(2) |
|
Known Fixed Releases: * | 4.2(7.62)S0, 5.1(0.126)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc97131 | Title: | OSPF admin down SVI subnet advertised on ISSU from 4.2(1)E2 to 4.2(2a)E1 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Problem/Symptom:
When an N7K is ISSU upgraded from 4.2(1)E2 to 4.2(2a)E1, and if there are SVI interfaces which are in shutdown mode part of OSPF, the network for the shutdown SVI will still be advertised by OSPF to its neighbors. Only some shutdown SVIs get advertised, and not all.
If there are no shutdown SVIs there is no operational impact.
Workaround:
This issue happens only on ISSU, and not on normal reload of the system.
It is being evaluated if a OSPF process restart after the ISSU process is over will clear the condition.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(2a)E1 |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.27), 4.2(4), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr94688 | Title: | NX LISP: netstack crash with instance-ids and v6 EIDS |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Netstack crashes, often followed by the router
Conditions: This occurs with vrfs/instances having IPv6 EIDs
Workaround: None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(0.266) |
|
Known Fixed Releases: * | 5.2(2)S2, 5.2(2.3)S0, 6.0(0.42)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti71753 | Title: | vlan context is not created after a vlan is created |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom :
snmp context for vlan is not created when vlan is created.
Condition :
The issue exists in NXOS software release 5.1(2) to 5.1(5).
The problem is fixed in NXOS software release 5.1(6), 5.2(1) and all the later releases.
Workaround :
- system reload for single Sup environment.
- system switchover for dual Sup environment.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(0.227) |
|
Known Fixed Releases: * | 5.1(1)S21, 5.1(6)S9, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsy94721 | Title: | FIB doesnt clear routes when urib deletes while consistency checker exec |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 7000 may end up with an IPv4 RIB which is out of sync with its
IPv4 FIB counterpart.
Conditions:
Ironically, this can happen when running the IPv4 consistency checker,
which is used to test whether the RIB and FIB are in sync.
test forwarding inconsistency
Workaround:
Running the consistency checker again can highlight the
inconsistencies, and the commands:
clear forwarding ...
clear routing ...
Can be used to fix the inconsistencies.
Further Problem Description:
This is likely to happen only when a delete route needs to be sent to
the FIB whilst the IPv4 consistency checker is running.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(0.174) |
|
Known Fixed Releases: * | 4.2(1), 4.2(1.9), 4.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb73645 | Title: | N7K: SSH is not responsive, N7K not letting any SSH connection. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus7000 would not allow ssh connection to the box after a while. The symptoms observed was the sshd process was not being released by Nexus, as shown in the show proc cpu there are at least 60 instances of sshd process. As a rsult the nexus would now allow additional ssh connection.
Conditions:
Not determined at this time but a script that customer is using may not be using a graceful disconnect such as 'exit'.
Workaround:
Workaround to make ssh function again is to disable the ssh and then re-enable it. One can alos telnet to the box as an alternative method to access the box.
Further Problem Description:
This problem has been existing from day one. It could hit any point of time, whenever ssh/sshd is involved, but the window of that race is very small. Hence the frequency is small
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(4) |
|
Known Fixed Releases: * | 4.2(1)N1(1), 4.2(2.32), 4.2(3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc48208 | Title: | Some routes not redistributed from BGP to OSPF after reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After changes in routing table (BGP flap changes in BGP routing table) routes that have same prefix but different mask are not always redistributed to OSPF.
Changes in OSPF config will correct redistribution
Conditions:
This is happening to routes that have same prefix but different mask. Triggers are for an example simply bgp flap or changes in BGP routing table.
Workaround:
none.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(2a) |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.6), 4.2(4), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts01451 | Title: | CLIS hogging system resources, PSS DB full |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
During a "no feature ospf" command if "snmp-server enable traps..." command exists, then CLIS gets into a infinite loop that will crash the supervisor card.
Conditions:
The root cause of the issue is that CLIS goes into an infinite loop while trying to delete 'snmp-server enable traps...' cmd for ospf when ospf feature is being disabled.
Workaround(s):
None.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(6)S58, 4.2(8)S27 |
|
Known Fixed Releases: * | 4.2(8)S32, 4.2(8.103)S0, 5.1(10.49)S0, 5.1(5)S8, 5.2(2)S5, 5.2(2.5)S0, 6.0(0.31)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn95497 | Title: | NXOS: HA switchover not reliable and could cause packet drops |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
N7K supervisor engineer failover not reliable and may take longer than expected. This can affect control plane L2/L3.
For example, after SSO failover between supervisor engines, the switch may not generate STP BPDUs for 6 - 9 seconds which can lead to TCNs and packet loss. Thus SSO and ISSU are not seemless
Conditions:
Nexus 7000 dual supervisor engines running 5.1.2 or 5.1.3 performing High Availability (HA) switchover.
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(2), 5.1(3), 5.2(0.245), 5.2(1), 6.0(0.36), 6.0(0.55) |
|
Known Fixed Releases: * | 5.1(10.1)S0, 5.2(2.63)S0, 6.0(2)S4, 6.1(0.123)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts77257 | Title: | N7k redistribution discrepancies between ospf and routing table |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The summary route is missing from RIB but the LSA corresponding to the prefix
is present in OSPF database.
Conditions:
The problem is seen when there are the following conditions:
1) a "summary-address" command configured on a router
2) The summary address has no component routes to advertise that falls
in that summary.
3) the router receives a LSA for a component route falling in that
summary from another router.
Under these conditions, when an incremental summary SPF run, the route may be
missing from the RIB
Workaround:
Forcing a FULL spf will fix the problem.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(5) |
|
Known Fixed Releases: * | 5.2(2.39)S0, 6.0(0.62)S0, 6.2(0.7)S0, 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf35299 | Title: | OSPF flap with clock is changed backwards using NTP or manually. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
OSPF neighbors configured with MD5 authentication and authentication-key 3 will loose its neighbor if clock of the Switch get changed to back dated.
Workaround: No work around.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(2a) |
|
Known Fixed Releases: * | 4.2(6)S56, 4.2(6.54)S0, 5.0(2), 5.0(2.44), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr52312 | Title: | aciqos crash after issu from 426 to 521 followed by peer link flap |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
aclqos crash
Conditions:
issu(4.26->5.2.1) followed by peer-link flap
Workaround:
none
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1)S71 |
|
Known Fixed Releases: * | 5.2(1)S73, 5.2(1.62)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw80964 | Title: | ISSD from 5.2.3 to 5.1.3 fails due to broken pipe to SAP 309 (Netstack) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
During an ISSD from NX-OS 5.2(3) to 5.1(3), an error in the MTS may be seen with a destination SAP of 309 specifying error code -32 (broken pipe) on the standby supervisor.
%KERN-2-SYSTEM_MSG: mts_basket_process_entry() failed 512 with
error-code -32 for opcode 106497, d_sap 309<2>mts_set_HA_state() -
Conditions:
An ISSD is performed. This error is typically seen when downgrading to a release of NX-OS where SAP 309 is not a valid destination for an MTS pipe, due to changes in code related to the Netstack service. Specifically, this happens when an attempt is made to perform a PSS snapshot for Netstack.
Workaround(s):
None known.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(3)S20 |
|
Known Fixed Releases: * | 5.2(3.30)S0, 6.0(2)S30, 6.1(0.174)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud03634 | Title: | RIP keep advertising route even though original route source is down |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
RIP keep advertising route even though the original advertising source is down.
Conditions:
The route is redistributed to RIP.
Original source (other Routing protocols or Connected link) is down.
or
RIP native route
Workaround:
None.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N1(0.349) |
|
Known Fixed Releases: * | 5.2(9.51)S0, 6.0(2)A1(1c), 6.0(2)N2(1), 6.0(2)U1(3), 6.1(4.1)S0, 6.1(5), 6.2(1.93), 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts89287 | Title: | OTV: N7k sends duplicate multicast traffic |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
In an OTV network, Multicast traffic for one stream is being duplicated.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1), 5.2(1)S89 |
|
Known Fixed Releases: * | 5.2(2.44)S0, 6.0(1)S3, 6.1(0.104)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr65106 | Title: | N7K Random OSPF adjacency drops |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | OSPF packets are dropped internally when the high watermark is reached for the hello queue or the flood
queue ("show ip ospf stat"). Neighbors might thus reset.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4), 5.0(2a), 5.0.5 |
|
Known Fixed Releases: * | 5.1(10.44)S0, 5.1(10.45)S0, 5.1(10.52)S0, 5.1(5)S11, 5.1(5)S4, 5.1(5)S6, 5.2(2.38)S0, 6.0(0.42)S0, 6.0(0.43)S0, 6.0(0.51)S0 |
|
|
| |
| |
|
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: | 17-JUN-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), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy51156 | Title: | Port stuck in authorization pending state after link flaps |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On nexus 7000/7700 series, a port configured with cts macsec encryption may be stuck in authorization pending state after link flaps. The port will pass traffic if cts is removed.
Conditions:
- F2/F2E, or F3 cards present with macsec configured
- link down/up event occurs for any reason
Workaround:
A module reload clears the issue, or please contact TAC for
possible workaround w/o reloading the module.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(16)E1, 7.3(0)UCI(0.41), 7.3(1)DX(0.35), 7.3(1)FTO(0.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg88857 | Title: | bogota:'OID not increasing' in IP-FORWARD-MIB:InetCidrRouteEntry (IPv6) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A snmpwalk of the mib defined by RFC 4292 results in an error message
saying "oid not increasing" for an ipv6 route.
Conditions:
This will occur when there is an ipv6 prefix with multiple ecmp and
the ip address associated with the lower interface is
lexicographically larger than the ip address associated with the
higher interface.
Workaround(s):
There is no work around for this issue.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2) |
|
Known Fixed Releases: * | 5.1(0.154)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux47262 | Title: | STP stuck on LRN state after upgrade |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In vPC scenario, during the ISSU upgrade step, we found part of vlan (vlans 606, 1336, and 1340) on vpc port-channel 301 stuck in LRN state, and can not recover.
Conditions:
Workaround:
Issue only disappeared after remove vlans on peer-link and then add back. To resolve the problem, we removed the vlans 606, 1336, and 1340 off both N7Ks for VPC 301 (removed from trunk allowed list). We re-added the vlans back and STP went forwarding as we expected.
Further Problem Description:
As a sanity check procedure after ISSU, you can check the connectivity of VLANs (such as ping test to the SVI). If the situation happens, recycle the VLAN configuration. This will be the workaround.
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(2), 6.2(8a) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.97), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy81913 | Title: | After ISSU change the lkup mode globally from IP to MAC traffic drop |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After changing l2 multicast lookup mode by "[no] layer-2 multicast lookup mac" before and after ISSU, the l2 mcast route is not programmed in hardware.
Conditions:
The problem is hit when l2 multicast lookup changes before and after MFDM restart - either due to ISSU, system switchover, or mfdm crash.
Workaround:
In steady state, change the lookup back and forth one more time. This will ensure the routes in old lookup mode be deleted in memory and new routes will be push to LC to be programmed in hardware.
Further Problem Description:
When l2 lookup mode changes, mfdm will clean up all the route in existing lookup mode. However this is a software bug that these routes are not deleted from PSS. So when mfdm restart happens - due to ISSU or system switchover, route in old lookup mode will be recovered in mfdm. So mfdm is hold the route with two lookup mode. If now the lookup mode is changed again back to old lookup mode, it will delete all the routes in new lookup mode but keep the route in old lookup mode. So after the lookup mode change, when control plane push down the route in old lookup mode, mfdm considers it as identical route, and ignores the update. As the result, LC (hardware) will not be programmed.
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.123), 7.3(0)DX(1), 7.3(0)TSH(0.99), 7.3(1)D1(0.23), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy43188 | Title: | In "F2E F3" VDC, IPSG entries being pushed on F3 rather than F2E |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IPSG entries are not getting pushed to F2E card while for other line card F3 it is working fine
Hardware programming on F2E:
====================
N2-ACCESS# sh forwarding security mac module 1 vrf all
IPv4 security information for table 0x5, prefix count 15
------------------+------------------------+-----------
Prefix | Mac-address M V P | Interface
------------------+------------------------+-----------
IPv4 security information for table 0xfffe, prefix count 3
------------------+------------------------+-----------
Prefix | Mac-address M V P | Interface
------------------+------------------------+-----------
N2-ACCESS#
Hardware programming on F3:
===================
N2-ACCESS(config)# sh forwarding security mac module 8 vrf all
IPv4 security information for table 0x5, prefix count 17
------------------+------------------------+-----------
Prefix | Mac-address M V P | Interface
------------------+------------------------+-----------
30.0.0.10/32 0022.19a7.5567 1 0 1 Eth1/25
30.1.0.10/32 0000.0000.0001 1 0 1 Eth1/1
Conditions:
Mixed VDC with F2E and F3 LC's
Workaround:
Not Known at this moment of Time
Further Problem Description:
N/A
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(16)S32, 7.3(0)DX(0.96) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(0.133), 7.3(0)DX(0.145), 7.3(0)DX(1), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy21050 | Title: | MBD OIFlist programming is incorrect in MFDM post swithover |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
L2 multicast traffic drops due to that L2 LTL driven by l2 lookup doesn't have correct oifs. These oifs are programmed by PIXM. However PIXM lost the oifs info after LC reloaded, and expect a trigger from mfdm to repopulate the oifs for the LTL.
Conditions:
All following conditions need to be met to hit the problem:
1. Vinci Spine switch with fabric VNIs configured.
2. system switch over, or ISSU from GRB to HSK
3. L2 multicast egress LC reload.
Workaround:
Since Fabric VNIs is used for pruning, without it, it will be flooded in spine. So temporarily remove it won't cause any traffic outage. This can be used as workaround as described below:
Before switchover, or ISSU, unconfig fabric VNIs. After switchover or ISSU, re-config fabric VNIs. After this, LC reload will not causing the problem.
Example:
10000 is fabric control VNI - this should not be removed.
50001-50050 is fabric VNI.
Before SSO, or ISSU, config:
"no vni 50001-50050"
After SSO or ISSU, config:
"vni 50001-50050"
Further Problem Description:
The root cause is that with "feature fabric multicast" configured on spine, Monster BD will have ftag entry created. These entry are not properly restored during switchover or ISSU that the tag entries restored lost vni value in it. Such entries are not from m2rib and will not be removed when LC is reloaded. As the result the oiflist pointed by these entries will never be removed and added back and PIXM won't get the expected trigger for them.
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.127), 7.3(0)DX(1), 7.3(0)TSH(0.99), 7.3(1)D1(0.12), 7.3(1)FTO(0.7), 7.3(1)PDB(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy45305 | Title: | port moved from vdc and errors for %DHCP_SNOOP-2-HWPGMFAILURE: Hardware |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
%DHCP_SNOOP-2-HWPGMFAILURE: Hardware programming has failed
Conditions:
%DHCP_SNOOP-2-HWPGMFAILURE: Hardware programming has failed
Workaround:
%DHCP_SNOOP-2-HWPGMFAILURE: Hardware programming has failed
Further Problem Description:
%DHCP_SNOOP-2-HWPGMFAILURE: Hardware programming has failed
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.90) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.125), 7.3(0)DX(0.127), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy49147 | Title: | VTPV3_VPC - ERROR: Password mismatch seen in 7.3.0.DX.0.90.gbin.S0 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Password mismatch is observed on becoming primary server for feature vlan/mst.
Conditions:
Workaround:
Set vtp password in hidden mode again or hit enter.
Further Problem Description:
Initially hidden password is set. Once we make mst instance or vlan instance primary, new password is accepted and instance become primary but password is set to empty. So, on setting 2nd instance primary, password is rejected - Passowrd mistmatch. VTP password is not configured. Hence, rejecting new password 2nd time.
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.90) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.125), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy30270 | Title: | LISP: synch leads to frequent uRIB writes, which block route reads |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In a deployment with lisp ESM mobility enabled, a standby HSRP box starts observing high delays in software forwarding.
As a consequence, HSRP suffers hello packet loss and periodically flaps.
Conditions:
The trigger for this is when the number of hosts that lisp detects goes above the recommended 250. The impact is higher when the number of hosts detected grows beyond 600 hosts and depending on the number of processes that are actively using software forwarding on the box.
Workaround:
The only available workaround now is to limit the number of lisp mobility hosts to values below 250 or deploy LISP without HSRP.
Further Problem Description:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: * | 6.2(14)E1, 6.2(16)S46, 7.0(0)BZ(0.127), 7.2(2)D1(0.41), 7.2(2)N1(0.407), 7.2(2)N1(1), 7.2(2)ZD(0.112), 7.2(2)ZN(0.109), 7.3(0)DG(0.3), 7.3(0)DX(0.133) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut29799 | Title: | Privilege escalation with o+w files and directories |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Cisco NX-OS based devices contain a number of files and directories that are assigned weak file permissions. This could allow an attacker that was able to gain access to the
underlying operating system to view or modify certain files that should be restricted.
Conditions:
Nexus devices running an affected version of NX-OS Software.
Workaround:
None.
Further Problem Description:
Credit:
Cisco would like to thank Jens Krabbenhoeft for discovering and reporting this vulnerability.
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 1.7/1.4:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:N/I:P/A:N/E:F/RL:OF/RC:C&version=2.0
No CVE ID has been assigned to 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: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.0(0)HSK(0.392), 7.3(0)D1(0.69), 7.3(0)D1(1), 7.3(0)DX(0.4), 7.3(0)DX(1), 7.3(0)PDB(0.11) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz23741 | Title: | hardware qos mpls exp topmost pipe-mode is broken |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
"hardware qos mpls exp topmost pipe-mode" with "set mpls experimental topmost ? should not rewrite the packet DSCP, but in M3 its broken.
Conditions:
When qos action is "set mpls experimental topmost ? on PE-1, we treat this is a uniform mode. In uniform mode inner packet dscp is modified based on the .
But, "hardware qos mpls exp topmost pipe-mode? with ?experimental topmost " should not change the inner cos as per the customer needs. But in M3, its rewriting DSCP value.
Workaround:
Further Problem Description:
PE-1 :
PE-1# sh run | inc hard
hardware qos mpls exp topmost pipe-mode
PE-1#
PE-1# sh policy-map interface ethernet 1/4 type qos
Global statistics status : enabled
Ethernet1/4
Service-policy (qos) input: sample
SNMP Policy Index: 285214816
Class-map (qos): match_dscp_10 (match-all)====> IP packet ingressing with DSCP#10
Slot 1
3096152587 packets 142425355940 bytes
5 minute offered rate 2738140090 bps
Aggregate forwarded :
3096152587 packets 142425355940 bytes
Match: dscp 10
set mpls experimental topmost 7====> QOS action is : set mpls experiment topmost 7 with hardware qos mpls exp topmost pipe-mode.
====> This should not change the packet DSCP (inner). But in the case of M3, its getting rewritten in the ingress PE.
Class-map (qos): class-default (match-any)
Slot 1
28 packets 1722 bytes
5 minute offered rate 32 bps
Aggregate forwarded :
28 packets 1722 bytes
PE-1#
PE-2 :
E-1-PE-2# sh policy-map interface ethernet 1/44 type qos
Global statistics status : enabled
Ethernet1/44
Service-policy (qos) output: egress-new-qos
SNMP Policy Index: 285213778
Class-map (qos): match_dscp_10 (match-all)====> Expected : Ingress PE-1 should not rewrite the DSCP, and expected packet to be classified here, but its rewritten based on EXP set.
Aggregate forwarded :
0 packets
Match: dscp 10
police cir 2 gbps bc 200 ms
conformed 0 bytes, 0 bps action: transmit
violated 0 bytes, 0 bps action: drop
Class-map (qos): match_dscp_63 (match-all)
Slot 1
2817442757 packets 2105306975838 bytes
5 minute offered rate 2738131861 bps
Aggregate forwarded :
2817442757 packets 1105813614952 bytes
Match: dscp 63
police cir 2 gbps bc 200 ms
conformed 1105812579492 bytes, 1438155974 bps action: transmit
violated 999493360886 bytes, 1299976941 bps action: drop
Class-map (qos): match_dscp_0 (match-all)
Aggregate forwarded :
0 packets
Match: dscp 0
police cir 2 gbps bc 200 ms
conformed 0 bytes, 0 bps action: transmit
violated 0 bytes, 0 bps action: drop
Class-map (qos): match_dscp_5 (match-all)
Aggregate forwarded :
0 packets
Match: dscp 5
Class-map (qos): class-default (match-any)
Aggregate forwarded :
0 packets
PE-1-PE2
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.141) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(0)UCI(0.39), 7.3(1)DX(0.3), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw10098 | Title: | FPC members in error disabled state with error as INVALID INTERFACE |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | FEX uplink interfaces are in error state
Symptom:
FEX uplink interfaces are in error state:
switch# show interface ethernet 2/9
Ethernet2/9 is down (Error disabled, sim: invalid interface)
Conditions:
After ISSU/switchover a FEX module is removed / reloaded. It may come back up in an error state.
Workaround:
Reload of switch will resolve the issue
Further Problem Description:
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.82) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)D1(1), 7.3(0)DX(1), 7.3(0)TSH(0.99), 7.3(0)UCI(0.39), 7.3(1)D1(0.12), 7.3(1)DX(0.10), 7.3(1)DX(0.9), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz29940 | Title: | MFIB fail to install route with Tunnel after LC reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
For systems with multicast over GRE configuration (multicast with tunnel in the oiflist), it's possible that a module reload will result in the some routes not being installed on the reloaded module. This will result in traffic drops for all affected routes.
Conditions:
The problem is more likely to occur in a scale topology with >20K multicast routes, but may happen with less. This problem has only been seen thus far with Flanker (F3) based modules. However, the condition applies to other module types.
Workaround:
The CLI "clear ip mroute" for the affected VRFs will fix up the HW programming.
Further Problem Description:
None
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)UCI(0.39), 7.3(1)DX(0.23), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux93185 | Title: | n7k/COPP - move mcast exception connected to dedicated class |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Intermittent unicast traffic disruption can be seen with high number drops in COPP class normal and higher proportion of multicast traffic send to CPU
Conditions:
Issue can happen when directed connected sources for multicast connected without any receivers. This cause multicast traffic to be sent to cpu and cause drop in class normal that contain ARP.
Workaround:
Change COPP config and move directly connected multicast traffic to dedicate class:
class-map type control-plane coop-class-multicast-connected-new
match exception ip multicast directly-connected-sources
match exception ipv6 multicast directly-connected-sources
class-map type control-plane match-any copp-class-normal-new
match access-group name copp-acl-mac-dot1x-new
match protocol arp
policy-map type control-plane copp-policy-strict-new
class copp-class-redirect-new
set cos 1
police cir 280 kbps bc 250 ms conform transmit violate drop
class copp-class-multicast-connected-new
set cos 1
police cir 680 kbps bc 250 ms conform transmit violate drop
class copp-class-normal-new
set cos 1
police cir 680 kbps bc 250 ms conform transmit violate drop
Further Problem Description:
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)UCI(0.39), 7.3(1)DX(0.33), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy33276 | Title: | TCAM_PF_INSERT_FAIL mcast address files |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
After module poweroff/no poweroff you can see error on the TCAM insertion for multicast:
2016 Feb 8 22:50:26 arlon %IPFIB-SLOT2-4-FLN_FIB_TCAM_PF_INSERT_FAIL:
FIB TCAM prefix insertion failed for IPV4 multicast on instance 2
2016 Feb 8 22:50:26 arlon %IPFIB-SLOT2-4-FLN_FIB_TCAM_PF_INSERT_FAIL:
FIB TCAM prefix insertion failed for IPV4 multicast on instance 3
2016 Feb 8 22:50:26 arlon %IPFIB-SLOT2-4-FLN_FIB_TCAM_PF_INSERT_FAIL:
FIB TCAM prefix insertion failed for IPV4 multicast on instance 4
IF you check sh forwarding ip multi route vrf all --> all or most of the routes are missing.
Conditions:
seen with 7.3(0)D1(1)
Workaround:
reseat the module again, eventually the insertion is correct.
Further Problem Description:
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1), 7.3(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz42342 | Title: | NXOS:ISIS:FP - ISIS crash during ISSU on PSS recovery |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
ISIS crash with error:
%SYSMGR-2-SERVICE_CRASHED: Service "__inst_001__isis_fabricpath" (PID 6120) hasn't caught signal 6 (core will be saved).
Conditions:
ISSU crash could happened during ISSU upgrade, when an upgrade from pre-6.2 into 6.2 is part of the ISSU sequence.
Workaround:
After the pre-6.2 -> 6.2 ISSU a "restart fabricpath domain" should be performed.
Further Problem Description:
An example would be the ISSU sequence 6.1(5) -> 6.2(8a) -> 6.2(14). The crash happens in 6.2(14). The proposed workaround should happen with 6.2(8a) code after the ISSU from 6.1(5)
|
|
Last Modified: | 03-JUN-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz21326 | Title: | Aclmgr Crashes on 6214 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Multiple aclmgr crash
Conditions:
frequent ACL add/delete/edit of ACEs is done using config session
changes can be done manually or via script
Must condition :-
During the time changes are done, and config
session is not committed yet. Now, if there is a switch reload , then cleanup of the session post switch reload causes crash.
Other condition for crash is TBD
Workaround:
Need to make sure there are no pending config session before reload, with following cli:
"show configuration session".
If there are active one, either commit or discard it.
Further Problem Description:
|
|
Last Modified: | 03-JUN-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | 6.2(16)E1, 7.3(1)D1(0.51), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh23173 | Title: | Xbow-sup3: SH crashed on swover running UTE script |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Issue is rare and random in nature and seen mostly on a few QA setups
Symptom:
System manager will detect core files of standard linux utilities like sh, tar etc.
Conditions:
Its seen only on N7000 and N7700 SUP2 platforms. Its triggered during heavy memory related activities such as switchovers.
Also configuring many snmp users that will access the password and password shadow files can lock access
to those login files and cause anything needing access to those login files to core especially during ISSU upgrading.
Workaround:
None.
Removing unused snmp users from system and configurations will lessen the likelihood of locking the password and password shadow files.
Further Problem Description:
|
|
Last Modified: | 07-JUN-2016 |
|
Known Affected Releases: | 6.2(10)E1, 6.2(10)S102, 6.2(10)S23, 6.2(10)S36, 6.2(10)S65, 6.2(10)S82, 6.2(12)S12, 6.2(2)S21, 6.2(2)S23, 6.2(7.28)S0 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz00513 | Title: | F3: L3 mcast uncredited drops from 40G to 10G |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
we are able to send 2 multicast streams 8G each from 40G to 10Gig port-channel, without any issues/drops, if traffic is received and sent in same VLAN. But, we would see uncredited drops only when we route the multicast traffic received from 40G to 10G.
Conditions:
1. mcast traffic should get routed
2. no receiver in source vlan
3. OMF enabled ( VDC OMF)
Workaround:
DISABLE OMF or always have a receiver in source vlan
Further Problem Description:
This is a software design limitaiton
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup60557 | Title: | F2 / F2e does not send ICMP unreachable for ip length 1501-1516 bytes |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Routing between interfaces with F2 or F2e modules where the ingress interface has an MTU of 9216 and the egress interface has an MTU of 1500, with no 802.1Q trunking or fabricpath configured and ICMP unreachables enabled on the ingress interface, a N7K will not generate an ICMP unreachable for packets with an ip length between 1501 bytes and 1516 bytes with the DF bit set for path MTU discovery.
In other words, even though the MTU for the egress interface is 1500 Bytes, it will still hardware-switch the packets up to a 1516 byte IP payload for F2/F3, and up to a 1534 byte IP payload for F2e. This behavior is changed 6.2(10) and later such that any payload exceeding the MTU (i.e. 1501) will be software switched.
Conditions:
F-Series line cards and a discrepancy between the ingress and egress MTU.
Workaround:
None
Further Problem Description:
The F2 or F2e forwarding engine architecture to accommodate mac-in-mac encapsulation for fabricpath functionality. currently software programs the forwarding engine with the configured MTU + 16 bytes to accommodate the fabicpath header, even if fabricpath is not enabled/configured.
Until the packet length is greater-than MTU + 16 bytes in length for the egress interface, the packet will not be subjected to fragmentation or sent to cpu for ICMP unreachable message generation.
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 6.2(6a), 6.2(8), 7.1(0)D1(0.152) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S24, 6.2(10)S27, 6.2(10)S66, 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.289), 7.1(0)D1(0.312) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz56514 | Title: | L2FM is not receiving UP state for remote VPC leg FEXA-A VDC reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Duplicate traffic is noticed on downstream FEX connected to F2 cards (not F2CR or F3) in FEX A-A setup
Conditions:
On switch reload / VDC reload, mac is missing on one side of VPC and traffic hashes to the side missing.
Workaround:
clear mac address dynamic
OR clear mac address address on the side present.
Further Problem Description:
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: * | 7.3(1)DX(0.49) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz35456 | Title: | SMU:Install operation 2 failed because patch is not found:libpmcli issue |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
-If the patch contains fix for libpmcli_common_fcoe.so, it will not support install operation.
-De-activation will fail if we have patches which involves libraries for line-cards.
Conditions:
-patching involving the library libpmcli_common_fcoe.so
The line card patch involves a library.
Workaround:
-Special cases like libpmcli_common_fcoe.so is not supported
- Line card patches involving library, make it a reload.
Further Problem Description:
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: * | 8.3(0)CV(0.429), 8.3(0)MVA(0.11) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy19010 | Title: | SNMPd causes boot loop after reload with unload-MIB configuration |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
SNMPd may crash repeatedly immediately after boot. While a single crash of the SNMPd service will not cause a reload, multiple crashes in quick succession are considered fatal and so the system will reboot.
Due to this issue, the system will enter a boot loop that can be recovered only by erasing the configuration (via 'write erase' from kickstart) and re-applying it.
Conditions:
The trigger for this issue is to configure 'no snmp-server load-mib ' and save the configuration. This does not cause any impact during runtime, but if the switch later reboots for any reason this will trigger the crashes and bootloop.
This is known to affect all currently available versions of code in the 7.1, 7.2 and 7.3 code trains for the Nexus 5000. The 7.0 code train is not affected.
The code problem is platform-independent and therefore likely affects other Nexus switching platforms as well.
Workaround:
Do not unload MIBs via the 'no snmp-server load-mib' command.
Further Problem Description:
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: | 8.3(0)CV(0.300) |
|
Known Fixed Releases: * | 8.3(0)CV(0.429), 8.3(0)MVA(0.11) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus20934 | Title: | vPC crashed while booting up with the configuration - N7K |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VPC component will crash and cause a HAP reset
Conditions:
The following configuration will lead to the crash
Config Scale :
Primary Vlan: 15
Secondary vlan: 50
Physical ports: 8
vPC+ PC in pVlan: 30
Workaround:
Reduce the PVLAN configuration
Further Problem Description:
PVLAN scale causes the crash. The workaround is to use the reduced PVLAN configuration
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: * | 6.2(10)S7, 6.2(12)S18, 6.2(12)S7 |
|
Known Fixed Releases: | 6.2(12), 6.2(12)S20, 6.2(12.4)S0 |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz43417 | Title: | mvpn qos : Discard-class classification is not working on P box |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
'discard-class' classification is not working in P router (egress qos) in MVPN setup
Conditions:
when QoS policies applied on VLAN
Workaround:
Further Problem Description:
|
|
Last Modified: | 11-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy47013 | Title: | MBGP local path is marked invalid if other path is learned from neighbor |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Routes in BGP multicast Address family not installed as per BGP best path selection / Nexus
Conditions:
Customer is setting up IPv4 BGP Multicast peering between Nexus 3k / 5k devices and we see that IBGP learned prefix is preferred over locally generated route at the IPv4 Multicast BGP table.
Workaround:
None
Further Problem Description:
Customer is setting up IPv4 BGP Multicast peering between Nexus 3k / 5k devices and we see that IBGP learned prefix is preferred over locally generated route at the IPv4 Multicast BGP table.
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 6.2(14), 7.3(0)DX(0.141) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.0(3)I3(1.4), 7.0(3)I3(2), 7.0(3)I4(0.17), 7.0(3)I4(1), 7.0(3)IBT3(2), 7.0(3)IBT3(2.5), 7.0(3)IM3(1.75), 7.0(3)IM3(2), 7.3(0)DX(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy28615 | Title: | some IPv6 prefixes not advertised to vrf-lite edge peer |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
This bug is seen for IPv6 prefixes only. This is a happens to a subset of ipv6 prefixes for for north south traffic. In some race condition where a update on a host comes very close to each other. For e.g. when a IPv6 host connects to a vPC leaf node. The border Leaf may not propagate this prefix to DC edge box. Since its a race condition it may not occur at other BL's and connectivity may still be maintained.
Conditions:
For e.g. when a IPv6 host connects to a vPC leaf node.
Workaround(s):
Deploying multiple Border leaf nodes may reduce probability of external router getting this host from at least one of the border leaf nodes
Workaround:
Clearing the Host address at leaf node may help
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.90), 7.3(0)N1(0.290) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.124), 7.3(0)DX(1), 7.3(0)TSH(0.99), 7.3(0)UCI(0.30), 7.3(1)D1(0.12), 7.3(1)FTO(0.7), 7.3(1)N1(1), 7.3(1)PIB(0.26) |
|
|
| |
| |
|
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: | 13-JUN-2016 |
|
Known Affected Releases: | 6.2(14), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S28, 7.0(0)BZ(0.108), 7.3(0)D1(1), 7.3(0)DG(0.3), 7.3(0)DX(0.88), 7.3(0)DX(1), 7.3(0)IZN(0.13), 7.3(0)N1(0.272), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz42373 | Title: | BGP Convergence on 7.2(1)D1(1) has items remaining on the new-list. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Routes can take a long time to converge in BGP
Conditions:
MPLS CSC setup with RFC3107 labels
Workaround:
None
Further Problem Description:
Routes spend a long time being processed on the New List during convergence.
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.48), 7.2(2)N1(0.435), 7.2(2)N1(1), 7.2(2)ZD(0.140), 7.2(2)ZN(0.143), 7.3(0)UCI(0.41), 7.3(1)DX(0.37), 7.3(1)FTO(0.8), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz06671 | Title: | SSTE:Per-vlan consistency check failed with ISSU + both vPC peers reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In the scale setup, the vPC consistency check failed after sequence of ISSU and reload both vPC switches
Conditions:
- ISSU from HSK2 to UPG
- Reload both vPC devices
- The switches were auto-configured in scale setup of > 1K vlans
Workaround:
Option1:
Make sure to config the vPC peer-link port-channel after all LC modules are up
Option2:
Manually recover the particular inconsistent vlan(s)
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.125), 7.3(0)DX(0.131) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(0)UCI(0.39), 7.3(1)DX(0.12), 7.3(1)FTO(0.7), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz35540 | Title: | SSTE: Reliance Sol: Label issue with BGP send label enabled on 7.2 MR |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Labels that should be present in ULIB are not present. This cascades to forwarding as well.
Conditions:
When a routing protocol allocates FEC in ULIB and a second routing protocol deletes the FEC without first allocating it, the FEC and associated local label is deleted from ULIB for both routing protocols.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.2(2)D1(0.46), 7.2(2)N1(0.433), 7.2(2)N1(1), 7.2(2)ZD(0.138), 7.2(2)ZN(0.141), 7.3(0)UCI(0.39), 7.3(1)DX(0.11), 7.3(1)FTO(0.7), 7.3(1)N1(1) |
|
|
| |
| |
|
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: | 13-JUN-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)EG(0.14), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy00151 | Title: | NVT: Crash in feature-mgr when we use show feature cli on standby RP |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Executing "show feature" command on standby supervisor causes feature manager to crash.
Symptom:
Usually "show feature" CLI command is executed on active supervisor. If executed on standby supervisor, this causes feature manager to crash.
Conditions:
This above scenario is only seen if "show feature" CLI is executed on standby.
Workaround:
Please execute "show feature" CLI command only on active supervisor.
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)UCI(0.39), 7.3(1)DX(0.33), 7.3(1)FTO(0.7), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy35651 | Title: | Removing IPSG config from one Client int, clears other entries from H/W |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Problem:
I am observing that on removal of IPSG config on one Client facing interface, the IPSG entry of the other is being removed from the hardware programming.
The issue is seen even in 6.2.12, 7.2.1.D1
RCA:
This issue is solely due to the Limitations in SAL design to hold vlan information per IPSG entry.
SAL is unable to distinguish every entry based on it vlan.
DHCP is sending "MTS_OPC_IPSG_DISABLE" event for a vlan when entry deleted is last entry for the vlan. Upon receiving "MTS_OPC_IPSG_DISABLE" event in SAL we are removing the complete table. We are assuming that there's a one to one mapping for vlan to table-id but this is not true for SVI where table id is getting allocated based on VRF. So for default VRF all entries will be under single table-id and upon receiving disable event we are deleting the table which will delete all other entries in table too
Conditions:
Removing one VLAN
Workaround:
Tis problem is seen when IPSG is removed from one interface/vlan.
As a workaround, Removing IPSG from all interface/vlan and adding only in the required interface/vlan will help us avoid this state of the issue.
Further Problem Description:
|
|
Last Modified: | 15-JUN-2016 |
|
Known Affected Releases: | 6.2(16)S32, 7.3(0)DX(0.110) |
|
Known Fixed Releases: * | 6.2(16)S51, 6.2(16)S64, 7.0(0)BZ(0.115), 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.122), 7.3(0)DX(0.133), 7.3(0)DX(0.141), 7.3(0)UCI(0.30), 7.3(1)DX(0.55) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz13307 | Title: | kgdb on udld process while peer-link shut no shut continuously |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 5500 switch running NX-OS 5.1(3)N1(1) might reload with kernel
panic.
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 543702 usecs after Wed Feb 1 03:27:24 2012
Reason: Kernel Panic
Service:
Version: 5.1(3)N1(1)
Conditions:
Observed on Nexus5K and Nexus7k as well. The UDLD link shut/noshut test was the only use case where this bug was observed on N7K platform lab test. And the submitter was not able to reproduce it. However, there are many more customer cases observed on N5K platform.
This problem could happen with a sdb (shared database) when a writer is updating the database at the same time the readers are reading it. This is a relatively corner case and would only hit if the writer is doing a batch of writes (i.e. writing more than one record at at time).
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 5.1(3)N2(1a), 5.2(4.83)S0, 6.0(4)S1, 6.1(0.280)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt97081 | Title: | 'copy run start' stuck at 98% or standby supervisor power cycling |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Two symptoms are possible. Either:
1) Copying the running config to startup fails at 98%. The following messages are logged to syslog:
%SYSMGR-STANDBY-3-CFGWRITE_REJECT: Discarding request for configuration startup-config sync: configuration action already in progress.
%SYSMGR-3-CFGWRITE_FAILED: Configuration copy failed (error-id 0x401E0000).
2) After a system switchover, the standby supervisor is continuously reset and does not reach 'ha-standby' state. The 'show system reset-reason' command shows the following reset reason for the standby supervisor:
Reason: Reset of standby by active sup due to sysmgr timeout
Conditions:
This issue may occur if a 'copy running startup' command was aborted since the last system power up or supervisor switchover.
Workaround:
Reload the switch or contact Cisco TAC for assistance to recover nondisruptively.
Further Problem Description:
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.2(0.1), 5.2(1) |
|
Known Fixed Releases: * | 5.2(1)N1(1), 5.2(2.75)S0, 5.2(2d)S11, 6.0(2)S7, 6.1(0.135)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti14264 | Title: | ARP incompletes seen with otv suppress-arp-nd on overlay interfaces |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms
When using the default otv suppress-arp-nd on overlay interfaces in the OTV
VDCs,
periods of incomplete ARPs can be seen, resulting in packet loss in one of our
data centers.
Conditions
incomplete-arps seen for nodes over the OTV-network.
Has been observed on customer network running 5.0.3
Workaround
remote otv suppress-arp-nd: 'no otv suppress-arp',
to let the ARP-requests going over the OTV-network again,
and packet loss will be solved
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 5.1(0.214)S12, 5.1(0.214)S13, 5.1(0.221)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti77845 | Title: | vpc+: hsrp reload delay is not working |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
hsrp delay reload feature doesn't work as expected.
Conditions:
This symptom may be observed when hsrp delay reload feature is enabled and then
Nexus 7000 Series Switch which is running 5.0(x) is reloaded.
Workaround(s):
none
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(1) |
|
Known Fixed Releases: * | 5.0(6.20)S0, 5.1(1)S10, 5.1(1.10)S0, 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb51142 | Title: | HSRP stuck at Waiting for hardware resource after switch reloaded |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
HSRP interfaces one one module stuck at initiatl (Waiting for hardware resource).
Conditions:
Reload the switch while the module is down.
Workaround(s):
no
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(2.2), 4.2(3), 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts27542 | Title: | Cannot clear sysmgr startup-config lock if PID is greater than 65536 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Unable to issue the command "system startup-config unlock X" when x>65536
Conditions:
NONE
Workaround:
NONE
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: * | 5.1(3)N1(1), 5.2(1)N1(1), 5.2(2.21)S0, 6.0(0.38)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj44206 | Title: | N7K/5.1.1: copy runn start aborted due to timeout |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The utaker klm queue overflows. A syslog of this format will be seen in the
supervisor's show logging output.
%KERN-2-SYSTEM_MSG: Utaker overflowed. Size -40/5242880 - kernel
Conditions:
One of the conditions when this can happen is when a large number of processes
exit/crash.
Workaround(s):
Reloading the relevant supervisor is the workaround. If the issue is seen on
the active sup, then reload the active sup. If seen on the standby sup, reload
the standby module.
Further Problem Description:
During the issue, the switch may not let the user to initiate the system failover.
N7K-A# system switchover
Failed to switch over (update of startup configuration in progress)
It is recommended to reload the specific Sup engine using:
N7K-A# reload module
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(0)MP1(0.382), 5.1(1), 5.1(1a), 5.2(0.128) |
|
Known Fixed Releases: * | 5.1(1)S48, 5.1(1.43)S0, 5.1(1.47)S0, 5.3(0.112n)S1, 6.0(0.2)S0, 6.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb18456 | Title: | Nexus Service "evms" crash when using % character in eem config |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
Nexus Service "evms" crash when using % in event manager configuration:
%SYSMGR-2-SERVICE_CRASHED: Service "evms"
Active Supervisor failover when crash happens
Conditions:
Crash happens when % is used in the event manager 'action' configuration string and when command 'sh run eem' or 'sh run | i eem' is executed
Workaround:
Do not use % character in 'action' string
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(5), 4.2(1) |
|
Known Fixed Releases: * | 4.2(1.54), 4.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr97385 | Title: | SNMP crash due in config-copy MIB due to missed heartbeats |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
SNMP can crash when using config-copy MIB.
Workaround:
None
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(4) |
|
Known Fixed Releases: * | 5.1(5)S1, 5.2(1)N1(6), 5.2(1)N1.6, 5.2(2)S12, 5.2(2.20)S0, 5.2(2.58)S0, 6.0(1)S24, 6.1(0.117)S0, 6.2(0.2)S0, 6.2(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr72438 | Title: | vrrp does not work with authentication |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VRRP groups become master-master, with text authentication enabled.
Below syslogs can be seen as well.
Jul 26 23:01:06.870 IST: %VRRP-4-BADAUTH: Bad authentication from 100.100.199.2, group 3, type 1
Conditions:
This bug is present in NXOS 5.2(1) release.
The issue happens if VRRP groups peer with non-Nexus 7000 devices with authentication enabled, and if the password configured is less than 8 characters.
There is no impact to ISSU from earlier release though even for groups with authentication enabled - the groups will continue to function post the upgrade.
Workaround:
Use authentication secret of 8 characters in length for VRRP.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.1(0.210)S0, 5.1(1), 5.2(2)S1, 5.2(2.3)S0, 6.0(0.17)S0, 7.1(0)ZN(0.284), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk94528 | Title: | OTV : Error shown on unextending vlans |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
While adding and removing VLANs from the OTV overlay interface in rapid
succession the command may not execute.
The following error messages will be displayed:
Switch(config-if-overlay)# otv extend-vlan add 2020
Processing currently extended vlans, please wait for some time and retry
your command
Or
Switch(config-if-overlay)# otv extend-vlan 1-99, 2020
Vlan 1 in delete holddown for overlay Overlay0
. No vlan in the present command will be extended
Conditions:
- Nexus 7000 running 5.1(x) using OTV
- Adding and removing extended VLAN list from the OTV interface in rapid succession
Workaround(s):
Reload OTV VDC
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(2), 5.2(0.180) |
|
Known Fixed Releases: * | 5.2(0.219)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta77486 | Title: | ISSU downgrade to 4.1.5, doesnt check for incompatible CLI's |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
User would not be able to create/delete existing NTP servers/peers.
Conditions:
While doing an ISSD from 4.2.1 to 4.1.x images the user chooses to override the incompatibility check.
Workaround(s):
Do *NOT* override the incompatibility check. Remove ntp distribution before downgrading from 4.2.1 to 4.1.x images
Before downgrade do a "show incompatibility-all system "
root@switch(config)# show incompatibility-all system bootflash:n7000-s1-dk9.4.1.5.gbin
Checking incompatible configuration(s) for vdc 'switch':
--------------------------------------------------------
The following configurations on active are incompatible with the system image
1) Service : ntp , Capability : CAP_FEATURE_NTP_CFS_DIST
Description : NTP distribution is enabled.
Capability requirement : STRICT
Disable command : no ntp distribute
If you get the above incompatibility, REMOVE ntp distribution before doing a downgrade.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(1), 4.2(1.51), 4.2(1.56), 4.2(1.57), 4.2(2), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts64738 | Title: | FP: MAC learning on broadcast |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Unicast macs are learnt in FP core switches during broadcast arp on setup having F2.
Condition:
On F2, unicast macs are learnt from broadcast arp resulting in macs being being learnt sub optimally in the mac table. Further uicast re-arp should take care of macs being removed on Fabricpath core switches.
Workaround:
None
This affects only switches having F2 lcs.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.0(0.47)S5 |
|
Known Fixed Releases: * | 6.1(0.239)S0, 6.1(0.248)S0, 6.1(0.293)S6, 6.1(0.298)S0, 6.1(1)S31, 6.1(1)S39, 6.1(1.33)S0, 6.1(1.41)S0, 6.1(1.42)S0, 6.1(2)E10 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr46317 | Title: | ntp crashed after ISSU from 5.1.3 to 5.2.1.S69 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
- %SYSMGR-2-SERVICE_CRASHED: Service "ntp" hasn't caught signal 11 (core will
be saved).
Affects 7k and 5k as well
Conditions:
-ntp logging enabled
-ISSU performed recently
Workaround:
-disable ntp logging.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(5), 5.2(1) |
|
Known Fixed Releases: * | 5.2(1)N1(5), 5.2(2.39)S0, 6.0(0.61)S0, 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf90923 | Title: | SNMPD core when port-monitor configured in non-default VDC |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | When port monitor is configured in non-default VDC snmpd may crash. The issue is not seen in default VDC.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(3.1) |
|
Known Fixed Releases: * | 4.2(5.20), 5.0(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk55859 | Title: | Duplicate tunnels created when OTV adj flapped. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms:
OTV adjacency is down while the OTV ISIS adjacent is up for the same neighbor.
Conditions:
This can be seen via the "show otv adjacency and show otv isis adjacency" commands.
show otv adj
Hostname System-ID Dest Addr Up Time State
OTV 0026.980c.5741 192.188.160.10 01:47:15 DOWN
show otv isis adj
System ID SNPA Level State Hold Time Interface
0026.980c.5741 0026.980c.5741 1 UP 00:00:28 Overlay1
Duplicate tunnels are created during a supervisor failover causing the OTV adjacency to go down. Following message maybe seen in the logs:
%TUNNEL-5-IF_STATE_UPDATE: Interface Tunnel16434 is down reason duplicate tunnel configuration can't coexist Interface Tunnel16411 also has same configuration
Workaround:
Reload of the OTV VDC.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(1) |
|
Known Fixed Releases: * | 5.1(2)S11, 5.1(2.9)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth54452 | Title: | VRRP sends invalid type 15 packet from backup with src mac of group |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VRRP may send a packet with an invalid type (type 15) from the backup peer sourced with the group's virtual mac address in some rare conditions. This may lead to all layer 2 switches on this vlan to learn this mac address on the incorrect port.
Conditions:
This condition gets triggered if a group level shut/no-shut is performed over a range of interfaces.
E.g an operation such as below :
interface vlan 1-200
vrrp 1
shut
no shut
Workaround:
The workaround is to force the VRRP group on the affected interface from backup to master by setting the priority to a higher value than the current master, allowing it to change state. Once this device is now active, set the priority back to its original value so it returns to backup status.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(2a)E1 |
|
Known Fixed Releases: * | 4.2(6)S36, 4.2(7.29)S0, 5.0(3)S46, 5.0(5)S3, 7.1(0)ZN(0.284), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq57911 | Title: | GLBP AVG redirect host to old vMAC after redirect timer expired |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
GLBP AVG keep redirecting hosts to old vMAC even after redirect timer expired
Conditions:
when configured GLBP.
Workaround:
reload Nexus
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 4.2(8)S25, 4.2(8.93)S0, 5.1(5)E1, 5.1(6)S1, 5.2(1)S30, 5.2(1.36)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl42961 | Title: | n7k/nxos: hsrp stuck in intit after reload/sso |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
HSRP groups remain in Initial state.
Conditions:
May be seen after system reload or switchover.
Workaround(s):
Reconfigure HSRP groups or perform a further switchover.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: * | 5.1(2.41)S0, 5.2(0.190)S0, 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz75327 | Title: | "show glbp group" command on nexus caused the GLBP service to crash |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
GLBP service crash when configured with millisecond timers.
GLBP active router (AVG) does not recognize the standby router (SVG) as seen through "show glbp" command.
Conditions:
When multiple GLBP groups are configured with 250 milliseconds hello and 1 second hold timer, under some scenarios GLBP process crash is observed. This is due to an internal memory leak.
Workaround:
Where possible avoid using millisecond timers for GLBP.
GLBP service though recovers gracefully from the crash, without requiring reboot of the system or switchover of supervisor module.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1.2 |
|
Known Fixed Releases: * | 4.2(0.232), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr95925 | Title: | BFD state @ groups are in unknown state after switchover |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After system switchover, BFD state shows as Unknown in 'show hsrp' output.
Conditions:
This is seen on Nexus 7000 series switches running version 5.2(1). This bug is caused by failure to sync BFD state to Standby.
Workaround(s):
None.
The problem has been fixed in 5.2(3) and 6.0(1).
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(2.27)S0, 6.0(0.57)S0, 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts08764 | Title: | N7K VDC May Fail After Forced Supervisor Switchover |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After supervisors failover in a N7K, a VDC may show as failed in the output of
'show vdc'.
N7K# show vdc
vdc_id vdc_name state mac lc
------ -------- ----- ---------- ------
2 VDC2 failed m1 f1 m1xl
Conditions:
This was seen directly after the user issued a forced switchover between
supervisors.
Workaround:
Reload the vdc in question with the "reload vdc " command
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(1), 5.2(1) |
|
Known Fixed Releases: * | 5.2(2.49)S0, 6.0(1)S12, 6.1(0.110)S0, 6.2(0.13)S0, 6.2(2), 7.0(0.91)SQ, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111), 8.3(0)CV(0.118) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk63052 | Title: | OTV: "otv-extend vlan" sh run output may display distorted output |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Show running-config may present an inconsistent or distorted output for the
command "otv vlan-extend"
Conditions:
This has been seen if you have greater then approximately 175 characters in
that command. When above this number, the command may appear inconsistent or
distorted when running "show run", which is due to the code adding extra
characters to the command. This may also cause you to run into CSCtk95728
Workaround(s):
Reduce the number of characters in your "otv extend vlan" command.
You may have to extend vlans that don't actually exist to have a shorter vlan
range but this is fine, as they will just show an "inactive" state from OTV
perspective.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(1.77), 5.1(2), 5.2(0.180) |
|
Known Fixed Releases: * | 5.2(0.187)S0, 5.2(0.255)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth54816 | Title: | N7K-Reg:Netstack crash on standby while deleting vdc |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Netstack had cored on standby supervisor, with the following bt:
#0 0xb7841910 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0xb7842e08 in *__GI_abort () at ../sysdeps/generic/abort.c:88
#2 0xb7d60d9c in active_timer_wheel_alarm (id=6 '\006', climit=0xb6571788, tlimit=0x0) at ../routing-sw/libs/timers/active_timer.c:1808
#3 0xb7d5ce50 in active_timer_service_alarm () at ../routing-sw/libs/timers/active_timer.c:535
#4 0xb7d5d4df in active_timer_signal_thread (arg=0x0) at ../routing-sw/libs/timers/active_timer.c:661
#5 0xb7d29b7d in procket_pthread_rtn (arg=0x8342e54) at ../routing-sw/libs/syswrap/procket_pthread.c:815
#6 0xb79361e8 in start_thread (arg=0xb6571bb0) at pthread_create.c:254
#7 0xb78ca72a in clone () from /tmp/sua_20120329205832/x86/lib/tls/libc.so.6
Conditions:
The type of timers adopted by netstack till 4.2.7 could not handle the time going back/fwd beyond a certain limit. All the timers were moved to a different type starting 4.2.8.
This issue is independent of VDCs and is solely dependent on the periodic +/- adjustment of clock time getting synced from active to standby.
Workaround(s):
None
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(6.31), 4.2(7.31) |
|
Known Fixed Releases: * | 4.2(7.29)S0, 4.2(7.33)S0, 4.2(7.39)S0, 7.1(0)ZD(0.16), 7.1(0)ZD(0.23), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq79432 | Title: | Static Route needs to be configured after setup script in Storage VDC |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On the storage VDC of the switch, the default gateway and the IP address of the switch may not be reachable if it is configured using the setup script.
Conditions:
This problem can happen when using the setup script for configuring the default gateway and IP address. The default gateway and IP address should be configured in the "default" vrf manually.
Workaround(s):
Re-configure the default-gateway and IP address in the "default" vrf.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(2.32)S0, 6.0(0.54)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf75031 | Title: | HSRP groups in init state after net restart |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
HSRP groups remain in Initial state.
Conditions:
May be seen after a restart of the netstack process.
Workaround(s):
Reconfigure HSRP groups or perform a further switchover.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(2) |
|
Known Fixed Releases: * | 4.2(8)S23, 4.2(8.89)S0, 5.0(2), 5.0(2.42), 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg94800 | Title: | HSRP: 'no ip <vip>' does not remove the vip and has no effect |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
"no ip secondary" does not remove the secondary
VIP in the group.
Conditions:
Primary VIP can be removed with command "no ip"
but secondary addresses can not removed, once configured,
using "no ip" command.
Workaround(s):
Need to remove the group and re-add the group along with other paramters.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(2) |
|
Known Fixed Releases: * | 5.0(3)S7, 5.0(3.13)S0, 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta50173 | Title: | ECMP routing is not done for intra-area routes |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
OSPFv3 does not install ECMP routes for intra-area prefixes
Conditions:
When an intra-area prefix is advertised by two or more sources, OSPFv3 installs only one route amongst them in the RIB.
Workaround(s):
Currently there is no workaround.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(1.44), 4.2(1.57), 4.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh42629 | Title: | CSCuh42629SNMPd crashed in idle state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
snmpd crashes on Nexus switch resulting in supervisor crash
Conditions:
Errors:
%SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID ) hasn't caught signal 11
(core will be saved).
Workaround:
Seen when polling OSPF MIBs on Nexus switches. Crash is random and not related to the amount of time spent polling the device, or a specific OSPF MIB under OID 1.3.6.1.2.1.14.4.1.8
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.2(1.125)S6 |
|
Known Fixed Releases: * | 5.2(1)N1(7.99), 5.2(1)N1(8), 6.0(2)N3(0.73), 6.0(2)N3(1), 6.0(2)U3(0.650), 6.0(2)U3(1), 6.2(1.136)S6, 6.2(1.141)S0, 6.2(2), 7.0(0)N1(0.385) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr52593 | Title: | tie-breaker for ieigrp and ibgp admin distance broken |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
We have two protocols adding the same route - i.e. ospf and rip.
The admin distance of rip is configured to be the same of that as ospf. If the metric for the rip route is better than the ospf route, the rip route will win (which is incorrect behavior).
Conditions:
This issue occurs when two protocols are configured to have the same admin distance. If rip and ospf are configured to have the same admin distance then the code is currently choosing the route with the lower metric. Because metrics do not have any meaning across protocols and only within a protocol this does not make sense - we should be choosing the route found by the protocol with the lower default admin distance in this scenario.
Workaround:
Configure the protocol that should be winning to have a lower admin distance - do not configure both protocols to have the same value. This workaround should always avoid the aforementioned scenario.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(2)S15, 5.2(2.12)S0, 6.0(0.23)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj69147 | Title: | FEX: QoS with ACL match applied to multiple fex ports fails unpush |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Removal of a port from a port channel for a FEX uplink causes QOS policies to be improperly applied on FEX ports.
Conditions:
A QOS policy is applied on a FEX satellite port. The FEX uplinks from the FEX are linked to multiple linecards.
Workaround(s):
Remove QOS policies before removing port from port channel, then reapply the policies afterwards.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(1)S48 |
|
Known Fixed Releases: * | 5.1(1.46)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj99284 | Title: | N7K crashing at ../routing-sw/routing/netstack/netstack_main.c:591 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:Nexus 7000 will continually crash at netstack and reload. The output of show cores will be
N7k# sh cores
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- --------
-------------------------
1 5 1 netstack 4016 2010-11-04 14:27:51
Conditions:Version 5.1(1)
Workaround:If a pair of nexus 7000 alternate crashing and reloading, either disabling one will stop the issue or downgrading to 4.2(6)
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(0.1) |
|
Known Fixed Releases: * | 5.1(1.64)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
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: | 01-JUN-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)DX(1), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy57603 | Title: | Wrong return value for MACAddress and SystemID in IEEE8023-LAG-MIB |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Return value for MACAddress and SystemID from lagMIB at NX-OS is wrong as follows: XX-XX-XX-XX-XX-XX.
Conditions:
Retreive following MIB OID
IEEE8023-LAG-MIB::dot3adAggMACAddress
IEEE8023-LAG-MIB::dot3adAggActorSystemID
IEEE8023-LAG-MIB::dot3adAggPartnerSystemID
Workaround:
No workaround.
Translate retrurn value to characters format as follows: XX-XX-XX-XX-XX-XX.
Further Problem Description:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.1(2)E5, 6.2(14), 7.3(0)D1(1), 7.3(0)DX(0.102) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.114), 7.3(0)DX(0.120), 7.3(0)DX(0.127), 7.3(0)DX(1), 7.3(0)TSH(0.99), 7.3(0)UCI(0.30), 7.3(1)D1(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut36702 | Title: | F3 / 4-Way HSRP / VMAC Programmed To sup-eth31 On Listen Members |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
HSRP vmac programmed to sup-eth or emulated SWID of vPC peers on routers in HSRP Listen state
Conditions:
vPC peers in listen state due to 4-way HSRP and `no port-channel limit` enabled under vPC domain.
Workaround:
enable port-channel limit under vPC domain
Further Problem Description:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(10), 7.3(0)D1(1), 7.3(0)DX(0.66) |
|
Known Fixed Releases: * | 7.3(0)DX(0.78), 7.3(0)DX(1), 7.3(0)TSH(0.99), 7.3(1)D1(0.12), 7.3(1)PDB(0.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux31915 | Title: | N7K:vsh crash on Linecard while collecting tacpac |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On N7K Linecard , vsh process crashed while collecting tacpac
Following error logged at that time.
%SYSMGR-SLOT4-2-LAST_CORE_BASIC_TRACE: : PID 10147 with message vsh(non-sysmgr) crashed, core will be saved
Conditions:
Nexus7000
NXOS6.2(10)
Workaround:
Further Problem Description:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(10), 7.3(0)DX(0.73) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DG(0.3), 7.3(0)DX(0.83), 7.3(0)DX(1), 7.3(0)UCI(0.5), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux77234 | Title: | F3 packets are flooded for 2-3 sec during receiving gratuitous arp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Packets are flooded for 2-3 seconds during receiving gratuitous arp.
Conditions:
Nexus 7700 series with F3 line cards. This symptom seen on both NX-OS release 6.2(14) and 7.2(1)D1(1).
Port where traffic is received and gratuitous arp is received are located on different SoC.
Workaround:
Not available at this moment.
Further Problem Description:
Root cause is identified and solution is provided in further software releases.
Fix is to change internal timer for quicker processing.
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(14), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.103), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux80178 | Title: | SSTE: Error for ISIS topology changes during ISSU for BD Flood prog |
|
Status: | Fixed |
|
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: | 01-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.194) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DG(0.3), 7.3(0)DX(0.87), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux49719 | Title: | pam_aaa_motd:cannot open motd file : /vdc_4/etc/motd - dcos_sshd |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
when we do switchto vdc , PAM infra tries to read motd file specific to VDC .
However exec banner as a feature is specific to the box/device but not to vdc . This is vdc unaware file .
This is not an issue with respect to motd . so we can ignore this message.
it is not a harmful msg
Conditions:
This issue will be seen during switchto vdc
Workaround:
it will be seen in the console if logging level of the console is set to error level & above.
workaround:
1.logging level console 2
2 .if customer is not happy with changing the logging level to 2, then we can ignore this msg.
Further Problem Description:
when we do switchto vdc , PAM infra tries to read /etc/motd file specific to VDC .
However exec banner as a feature is specific to the box but not to vdc . This is vdc unaware file .
This is not an issue with respect to motd . so we can ignore this message.
it is not a harmful msg for the customers .
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.172), 7.3(0)D1(0.179), 7.3(0)DX(0.110), 7.3(0)DX(0.87) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.120), 7.3(0)DX(1), 7.3(0)UCI(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy68552 | Title: | M2-100 : type is not displayed on CFP-100G-ER4 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
CFP-100G-ER4 was not displayed properly in CLI "show interface transceiver".
Conditions:
When the transceiver is CFP-100G-ER4.
Workaround:
Check the value in "cisco product id is" from the same command.
Further Problem Description:
Problem exists only in 7.2(0)D1(1) and 7.3(0)D1(1) releases.
Fixes had been integrated into 7.3(0)DX(1) and later releases.
Problem does not exists in 6.2 releases.
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(1), 7.3(0)DX(0.110) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.115), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)D1(0.17) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux35766 | Title: | Incorrect power mode w supplies are shutdown on N7k PS-Redundant config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Incorrect power mode is indicated as Non-Redundant for ps redundant mode while having enough power for the chassis and modules
Conditions:
- Configured with ps redundant mode
switch(config)# power redundancy-mode ps-redundant
- Present with shutdown power supplies.
10 N77-AC-3KW 706 W 3000 W Ok
11 N77-AC-3KW 706 W 3000 W Ok
12 N77-AC-3KW 0 W 0 W Shutdown
13 N77-AC-3KW 701 W 3000 W Ok
14 N77-AC-3KW 703 W 3000 W Ok
15 N77-AC-3KW 705 W 3000 W Ok
16 N77-AC-3KW 0 W 0 W Shutdown
Workaround:
Physically remove the shutdown power supplies from the chassis
Further Problem Description:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)DG(0.3), 7.3(0)DX(0.88), 7.3(0)DX(1), 7.3(0)UCI(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy90969 | Title: | N7K Eompls decap uses wrong MTU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
EoMPLS packets with size more than MTU of the interface - 26 bytes are dropped on the egress interface of decap.
Conditions:
- This happens when packet size is more than 26 short of the MTU of the interafce
- Smaller packets does not have any issues.
- F3 Linecards are used
- Seen in 7.2(1)D1(1)
Workaround:
Increase the MTU on the egress interface of decap with original size + 26 bytes
Further Problem Description:
If the interface MTU is 1500, packets bigger than 1474 were getting dropped. Ideally packets bigger than 1500 bytes only should be dropped.
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(0.133), 7.3(0)DX(0.145), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy51899 | Title: | default logging level mvrp 2 shown with show run |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Observed logging level mvrp 2 popped in show run
Conditions:
mvrp feature enabled
Workaround:
Further Problem Description:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(14)S9 |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.111), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy16984 | Title: | 'otm' core on N7K running 7.3_D1_S12 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When "show track" CLI is issued, there is a possibility that OTM might crash.
Conditions:
Some track objects are configured and at least one client like HSRP is tracking it.
Workaround:
Instead of running "show track", we can retrieve each object track info using CLI "show tack <1-500>"
Further Problem Description:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.0(3)I4(0.64), 7.0(3)I4(1), 7.3(0)DG(0.3), 7.3(0)DX(0.94), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq14012 | Title: | MFIB stops updating multicast hardware hit counters |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:MFIB (Multicast forwarding information base) stops updating statistics for multicast routes. As a results, the S,G corresponding to the multicast route times out. Users will see the multicast route constantly timing out and being rebuilt.
Checking MRIB (multicast routing information base) statistics will always show zero hits against the multicast route:
n77a-core1# show forwarding multicast route source 10.2.1.2 group 239.1.1.1 module 9
(10.2.1.2/32, 239.1.1.1/32), RPF Interface: Vlan2, flags:
Received Packets: 0 Bytes: 0
Number of Outgoing Interfaces: 1
Outgoing Interface List Index: 1
Vlan3 Outgoing Packets:0 Bytes:0 <---- counts are always zero
Conditions:This has been observed under the following sequence of steps:
1) New module added to a chassis (all interfaces unallocated)
2) Perform ISSU
3) After ISSU, allocate interfaces to VDC. At this point, multicast statistics for traffic hitting the forwarding engine for the newly allocated interface will not increment
Workaround:Reload the affected module will clear the issue.
More Info:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S42, 7.1(0)D1(0.232), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.170), 7.2(0)D1(1), 7.3(0)DX(0.96), 7.3(0)DX(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy47125 | Title: | cshcNetflowResourceUsageTable return incorrect values in SNMP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Object cshcNetflowResourceUsageTable from CISCO-SWITCH-HARDWARE-CAPACITY-MIB returns incorrect values for Netflow utilization.
Conditions:
None.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.124), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz11696 | Title: | ISSU during upgrade process, removal of SFP is not recognized |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After ISSU is completed, the port which has no SFP inserted still shows as "connected". Although DOM and SPROM values are empty, the switch port still sees the SFP details of the removed SFP (show int ethx transceiver details).
The peer port has the correct "notconnected" state
Conditions:
Issue only appears when you remove of a SFP during the module upgrading phase of ISSU.
Workaround:
Shut the affected port, plug the SFP back in, then "no shut" the port.
SFP status of affected port and peer port will be corrected.
Further Problem Description:
|
|
Last Modified: | 02-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.141) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)UCI(0.39), 7.3(1)DX(0.3), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuj58342 | Title: | type7 to 5 translation not happening in NSSA ABR |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
NSSA ABR does not translate type-7 LSAs into type-5 LSAs
Conditions:
If there are internal ASBRs with router-ids higher than the NSSA ABR, then the NSSA ABR does not translate type-7 LSAs into type-5 LSAs
Workaround:
None
Further Problem Description:
..
|
|
Last Modified: | 03-JUN-2016 |
|
Known Affected Releases: | 6.2(2)S36 |
|
Known Fixed Releases: | 6.0(2)N3(1), 6.2(5)BF(0.22), 6.2(5.42)S0, 6.2(6), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)ZD(0.120), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.1(0)ZD(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui49066 | Title: | N7K: Storm Control syslog is not getting generated on M2 module |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
N7K-M224XP-23L doesn't generate syslog for storm-control even if the suppress counter increased.
The following messages should be generated.
%ETHPORT-5-STORM_CONTROL_ABOVE_THRESHOLD
%ETHPORT-5-STORM_CONTROL_BELOW_THRESHOLD
Conditions:
TotalSuppDiscards are definitely increased but no syslog won't be generated.
N7K-B# sh int e10/1 counters storm-control
--------------------------------------------------------------------------------
Port UcastSupp % McastSupp % BcastSupp % TotalSuppDiscards
--------------------------------------------------------------------------------
Eth10/1 0.01 0.01 0.01 501141713
N7K-B#
N7K-B# sh run int e10/1
!Command: show running-config interface Ethernet10/1
!Time: Tue Aug 6 09:10:14 2013
version 6.1(4)
interface Ethernet10/1
switchport
switchport access vlan 3
storm-control broadcast level 0.01
storm-control multicast level 0.01
storm-control unicast level 0.01
Workaround:
The actual functionality is not affected. Excessive traffic will be dropped in case of violation.
Further Problem Description:
|
|
Last Modified: | 06-JUN-2016 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | 7.3(1)DX(0.46) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux46318 | Title: | Unable to modify the config profile template after no feature ipp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
when the feature ipp is attempted to be turned off, ppm is crashing.
Conditions:
When the feature ipp is turned on the system and tenants are configured onto the switch, if this feature is attempted to be turned off then we see that ppm process is not able to clean up the profiles and its param list which are applied. this might be because the ipp process exists before the ppm cleans up the profile applied on the switch.
Workaround:
I think currently ipp process needs to wait before the process exits till the ppm clears of the profiles.
Further Problem Description:
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.117) |
|
Known Fixed Releases: * | 7.3(1)DX(0.49) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy99477 | Title: | Change metrictype of redistributed routes from MPBGP-OSPF from E2 to E1 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Ability to override default behavior of advertising the redistributed routes from MP BGP->OSPF from E2 to E1 using a route map on receiving PE.
Conditions:
Using MP BGP and different OSPF domains.
Workaround:
None, this is expected behavior as per RFC
Further Problem Description:
In a MP-BGP setup, when redistributing External OSPF routes ->BGP on PE1, PE2 gets these routes in MP-BGP and redistributes the same in OSPF to CE2. Domain IDs are different in this case & as per RFC 4577, the route is seen as E2 on CE2 device.
CE1--PE1--Provider--PE2--CE2
Customer would like the ability to change the metric-type on PE2 from E2 (default) to E1 by using a route-map on PE2.
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 8.3(0)CV(0.426), 8.3(0)MVA(0.11) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy62745 | Title: | Master Bug to port fix for 2348 Issues from N5k to N7k,N9k |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Master Bug to port fix for 2348 Issues from N5k to N7k,N9k
Conditions:
Issues seen on Nexus 2348UPQ platform which need to be fixed on other Nexus platforms
Workaround:
Further Problem Description:
|
|
Last Modified: | 11-JUN-2016 |
|
Known Affected Releases: | 6.2(14)S1, 6.2(16)S9 |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(0)FXK(0.26), 7.3(0)FXK(0.27), 7.3(0)FXK(0.28), 7.3(0)UCI(0.39), 7.3(0)UCI(0.41), 7.3(1)DX(0.2), 7.3(1)DX(0.41), 7.3(1)DX(0.51) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva04628 | Title: | N7K:MAC does not age out on F2E module of a FP spine switch |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
MAC does not age out on F2E module of a FP spine switch
Conditions:
Unknown
Workaround:
clear mac with a cli command
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy47121 | Title: | SSTE: LISP Process crash during continuous process restart |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LISP process crashes after continuously manually restarting lisp from CLI.
Conditions:
LISP is continuously restarted manually via CLI "process restart lisp" during bringup.
Workaround:
None. Not deterministic.
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 6.2(16)S38, 7.3(0)DX(0.102) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.121), 7.3(0)DX(1), 7.3(1)FTO(0.7), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut94652 | Title: | Adding basic show commands to feature show techs (N7K) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
some commands are missing in feature show tech which causes BDB/BORG data analysis automation to fail
Conditions:
all
Workaround:
na
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 8.3(0)CV(0.454), 8.3(0)MVA(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut41525 | Title: | Rx span not happening with vlan as source |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When 2 vlans are configured as rx sources in a span session. the rx span from one of the vlans does not reach the destination port, debugged with asiic and driver team (vinay ) as a bad vqi, which is programmed in the span copy, due to DE_bypass bit set in the asiic span_SCT register.
Conditions:
When 2 vlans are configured as rx sources in a span session. the rx span from one of the vlans does not reach the destination port, debugged with asiic and driver team (vinay ) as a bad vqi, which is programmed in the span copy, due to DE_bypass bit set in the asiic span_SCT register.
Workaround:
no workaround
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 7.0(0)HSK(0.373) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.381), 7.3(0)DX(0.4), 7.3(0)DX(1), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4), 7.3(1)FTO(0.7), 8.3(0)CV(0.436), 8.3(0)MVA(0.14) |
|
|
| |
| |
|
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: | 13-JUN-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)EG(0.14), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz98928 | Title: | NX-OS: pipe not recognized as special character by 'exclude' cli filter |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
when 'exclude' cli filter is used with pipe("|") special character, pipe is not treated as logical "OR", but rather as part of the pattern to match
For example, in the output below, neither lines with 'licenses' nor with 'Cisco' patterns are excluded, as parser is looking for match against 'licenses|Cisco' pattern
switch# show version | exclude licenses|Cisco
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_series_home.html
Copyright (c) 2002-2015, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
...
Conditions:
NX-OS version
Workaround:
use 'egrep -v' cli filter with pipe("|") instead of 'exclude' cli filter
Further Problem Description:
|
|
Last Modified: | 13-JUN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.0(3)IED5(0), 7.0(3)IED5(0.111), 7.0(3)IED5(0.112), 7.3(1)DX(0.50), 8.3(0)CV(0.501) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz18325 | Title: | Outage may be observed during vPC recovery |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a vPC environment, when the vPC domain on the vPC primary (or operational secondary) is reloaded, the STP state of the vlans on the peer-link may remain in blocking state until the delay-restore timer expires.
This results in the vlan remaining in Vlan/BD down status.
Conditions:
This issue is observed when all of the following conditions are true:
- peer-switch is configured on the device
- There are no orphan trunk ports carrying the vlan.
Workaround:
Remove peer-switch from the vPC pair or add an orphan trunk port carrying the vlans.
Further Problem Description:
|
|
Last Modified: | 15-JUN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 8.3(0)SPC(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx21848 | Title: | "fatal: no hostkey alg - sshd" message is logged |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
The following message could be seen on Nexus while a client is trying to connect via ssh.
%DAEMON-2-SYSTEM_MSG: fatal: no hostkey alg - sshd[29261]
Conditions:
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 15-JUN-2016 |
|
Known Affected Releases: | 5.1(0.1), 5.2(3.41)S0, 5.2(4), 6.1(0.174)S1 |
|
Known Fixed Releases: | 6.1(0.237)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti73121 | Title: | N7K: VRRP crash when collecting' show run' |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The vrrp_engine process may restart when a periodic "show running vrrp" or "show running" is issued.
Conditions:
The issue is due to a memory leak in the vrrp_engine process of VRRP service. The problem is self-correcting - when the memory leak exceeds thresholds, the process restarts and recovers gracefully.
Workaround:
There is no workaround known at this time.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(4)E1 |
|
Known Fixed Releases: * | 4.2(7.73)S0, 5.0(5)S3, 5.1(1)S10, 5.1(1.10)S0, 7.1(0)BF(0.47), 7.1(0)ZD(0.129), 7.1(0)ZN(0.284), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc52051 | Title: | N7K: Rollback fails with callhome alert-group command |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Rollback fails with an error message below.
========================================================
`conf t`
`callhome`
`no alert-group Configuration user-def-cmd show ver`
error : this cli command is not configured for this alert group
========================================================
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(2a) |
|
Known Fixed Releases: * | 5.1(0.221)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCte57721 | Title: | EEM SNMP event gets published continuously |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When using SNMP EEM event publishing using OIDs, the event gets published constantly causing
the actions to be triggered constantly
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(4), 4.2(4.16), 4.2(5), 5.2(1)S35, 5.2(1.42)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta32989 | Title: | SNMP-ACL:v6 SNMP req not permitted when object groups do not pre-exist |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If the ACL applied to snmp community has and object group (address/port) that
does not pre-exist, and snmp query is filtered against this ACL, it would not be
permitted.
Conditions:
entry object group, either address or port, is configured in ACL
Workaround(s):
Use object groups in defining ACL that are already predefined.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(1.24), 4.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc20038 | Title: | hsrp_engine process restarts when reload timer triggers on listen router |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom :
hsrp_engine process restarts
Description :
hsrp_engine process may restart in rare conditions when "reload timer" is configured, and gets triggered. This typically happens when a Nx7000 is brought up with HSRP in startup-config, or an interface with HSRP configuration is enabled (through no shut) after a reload.
This condition will happen only if the HSRP group reaches the "listen" state, and the configured reload delay timer gets triggered in this state.
Workaround:
HSRP service restarts and continues as normal, no workaround required.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(2) |
|
Known Fixed Releases: * | 4.2(2.39), 4.2(3), 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt37820 | Title: | cseSysCPUUtilization from cisco-system-ext-mib is not correct |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: CPU utilization from the MIB is not correct.
Conditions: snmp get on SNMPv2-SMI::enterprises.9.9.305.1.1.1.0
Workaround: none
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(1)N1(1), 5.2(2.66)S0, 6.0(2)S7, 6.1(0.125)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto24460 | Title: | undefined symbol error when executing tclsh from scheduler job |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
You will see unresolved symbol error when a scheduled job is about to trigger, causing failures.
Conditions:
When user configures a job in scheduler in versions greater thatn 5.0
Workaround(s):
None.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(1) |
|
Known Fixed Releases: * | 5.2(0.267)S0, 5.2(0.271)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz63576 | Title: | glbp vmac still points to inband after external forwarder recovery |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom
On N7000 platforms, under certain timing conditions, the GLBP VMAC is not programmed correctly in hardware. This means that in some cases the packet could forwarded as L3 instead of L2 switched because of gateway mac setting turned on/off incorrectly.
Condition
The GLBP and MAC address tables can get out of sync due to a timing issue in the GLBP forwarder VMAC programming logic. This happens when there are multiple changes in the GLBP forwarder state within a short span of time. The error condition can be observed through the "show glbp" and "show mac address-table" command where a Listen forwarder may have Gateway bit set.
Workaround
The condition can be temporarily fixed by performing a "shutdown" and "no shutdown" on the GLBP links so that the error state gets cleared. A software upgrade for the fix is recommended though to mitigate this error permanently.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(5) |
|
Known Fixed Releases: * | 4.2(0.221), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt44813 | Title: | GLBP configuration missing on non-ISSU upgrade from 5.0(2) to 5.1(5) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On upgrade from 5.0(2a) release to 5.1(x), show running does not display GLBP related configurations in 'show running'. 'show startup' has the correct information.
Impact:
There is no functional impact to the system, it is only a display issue with 'show running' for GLBP.
Conditions:
Upgrade from 5.0(2a) release to 5.1(x).
Workaround:
This issue is seen when you have GLBP secondary configured on one of the interfaces.
Eg:
If you have have vlan 1 to 100 configured, and vlan 25 has GLBP secondary configured,
'show run' will not display the GLBP parameters for vlan 1 through 25, for vlan 26 through 100 will show the GLBP configuration correctly.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(5) |
|
Known Fixed Releases: * | 5.1(5)E1, 5.1(6)S1, 5.2(2.65)S0, 6.0(1)S33, 6.1(0.125)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb05399 | Title: | HSRP: (Lower threshold touched) tag added after ISSU 4.0.4 -> 4.2.1.S36 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
Unable to ping the VIP of HSRP from Standby.
Conditions:
Occurs after an upgrade with ISSU
Workaround(s):
The workaround is to remove the hsrp group configurations from the
interface and re-apply them.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(1), 4.2(1.46), 4.2(2), 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
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: | 16-JUN-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), 6.2(16)S18, 7.0(3)FP(0.1), 7.0(3)I3(0.163), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn90224 | Title: | show scheduler internal mem-stats causes scheduler crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
enter show scheduler internal mem-stats may cause process scheduler crash.
Conditions:
the problem is first seen in 5.1(2)
Workaround:
None
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: * | 5.2(0.248)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsr28813 | Title: | CLI "snmp-server enable traps" doesnt enable STP related traps. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The following five traps in CLI "show snmp trap" can not be enabled/disabled by CLI "[no] snmp-server enable traps".
bridge topologychange
bridge newroot
stpx inconsistency
stpx loop-inconsistency
stpx root-inconsistency
Conditions:
Using CLI "[no] snmp-server enable traps" to enable/disable all traps.
Workaround:
Enable affected traps individually.
Further Problem Description:
Fixes had been integrated into 5.1(1) and later releases.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(1.67), 5.0(5), 5.1(0.172) |
|
Known Fixed Releases: * | 5.1(0.216)S0, 5.1(0.217)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta06211 | Title: | SNMP-Trap infra: cNotifCtrlTable shows no entries for bridge MIB/STP tra |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
cNotifCtrlTable in CISCO-NOTIFICATION-CONTROL-MIB does not have the following traps:
BRIDGE-MIB
newRoot
topologyChange
CISCO-STP-EXTENSIONS-MIB
stpxInconsistencyUpdate
stpxRootInconsistencyUpdate
stpxLoopInconsistencyUpdate
Conditions:
SNMP walk agaist cNotifCtrlTable in CISCO-NOTIFICATION-CONTROL-MIB
Workaround:
No workaround.
Further Problem Description:
Fixes had integrated into NX-OS Software release 5.1(1) and later releases.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(0.232), 4.2(0.239), 5.0(2), 5.0(2.23), 5.0(2.42), 5.1(0.68) |
|
Known Fixed Releases: * | 5.1(0.146)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt22781 | Title: | hsrp failover took 25 seconds, but traffic lost only sub-second. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After a group takes over as Active by preempting an active group, the prev-active group takes more time than expected (upto 3x of hold instead of 2x of hold). It will be either in Listen or Speak state.
Conditions:
This bug is seen only when when preemption kicks in. The bug delays "ONLY" standby election. But Active election is fine and hence the forwarding. So we can say that there is no traffic impact at all due to this bug. Timer was not reset properly just around when group got preempted.
Workaround:
There are no workarounds. There is no functional impact as there is no traffic loss. Configuring least hold time value might make convergence faster compared to <3,10> but it depends on how many groups are there in the system.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.2(2.60), 6.0(1)S12 |
|
Known Fixed Releases: * | 5.2(2.82)S0, 6.0(2)S23, 6.1(0.141)S0, 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz82038 | Title: | NTP issue - same as CSCts39876, logged at N7K request |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:Placeholder defect for other similar issue
Conditions: See headline for details and other defect
Workaround: not applicable
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(3.7) |
|
Known Fixed Releases: * | 5.2(6)S0, 5.2(7), 6.0(2)N2(1), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq98904 | Title: | Memory leak in sysmgr on standby Nexus 7000 supervisor upon VDC reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptoms
High memory utilization may be observed under the sysmgr process.
Conditions
This issue is seen when there have been a lot of vdc reloads on the standby
prior to a switchover.
Workaround
Performing a switchover on the device will release the leaked memory.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 4.2(8)S21, 4.2(8.82)S0, 5.1(5)S2, 5.2(1)S52, 5.2(1.51)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr63517 | Title: | GLBP Crash due to MTS leak with show glbp capabilities |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
GLBP process crash after entering "show glbp capabilities"
%SYSMGR-2-SERVICE_CRASHED: Service "glbp" (PID 3908) hasn't caught signal 6 (core will be saved).
Conditions:
N7K running 5.1(2) or 5.1(4)
Workaround:
Avoid using 'capabilities' command
Convert to HSRP or VRRP
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(2), 5.1(4) |
|
Known Fixed Releases: * | 5.1(5)E1, 5.1(6)S1, 5.2(2)S7, 5.2(2.7)S0, 6.0(0.17)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto75014 | Title: | MD5 type-7 key-string not compatible between NxOS and IOS |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
HSRPv2 authentication failure between NxOS and IOS router
Conditions:
HSRPv2 configured with md5 type-7 encrypted string on the nexus device.
Authenticates Successfully
NxOS: authentication md5 key-string rainyday
IOS: standby authentication md5 key-string rainyday
Authenticates Successfully
NxOS: authentication md5 key-string rainyday
IOS: standby authentication md5 key-string 7 0101070D5512020E38
Authentication Failure
NxOS: authentication md5 key-string 7 0101070D5512020E38
IOS: standby authentication md5 key-string rainyday
Authentication Failure
NxOS: authentication md5 key-string 7 0101070D5512020E38
IOS: standby authentication md5 key-string 7 0101070D5512020E38
Workaround:
Use a type-0 key on the Nexus
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.2(1)S16, 5.2(1.19)S0, 7.0(1)ZD(0.3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq38302 | Title: | Need action on ASIC Fatal error |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | When ASIC fatal error happens, we have EEM event to reset ASIC to recover from the condition, and log the information to persistant (OBFL) log and exception log. However, if the fatal error is persistent, we would continue trying to reset the the ASIC to recover, which may not be desirable.
This caveat is filed to better handle persisten ASIC fatal error.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.1(6)S1, 5.1(6)S4, 5.2(1)S28, 5.2(1)S30, 5.2(1)S32, 5.2(1.33)S0, 5.2(1.35)S0, 5.2(1.37)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn67511 | Title: | GLBP core after configuring secondary vip |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
GLBP process may restart, when GLBP secondary is configured,
and a 'show running glbp' is executed.
Workaround:
Removing GLBP secondary is one workaround.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(2a), 5.2(0.222) |
|
Known Fixed Releases: * | 5.1(10.1)S0, 5.1(5)E1, 5.1(6)S1, 5.2(0.236)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd86912 | Title: | HSRP filling up root file sytstem |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
VDC creation fails. System root partition gets full. This can be viewed using
show system internal flash
Mount-on 1K-blocks Used Available Use% Filesystem
/ 409600 409600 0 100 /dev/root
Conditions:
This happens when HSRP feature is enabled, and generation of HSRP traps is enabled, or HSRP MIB objects are constantly polled.
Workaround:
Avoid polling HSRP MIB objects in release prior to 4.2(3).
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(1a), 4.2(3) |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.48), 4.2(4), 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd86169 | Title: | NTP: poll interval never is greater than 64 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Maximum NTP poll interval was 64. This value was chosen keeping time stamping
in mind. With this defect, a cli option has been provided to allow the user to
configure the maximum and minimum poll interval values, still keeping the
default to be 64.
ntp server [ prefer | key | use-vrf | minpoll
| maxpoll ]
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(0.285) |
|
Known Fixed Releases: * | 5.0(1.14), 5.0(2), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf17673 | Title: | NxOS no write access to scripts directory |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The default directory for custom python scripts is bootflash:/scripts/. The following error is seen when attempting to copying a file to this directory:
Error: could not open temporary file /bootflash/scripts/test.py (errno=13)
Conditions:
Workaround:
Customers who require write access to /bootflash/scripts/ can contact TAC to load a dplugin to manually change the write access to this directory.
Further Problem Description:
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: * | 6.0(2)N3(0.330), 6.0(2)N3(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsx59419 | Title: | Memory leak with ACLLOG @ libavl.so |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Increase of memory usage by acllog as can be seen from "show logging ip access-list internal mem-stats detail".
Conditions: Large amount of traffic flowing through the system continuously.
Workaround: None.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(3) |
|
Known Fixed Releases: * | 4.2(0.156), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz58822 | Title: | ELTMC crash when running 'show tech detail' |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Nexus 7000 switch running 6.2(12) could experience a segmentation fault (Signal 11) crash in the ELTMC process when running 'show tech detail':
%SYSMGR-SLOT8-2-SERVICE_CRASHED: Service "eltmc" (PID 2176) hasn't caught signal 11 (core will be saved).
Conditions:
Running 'show tech detail' on a switch running 6.2(12). Exact conditions still under investigation.
After un-allocating the default VDC ports from the LC, any flap on port-channel leads Linecard process to be vulnerable to this problem.
After this condition, 'show tech detail' or 'show tech eltm' can cause this.
Workaround:
Avoid running 'show tech detail' and 'show tech eltm' on the affected switch.
Reloading the affected linecard will also prevent this error from occurring again.
Further Problem Description:
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)UCI(0.41), 7.3(1)DX(0.38), 7.3(1)FTO(0.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsv52712 | Title: | NTP caches VRF id in PSS on Nexus 7k Platform |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptoms:
Message of this type appears ~ 1 minute on Nexus 7k running 4.0(3E1) running NTP.
%NETSTACK-3-IP_INTERNAL_ERROR: netstack [4100]
Failed to get IP VRF while forwarding packet received on (null) (VRF-id 5)
Conditions: VRF which was being used for NTP is deleted.
Workaround: Remove the NTP config and re-add it.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.0(4) |
|
Known Fixed Releases: * | 4.1(2), 4.1(3), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz11521 | Title: | GLBP: Election doesnt go thru when vrf membership is changed. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
GLBP protocol does not work correctly if GLBP is configured on non-default VRF interface before the VRF context is configured.
Conditions:
This issue is observed on Nexus 7000 series running version 4.0 and above.
Workaround::
The work around is to configure the VRF context before configuring VRF membership and GLBP on an interface.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(4) |
|
Known Fixed Releases: * | 4.2(0.203), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc76350 | Title: | unmounted logflash cannot be checked with system health check |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | When logflash is not mounted it cannot be checked with
system health check logflash
As a workaround try to physically remove/reinsert logflash, if this doesn't help logflash can be reformatted with 'format logflash:' Note, formatting will erase all data of logflash
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(2) |
|
Known Fixed Releases: * | 5.0(0.250), 5.0(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf24829 | Title: | Editing NTP authentication key removes trusted key config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Editing NTP authentication key removes trusted key config
Conditions:
ntp trusted key is removed, when we reconfigure the ntp authentication-key
Workaround:
reconfigure the ntp trusted key after editing ntp-authentication-key
Further Problem Description:
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N2(0.46) |
|
Known Fixed Releases: * | 6.0(2)N2(1), 6.1(4.97)S0, 6.1(5), 6.1(5.1)S0, 6.2(10), 6.2(10)CM(0.31), 6.2(11)FM(0.7), 6.2(8)TS(0.28), 6.2(9.4)S0, 7.1(0)ZN(0.231) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo63287 | Title: | Nexus 7000 Packet leaks between VDC |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Packets may leak between VDC
Conditions:
Have a linecard in the admin VDC and configure some port channels. Have another linecard not used always in admin VDC. Allocate every interface from the second linecard to another VDC.
Allocation must be done for all ports at once, not for some port groups at a time.
Workaround:
reload the linecard
Further Problem Description:
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.2(6a), 6.2(6b), 6.2(8), 6.2(8a), 6.2(8b) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.2), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.12)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz35989 | Title: | while issu license installation hanged , better dont allow it while issu |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | License installation may hang while ISSU is in progress. Please avoid issuing installation command while ISSU is in progress. In case if it hangs, please cancel the operation by pressing ctrl + c and reinstal licensel once ISSU is done.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(0.202) |
|
Known Fixed Releases: * | 4.2(0.211), 4.2(1), 7.1(0)BF(0.74), 7.1(0)ZD(0.158), 7.1(0)ZD(0.225), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsw23343 | Title: | ntp server config is not saved when configured with a different VRF |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
You may see this when executing Network Time Protocol(NTP) CLI commands. The command "ntp server use-vrf " when executed with a different vrf for a already configured ntp server/peer, the configuration is silently ignored.
Conditions:
You may see this when you are working with NTP.
Workaround:
Remove the existing configuration and reconfigure the same server with the desired vrf.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(2) |
|
Known Fixed Releases: * | 4.1(3), 4.2(0.122), 4.2(1), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsu05410 | Title: | NTP LC no response level-2 syslog seen periodically |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
%NTP-2-NTP_SYSLOG_NO_RESP_FROM_LC: from LC1 for Timestamp Disable
NTP message from LCs are periodically shown up.
Conditions: Unknown
Workaround: None, however this does not impact to traffic.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.0(4), 4.1(2) |
|
Known Fixed Releases: * | 4.2(0.120), 4.2(1), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg80860 | Title: | cmd "clo forma 12-hours" is not retained across issu from 4.2.1(2a) to X |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The configuration to display time in 12-hour format is lost. So the display is in 24-hour format.
Conditions:
This occurs upon ISSU from 4.2.1 or 4.2.2a to higher versions. For eg if the upgrade is from 4.2.1 to 5.0.2, the config "clock format 12-hours" is lost.
Workaround(s):
The cli command "clock format 12-hours" can be issued. There after the display of time is in 12-hour format.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(2) |
|
Known Fixed Releases: * | 4.2(6)S18, 4.2(7.6)S0, 7.0(1)ZD(0.3), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl61830 | Title: | N7K failed to bind interfaces to VDC after reload |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
After a VDC reload, ports failed to join the VDC with the following error:
%IM-5-IM_INTF_STATE: mgmt0 is UP in vdc
%SYSMGR-STANDBY-5-CFGWRITE_STARTED: Configuration copy started (PID 29081).
%ELTMC-SLOT1-2-ELTMC_INTF_TO_SLOT: Failed to get slot for interface Ethernet
2/X return status no such pss key
last message repeated 2 times
%ELTMC-SLOT1-2-ELTMC_INTF_TO_SLOT: Failed to get slot for interface Ethernet
2/X return status no such pss key
Conditions:
This issue is experienced in Nexus7000 running 4.2(6) release.
Workaround:
A reset of module that reported the ELTMC error allowed the ports to rejoin the
VDC.
In the above example a reset of module 1 allowed Ethernet port 2/X to rejoin
the VDC.
%ELTMC-SLOT1 ===>> Module 1
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(6), 5.2(0.166), 5.2(0.180) |
|
Known Fixed Releases: * | 5.2(0.244)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsu01914 | Title: | HSRP stuck in Initial state when hsrp delay reload cfgd |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
HSRP is stuck in Initial (Interface Reload Delay)(0 remaining) after a reload or shut/no shut.
Conditions:
This happens when you have the command "hsrp delay reload" configured and after a reload or shut/no shut on the interface.
Workaround:
Do not use 'hsrp delay reload" configuration to avoid this problem.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.0(3) |
|
Known Fixed Releases: * | 4.0(3)E1, 4.0(4), 4.1(2), 4.2(0.120), 4.2(1), 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd49820 | Title: | Proper Author not done when Fallback from dummy to reachable servers |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When AAA groups are configured for per command authorization, then fallback was not happening to next group even if all servers in current group are unreachable.
Conditions:
More then one groups are configured for per command authorization and all the servers in first group are unreachable.
Workaround(s):
Add a working reachable AAA server in first group configured for per command authorization. Basically the first AAA group should be reachable.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.39), 4.2(4), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj44481 | Title: | Unidirectional Connectivity + ISSU = GLBP Authentication Failure |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On a Nexus 7000 running 5.0(3) you might experience GLBP authentication failures after an ISSU or supervisor switchover despite the authentication text being the same on both nexus's.
Conditions:
This happens when the following sequence of events occurs:
1) There is unidirectional connectivity which causes authentication failures (which is expected)
2) Configuration changes were made to the authentication string text
3) Supervisor switchover occurs or ISSU is performed
4) Bidirectional connectivity is restored
Workaround:
Remove and re-apply the authentication string after the ISSU/supervisor switchover.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 5.1(1.40)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj71200 | Title: | Service "otv" crash while changing extend-vlans |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Service "otv" crash while changing extend-vlans
Conditions:
When changing extend-vans configurations, otv process may crash. This has been observed when entirely new set of extended vlans are configured without first removing the previous extended vlan configuration:
interface Overlay1
otv join-interface Ethernet1/1
otv control-group 239.1.1.1
otv data-group 232.192.1.0/24
otv extend-vlan 35, 52, 134, 152, 177, 185, 241-242, 462, 467-469, 473, 512, 535, 826-828, 834
Other_switch(config-if-overlay)#
Other_switch(config-if-overlay)# otv extend-vlan 2
2010 Oct 26 02:37:46 Other_switch %SYSMGR-2-SERVICE_CRASHED: Service "otv" (PID 13780) hasn't caught signal 11 (core will be saved).
Workaround:
First remove previous extend-vlans via "no otv extend-vlan" and then add new configuration.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 5.1(1.57)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf26637 | Title: | sysDescr snmp OID invalid in non-default VDCs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
SNMP OID sysDescr in non-default VDCs returns invalid text."Error opening the image /var/sysmgr/ftp/img-sync/curr-isan.img"
Conditions:
Query sysDescr in a non-default VDC.
Workaround:
None.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 5.1(0.141)S0, 5.1(0.208)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd04860 | Title: | snmp gets killed due to heartbeat missing, when EEM queries every 1 sec. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
OSPF does not respond to SNMP requests, when SNMP queries are issued
frequently (~1s in this case), and SNMP server process crashes.
Conditions:
This problem is seen only in the case when the rate of polling (SNMP trap queries)
is very high. OSPF is slow to respond to these queries, and responds to older
queries.
Workaround(s):
Once you encounter this scenario, unfortunately, there is no known workaround.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(2a)E1 |
|
Known Fixed Releases: * | 12.2(32.8.11)XJC273.33, 15.1(0.12)T, 4.2(3), 4.2(3.27), 4.2(4), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq38949 | Title: | MSDP error messages while bringing up system with saved configs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
During boot the following messages may show:
%MSDP-3-BGP_APIMTSRECV: MTS receive failed on API queue: Timer expired
%MSDP-3-AS_NUMBER: msdp [4182] MSDP/BGP local AS number is - 0
The command "show ip msdp internal event-history event" will show "Peer-RPF lookup for x.x.x.x failed, BGP is not running"
Conditions:
MSDP initialization may fail at bootup.
Workaround:
Restart the MSDP process with the "restart msdp" command.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(4), 5.2(0.907) |
|
Known Fixed Releases: * | 5.2(1)S25, 5.2(1.30)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto55861 | Title: | NXOS/Mcast: P2P VLAN for L3 routing on peer link not considered as L3 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In VPC setup, if reachability to the source is only from secondary and if metrics are the same to reach the source, there will be blackholing of traffic for that Source.
Conditions:
Following conditions have to be met:
1. VPC Setup
2. Source is in L3 domain
3. Source is reachable from Secondary
4. Metrics to reach source are same on both Primary and Secondary
Workaround:
There is no workaround.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(6), 5.1(3) |
|
Known Fixed Releases: * | 4.2(8.47)S0, 5.2(0.270)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk56181 | Title: | OTV: Bogus adjacencies exist due to inept cleaning of adjacencies |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
There are stale OTV Adjacencies under the output of "show otv adj"
Conditions:
Clear the OTV Adjacencies does not clear the problem and does not reset the OTV Adjacencies timer.
Workaround:
Remove and add the Config for Overlay interface resolved the issue
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(1.77), 5.1(2) |
|
Known Fixed Releases: * | 5.2(0.169)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui08344 | Title: | multicast convergence improvements |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
the l3 multicast convergence is slow during a spine switch reload, when the spine switch is the ISIS multicast root
Conditions:
When there is unicast and multicast traffic going on, when the spine switch is reloaded and the switch is the ftag root. This is because multicast and unicast tries to converge at the same time as the switch coming up, and the switch is busy
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N1(2) |
|
Known Fixed Releases: * | 6.0(2)N2(2), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)KM(0.37), 7.0(0)N1(0.398), 7.0(0)N1(1), 7.0(0)ZD(0.172), 7.0(0)ZN(0.123), 7.1(0)ARP(0.2), 7.1(0)D1(0.43) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti49858 | Title: | nexus 7k -high cpu due to netstack |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: High CPU observed with the following output.
ba01z02# sh proc cpu sort
PID Runtime(ms) Invoked uSecs 1Sec Process
----- ----------- -------- ----- ------ -----------
3427 142 62 2291 95.0% netstack
3499 603 24252018 0 6.0% xbar_driver_usd
1 992 3389026 0 0.0% init
2 1331 1617785 0 0.0% migration/0
Conditions:
IP Multicast code while handling back-to-back adds/delete of IGMP routes in management VRF it ends up in a tight loop
2010 Jul 20 18:55:44.220881 mrib [3640]: : Received Prune Notify Ack from ip
2010 Jul 20 18:55:44.220707 mrib [3640]: : Received Join Notify Ack from ip
2010 Jul 20 18:55:44.126352 mrib [3640]: : Received Prune Notify Ack from igmp
2010 Jul 20 18:55:44.125536 mrib [3640]: : Received Join Notify Ack from igmp
2010 Jul 20 18:55:44.125360 mrib [3640]: (management) : notify "igmp" about 1 Prune route changes
2010 Jul 20 18:55:44.125341 mrib [3640]: (management) : notify "ip" about 1 Prune route changes
2010 Jul 20 18:55:44.125321 mrib [3640]: (management) : notify "igmp" about 1 Join route changes
2010 Jul 20 18:55:44.125290 mrib [3640]: (management) : notify "ip" about 1 Join route changes
2010 Jul 20 18:55:43.616486 mrib [3640]: (management) : Copy oifs to all (Si,G)s for "igmp"
2010 Jul 20 18:55:43.616482 mrib [3640]: (management) : Doing multi-route add for "igmp" locally-joined
2010 Jul 20 18:55:43.616228 mrib [3640]: (management) : "igmp" add route (*, 239.255.70.83/32) (mgmt0), rpf Null 0.0.0.0, iod 0, bidir: 0, locally-joined
2010 Jul 20 18:55:43.615778 mrib [3640]: (management) : update IPC message from "igmp", 1 routes present
2010 Jul 20 18:55:43.120322 mrib [3640]: : Received Delete Notify Ack from ip
2010 Jul 20 18:55:43.120232 mrib [3640]: : Received Join Notify Ack from ip
2010 Jul 20 18:55:43.115795 mrib [3640]: (management) : Route removed from mrib
2010 Jul 20 18:55:43.115771 mrib [3640]: (management) : "igmp" delete route (*, 239.255.70.83/32)
2010 Jul 20 18:55:43.115714 mrib [3640]: (management) : Doing multi-route delete for "igmp"
2010 Jul 20 18:55:43.115710 mrib [3640]: (management) : "igmp" delete route (*, 239.255.70.83/32) (mgmt0)
2010 Jul 20 18:55:43.115633 mrib [3640]: (management) : update IPC message from "igmp", 2 routes present
Workaround:
Supervisor Switchover with the command "system switchover
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(8)S11, 4.2(8.44)S0, 5.1(0.234)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsy98865 | Title: | N7K: MSDP SA filter not removed unless process is restarted |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
- MSDP SAs received on N7K can be filtered and not installed in the MSDP SA cache even if no sa-policy is applied to MSDP peer
Conditions:
- This behavior can be seen if there has been an MSDP SA filter applied to the MSDP peer with the use of "ip msdp sa-policy" command which has been removed without any restart of the MSDP process
- Although there is no sa-policy applied to the MSDP peer, the MSDP SA filter continues to be applied to all incoming MSDP SAs
- This issue affects 4.1(5) and earlier releases
Workaround:
- After the sa-policy configuration is removed, restart the MSDP process with "restart msdp"
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(5) |
|
Known Fixed Releases: * | 4.2(0.190), 4.2(0.194), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg45703 | Title: | PIM RP remains in PIM cache after removal from configuration |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When an RP is configured to server multiple group ranges and then this RP is de-configured, the group ranges are removed but the RP is still in the system cache.
Workaround:
The workaround is to restart PIM
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 5.1(0.182)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf94368 | Title: | OSPF snmp mib for importNoExternal incorrectly shows area as stub |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | None
Symptom:
SNMP walk of MIB shows OSPF Area 0 as importNoExternal(2), which is incorrect.
.1.3.6.1.2.1.14.2.1.3.0.0.0.0 = 2
Conditions:
show ip ospf shows area as normal
Workaround:
No workaround
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 4.2(8)S6, 4.2(8.10)S0, 5.0(2), 5.0(2.47), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz07844 | Title: | Start sendtime of key2 & endtime sendtime of key1 are same, creates hole |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:Protocol adjacancies flap when keychain is configured without overlap
Conditions: This only happens when end time of previous key is same as starttime of current key i.e no overlap
Workaround: Make sure that there is atleast 1 sec overlap between the keys
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(0.184) |
|
Known Fixed Releases: * | 4.2(0.194), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud59785 | Title: | Intra-area Summary Route not re-advertised if a Summary Route exists |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If a Nexus 7000 has an OSPF Intra-Area for prefix X/24 and receives an Inter-Area prefix for X/16. When the Nexus 7000 looses the Intra-Area for Subnet X/24 (ospf passive), when it returns to service, it doesn't send an LSA
update for the X/24 prefix, therefore the rest of the network never re-installs the X/24 prefix.
Conditions:
A 7K has an SVI X/24 prefix in area 11 (example). The 7K now receives a prefix X/16 from another router which summarized it via a Range command) and so all routers in the network have X/24 and X/16 in the OSPF database and the routing table.
When the 7K looses it's directly connected route X/24 (ospf passive) for whatever reason, when it returns to service, it doesn't send an LSA update for the /24, therefore the rest of the network never re-installs X/24.
If the X/16 summary route is not advertised by the other router, the 7K re-sends an LSA for X/24 when it returns to service.
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(5)E2, 5.2(7), 6.0(4) |
|
Known Fixed Releases: * | 5.2(9), 5.2(9)S27, 5.2(9.53)S0, 6.0(2)N2(1), 6.0(2)U1(1), 6.1(3), 6.1(3)S30, 6.1(3.44)S0, 6.2(1.93), 6.2(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub99717 | Title: | "Redistribute static route-map" redistribute the defaullt route |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: When using "redistribute static route-map <>" under RIP to
redistribute specific prefixes, it leaks the default route in RIP.
It should only redistribute prefixes matched in the prefix-list RIP, however, it does
redistribute default route which should not happen
Conditions: Default route & a route-map configured to redistribute specific static routes in RIP.
Workaround: Apply RIP filter on NExus so that it doesn't send default prefix to its neighbors.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.1(1.1), 6.2(8a) |
|
Known Fixed Releases: * | 5.2(8.17)S0, 5.2(9), 6.0(2)A1(1c), 6.0(2)N2(1), 6.0(2)U1(3), 6.1(2.35)S0, 6.1(4.1)S0, 6.1(5), 6.2(0.285), 6.2(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk46878 | Title: | SNMP community not removed in show tech when using an ACL |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a Nexus 5000 or 7000 series switch, SNMP community is not removed in the output of show run in the output of show tech when the community has an ACL tied to it
snmp-server community group network-operator
snmp-server community group network-admin
snmp-server community group network-admin
snmp-server community testing123 use-acl snmp-acl
Conditions:
There is an access-list tied to the snmp-server community.
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2)N1(1) |
|
Known Fixed Releases: * | 5.1(10.1)S0, 5.1(2.16)S0, 5.2(0.225)S0, 7.0(1)ZD(0.3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr18129 | Title: | Device crashes with: ospf process crash due to LSA throttling |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
OSPF process crash is observed causing a card switchover.
Conditions:
- LSA throttling is leading to the crash.
- In some cases VDC restoration can also trigger this.
Workaround:
None.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.2(1)N1(1), 5.2(2.38)S0, 6.0(0.3)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq61924 | Title: | Incorrect size Get-response when using SNMP over IPv6 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When using SNMP over IPv6, a Nexus 7000 might respond with larger than needed
SNMP Get-response frames causing them to be fragmented. This can cause certain
SNMP managers to ignore the Get-response.
Conditions:
SNMP over IPv6 is being used.
Workaround:
Use SNMP over IPv4
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.2(1)S66, 5.2(1.59)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc73943 | Title: | NX-OS / OSPF not installing all ECMP paths in RIB |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
OSPF not installing all ECMP paths in RIB
Conditions:
NX-OS running 5.0(3)U4(1) with the interconnect in area0. ECMP paths advertised from neighbors connecting through NSSA.
issue is sometimes triggered after a reload
Workaround:
NA
reconfiguring OSPF seems to help sometimes
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 5.2(9), 5.2(9)S10, 5.2(9.19)S0, 6.0(2)A1(1), 6.0(2)A7(1.18), 6.0(2)A7(2), 6.0(2)N2(1), 6.0(2)U1(1), 6.0(2)U7(1.18), 6.0(2)U7(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsy28023 | Title: | PIM: Bidir RP not update when RP change in "show ip pim group-range" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
Bidir RP not updated when RP changes in "show ip pim group-range"
Conditions:
When Bidir RP changes, its state is not shown to the User.
Workaround: There is no workaround. But code internally does the right thing. Its only the UI command that is broken. restarting pim process should fix the issue.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(4) |
|
Known Fixed Releases: * | 4.2(0.228), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc32368 | Title: | JP messages not handled properly under failure condition |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom: Traffic loss for 60sec(PIM JP period) with Anycast RP setup if the RP to which client has joined fails
Conditions: Problem happens only when all the following conditions are satisfied
1. Anycast RP is used and
2. SPT is along shared tree and
3. Shared tree switches to new RP because of failure of old RP
Workaround: No workaround is available. Traffic loss is only for 60sec
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(2.44), 4.2(3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf30186 | Title: | snmpd service crash due to error table filled with messages |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Memory leak in snmpd process, when multiple oids are getting polled in one packet and if some errors happens on it.
Conditions:
Seen each time an snmp poll is done to more than one oid which generates an error.
Workaround:
snmpd will crash and come up again.
More Info:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(5), 5.2(5)S9, 5.2(9), 6.1(1) |
|
Known Fixed Releases: * | 5.2(1)N1(6), 5.2(9.167)S0, 6.0(2)N3(1), 6.0(2)U1(3), 6.0(2)U2(1Z), 6.1(4.97)S0, 6.1(4a), 6.1(4a)S9, 6.1(5.1)S0, 6.2(1.98)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz08092 | Title: | Admin distance is not used a tie-breaker between 2 process of same proto |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Nexus 7000 may make incorrect IPv4 route selection choice, and
promote a non-best route to best.
Conditions:
This can only occur when multiple instances of the same protocol are
competing for the best route, and the instance with the lower admin
distance, has a higher metric.
Workaround:
There is no workaround, though the problem could be mitigated by using
different metrics, or runing separate protocols.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(0.184) |
|
Known Fixed Releases: * | 4.2(0.195), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw63051 | Title: | N7K: ospfv3 route not advertised in case of point-to-point link |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ospfv3 route is not advertised in case ospfv3 network type is point-to-point.
Conditions:
ospfv3 runs and the network type is point-to-point link
Workaround:
use network type as broadcast
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(3.25)S0, 6.0(2)S24, 6.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl89610 | Title: | (s,g) RP-bit prune not sent immediately after (s,g) route created |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
When traffic switches from RPT to SPT duplicate traffic will be seen. This is
true if the RPF interface toward the RP and the source are different.This
could last for a maximum of 60 seconds.
Conditions:
RPT to SPT switch should have just occurred.
Workaround(s):
This will happen only when running PIM-SM. BIDIR/SSM do not have this issue.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: * | 5.1(3)E5, 5.1(3)N1(1), 5.1(4)S0, 5.2(0.251)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr09782 | Title: | PIM BSR packets limited to 1486 bytes. No fragmentation done. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | PIM Bootstrap packets are limited to 1486 bytes and so does not
advertise more than 66 single group-to-rp mapping.
The software is not trying to send fragmented bootstrap packets.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.2(1)S63, 5.2(1.56)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsw52373 | Title: | Pktmgr drops certain acllog packets in OFE path with permit logging |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When a ACL is applied to and interface with an entry to log packets that are permitted, the packets do not show up in acl log cache.
Impact:
There is no loss of traffic. The user might not be able to trace packets that were permitted against the entry. This does not affect ACL entries that log a packet that was denied.
Workaround:
There is no workaround. One could use ACL statistics to count the packets that match the rule or other features such as netflow to identify the source of the flow.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(2), 5.0(2) |
|
Known Fixed Releases: * | 5.1(0.65), 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb63037 | Title: | "ip pim event-history bidir size" will not change size |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
The bidir event-history log size is small on a Nexus 7k by default.
Conditions:
The cli "ip pim event-history bidir size large" is used to change the log size to large. The size remains small despite. the change.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(2.5), 4.2(3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud25824 | Title: | OSPF dead-timer not applied on reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ospf dead timer not maintained across reload
Conditions:
The default timers for ethernet interfaces on N7k are hello of 10 seconds and dead-timer of 4x10 = 40 seconds. When configuring a hello timer other than 10 seconds, the dead-timer automatically adjusts to 4x the newly configured hello timer. If a user needs to combine a non-default hello timer with the default 40 second dead timer, this new value will not show up in the running configuration. For example:
N7k1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
N7k1(config)# int vl 10
N7k1(config-if)# ip ospf hello-interval 5
N7k1(config-if)# ip ospf dead-interval 40
N7k1# show run int vl 10 | i face|ospf
interface Vlan10
ip ospf hello-interval 5 <---- dead timer not present
ip router ospf 1 area 0.0.0.0
N7k1# show ip ospf interface vlan 10 | i Timer
Timer intervals: Hello 5, Dead 40, Wait 40, Retransmit 5 <--- dead timer applied to process
N7k1# show ip ospf interface vlan 10 | i Timer
Timer intervals: Hello 5, Dead 20, Wait 20, Retransmit 5 <--- dead timer back to default
Note that the dead-timer of 40 seconds is applied within the OSPF process. On a reload, this value is removed from the OSPF process which will prevent adjacencies from coming up.
Workaround:
Manually reconfigure the custom timers after each reload
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: * | 6.0(2)N2(1), 6.0(2)U1(1), 6.1(3), 6.1(3)S23, 6.1(3.32)S0, 6.2(1.93), 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb52260 | Title: | OSPF MD5 authentication link failure on reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:OSPF configured using MD5 authentication returns "bad authentication" errors after a line card restart.
Conditions:The bug is applicable in the following configuration scenario.
(1) If there is any area level authentication command - i.e., area authentication [message-digest] followed by any authentication type such as md5.
(2) No other area level command such as NSSA/stub (area nssa/stub), cost (area default-cost) or address-range is configured.
The bug will be triggered if either
(1) All interfaces belonging to that area are unconfigured followed by a configuration of any interface(s) in that area, then those interfaces will not inherit the authentication command from the area and there will be authentication errors for these new interfaces.
or
(2) All interfaces belonging to the area are on a particular line card, and the line card goes through a reload, then there will be authentication errors seen on those interfaces, once they are up again.
Workaround:
The workaround is to unconfigure and configure the area authentication command.
Further Problem Description:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(5) |
|
Known Fixed Releases: * | 4.2(2), 4.2(2.3), 4.2(3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz34607 | Title: | unresolved route gets installed in URIB with recursive routes. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Nexus 7000 may accept and install a recursive IPv4 or IPv6 route in
the RIB. The route will break forwarding for the prefix.
Conditions:
This can only occur when the network generates a looping route, and
this route's next-hop is directly attached, e.g.
10.0.0.0/8, via 10.0.0.1, bgp
10.0.0.0/24, via Ethernet0, direct
i.e. the 10.0.0.0/8 route is via 10.0.0.1, which is directly attached.
The following would be a valid route:
10.0.0.0/8, via 10.0.0.1, bgp
10.0.0.0/24, via 172.16.0.1, Ethernet0, ospf
i.e. here 10.0.0.1 resolves to 172.16.0.1 on Eth0.
Workaround:
Clear the route using the following command:
clear routing {ip|ipv6} prefix
Further Problem Description:
The system would have removed this route via the loop detection logic,
so the route really needs to be removed. Note that this is likely a
transient loop caused as links go down, and without manually clearing
it, the BGP hold timer will expire and remove the route.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(0.196) |
|
Known Fixed Releases: * | 4.2(0.206), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj04685 | Title: | mgmt0 interface not reported and any vrf member |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Connectivity to the management interface may become intermittent, and checking vrf membership for mgmt0 will return no vrf mapping. Interface mgmt0 should always be a member of vrf management.
switch# show vrf management int
Interface VRF-Name VRF-ID
switch#
switch# show vrf
VRF-Name VRF-ID State Reason
default 1 Up --
management 2 Up --
switch# sh vrf int mgmt0
Interface VRF-Name VRF-ID
switch#
Conditions:
Issue seems to occur after ISSU upgrade to 5.0(3)
Workaround:
Reload corrects the problem.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 5.1(1), 5.1(1.18)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn60016 | Title: | LISP: RIB locator registration within EID vrf - should be Locator vrf |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Two routers participating in a site do not get informed with their neighbor's locators become available or unavailable
Conditions:
We are registering for interest in our locators in the EID vrf rather than the locator vrf
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(0.215) |
|
Known Fixed Releases: * | 5.2(0.251)S0, 5.2(0.275)S0, 6.0(0.42)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg83829 | Title: | PBR always recursively resolves nexthops which makes failover not work |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Configuration of any PBR 'set ip next-hop' will always recursively resolve the
next-hop automatically to less specific prefixes if they are present in the
forwarding table and the configured next-hop is not directly-connected.
This may have unintended consequences that when the next-hops are not
directly-connected within subnet(s) on N7K, failover may not occur between
multiple next-hops configured or bypass PBR if none are available.
Conditions:
Failover or fallback to non-PBR behavior may not work as intended when the
next-hop prefix(es) are not directly-connected and are available via
less-specific prefixes via a reachable next-hop.
Workaround:
Use PBR with directly-connected PBR destinations first followed by the
recursive next-hops next. Thereby the directly connected next-hops will
be picked first if they are reachable if not it moves on to the recursive
next-hops.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4), 5.1(0.214) |
|
Known Fixed Releases: * | 5.1(0.157)S0, 5.1(0.224)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj23150 | Title: | RIP routes churning on receiving poison reverse update |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
========
On a Cisco Nexus 7000, RIP routes are observed to be constantly churning in the routing table.
Conditions:
=========
This is seen when Nexus 7k receives a poison reverse update.
Workaround:
==========
Turn off poison reverse on peer
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 5.1(1.34)S0, 5.1(1.35)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf39937 | Title: | NX-OS SNMP -- Random IP Address shown in SNMP debugs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
SNMP debug on NX-OS shows an IP address in the debug message. This IP address represents the agent IP in SNMPv1 and should not be shown in the debugs.
Conditions:
Workaround:
None. The IP address can be ignored as it is harmless. The switch is not communicating to this IP Address in any way.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(3) |
|
Known Fixed Releases: * | 5.0(3)N1(1), 5.1(0.73), 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto26962 | Title: | PIM-RP-Enh: PIM not recog pim rp rmap configuration under non-def vrf |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PIM static RP configured with route-map in a non-default vrf does not show up
in the vrf using "show ip pim vrf "
Conditions:
- PIM service is running
- configure non-default vrf
- configure route-map
- configure "ip pim rp-address route-map
- configure this in the non-default vrf
- add L3 interface to the non-default vrf
Workaround:
a) Have at least one PIM interface (can even be a loopback) in the same
non-default vrf 'before' adding the rp-address configuration. Ex sequence below:
1) create vrf
2) add interface (x) to above vrf (can even be loopback)
2a) add PIM to this interface
3) add the pim rp-address configuration to the non-default vrf created above.
b) re-add the "ip pim rp-address route-map " command
c) restart PIM
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(6), 5.2(0.245)S1 |
|
Known Fixed Releases: * | 5.2(0.270)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc58022 | Title: | Missing summary LSA in case of overlapping network |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptoms:
When there is a overlapping network, OSPF may miss summary LSA.
Conditions:
Issue is seen Nexus7000 running 4.2 releases.
Workaround:
None.
This issue is fixed in 4.2(8) or later releases.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(2) |
|
Known Fixed Releases: * | 4.2(8), 4.2(8)E1, 5.0(0.298), 5.0(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk17975 | Title: | N7k sets unexpected value as ifAlias for L3 interface |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Nexus 7000 Series switch sets unexpected trap value as ifAlias.
ifAlias should be used description value set on interface configuration mode.
Actually, PC_IM_L3_PROTOCOL_STATE_CHANGE) is set as ifAlias.
Conditions:
This symptom is observed when configured description on interface configuration mode.
It only occurs on L3 interface such as SVI.
Workaround:
none
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3), 5.1(2) |
|
Known Fixed Releases: * | 5.1(2.14)S0, 5.1(2.6)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCte81687 | Title: | Cannot block responses to SNMP queries for CDP through role config. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The Nexus 7K may respond to SNMP queries for CDP information, even though the responses are explicitly blocked using the "role" configuration.
Workaround:
None at this time.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(3a), 4.2(3) |
|
Known Fixed Releases: * | 4.2(4.29), 4.2(5), 5.0(2), 5.0(2.3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud00524 | Title: | More specific PIM ASM RP config not overriding bidir RP config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a mixed ASM (PIM Sparse Mode) and PIM-Bidir environment, ASM (S,G) entries fail to be created.
Conditions:
This issue only happens when a static BiDir RP mapping is a supernet of the ASM RP configuration.
For example
ip pim rp-address 192.168.1.1 group-list 239.1.1.0/24
ip pim rp-address 192.168.2.2 group-list 239.1.0.0/8 bidir
If the ASM group is not a subnet of the Bidir group, this issue can not occur.
Workaround:
If the BiDir RP configuration no longer covers the
To correct the above example the following could be applied
ip pim rp-address 192.168.1.1 group-list 239.1.1.0/24
ip pim rp-address 192.168.2.2 group-list 239.1.0.0/24 bidir
ip pim rp-address 192.168.2.2 group-list 239.2.0.0/16 bidir
ip pim rp-address 192.168.2.2 group-list 239.3.0.0/16 bidir
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(7), 6.2(1.52)S2 |
|
Known Fixed Releases: * | 5.2(9), 5.2(9)S17, 6.0(2)N2(1), 6.1(3), 6.1(3)S12, 6.1(3.18)S0, 6.2(0.304), 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn59592 | Title: | OSPF cores when modifying the layer of associated interfaces |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptoms:
OSPF process may crash when configurations under physical/port-channel
interfaces are modified.
%SYSMGR-2-SERVICE_CRASHED: Service "__inst_001__ospf" (PID ) hasn't
caught signal 11 (core will be saved).
Conditions:
This issue is seen in Nexus7000 running 5.x releases.
Physical/Port-channel interfaces modified are associated with the OSPF,
irrespective of the interface status (shutdown or not shutdown)
Workaround(s):
None.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(3)S28, 5.3(0.153), 6.0(0.1) |
|
Known Fixed Releases: * | 5.2(0.242)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg25403 | Title: | %URIB-3-URIB_ASSERT_ERROR: Assertion "tsp_have_process_lock_only()" fail |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The following logs are observed :
%URIB-3-URIB_ASSERT_ERROR: ../routing-sw/routing/urib/urib.c:7095: Assertion "tsp_have_process_lock_only()" failed.
Conditions:
Seen after clearing a route.
Workaround:
None.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: * | 5.0(2)S65, 5.0(2.64)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq13525 | Title: | Missing validity checks on length field of OSPF Opaque LSA updates |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | SYMPTOM:
NX-OS may forward corrupted LSAs and suffer from system
instability (high CPU).
CONDITIONS:
The OSPF process handles a malformed LSA update.
WORKAROUNDS:
There are no workarounds, but Cisco NX-OS OSPF MD5 authentication can
be used to mitigate this issue by preventing unauthenticated neighbors
from injecting malformed LSAs.
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/6.1:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:M/Au:N/C:N/I:P/A:C/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2011-2031 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: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(0.270)S7 |
|
Known Fixed Releases: * | 5.2(1)S17, 5.2(1.21)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth05382 | Title: | SNMP-V2 "system.sysname" Mib supports polling for the FQDN in NX-OS |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
The system.sysname is a standard mib and when an snmp walk is done in IOS, or CATOS returns the FQDN. On NX-OS this is not supported.
Conditions:
snmp-walk on nexus5k or nexus7k. Nexus5k ddts is CSCtg99916.
Workaround:
Change the hostname to the FQDN, and although this workaround was given to the customer it does not scale for them. They would like the same behavior in IOS for NX-OS.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.0(0)AA(0.135), 4.2(1), 5.1(1) |
|
Known Fixed Releases: * | 4.2(1)N2(1), 4.2(6)S19, 4.2(7)S2, 4.2(7.7)S0, 5.2(1)S40, 5.2(1.46)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg48134 | Title: | Transient OSPF issue causes incorrect Forward Address in LSA 7 updates. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Only one route shows up in routing table when there are 2 Equal cost paths to the destination.
Conditions:
Summarizing server subnet on 2 routers and redistributing these into OSPF as Tupe-2 External.
There can be a race condition where when the first router is configured to summarize and redistribute, the other router will also advertise this route with ip address of the advertising router as the Forward Address in the LSA. When the router is configured to summarize and redistribute these same server subnets, it still sends LSAa with the other routers Forward Address instead of a local IP Address.
Workaround:
Remove the summary addresses on each router advertising the summary routes. This causes all server subnets to be advertised by both routers. Then add the summary commands back to the routers as close to the same time as possible.
The summary routes from each router doing the summarization should then be seen on the other routers.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2) |
|
Known Fixed Releases: * | 5.0(5.25)S0, 5.1(0.147)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd62160 | Title: | set community 0:0 stores info in unsupported format |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
set community 0:0 creates "set community internet" in the running config file even though the internet keyword is missing from the CLI.
Conditions:
Occurs with route-maps with set community 0:0 is used.
Workaround(s):
set community internet can be set by using "set community 0:0"
To remove the set community internet from a route-map, use "no set community 0:0".
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.40), 4.2(4), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCte45848 | Title: | Couldn't find PIM VRF for VlanX |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When multiple DataCenters are connected via L2 through an MPLS core, and specific L2 Vlans are configured for Multicast (PIM Sparse Mode), Those specific L2 VLANs in each DataCenter need to be configured for MC.
Conditions:
Some L2 Vlans shared between DataCenters were not configured for Multicast.
Workaround(s):
Configure Multicast on those Vlans that are shared between DataCenters
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(8)S6, 4.2(8.10)S0, 5.0(1.19), 5.0(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf64450 | Title: | coldstart trap needs static arp configured in order to be sent out |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
coldstart trap is NOT sent out from mgmt 0 if arp is not configured statically.
If arp is configured on mgmt 0 statically, coldstart trap is sent out.
Conditions:
arp is not statically configured for NMS or next-hop.
Workaround:
configure arp statically.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 5.1(0.85), 5.1(1), 6.0(2)U2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk66591 | Title: | DCNM:Adj.Status is not comming after deleting/creating portchannels |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Adjacency status not coming up for the interface in DCNM GUI "Interface
Settings" when port channel is deleted from Fabricpath topology
Conditions:
After creation of default Fabric path topology containing Fabricpath port
channels and discover the devices in DCNM. Delete the port channel using CLI on
both the devices. Adjacency status will not refresh for the interfaces in DCNM GUI.
The issue is, in 5.1(2)S19, "log-adjacency-changes" has not got enabled by
default. Due to this issue, Syslogs are not generated in device. As a result
DCNM status is not in sync with device.
Workaround(s):
Below are various workaround options for DCNM to be in sync with device, if the
issues is not addressed:
- Enable the log-adjacency status at FP domain level before discovery the
device in DCNM.
- If the device has been discovered before above configuration, then set the
above configuration and rediscover the device.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: * | 5.1(10.1)S0, 5.1(2)S16, 5.1(2)S17, 5.1(2.14)S0, 5.1(2.15)S0, 5.1(2.44)S0, 5.1(3)S24, 7.0(0)ZD(0.50), 7.0(0)ZD(0.53), 7.0(0)ZD(0.55) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj65960 | Title: | High CPU at OSPF due to SNMP Polling |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
High CPU seen at the OSPF process
Conditions:
This is seen when SNMP polling is used. Not sure which MIB being polled is causing the CPU at this point.
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 4.2(7.108)S0, 5.0(5)E1, 5.1(1.54)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr37274 | Title: | Nexus - filter is not working properly with match ip next-hop |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Filter not working properly with "match ip next-hop prefix-list" in a route-map
Conditions:
Next-hop being matched is a recursive next-hop.
Workaround:
Match the next-hop against the resolved next-hop instead of
a recursive next-hop.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.2(1)S70, 5.2(1)S71, 5.2(1.61)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz77386 | Title: | CLI for BSR should only allow priority up to 255 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
NX-OS CLI allows RP priority to be configured 0-65,535. Per RFC 5059 this is an 8 bit field and priority should be 0-255.
R2(config)# ip pim bsr rp-candidate loopback 0 group-list 239.0.0.0/8 priority ?
<0-65535> RP priority value
*Default value is 192
Workaround:
N/A
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(4) |
|
Known Fixed Releases: * | 4.2(0.228), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto04931 | Title: | Missing mroute oif entries |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Some S,G mutlicast streams are not forward correctly at the aggregation layer.
Conditions:
Recent reload of device. Multicast streams sourced from outside the DC/vPC environment. When viewing the mroute entry, there are no outgoing interfaces.
Workaround:
The issue can be cleared using the 'clear ip mroute '.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(8)S7 |
|
Known Fixed Releases: * | 4.2(8)E1, 4.2(8)S11, 4.2(8.44)S0, 5.2(0.264)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsy13309 | Title: | PBR statistics not working with ipv6 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Problem: Statistics doesn't work for IPv6 route-map applied through "ipv6 policy route-map"
Workaround: None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(0.159) |
|
Known Fixed Releases: * | 4.2(0.206), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk62754 | Title: | N7K: MSDP should not send connect requests when VRF is down |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | MSDP connect requests should not be generated when VRF is down.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(5) |
|
Known Fixed Releases: * | 5.2(0.164)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCte17608 | Title: | Duplicated MC packets received over vPC |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
When running in a vPC facing vPC topology on the Nexus 7000 platform duplicate
mulicast packets are seen on a shared segment.
Conditions:
vPC facing vPC topology with all 4 routers having an SVI on the same shared
Vlan with PIM enabled on the SVI.
Workaround:
There is no workaround. To stop the multicast packet flows remove PIM from one
of the interfaces to remove the redundant multicast path. However, by doing
this it removes some of the link and path redundancy.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(4), 4.2(4.14), 4.2(5), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr76412 | Title: | OTV : ISIS may leak memory on adjacency flaps |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptoms:
OTV ISIS process may experience exception reporting following message:
%ISIS_OTV-4-NO_MEM: isis_otv-default [] No memory event detected
Conditions:
Nexus7000 switch running 5.1.x NX-OS releases and enabled with OTV.
Workaround(s):
Switch reload or Sup failover provide temporary workaround.
This issue is resolved in 5.2(3a) or later releases.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.2(2)S8, 5.2(2.5)S0, 6.0(0.31)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk55248 | Title: | Incorrect LIF / RPF interface in mrib |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
RPF interface not correctly installed in mrib table and hardware.
Conditions:
RP recovery test
Workaround:
MRIB entry can be corrected by manually clearing either the *,G or a single S,G. Clearing a single S,G entry does not fix the remaining S,G which are sourced from the same urib/RPF interface.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(1) |
|
Known Fixed Releases: * | 5.1(2.41)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth88120 | Title: | If traffic is re-started when (S,G)s about to expire,takes 1min to conv. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If we restart the traffic just before the S,G expires, traffic takes longer to converge for traffic for certain flows as indicated in the Evaluation section.
Conditions:
Traffic has to stopped for 3.5 mins and then resume to run into this condition
Workaround:
No workaround.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: * | 4.2(6)S50, 4.2(7.45)S0, 5.0(3)S42, 5.0(3.50)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta42559 | Title: | Nexus 7k flushes OSPF routes during graceful restart/NSF recovery |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Nexus 7k may flush OSPF learned routes when a Cisco IOS OSPF neighbor undergoes an NSF/graceful restart, resulting in 5 to 10 seconds of packet loss.
Conditions:
This is seen when the OSFP neighbor undergoing the NSF/graceful restart is a Cisco IOS router.
Workaround:
none
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(1), 4.2(1.17), 4.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt14593 | Title: | Port-Channel interfaces for some vrf show up as members of default vrf |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Port-channel will not show up as part of the actual vrf when the command "show ip int brief vrf" is issued.
In some rare case, Interface create is seen at a later time after a vrf membership. This is not just a display
issue, traffic impact could be seen.
Conditions:
This issue may be seen after power reboot of systems running 5.1(3) s1.
Workaround:
Create a new VRF and move all related port-channels to new VRF.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(3)S1 |
|
Known Fixed Releases: * | 5.2(2.57)S0, 6.0(2)S7, 6.1(0.116)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo27552 | Title: | NXOS-VPLS_SCALE Blackhole after multiple process restart |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PWs are UP either Down on local PE or in the remote PE.
Conditions:
Both LDP and L2VPN process restarts in quick succession.
Workaround:
clear l2vpn service
Further Problem Description:
|
|
Last Modified: | 18-JUN-2016 |
|
Known Affected Releases: | 7.1(0)BF(0.48) |
|
Known Fixed Releases: * | 15.4(3)M2.1, 15.4(3)M3, 15.4(3)M3.1, 15.4(3)S0.6, 15.4(3)S1, 15.4(3)S2, 15.4(3)SN1a, 15.5(0.16)T, 15.5(0.16.1)CG, 15.5(0.20)PI27a |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut94161 | Title: | EEM: Configuration failed with: 0x412c000d validation timed out |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Configuring EEM with syslog as trigger is not accepted in a Nexus 5500/5600/6000
esc-5648-left(config)# event manager applet ntp
esc-5648-left(config-applet)# event syslog pattern "%PFMA-5-MOD_STATUS: Module 1 current-status is MOD_STATUS_ONLINE"
Configuration failed with: 0x412c000d validation timed out
Conditions:
Configuring EEM
Workaround:
Restart of evmc process can be done. Please open a TAC case for this since it needs to be done from the linux prompt.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.0(3)I2(0.528), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.1(2)N1(0.556), 7.1(2)N1(1), 7.1(2)ZD(0.11), 7.1(2)ZN(0.15) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo37471 | Title: | N7k/RIB displays HSRP VIP route incorrectly |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N7k/RIB using the route with deadbeef flaf set
Conditions:
N7k running 6.2(6) and installing stale route to HSRP VIP with deadbeef flag set.
Workaround:
The issue is only seen if HSRP is configured while the SVI is still shutdown.
If HSRP was configured after the SVI was no-shut, then the issue cannot be reproduced by shutting the SVI.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.2(6a) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)CM(0.19), 6.2(8)TS(0.28), 6.2(9.1)S0, 7.0(6)N1(0.274), 7.0(6)N1(1), 7.0(7)N1(1), 7.0(7)ZN(0.104), 7.1(2)N1(0.543), 7.1(2)N1(1) |
|
|
| |
| |
|
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: | 17-JUN-2016 |
|
Known Affected Releases: | 6.2(10)S17 |
|
Known Fixed Releases: * | 6.2(14a)S3, 6.2(16), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy89705 | Title: | 4 way HSRP does not work on Nexus 5k/6k switches |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If we have 4 way hsrp configured and n5k in VPC pair are in Active/listen[ or standby/listen] state then connectivity to VIP breaks.
Conditions:
4 way hsrp is configured and n5k/6k in VPC pair are in Active/listen[ or standby/listen] state
Workaround:
Make n5k/6k in VPC pair Active/standby or listen/listen state in 4 way hsrp.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.1(3)ZD(0.129), 7.1(3)ZN(0.275), 7.1(3)ZN(0.313), 7.1(4)N1(0.809), 7.1(4)N1(1), 7.2(2)D1(0.41), 7.2(2)N1(0.426), 7.2(2)N1(1), 7.2(2)ZD(0.128) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui18245 | Title: | LACP BPDUs should always be untagged irrespective of Port-ch config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When forming LACP port-channel, the port channel does not come up. The interface goes to suspended state stating the following: 'Suspended: No LACP PDUs.'
Conditions:
One of the following configured:
Globally: vlan dot1q tag native
Per Interface: switchport trunk native vlan
Workaround:
Set the configuration above to it's default value on both sides of the link.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.1(3)S50, 6.1(4), 6.1(4)S26, 6.2(1.143)S5, 6.2(2)S5 |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)CM(0.10), 6.2(10)CM(0.8), 6.2(10)CM(0.9), 6.2(10)MS(0.1), 6.2(10)MS(0.2), 6.2(8)E1, 6.2(8)ES(0.5), 6.2(8)KR(0.8), 6.2(8)TS(0.28) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq29707 | Title: | N7K: getnext on large instance otv id return wrong response |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
SNMP GETNEXT operation on cotvVlansTable objects returns incorrect entry.
Conditions:
The issue occurs only when GETNEXT operation is performed for cotvVlansTable objects
using cotvVlanId > 2^32.
Workaround:
None.
Further Problem Description:
The issue exists in NXOS software releases 6.2(x).
The fix has been integrated into 7.1(0) and all the later releases.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.2(10)S42 |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.251), 7.1(0)N1(0.313), 7.1(0)N1(1), 7.1(0)OTT(0.32), 7.1(0)PDB(0.199), 7.1(0)SIB(99.24), 7.1(0)ZD(0.299), 7.1(3)ZN(0.313) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux67319 | Title: | mem leak in fabric-access |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
a slow memory leak in fabric-access process will lead to memory starvation and then device hap-reset.
Conditions:
The leakage happens when feature fabric-access is enabled.
Workaround(s):
None
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.1(3)N1(1.1), 7.3(0)D1(0.187) |
|
Known Fixed Releases: | 7.1(3)ZD(0.153), 7.1(3)ZN(0.313), 7.1(4)N1(0.847), 7.1(4)N1(1), 7.2(2)D1(0.33), 7.2(2)N1(0.370), 7.2(2)N1(1), 7.2(2)ZD(0.69), 7.2(2)ZN(0.53), 7.3(0)D1(0.195) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun19641 | Title: | SSTE: BGP - %BGP-3-MTSDROP: MTS drop failed on queue: Invalid argument |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The following error messgae would be displayed either on the active SIP console or standby SUP console - "%BGP-3-MTSDROP: bgp- MTS drop failed on bgp- queue: Invalid argument"
Conditions:
The symptoms are observed when either reload with config or unconfig and reconfig router bgp.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 18-JUN-2016 |
|
Known Affected Releases: | 6.2(7.4)S0, 7.1(0)D1(0.76) |
|
Known Fixed Releases: * | 6.2(0)HS(0.10), 6.2(7.20)S0, 6.2(7.21)S0, 6.2(8), 6.2(8)NO(0.7), 6.2(9)FM(0.37), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.99), 7.1(0)D1(0.76), 7.1(0)D1(0.82) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj88840 | Title: | MSDC QI: Fix P1 SA warnings in acl-log |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
this is SA warning bug
Conditions:
this is SA warning bug
Workaround:
NA . this is SA warning bug
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(0)ZD(0.81) |
|
Known Fixed Releases: * | 7.0(0)BNZ(0.23), 7.0(0)KM(0.37), 7.0(2)NF(0.17), 7.1(0)ZD(0.40), 7.1(0)ZN(0.280), 7.1(3)ZN(0.313), 7.2(0)D1(1), 7.2(0)ZN(0.112), 7.2(1)N1(0.1), 7.2(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu73084 | Title: | HSRP Bundle in INIT state after reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
HSRP Anycast bundle goes to INIT state after reload.
Conditions:
HSRP Anycast bundle may go to INIT state after reload. This can happen if some interfaces come up later in the initialisation sequence after reload and makes the bundle in down state.
Workaround:
Shut and no shut the hsrp Anycast bundle to recover.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.2(10), 7.2(0)D1(0.484) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.75), 7.1(2)N1(0.558), 7.1(2)N1(1), 7.1(2)ZD(0.14), 7.1(2)ZN(0.17), 7.1(3)ZN(0.313), 7.2(0)D1(1), 7.2(1)D1(0.1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup11309 | Title: | Non MD5 HSRP Packets Processed When MD5 Configured |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A vulnerability in HSRP authentication of Cisco Nexus series could allow an unauthenticated, adjacent attacker to affect the state of HSRP group
members and cause blackholing of traffic.
The vulnerability is due to incorrect parsing of malformed HSRP packets. An attacker could exploit this vulnerability by sending malformed HSRP
packets to bypass HSRP authentication. An exploit could allow the attacker to bypass HSRP authentication and affect the state of active HSRP group
members, causing them to go to SPEAK state and thus leading to blackholing of traffic and a denial of service (DoS) condition.
Conditions:
Cisco NX-OS devices configured for TEXT or MD5 group authentication will accept malformed HSRP packets leading to bypass of authentication. A
potential attacker can affect the state of HSRP group members, causing them to release ACTIVE/STANDBY roles and go back to SPEAK state.
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
4.8/4.6:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:P/A:P/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2014-3295 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2014-3295
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S14, 7.1(0)D1(0.194), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)IF(99.16), 7.1(0)N1(0.245), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur59789 | Title: | while configuring vrf Unrecognized IP message minor type 33 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
while configuring vrf Unrecognized IP message minor type 33
Conditions:
This failure message is seen by every DFA customer when they deploy a new VRF via auto-config.
Workaround:
Further Problem Description:
|
|
Last Modified: | 18-JUN-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.299), 7.1(0)N1 |
|
Known Fixed Releases: * | 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.1(1)N1(0.500), 7.1(1)N1(1), 7.1(1)ZD(0.31), 7.1(1)ZN(0.54), 7.1(3)ZN(0.313), 7.2(0)AB(9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup64806 | Title: | Update banner on titanium login |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When logging in to titanium we display this banner where we need to update to reflect NX-OS instead of NX/OS.
***************************************************************************
* Titanium is strictly limited to Cisco's internal use for evaluation, *
* demonstration and NX/OS education. Any use or disclosure, in whole or *
* in part, of the Titanium Software or Documentation to any third party *
* for any purposes is expressly prohibited except as otherwise *
* authorized by Cisco in writing. *
***************************************************************************
Conditions:
When logging in
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.0(1)ZD(0.216) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)D1(0.327), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.403), 7.1(0)N1(1), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq75175 | Title: | 0-120 secs of pkt loss on activating PIM SMU on vpc+ setup. DR change |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On activating a PIM SMU is causing DR change in my vpc+ setup, thus deleting one of the BDI from the OIF causing traffic drop of around 0-120 seconds
Conditions:
activating a PIM SMU DR change occurs in VPC+ setup
Workaround:
Further Problem Description:
|
|
Last Modified: | 18-JUN-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.221) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.264), 7.1(0)OTT(0.36), 7.1(0)PDB(0.213), 7.1(0)SIB(99.38), 7.1(0)ZD(0.313), 7.1(0)ZN(0.413) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq40658 | Title: | N7K - SNMP - support for show log level snmpmib_proc |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If CLI "logging level snmpmib " is configured and is not the default level 2, "show running-config" will display the config as "logging level snmpmib_proc " rather than "logging level snmpmib ". So if the running config is saved into a file and used to replay, the config "logging level snmpmib_proc " will be rejected as the syntax is "logging level snmpmib ".
Conditions:
Image with version 6.2(2) and onward.
Workaround:
There are two workarounds for config replay:
1. Config the log level to default level 2 before save the config.
2. Manually modify the saved config file, changing "logging level snmpmib_proc " to "logging level snmpmib " before replay.
Further Problem Description:
|
|
Last Modified: | 18-JUN-2016 |
|
Known Affected Releases: | 6.2(10)S47, 6.2(13)S6, 7.1(0)D1(0.254) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.244), 7.1(0)D1(0.256), 7.1(0)N1(0.318), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.31), 7.1(0)PDB(0.183) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq23138 | Title: | first collapse of pi71-sjc-l2o-bnb |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
B&B collapse, not applicable
Conditions:
B&B collapse, not applicable
Workaround:
B&B collapse, not applicable
Further Problem Description:
|
|
Last Modified: | 18-JUN-2016 |
|
Known Affected Releases: | 7.1(0)ZD(0.272) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.228), 7.1(0)N1(0.281), 7.1(0)N1(0.321), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.179), 7.1(0)ZD(0.281) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud61168 | Title: | SNMPWalk fallback on ifHCInOctets for FEX interfaces |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:SNMPWalk fallback on ifHCInOctets for Nexus7K Fex interface
Conditions:We see the IF Counters for N7K FEX interface fall back frequently for one polling cycle. The next polling cycle, the counter values are fine.
Workaround:The counters can be obtained via cli when snmp fails.
More Info:For N5k/N2k the bug is fixed in 5.2(1)N1(8), 6.0(2)N2(1) and later releases.
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 6.0(3)E2, 6.2(1.79)S2 |
|
Known Fixed Releases: * | 5.2(1)N1(7.113), 5.2(1)N1(8), 5.2(4)FD(0.32), 5.2(4)FD(0.33), 5.2(9), 5.2(9)S26, 6.0(2)N2(1), 6.1(0)FE(0.32), 6.1(0)FE(0.33), 6.1(0)FE(0.34) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty99763 | Title: | Host vpc : same Actor Port number used with symmetric configuration |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a host vpc configuration where the server is dual-attached to fex'es, LACP port bundling may fail with the links ending up in suspending state as the server stops sending PDUs.
Conditions:
This is seen when the host vpc is configured across two fex'es with the same number, using the same port on each fex.
Workaround:
Use asymetric configuration, for instance port 101/1/1 on one fex, 101/1/2 on the other fex; or port 101/1/1 on one fex, 102/1/1 on the other.
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 6.2(0)FH(0.5), 6.2(0)FH(0.9), 6.2(0.157)S0, 6.2(1.17)S0, 6.2(2), 7.1(0)D1(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux03524 | Title: | N7k: Multicast traffic not transmitted towards FEX on same FE as source |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When multicast source exists on the same FE as the FEX fabric link, the receiver connected to the FEX HIF won't receive the multicast stream.
Conditions:
- Multicast source and receiver setup for pim sparse-mode
- LC: N7K-M224XP-23L
- SW: 6.2.2-14
Workaround:
Move the FEX fabric link to a different FE as the source (either same LC or different LC).
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 6.2(14), 6.2(2) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S51, 7.2(2)D1(0.48), 7.2(2)ZD(0.140), 7.3(0)DX(0.143), 7.3(0)DX(1), 7.3(1)D1(0.48), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy16372 | Title: | N7K No autostate on admin down SVI brings it into operationally up state |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
An N7K SVI may be in an operationally up state even when it is configured to be shut down.
Conditions:
An admin down SVI for which autostate is disabled.
Workaround:
1) Re-enable auto state
2) Bounce the interface with "no shut" followed by "shut"
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(14), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.38), 7.2(2)ZD(0.82), 7.3(0)TSH(0.99), 7.3(1)D1(0.12), 7.3(1)PDB(0.10) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux96258 | Title: | Multiple issues with LISP PxTR functionality |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:When LISP remove subscriptions to RNH notifications, in some cases, the forwarding entry to which that RNH applies is also removed although a valid route is still present in the routing table.
Conditions:When customer clears a LISP map-cache using command "clear ip lisp map-cache"
Workaround:clear ip lisp map-cache and clear ip route will solve the issue.
|
|
Last Modified: | 21-JUN-2016 |
|
Known Affected Releases: | 7.3(0)D1(1), 7.3(0)DX(0.140) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva16707 | Title: | F3 - static MAC programmed for TCAM Bucket0 |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Traffic destined to CPU is flooded instead of being punted.
This causes symptoms such as ARP being incomplete, L3 routed traffic not getting routed correctly
Following error is message is observed:
%MTM-SLOT1-4-BUCKET_ZERO_COLLISION: Mac 0000.0c9f.fc4b vlan 160 got replaced from FE inst 0 due to collision
Conditions:
We have determined this is a result of the Interface VLAN MAC address not programmed in the hardware
Workaround:
shut/no shut of the interface vlan
This will force the switch to reprogram the router mac address
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo39308 | Title: | An LLDP frame with length of 0 in an optional TLV is discarded |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The following syslog message is seen on an NX-OS device:
2014 Apr 1 16:31:13.550 N7K_1 LLDP-3-INVALID_LLDP_RECEIVED Received an invalid LLDP on Eth4/31
1.This bug will be seen in N7K 6.2.8 and all the N7K releases before that
2.This bug has been resolved and will not be seen in 6.2.10 and onwards.
Conditions:
An LLDP peer of an NXOS device is including an optional TLV in the LLDP frame with a length of 0. This particular optional TLV does not have a specified minimum length per the LLDP standard (802.1AB)
Also, the logging level for lldp has been increased from its default of '2' to 3 or higher:
N7K_1# show logging level lldp
Facility Default Severity Current Session Severity
-------- ---------------- ------------------------
lldp 2 5 <<<<<<<<<<<<<<<<<<<<<<<
0(emergencies) 1(alerts) 2(critical)
3(errors) 4(warnings) 5(notifications)
Workaround:
N7K_1# conf t
N7K_1(config)# logging level lldp 2
N7K_1(config)# end
N7K_1# copy running-config startup-config
Note:
1. This bug will be seen in N7K 6.2.8 and all the N7K releases before that.This workaround will only stop the syslog server/local log file from being flooded with LLDP-3-INVALID_LLDP_RECEIVED messages. This will not change the behaviour of the Nexus device to process this frame as a valid LLDP frame.Workaround is valid only for N7k releases 6.2.8 and before that.
2. Bug is resolved in 6.2.10 and hence will not be seen in 6.2.10 and onwards.
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: * | 6.1(2)I3(1), 6.2(0)FH(0.155), 6.2(10), 6.2(10)CM(0.27), 6.2(10)EC(0.21), 6.2(10)FM(0.26), 6.2(10)NO(0.20), 6.2(8)E10, 6.2(8)KR(0.8), 6.2(8)TS(0.28) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy50118 | Title: | N7k / N77k - Multiple Fex 2300 reports fan failure |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
Multiple FEX FAN minor alarm at different times. This is seen/applicable for 23xx series FEX's:
%SATCTRL-FEXxxx-2-SOHMS_DIAG_ERROR: FEX-xxx System minor alarm on fans in fan tray 1
%SATCTRL-FEXxxx-2-SOHMS_DIAG_ERROR: FEX-xxx Recovered: System minor alarm on fans in fan tray 1
%SATCTRL-FEXyyy-2-SOHMS_DIAG_ERROR: FEX-yyy System minor alarm on fans in fan tray 1
%SATCTRL-FEXyyy-2-SOHMS_DIAG_ERROR: FEX-yyy Recovered: System minor alarm on fans in fan tray 1
Conditions:
Reason for the above error message is because of wrong sensor values being considered for calculating the environment temperature and hence adjusting the fan speed.
Workaround:
software upgrade
Further Problem Description:
none
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(2)FIP(0.199), 7.0(2)FIP(0.200), 7.0(2)FIP(0.201), 7.2(2)D1(0.59), 7.2(2)D1(0.61), 7.2(2)ZD(0.150), 7.2(2)ZD(0.153) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux62214 | Title: | L2FM consistency checker can cause memory leak / crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
L2fm process crashes with signal 6
Conditions:
Either running CLI "show forwarding consistency checker" every 5 minutes or at a higher frequency on switch Or running CLI in background via script (EEM with scheduler OR py script)
Workaround:
There is no workaround
Do not use this CLI more often than a day.
Further Problem Description:
|
|
Last Modified: | 23-JUN-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.2(2)D1(0.48), 7.2(2)ZD(0.140), 7.3(0)D1(1), 7.3(0)TSH(0.99), 7.3(0)ZD(0.238), 7.3(1)D1(0.2), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq57422 | Title: | vPC: Peer-Switch is not Supported on Non-Root Peers |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
The following symptoms have been seen:
- vPC peer-link going into ALT BLK state
- Device not participating in STP with rest of network after upgrade
Conditions:
Peer-switch enabled on a non-root device
Workaround:
Disable peer-switch on non-root device
Further Problem Description:
For the peer-switch feature to be supported the vPC peer's that it is being enabled on must be the root of the STP.
|
|
Last Modified: | 24-JUN-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz74998 | Title: | igmp static-oif fails when using route-map |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
when using route-maps to configure igmp static-oifs, we do not see creation of (s,G) entry.
this works in verison 7.2(1)N1(1):
interface Vlan20
no shutdown
ip address 20.1.1.1/24
ip pim sparse-mode
ip igmp version 3
ip igmp static-oif route-map nws-sources
route-map nws-sources permit 10
match ip multicast source 10.1.1.2/32 group 232.1.2.7/32
N6K-2# sh ip mroute
IP Multicast Routing Table for VRF "default"
(10.1.1.2/32, 232.1.2.7/32), uptime: 00:09:04, ip pim static
Incoming interface: Vlan10, RPF nbr: 10.1.1.2
Outgoing interface list: (count: 1)
Vlan20, uptime: 00:02:54, static
once upgrade to 7.3(0)N1(1) : (S,G) entry does not get populated.
Conditions:
Workaround:
configure static-oif , by specifying the group and source under vlan 20:
N6k-2(config-if)# ip igmp static-oif 232.1.2.7 source 10.1.1.2
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)N1(1) |
|
Known Fixed Releases: * | 7.3(1)DX(0.56), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo63486 | Title: | LLDP - link err-disabled upon reload when dcbx tlv is disabled |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Interface get error disabled upon switch reboot due to DCX-No ACK in 100 PDUs. DCBX tlv is disabled on the switch
Conditions:
N7K: 6.2.2a
N5K: 7.0(0)N1(1)
LLDP enabled
Workaround:
Disable LLDP
Further Problem Description:
Please note:
The problem described in this software defect is about that we dont correctly create a piece of the binary configuration in the Nexus switch when we turn the dcbx off on the switch and save the configuration.
The fix in this software defect is to create this part of the binary confiuration correct.
However when you upgrade from a impacted version to a fixed version, i.e. 7.0(3)N1(1) has the fix, we do NOT
automatically create the correct binary key.
The user needs to do the following after the upgrade, and it does not matter if that upgrade is done disruptive or non disruptive.
lldp tlv-select dcbxp
no lldp tlv-select dcbxp
copy running-config startup-config
With the first command you turn dcbx back on, then we turn it back off to make sure that the runtime status is turned off, and then with the saving of the configuration we generate the correct binary configuration.
From then on going forward you can reload the switch or upgrade in the future to a higher version without impacting the configuration of dcbx.
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 6.2(2a) |
|
Known Fixed Releases: * | 6.0(2)A4(0.760), 6.0(2)A4(1), 6.0(2)U4(0.760), 6.0(2)U4(1), 6.2(10), 6.2(10)FM(0.27), 6.2(10)NO(0.20), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0 |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz99069 | Title: | N77 - PCAP debug packet snmp dura 100 - "sh: nice: command not found" |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
N77 - PCAP debug packet snmp dura 100 - "sh: nice: command not found"
Conditions:
Issue seen only on Sup2 cards.
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(1), 7.3(1)DX(0.43) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv81861 | Title: | OSPF NSSA sending type 7 LSA after converted to regular area |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Type 7 LSA being sent by a device that is not a NSSA device
Conditions:
After changing from NSSA to regular area
Workaround:
None
Further Problem Description:
Recovery: restart ospf
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 12.0(0.145), 12.0(1.8), 12.1(0.8), 7.0(3)I2(1.19), 7.0(3)I2(2), 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.47), 7.3(0)PDB(0.112) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz34593 | Title: | N7K: Incorrect filename when issuing 'copy run ftp' |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The Nexus 7K does not save the configuration filename correctly on the remote host when performing a "copy running-config ftp". This behaviour has been observed on both the default and non-default VDC's.
When performing an FTP copy to a remote host, the command allows the user to use the default filename or to specify a different name. In either case the result always writes the file as "HOSTNAME-running-config".
Example:
N7K# copy run ftp://ftp.cisco.com/system.cfg
filename on remote host: N7K-running-config
Conditions:
Workaround:
Rename the file on the remote host
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: * | 6.2(14), 6.2(15) |
|
Known Fixed Releases: | 7.2(2)D1(0.71), 7.2(2)ZD(0.162), 7.3(1)DX(0.60) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva31129 | Title: | "Unable to resolve NH" on peer in Unicast OTV after switchover |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
On N7k switchover, Unicast OTV peer starts showing "unable to resolve NH" for OTV routes.
Conditions:
stateful switchover on Nexus 7000
Workaround:
shut/no shut overlay interface on Nexus 7000
or
Reload OTV VDC
Further Problem Description:
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz21548 | Title: | ISSU MDP replay avoidance with no model change |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
none
Conditions:
none
Workaround:
none
Further Problem Description:
none
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.0(3)I4(0.74), 7.0(3)IED5(0.140) |
|
Known Fixed Releases: * | 7.0(3)IED5(0), 7.0(3)IED5(0.137), 7.0(3)IED5(0.142), 7.0(3)IED5(0.145), 7.0(3)IED5(0.146) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva18560 | Title: | clearing an IPv6 lisp map-cache does not remove it from forwarding |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
What we are seeing is that when we clear an IPv6 lisp map-cache, the cache is removed both from lisp and uRIB but the forwarding entry remains (and breaks some regressions :)). This is easy to repro if you need a testbed to gather logs/retry
Let me illustrate:
(1) We have an IPv6 map-cache
lisp3-n7k-1# show ipv6 lisp map-cache vrf se1
LISP IPv6 Mapping Cache for VRF "se1" (iid 16777211), 1 entries
* = Locator data counters are cumulative across all EID-prefixes
110:114:5::/48, uptime: 00:00:02, expires: 23:59:57, via map-reply, auth
Locator Uptime State Priority/ Data Control MTU
Weight in/out in/out
99.99.0.40 00:00:02 up 1/100 0/0* 0/0 1500
(2) We clear the map-cache and check that it is removed from the routing table.
lisp3-n7k-1# clear ipv6 lisp map-cache vrf se1
lisp3-n7k-1# show ipv6 route vrf se1
IPv6 Routing Table for VRF "se1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
11:11:5::/48, ubest/mbest: 1/0, attached
*via 11:11:5::10, Eth3/1/1.5, [0/0], 00:29:09, direct,
11:11:5::10/128, ubest/mbest: 1/0, attached
*via 11:11:5::10, Eth3/1/1.5, [0/0], 00:29:09, local
200:1:1::/48, ubest/mbest: 1/0
*via 11:11:5::1/128, [1/0], 00:29:06, static
200:2:1::/48, ubest/mbest: 1/0
*via 11:11:5::1/128, [1/0], 00:29:06, static
(3) However the the forwarding entry still remains.
lisp3-n7k-1# show forwarding ipv6 route vrf se1
(...)
IPv6 routes for table se1/base
'*' denotes recursive route
--------------------+---------------------------------------+----------------------+-----------------
Prefix | Next-hop | Interface | Labels
--------------------+---------------------------------------+----------------------+-----------------
0::/127 Drop Null0
fe80::/10 Receive sup-eth1
ff00::/8 Drop Null0
11:11:5::/48 Attached Ethernet3/1/1.5
11:11:5::1/128 11:11:5::1 Ethernet3/1/1.5
11:11:5::10/128 Receive sup-eth1
110:114:5::/48 Src 22.22.0.10 Dest 99.99.0.40 LISP Encap
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 7.3(1)DX(0.61) |
|
Known Fixed Releases: * | 7.3(1)DX(0.75) |
|
|
| |
| |
|
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: | 01-JUN-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)DX(1), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu48646 | Title: | snmpwalk on ccmHistoryStartupLastChanged always returns 0 |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
snmpwalk on OID ccmHistoryStartupLastChanged always returns a zero irrespective of startup config getting modified
Conditions:
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: | 6.2(12), 7.3(0)ZD(0.99) |
|
Known Fixed Releases: * | 8.3(0)CV(0.426), 8.3(0)MVA(0.11) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz44784 | Title: | FIB Consistency checker fail for NVE loopback on M3 |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
After running consistency checker, it will report inconsistencies for NVE loopback interface IP address.
Conditions:
VxLAN or VxLAN EVPN configurations must be present.
Workaround:
Further Problem Description:
It has no impact on traffic, just the consistency checker shows this loopback route as inconsistent in FIB hardware.
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
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: | 13-JUN-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DG(0.3), 7.3(0)DX(0.65), 7.3(0)DX(1), 7.3(0)EG(0.14), 7.3(0)UCI(0.2), 7.3(1)FTO(0.7), 8.3(0)CV(0.436), 8.3(0)MVA(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd78947 | Title: | Duplicate N7K online help for some exec commands |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Nexus7000 displays duplicate online help for some exec commands:
n7k-1# debug pktmgr?
pktmgr Packet manager debug/tunnel information
pktmgr Pm debug
n7k-1#
n7k-1# undebug pktmgr?
pktmgr Packet manager debug/tunnel information
pktmgr Pm debug
n7k-1#
n7k-1# test hard?
hardware Hardware
hardware Test hardware internal parameters
n7k-1#
Conditions:
Online help.
Workaround:
Ignore the duplicate.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(2a) |
|
Known Fixed Releases: * | 5.0(1.33), 5.0(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCte01050 | Title: | Enh: Sorting EEM Applet/Script Lexiconically |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
EEM Applet not displayed in alphabetic/lexiconical order under configuration
Conditions:
When checking EEM configuration using "show run eem", the output is not sorted based on alphabetic/lexiconical order which makes it difficult for users to verify applets named similarly for tracking purpose.
csw01a.snc4(config-applet)# sh run eem
!Command: show running-config eem
!Time: Mon Nov 23 15:01:56 2009
version 4.2(2aE1)
event manager applet AUTOSTATE_27_DN
event track 27 state down
action 1.0 syslog priority warnings msg "### WARNING Vlan2027 shut by EEM"
action 2.0 cli config terminal
action 3.0 cli interface vlan 2027
action 4.0 cli shutdown
action 5.0 cli end
event manager applet AUTOSTATE_11_UP
event track 11 state up
action 1.0 syslog priority warnings msg "### WARNING Vlan2011 unshut by EEM"
action 2.0 cli config terminal
action 3.0 cli interface vlan 2011
action 4.0 cli no shutdown
action 5.0 cli end
Workaround:
None
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(5.20), 5.0(2), 5.0(2.51), 5.0(2.52), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCte82187 | Title: | N7K: show vrf output misaligned when vrf name is >25 characters |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | "show vrf" output is misaligned when the vrf name is longer than 25 characters.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 5.0(2), 5.0(2.3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl01368 | Title: | N7k - NTP - parser issue with prefer keywork in ntp server. |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: |
It is not possible to add prefer keyword to an existing NTP server configuration.
work-around :
To be able to use prefer keyword , the ntp server configuration should first be removed and
reapplied with prefer keyword,
Example
Nexus(config)# sh run ntp
version 5.1(1)
ntp server x.x.x.x use-vrf management
--------------------prefer keyword is added to existing server but ignored.
Nexus(config)# ntp server x.x.x.x prefer use-vrf management
Nexus(config)# sh run ntp
!Command: show running-config ntp
!Time: Wed Dec 15 08:31:22 2010
version 5.1(1)
ntp server x.x.x.x use-vrf management
---------------- we remove server and create it again with prefer , now
it is there
Nexus(config)# no ntp server x.x.x.x use-vrf management
Nexus(config)# sh run ntp
version 5.1(1)
Nexus(config)# ntp server x.x.x.x prefer use-vrf management
Nexus(config)# sh run ntp
!Command: show running-config ntp
ntp server x.x.x.x prefer use-vrf management
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(1), 5.2(0.180)S6 |
|
Known Fixed Releases: * | 5.2(0.236)S0, 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtd00667 | Title: | Incorrect online help for 'clear ntp statistics' options |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The online help for 'clear ntp statistics' shows the following, which is not correct:
n7k# clear ntp statistics ?
all-peers Clear IO statistics
io Clear IO statistics
local Clear IO statistics
memory Clear IO statistics
For reference, the online help for 'sh ntp statistics':
n7k# sh ntp statistics ?
io Show the input-output statistics.
local Show the counters maintained by the local NTP.
memory Show the statistics counters related to memory code.
peer Show the per-peer statistics counter of a peer.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(2a) |
|
Known Fixed Releases: * | 5.0(0.257), 5.0(1), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg36399 | Title: | running config of eem snmp-trap action includes hidden attributes |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom :
Copy and paste of EEM SNMP policy configuration output from "show running-config" fails when applied to a device.
Description :
If the user configures a SNMP trap action as part of an EEM policy as
action 1.0 snmp-trap intdata1 10 intdata2 20 strdata "hello"
the "show running-config eem" will show extra text as below :
action 1.0 snmp-trap intdata1 10 intdata2 20 strdata "hello" event-type $_event_type policy-name $_policy_name
Copy-Paste of the above remapped CLI from the output of "show running config" would fail for each of the "action snmp-trap" commands.
Workaround :
When doing a copy and paste, remove the two extra parameters from the "action" command.
E.g when doing a "show running-config" the output looks as below
event manager applet TEST
action 1.0 snmp-trap strdata "test" event-type $_event_type policy-name $_policy_name
remove the "event-type" and "policy-name" option text and apply (as below)
<....>
event manager applet TEST
action 1.0 snmp-trap strdata "test"
<....>
Fix for this bug is available as part of 4.2(6), 5.0(2) and higher releases.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(1), 5.0(2) |
|
Known Fixed Releases: * | 4.2(6)S5, 4.2(6.15)S0, 5.0(2)S81, 5.0(2.79)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn65427 | Title: | SNMPd Crash when using CcCopyEntry in CISCO-CONFIG-COPY-MIB |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
If SNMPSET via the Cisco-Config-Copy-MIB is executed in certain conditions SNMPd may be seen to crash.
OID in question would be:
1.3.6.1.4.1.9.9.96.1.1.1.1.14. i 1
Conditions:
This is only seen if SNMP debugs are enabled while the snmpset is executed, and the variables for the entry have not been set/the entry has not been created properly.
Workaround:
1) Don't run snmp debugs when using SNMPSET via the CISCO-CONFIG-COPY-MIB.
2) After you Destroy the entry (setting integer to 6) make sure to Create and Wait (integer 5) before attempting to set the variables.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: * | 5.2(1)N1(1), 5.2(2)S17, 5.2(2.14)S0, 5.3(0.216)S0, 6.0(0.2)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta78608 | Title: | 'no user role' error is obfusicated |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
no username and no snmp-server username commands produce confusing a error message when trying to delete a users last role/group.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(5) |
|
Known Fixed Releases: * | 5.0(0.219), 5.0(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti16039 | Title: | Need clean up with logging level commands |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
NX-OS 5.0.3 and 4.2.6 need clean up with regard to following issues.
a) "logging level all x" does not take an effect on some facilities.
b) Some facilities do not appear both in running-config and startup-config
so will revert to default level after reload.
aclmgr
device_test
diagclient
feature-mgr
fs-daemon
ifmgr
ipqosmgr
oc_usd
res_mgr
sksd
hsrp
Few facilities appear in running-config but startup-config even after copying.
confcheck
feature-mgr
ufdm
c) Three facilities below appear both in running-config and startup-config
but revert to default level after reload.
The configured logging level is still seen in startup-config after reload but
in running-config.
evmc
mvsh
smm
Conditions:
Workaround:
For a), user can change logging level individually.
For b) and c), user need to re-modify logging level after reload.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(6), 5.0(3), 5.1(3), 5.2(1) |
|
Known Fixed Releases: * | 5.1(1)S5, 5.1(1.17)S0, 5.1(1.22)S0, 5.1(1.32)S0, 5.1(1.35)S0, 5.1(1.43)S0, 5.1(1.6)S0, 5.1(2.9)S0, 5.2(0.168)S0, 5.2(1)S52 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts43705 | Title: | Edinburgh: Enabling feature otv gives orib_sysmgr_main: unknown syslog |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
An error message below appears when enabling otv feature.
This is not an error requiring action. After this bug fix, this message will be suppressed.
ORIB-3-UNKNOWN_ORIB_MAJOR: orib [26778] orib_sysmgr_main: unknown major mtype: 79881
Condition:
When enabling 'feature otv'.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.0(0.36) |
|
Known Fixed Releases: * | 6.0(0.55)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf30682 | Title: | delete SVI w/ GLBP configured causes /32 null route to VIP |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
If an SVI with GLBP is deleted without first removing GLBP from SVI the uRIB will then show a /32 null route to the VIP
nexus-4.2.3(config)# sh ip route 192.168.1.2
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
192.168.1.2/32, ubest/mbest: 1/0
*via 192.168.1.2, (null), [0/0], 00:00:12, glbp
Conditions:
SVI must have GLBP VIP configured. SVI must be up and in the uRIB. SVI must be deleted without first removing GLBP config.
Workaround:
clear ip route x.x.x.x
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(5.3), 5.0(3)S23, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb79510 | Title: | config parser helper lists - "no" twice |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Online context help shows duplicate entries for "no" command as below :
switch(conf)# ?
<...>
no Negate a command or set its defaults
no Negate a comment, a command or set a command's default
<...>
Conditions:
This happens when the online context help is invoked using the "?" key, from the config mode.
There is no functionality impact.
Workaround(s):
None
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(1), 5.0(0.203) |
|
Known Fixed Releases: * | 4.2(2.25), 4.2(3), 4.2(4), 5.0(0.214), 5.0(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto01883 | Title: | OTV Site vlan goes down on STP topology change |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Long OTV convergence when links to spanning tree root fails and alternative blocked port is selected
Conditions:
OTV Site vlan goes down momentarily when STP re convergences
Workaround:
None
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 6.0(0.42)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz43535 | Title: | Backup VRRP not reachable when same real and virtual used on master |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
When VRRP is configured and same ip is used for VRRP IP address and real address. Backup server IP addres is not reachable from master.
Conditions:
This is happen only when real and vrrp ip is same.
Workaround:
Use dedicated VRRP IP address (differnt than real ip used on router interface)
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(5), 4.2(1) |
|
Known Fixed Releases: * | 4.2(0.230), 4.2(0.247), 4.2(1), 4.2(2.24), 4.2(3), 7.1(0)ZN(0.284), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsx75637 | Title: | n7k: with HSRP preemption timer running active router shows as "unknown" |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: |
Symptom:
When preemption delay is configured on a HSRP interface, if you run a show hsrp interface during the preemption time you will the Active router will be "unknown".
This output is not correct and there is a neighbor present on the segment
Conditions:
Preemption delay must be configured on the HSRP interface.
Workaround:
none
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(3) |
|
Known Fixed Releases: * | 4.2(0.201), 4.2(1), 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj78354 | Title: | %VSHD-5-VSHD_SYSLOG_CONFIG_I: Configured from vty by admin on vsh. |
|
Status: | Other |
|
Severity: | 4 Minor |
Description: * | Symptom:
Logs may appear while nobody is accessing the device :
%VSHD-5-VSHD_SYSLOG_CONFIG_I: Configured from vty by admin on console
%VSHD-5-VSHD_SYSLOG_CONFIG_I: Configured from vty by admin on vsh
Conditions:
Cosmetic - triggered by internal processes. May happen during bootup, interface flap, system switchover or other conditions.
Workaround:
unknown
Further Problem Description:
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.2(5.27)S0 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsy40411 | Title: | Nexus VRRP master responds to unconfigured virtual address |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptoms
A Nexus 7000 may keep an unconfigured VRRP virtual address active.
After the reconfiguration of the virtual address, ping and telnet to the
unconfigured address is still successful.
Conditions
VRRP is active and running.
The virtual address is reconfigured.
Workaround
shut / no shut on both VRRP and/or physical interface does not clear the
issue.
To clear previous unconfigured addresses there is a need to remove the VRRP
feature and put back the VRRP configuration on the interface.
Nexus(config)# no feature vrrp
Note: when the feature is removed, the vrrp configuration is removed as well.
To avoid triggering this behaviour the configuration change needs to be done only when the group is shutdown.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(3) |
|
Known Fixed Releases: * | 4.1(5)E2, 4.2(0.176), 4.2(1), 7.1(0)ZN(0.284), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc62021 | Title: | Need a command to display and clear tmp directories |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Problem/Symptom:
SYSMGR-2-TMP_DIR_FULL: System temporary directory usage is unexpectedly high at 100%.
The above message means the /tmp directory which stores some application debug event
messages is full. However, there is no way for the user to look at what application is using the
directory, and also there is no way to clear it. This is an enhancement to get a 'show/clear' command for this operation.
There is no operational impact to the system because of this.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(1), 4.2(2) |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.39), 4.2(4), 5.0(0.255), 5.0(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti24202 | Title: | install license should be able to skip license in use |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:License fails to install with the following error message
Updating license failed: License is in use
Conditions:Nexus 7k has an existing permanent license in use and new
license has the same permanent license PKG
Workaround:Licenses are composed of "INCREMENT" and are modular.
check the output from
Nexus-7k# sh license usage
Feature Ins Lic Status Expiry Date Comments
Count
------------------------------------------------------------------------
--------
SCALABLE_SERVICES_PKG No - Unused -
TRANSPORT_SERVICES_PKG No - Unused -
LAN_ADVANCED_SERVICES_PKG Yes - Unused Never -
LAN_ENTERPRISE_SERVICES_PKG Yes - In use Never -
------------------------------------------------------------------------
--------
Check the new license file by using "show file" command.
If the license file has an "INCREMENT" section that has the same PKG name as
one of the license in use, then please get separate licenses for individual
PKG.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.3(0.1), 6.0(0.1) |
|
Known Fixed Releases: * | 5.2(0.87)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti15486 | Title: | dns done to "dino" rather than "dino.cisco.com" |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
On a Nexus 7k ftp,tftp,scp,sftp in vrf management might fail initially if domain name resolution is used.
Conditions:
vrf management only
Workaround(s):
none
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(6) |
|
Known Fixed Releases: * | 4.2(7.80)S0, 5.0(6.19)S0, 5.0(6.22)S0, 5.1(0.229)S0, 5.1(1), 5.1(1)S21, 5.1(1.18)S0, 5.1(1.22)S0, 5.1(1.32)S0, 5.1(1.41)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl60413 | Title: | "show ip ospf policy statistics redistribute <type>" not showing outputs |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Command "show ip ospf policy statistics redistribute " is not giving any outputs.
Conditions:
Ospf configured for redistribution via route-maps
i.e:
router ospf 1
router-id 1.1.1.1
redistribute direct route-map CONNECTED
redistribute static route-map STATIC
redistribute rip test route-map RIP
default-metric 20
Workaround:
none
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3), 5.0(5), 5.1(2) |
|
Known Fixed Releases: * | 5.2(0.190)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq37520 | Title: | ciscoFTPClientMIB: memory leak after an snmpwalk |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Perform an ftp copy in the system.
snmpwalk ciscoftpclient mib [1.3.6.1.4.1.9.9.80] and a memory leak will be seen in the Nexus 7K
Conditions:
N/A
Workaround(s):
Switchover to get SNMP to respond again
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 4.2(7b)E4, 4.2(8)S25, 4.2(8.98)S0, 5.0(6.124)S0, 5.1(10.41)S0, 5.1(5)S3, 5.2(1)S29, 5.2(1.34)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn41963 | Title: | Nexus7000: ospfv3: default-information originate may not work properly |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
ospfv3 "default-information originate" may not work.
1) to apply "default-information originate" to Nexus7000-A
Nexus7000-A
router ospf 1
router-id 1.1.1.1
default-information originate
2) to add default route on Nexus7000-A
ipv6 route 0::/0 Null0
3) "show ipv6 route" from Nexus7000-B never see the default route
Nexus7000-B# sh ipv6 route
IPv6 Routing Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
2001::/64, ubest/mbest: 1/0, attached
*via 2001::2, Vlan4, [0/0], 1d04h, direct,
2001::2/128, ubest/mbest: 1/0, attached
*via 2001::2, Vlan4, [0/0], 1d04h, local
2002::/64, ubest/mbest: 1/0
*via fe80::21b:54ff:fec2:b7c1, Vlan4, [110/80], 1d04h, ospfv3-1, intra
Conditions:
ospfv3
Workaround:
re-configure "default-information originate" on nexus7000
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: * | 5.2(0.222)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn89642 | Title: | Nexus no installing type5 LSA in routing table |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: |
A Nexus7000 may be unable to install type-5 external LSA in the routing table when the forward address is non-null. This occurs when the forward address interface is passive, and
advertised in OSPF via other interfaces, and at the same time seen as connected on the Nexus.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2a), 5.1(2) |
|
Known Fixed Releases: * | 5.2(0.251)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto98401 | Title: | N7K cannot flush OSPF non area type compatible LSA |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Nexus is not able to flush the LSA which is not compatible with the area type in configuration
Conditions:
The issue seen when we change the area type from normal area to stub or NSSA area.
Due to this change we need to flush all type 4 LSA in the database.
Nexus tries to flush the LSA by sending type 4 LSA with age of 3600 but it does not flush the same from its own database thus it continues to send type 4 LSA with age of 3600.
This is reported as error on other routers in that area. Clearing the ospf process has no effect.
This is generic defect, which could be applied to any area type change in OSPF.
Workaround:
Reconfigure ospf in that area or restart the ospf process.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(8), 5.1(2) |
|
Known Fixed Releases: * | 5.2(8.1)S0, 5.2(9), 6.0(2)N2(1), 6.0(2)U1(1), 6.1(4.1)S0, 6.1(5), 6.2(0.19)S0, 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti05555 | Title: | vPC: PIM Assert Storm in Dual vPC Design |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
PIM assert storm between different vPC pairs
Conditions:
- PIM enabled
- Same vPC domain ID between different vPC pairs
Workaround:
Use unique vPC domain IDs between different vPC pairs.
Further Problem Description:
This enhancement adds a log message to report when the same vPC domain IDs are used between different pairs.
Issue can also be seen across OTV.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 4.2(8)S6, 4.2(8.10)S0, 5.2(1)S34, 5.2(1.39)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto17595 | Title: | Garbage information displayed when doing ISSU |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
While doing install all the system displays the following garbage information
Additional info for this installation:
--------------------------------------
Do you want to continue with the installation (y/n)? [n] n
Conditions:
Nexus 7000 running 5.1.2
Workaround:
None at this time.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(2), 5.1(5)S14 |
|
Known Fixed Releases: * | 5.2(0.257)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg90224 | Title: | Nexus7000 doesn't generate network LSA |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Nexus7000 does not generate a network LSA for the link it is the DR for. Then neighbors of the Nexus7000 on this link will not install any routes advertised by the Nexus.
Conditions:
"timers throttle lsa all" is manually configured with a high start interval
Workaround:
Make a different device the DR
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 4.2(7.6)S0, 5.1(0.146)S0, 5.1(0.159)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn68302 | Title: | High cpu on N7K due to dcos_sshd |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom: High cpu due to SSH and dcos_sshd
Conditions: When the N7k receives SSH logins at very high rates the dcos_sshd process can cause high cpu
Workaround: None.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 5.0(3)U1(2a), 5.0(6.68)S0, 5.1(10.1)S0, 5.2(0.248)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr88670 | Title: | Redistribute BGP route to OSPF sets wrong forwarding address |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
OSPF forward address is set to 0.0.0.0 when it should be the actual next hop
Conditions:
Type 5 LSA redistributed from BGP into OSPF
Workaround:
none
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(4) |
|
Known Fixed Releases: * | 5.2(2.35)S0, 6.0(0.31)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq45837 | Title: | Nexus7000: RIP: default-information originate may not work properly |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
default route may not be advertised via rip if route summarization is
configured.
Conditions:
RIP route information is summarized by ip rip summary-address x.x.x.x
Workaround:
none
+---------+ e2/10 +---------+
| N7K-A |--------------| N7K-B |
+---------+ e2/10 +---------+
N7K-B# sh run rip
!Command: show running-config rip
!Time: Mon May 23 18:26:26 2011
version 5.1(3)
feature rip
ip route 0.0.0.0/0 1.0.0.1
router rip TEST
address-family ipv4 unicast
default-information originate always <---###
interface loopback2
ip address 192.168.1.1/32
ip router rip TEST
interface Ethernet2/10
ip router rip TEST
ip rip summary-address 192.168.0.0/16 <---###
N7K-A(config-if)# sh ip route rip
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
<----- default route is not seen!!!
192.168.0.0/16, ubest/mbest: 1/0
*via 172.16.0.2, Eth2/10, [120/2], 00:09:15, rip-TEST, rip
If route summarization is not used, the default route is seen properly.
N7K-A(config-if)# sh ip route rip
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
0.0.0.0/0, ubest/mbest: 1/0 <---###
*via 172.16.0.2, Eth2/10, [120/2], 00:00:06, rip-TEST, rip
192.168.1.1/32, ubest/mbest: 1/0
*via 172.16.0.2, Eth2/10, [120/2], 00:00:06, rip-TEST, rip
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(3), 5.2(1)S12 |
|
Known Fixed Releases: * | 5.2(1)S30, 5.2(1.35)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts20665 | Title: | OSPF type3 default route remains in ospf database after removing stub |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
OSPF type3 default route remains in ospf database after removing ospf
stub configuration
Conditions:
NX-OS 5.2(1), 5.1(4), 4.2(8)
Once ospf totally stub configuration applied, and then remove it.
After removing stub configuration, ospf database has type3 default
route.
For example:
router ospf 1
router-id 172.16.1.1
area 0.0.0.1 stub no-summary <--- totally stub
N7K(config-router)# no area 1 stub
Summary Network Link States (Area 0.0.0.1)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 172.16.1.1 1785 0x80000008 0x2b22 <--- ###
Workaround:
when removing totally stub configuration, please follow the steps.
1. "no area 0.0.0.1 stub no-summary"
2. "no area 0.0.0.1 stub"
When you encounter the issue, you can recover from the problem by
restarting ospf process.
"restart ospf "
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(8), 5.1(4), 5.2(1) |
|
Known Fixed Releases: * | 5.2(1)N1(1), 5.2(2.38)S0, 6.0(0.39)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti62294 | Title: | Unable to clear (set) P bit on NSSA ASBR |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | When an extra area is inadvertently added to an NSSA ASBR, the existing Type 7 LSA's will have their P bit set to 0 once the maxage is reached. This is expected since the device is now a NSSA ABR.
When the extraneous configuration is removed, and the device is purely an NSSA ASBR the P bit is not set to 1 and remains set to 0.
If you remove the redistribute statement at the ASBR, wait for a few seconds (for LSA to flush) and add it back in, the P bit gets set again.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(6) |
|
Known Fixed Releases: * | 5.1(1.1)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj04651 | Title: | switchport interfaces show up as members of default vrf |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Under some circumstance, layer 2 (switchport) interfaces will show up as part of the default vrf when the command 'show vrf interfaces' is issued.
Conditions:
This issue may be seen across reload of systems running 5.0(3) and later
Workaround:
The problem is cosmetic, and will not affect performance of the switch.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 5.1(1.18)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsx09749 | Title: | Netstack error message for failed packet lenght check |
|
Status: | Other |
|
Severity: | 4 Minor |
Description: |
Symptoms
A Nexus 7000 may exhibit repeated NETSTACK-3-CPI_ERR error logs for failed
packet length checks.
Sample message:
%NETSTACK-3-CPI_ERR: netstack [<#>] Failed to build packet to mbufsk. Packet
length mismatch. len = <#>, actual len = <#>
Conditions
This behaviour was first detected on a Nexus7000 model running version 4.1(2)
Further Informations
Please be aware, that this issue is not fixed in 4.1(3). Release 4.1(3)
contains further debugging methods in order to identify packets, which causing
this error message.
Workaround
None.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(2) |
|
Known Fixed Releases: * | 4.1(3), 4.1(5), 4.2(0.142), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr84507 | Title: | max-metric router-lsa external-lsa does not work for default routes |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
"max-metric router-lsa external-lsa" does not modify the
default route which is generated by using "default-info originate "
Conditions:
The issue is seen at the first occurance when "max-metric router-lsa external-lsa" is applied.
The metric of all other external routes is modified, but the default route stays unaffected
Workaround:
remove and add the default-info originate command
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(1) |
|
Known Fixed Releases: * | 5.2(3.28)S0, 6.0(0.21)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva04566 | Title: | N7K Doc PBR - hardware access-list allow deny ace |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
Usage of '[no] hardware access-list allow deny ace' global configuration command is incorrect in both 6.x and 7.x 'Configuring Policy-Based Routing' chapter of the 'Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide' ('Configuring a Deny ACE' paragraph).
The '[no] hardware access-list allow deny ace' global configuration command should be set in the default or admin VDC
Conditions:
Configuration of the '[no] hardware access-list allow deny ace' global configuration command as per following instructions:
Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide
Chapter: Configuring Policy-Based Routing
Configuring Policy-Based Routing - Configuring a Deny ACE
Before You Begin
Ensure that you are in the correct VDC (or use the switchto vdc command). <<<<<<<<<<< Incorrect
Workaround:
Before You Begin
Ensure that you are in the default or admin VDC.
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti00817 | Title: | SNMP VACM issue |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptoms:
Affected versions of NX-OS allow an authenticated, remote attacker to gain unauthorized access to information via the View-based Access Control
MIB. As a result, the attacker could enumerate valid SNMPv3 communities and users.
Conditions:
Affected versions of NX-OS on Nexus 7k devices when SNMP is enabled with Read or Write access.
Workaround:
Disable SNMP.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 4/3.3:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:S/C:P/I:N/A:N/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2012-1371 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: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: * | 5.0(4)S1, 5.0(4.4)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt06723 | Title: | delete/add dynamic-eid causes U6RIB traceback |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Traceback from U6RIB will be seen after deleting / re-adding dynamic-eid.
Conditions:
It will be seen If the dynamic-eid you are deleting and re-adding is associated a SVI
Workaround:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(1), 5.2(2)S99, 6.2(0.1) |
|
Known Fixed Releases: * | 5.2(2.77)S0, 6.0(2)S8, 6.1(0.146)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti71344 | Title: | NX-OS: "ip ospf advertise-subnet" cmd doesn't apply to secondary IP's |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Description:
Issue 1: "ip ospf advertise subnet" cmd does not apply to secondary addresses
The "ip ospf advertise-subnet" command does not advertise the proper subnet mask for secondary IP addresses configured on a loopback interface. When the command is applied to a loopback interface, the primary IP address mask is advertised as configured, but any secondary addresses are advertised as a /32. The behavior for this command should be consistent for all IP addresses configured on a loopback interface.
Issue 2: secondary addresses not advertised properly (Impacts Routing)
The example below demonstrates this behavior where 192.168.2.1/24 is advertised as 192.168.2.0/32, so the 192.168.2.1 address is not reachable. This address should be advertised as 192.168.2.1/32. If the address is configured as a /32 it is advertised correctly (ie: 192.168.2.1/32) and routing works as expected. This issue is independent of "Issue 1". This only seems to be an issue with loopback interfaces. (/32's are not configurable on Ethernet interfaces.)
Workaround:
None - Configuring secondary IP addresses on loopback interfaces isn't very common.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 5.1(1.6)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn17295 | Title: | N7k & MDS 5.0(3) snmp agent high CPU when malloc fails |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Nexus 7018 snmpd CPU HOG under some conditions when busy
Conditions:
Under certain condition when SNMP is busy and memory allocation fails the process remains stuck in a loop creating high CPU.
Workaround:
none
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(3), 5.1(3) |
|
Known Fixed Releases: * | 5.2(1)S13, 5.2(1.15)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsy25021 | Title: | TCP MSS incorrectly advertised when Nexus 7000 is active TCP client |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: |
Symptom:
NxOS may show an mss value different to what is seen to be negotiated in a sniffer trace when
looking at 'show sockets connection tcp detail' for any TCP connection. An example is for BGP peering
between a 7206VXR and Nexus 7000.
On Nexus7000:
N7K-1#show sockets connection tcp local 10.100.100.3 detail
Total number of tcp sockets: 10
Active connections (including servers)
Local host: 10.100.100.3 (26916), Foreign host: 10.100.100.1 (179)
Protocol: tcp, type: stream, ttl: 64, tos: 0xc0, Id: 20
Options: , state: none
Receive buffer:
cc: 0, hiwat: 16384, lowat: 1, flags: none
Send buffer:
cc: 0, hiwat: 16384, lowat: 2048, flags:
Sequence number state:
iss: 3443745278, snduna: 3443745451, sndnxt: 3443745451, sndwnd: 16212
irs: 101087528, rcvnxt: 101087631, rcvwnd: 16384, sndcwnd: 2048
Timing parameters:
srtt: 6400 ms, rtt: 0 ms, rttv: 1000 ms, krtt: 1000 ms
rttmin: 1000 ms, mss: 512, duration: 10500 ms
State: ESTABLISHED
Flags: none
Context: default
On 7206VXR:
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled
Local host: 10.100.100.1, Local port: 179
Foreign host: 10.100.100.3, Foreign port: 26916
Connection tableid (VRF): 0
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x71DBC248):
Timer Starts Wakeups Next
Retrans 4 0 0x0
TimeWait 0 0 0x0
AckHold 4 2 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
iss: 101087528 snduna: 101087650 sndnxt: 101087650 sndwnd: 16384
irs: 3443745278 rcvnxt: 3443745470 rcvwnd: 16193 delrcvwnd: 191
SRTT: 124 ms, RTTO: 1405 ms, RTV: 1281 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
Rcvd: 8 (out of order: 0), with data: 4, total data bytes: 191
Sent: 6 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 3, total data
bytes: 121
Conditions:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(4) |
|
Known Fixed Releases: * | 4.2(0.200), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCul63090 | Title: | ICMP ping from standby to HSRP VIP does not work with uRPF |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
On a pair of Nexus 7000s, pinging from the Nexus 7000 which has the standby HSRP group to the HSRP VIP fails when loose uRPF (ip verify unicast source reachable-via any) is configured.
Conditions:
This issue is observed when fabricpath/vPC+ is enabled.
Workaround:
Removing loose uRPF fixes the issue.
However, as only IP traffic from the standby to the VIP is affected, this issue will not have any impact on production traffic.
Further Problem Description:
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsu87911 | Title: | MSN: Buffer_append_space syslig seen on switch-sshd |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | This bug is seen intermittently and is not easily reproducible.
This syslog is an error message logged by ssh and doesn't seem to impact anything.
Symptom:
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: | 4.1(3) |
|
Known Fixed Releases: | 4.1(3), 4.2(0.120), 4.2(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy20186 | Title: | N77 - otv site ISIS-4-LAN_DUP_SYSID needs backoff algorithms |
|
Status: | Open |
|
Severity: * | 5 Cosmetic |
Description: | Symptom:
Following DUP SYSID error message seen on all OTV VDC's
Different type console messages can be seen depending on features enabled:
MESSAGE TYPE #1 - otv, isis features enabled
2016 Jan 29 02:13:25 N7K-250-16-N7K-250-17 %ISIS_OTV-4-SYSLOG_SL_MSG_WARNING: ISIS-4-LAN_DUP_SYSID: message repeated 67000 times in last 60 sec
MESSAGE TYPE #2 - fabricpath, isis features enabled
2016 Feb 5 19:07:38 N7K-250-16 %ISIS_FABRICPATH-4-SYSLOG_SL_MSG_WARNING: ISIS-4-P2P_DUP_SYSID: message repeated 667015 times in last 60 sec
Conditions:
CONDITION #1 - physical loopback or physical loopback device connected.
Physical loopbacks and physical loopback devices are not supported.
CONDITION #2 - otv config is very basic, and needs to be changed to be unique values for each vdc or switch
Workaround:
### CONDITION #1
Interface admin "shutdown" works for all Workarounds in CONDITION #1.
1a) remove illegal physical loopback device
1b) shutdown port where illegal device is attached
1c) find loop in your network usually with fiber Tx/Rx mismatch, and
use this udld and errdisable CLI command to discover location of mis-connected fiber:
"show interface status err-disable | include udldLoop"
### CONDITION #2
2a) assign unique otv site identifier to each vdc and switch
"otv site-identifier 0x1" <-- do not use this everywhere
## possible unique value
"otv site-identifier 0x22"
Further Problem Description:
|
|
Last Modified: | 06-JUN-2016 |
|
Known Affected Releases: | 6.2(16)S32, 7.3(0)D1(1), 7.3(0)DX(0.87) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz99510 | Title: | NXOS replay with label |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
NXOS replay with vpn label for traceroute to unaccesible ip
Conditions:
Workaround:
n/a
Further Problem Description:
.
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 6.2(14)S5 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz99520 | Title: | NXOS PE replay with MPLS label for traceroute to unacessible ip |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
NXOS PE replay with MPLS label for traceroute to unacessible ip
Conditions:
.
Workaround:
n/a
Further Problem Description:
.
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsz87082 | Title: | "no preempt delay min 30 rel 30" doesnt remove the cfg |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptoms
When a HSRP group is configured with two tracked objects/interfaces, as well an
equal value for both the minimum prempt timer and reload prempt timer, it is
observed that following a HSRP failover (as a result of shutting one of the
tracked interfaces) the wrong counter decrements in the output of "show hsrp
interface".
Conditions
This is only observed if the following conditions are met:
-The HSRP preempt reload timer is equal to the HSRP preempt minimum timer.
-The interface running HSRP is configured to track two different
objects/interfaces, configured with decrement values to the priority.
-A legitimate failover occurs (i.e one of the tracked interfaces is shut
down).
Workaround
Use different values for the reload and minimum preempt timers.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(5) |
|
Known Fixed Releases: * | 4.2(4), 4.2(4.5), 4.2(5), 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc98478 | Title: | LLDP option not in feature help list |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
LLDP does not appear in the feature list when "feature ?" is executed from the CLI
Workaround:
No workaround is necessary. The issue is cosmetic in nature.
LLDP is not supported in 4.2 release. Remove LLDP feature and related command completely in 4.2
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(2a) |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.23), 4.2(4), 7.0(0)ZD(0.35), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg16415 | Title: | N7K: snmp-server filter-vrf keyword has same help string as use-vrf. |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | snmp-server host command shows the same help string for use-vrf and filter-vrf keywords.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 5.1(0.126)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb87331 | Title: | N7K - show ntp peer-status output mis-aligned |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | show ntp peer-stat command has mis-aligned output.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(2.20), 4.2(3), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum26305 | Title: | vPC+ suspends due to type-1 consistency check on hardware type |
|
Status: | Terminated |
|
Severity: | 5 Cosmetic |
Description: * | Symptom:
vPC+ suspends when the final vPC member link is removed on peer device. vPC suspends the remaining link on the local vPC+ device due to hardware consistency.
This was observed on F2e cards.
Conditions:
occurs when removing the final link on the vPC+ peer device causing the hardware type 'Empty'.
This occurs even though graceful consistency check is enabled (default)
Workaround:
use a dummy link on peer device if it is required to remove the final operational link. This will prevent the hardware type 'Empty'
Further Problem Description:
N7K-3(config-if)# sh vpc
>>Legend:
>> (*) - local vPC is down, forwarding via vPC peer-link
>>
>>vPC domain id : 10
>>vPC+ switch id : 10
>>Peer status : peer adjacency formed ok
>>vPC keep-alive status : peer is alive
>>vPC fabricpath status : peer is not reachable through
>>fabricpath
>>Configuration consistency status : success
>>Per-vlan consistency status : success
>>Type-2 inconsistency reason : Consistency Check Not Performed
>>vPC role : secondary
>>Number of vPCs configured : 1
>>Peer Gateway : Enabled
>>Peer gateway excluded VLANs :
>>105,1041,1851,2891,3201,3651,3891,3911
>>Dual-active excluded VLANs : -
>>Graceful Consistency Check : Enabled
>>Auto-recovery status : Enabled (timeout = 240 seconds)
>>Fabricpath load balancing : Disabled
>>Port Channel Limit : limit to 244
>>
>>vPC Peer-link status
>>---------------------------------------------------------------------
>>id Port Status Active vlans
>>-- ---- ------ --------------------------------------------------
>>1 Po11 up -
>>
>>vPC status
>>----------------------------------------------------------------------
>>-
>>---
>>--
>>id Port Status Consistency Reason Active vlans vPC+
>>Attribute
>>-- ---- ------ ----------- ------ ------------
>>--------------
>>803 Po803 down* failed Local card type - DF: No, FP
>> does not match MAC:
>> with peer's 10.1.65535
>>N7K-3(config-if)# sh int eth1/1
>>Ethernet1/1 is down (suspended by vpc) admin state is up, Dedicated
>>Interface
>> Belongs to Po803
>> Hardware: 1000/10000 Ethernet, address: 6c9c.ed48.253c (bia
>>6c9c.ed48.253c)
>> Description: *** EUWT1R2101 1/33 ***
>> MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec
>> reliability 255/255, txload 1/255, rxload 1/255
>> Encapsulation ARPA, medium is broadcast
>> Port mode is trunk
>> auto-duplex, 1000 Mb/s, media type is 1G
>> Beacon is turned off
>> Auto-Negotiation is turned off
>> Input flow-control is off, output flow-control is off
>> Auto-mdix is turned on
>> Rate mode is dedicated
>> Switchport monitor is off
>> EtherType is 0x8100
>> EEE (efficient-ethernet) : n/a
>> Last link flapped 00:00:26
>> Last clearing of "show interface" counters 00:07:04
>> 3 interface resets
>> 30 seconds input rate 0 bits/sec, 0 packets/sec
>> 30 seconds output rate 0 bits/sec, 0 packets/sec
>&
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb25171 | Title: | suppress harmless error messages in syslog |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: |
Symptom:
Following message is outputted in syslogs sometimes, but this is harmless message.
We should supress this kind of harmless message.
%NETSTACK-3-INTERNAL_ERROR: netstack [3969] Current time
could not be obtained while processing timer callback
Conditions:
Unknown
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(5) |
|
Known Fixed Releases: * | 4.2(2), 4.2(2.6), 4.2(3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc04285 | Title: | "show ip ospf" shows incorrect no. of stubs/nssa areas after HA trigger. |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
"show ip ospf XXX" shows incorrect no. of stubs/nssa areas after any HA trigger.
Conditions:
- Perform any HA related trigger (switchover, crash restart, ISSU etc).
- Then the output of the command "show ip ospf xxx" shows incorrect no. of stub/nssa areas.
Workaround:
- This bug is purely cosmetic. No routing impact.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.2(5)S23 |
|
Known Fixed Releases: * | 5.2(8.13)S0, 5.2(9), 6.0(2)N2(1), 6.1(4.1)S0, 6.1(5), 6.2(0.228)S0, 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc87500 | Title: | ospf lsa throttle timer inconsistency |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Default delay for initial ospf LSA generation is said to be 50 msec, while in reality 0 msec is used when default timers are configured
Workaround:
to have 0 msec - nothing to do
to have 50 msec - configure 'timers throttle lsa 50 5000 5000' under ospf router configuration
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(2) |
|
Known Fixed Releases: * | 4.2(3), 4.2(3.26), 4.2(4), 5.0(0.253), 5.0(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta11916 | Title: | ppf_process_msg() failed with error - Invalid operation (0x4117000c) |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
the following message may be logged:
%RPM-3-INFRA_SYSERR: rpm [5138] ppf_process_msg() failed with error - Invalid operation (0x4117000c) - in rpm_process_ppf_queue_msg()
Workaround:
none required. this message is harmless.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(5)E3 |
|
Known Fixed Releases: * | 4.2(1), 4.2(1.10), 4.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn53651 | Title: | RIP Debugs should show metric |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
debug rip outbound does not show the metric of the outbound RIP update.
This is an enhancement to add the outgoing metric to the routes that are being advertised by RIP in the debug output.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2) |
|
Known Fixed Releases: * | 5.2(0.236)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux79503 | Title: | [vPC]: "show vpc consistency-parameters" O/P truncated/incomplete |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Nexus 7K will not see all the VLANs that are actually 'Interface-vlan routing capable' or 'allowed VLANs', if the customer has a lot of VLANs configured and running vpc.
Output will be truncated after about '74' characters or slightly shorter if it cannot fit another VLAN range into the output without completion
Conditions:
Nexus device running vpc with a lot of Vlans configured in many disjoint ranges
Workaround:
Cosmetic in nature, no workaround
Further Problem Description:
The VLANs are up and running, passing traffic , however this can be concerning to a customer who runs this command and does not see the expected VLANs in the output.
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: * | 6.2(12)S33, 6.2(14), 7.3(0)D1(0.194) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 01-JUN-2016 |
|
Known Affected Releases: | 6.0(4) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.3(0)DG(0.3), 7.3(0)DX(0.29), 7.3(0)DX(1), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv65642 | Title: | configuring vni crashes the Line Card UFIB process |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
LC ufib crash
Conditions:
vni config command
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 01-JUN-2016 |
|
Known Affected Releases: | 7.0(0)HSK(0.494) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)FFW(0.11), 7.0(0)HSK(0.522), 7.3(0)DX(0.4), 7.3(0)DX(1), 7.3(0)EG(0.14), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud74810 | Title: | Nexus 7000 scheduler should convert repeat timer to correct ranges. |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
When using the scheduler command 'start time now repeat dd:HH:MM', it's possible to enter high values for HH and MM.
These are not converted to correct ranges (HH should be less than 24 and MM should be less than 60).
From 'show scheduler schedule':
Schedule Type : Run every 0 Days 500 Hrs 121 Mins
Conditions:
This can be configured on any nexus 7000.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 04-JUN-2016 |
|
Known Affected Releases: | 6.0(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva00012 | Title: | add multiple support for RTs per opflex framework |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
After initial config through postman with import/export RT set.
Then though GUI, add one import rt config under ipv4, see in spine it gets correct update:
....
EVPN Export RT list:
2234:1003
EVPN Import RT list:
1234:1003 <--- newly added
2234:1003
Conditions:
When multiple RT values are configured for a VRF on APIC, only the last RT values received from the Opflex server on the spine is auto- provisioned on the DCI.
Workaround:
Ensure only one RT values set is provisioned on the APIC for a VRF.
If needing to update RT values for a VRF, first delete the initial RT values and then create a new set of RT values.
Further Problem Description:
|
|
Last Modified: | 08-JUN-2016 |
|
Known Affected Releases: | 7.3(1)DX(0.9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty67801 | Title: | SVI should not be allowed for vpls vlan |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
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: | 08-JUN-2016 |
|
Known Affected Releases: | 5.2(0)LV1(0.274), 6.2(1.125)S6, 7.3(0)D1(1) |
|
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: | 13-JUN-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: | CSCuf90519 | Title: | N7k support to download large SGT,DGT pairs. |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
N7k cannot handle radius packets larger than 4k (so fragmented), meaning it will not tolerate if ACS/ISE send a packet with too many attributes.
This is particularly impacting in TrustSec if you have a very large egress policy matrix
Conditions:
Nexus 7k
Workaround:
RFC 2865 states that the maximum RADIUS packet size is 4096.
Thus the N7K was correct to drop these packets. ICE shouldn't
send RADIUS packets larger than 4096. Please refer to bug CSCuf90492.
It was filed against ICE so that it would not send RADIUS packets larger
than 4096. Upgrade your ICE appliance to get the fix for CSCuf90492
in order to resolve this problem.
Further Problem Description:
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: * | 6.0(2)N2(2), 6.2(0)FM(0.13), 6.2(0)FM(0.39), 6.2(4.2)S0, 6.2(6), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111), 8.3(0)CSS(0.4), 8.3(0)CV(0.398), 8.3(0)SF(0.94) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsq20638 | Title: | NxOS: Need support for access-list under line vty |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: |
This is an enhancement request to add functionality in NX-OS to configure
access-lists under a line vty to control telnet access
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.0(1.51) |
|
Known Fixed Releases: * | 5.1(0.126)S0, 5.1(0.135)S0, 5.1(0.149)S0, 5.1(0.174)S0, 5.1(0.54), 5.1(0.57), 5.1(1), 7.0(1)ZD(0.3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsv33349 | Title: | NTP on NX-OS is missing some capabilities compared to NTP on IOS |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: |
Symptom:
NX-OS is missing the following functions that exist in IOS.
NTP access-lists:
- [no] ntp access-group {query-only | serve-only | serve |
peer} access-list
NTP authentication:
- [no] ntp authenticate
- [no] ntp authentication-key (number) md5 (md5)
- [no] ntp trusted-key (number)
NTP Broadcast client (per interface)
- [no] ntp broadcast client
- [no] ntp disable
NTP Broadcast server (per interface)
- [no] ntp broadcast [destination {ipaddr} | {hostname}]
[key {key}] [version {version}]
NTP multicast client and server (per interface):
- [no] ntp multicast client [ipaddr]
- [no] ntp multicast {ipaddr} [key {key}] [ttl {val}]
[version {version}]
NTP logging/debugging:
- [no] ntp logging
NTP master:
- [no] ntp master [stratum]
Workaround:
none
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 5.0(0.226), 5.0(1), 5.2(0.170)S0, 5.2(0.171)S0, 5.2(0.180)S0, 6.2(0.166)S0, 6.2(0.255)S0, 6.2(2), 7.0(1)ZD(0.3), 7.1(0)ZN(0.231) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth57793 | Title: | CLI knob is required to change the SNMP packet size |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
SNMP packets could be up to 4K bytes in size. The packet size cannot be set manually in cases the NMS cannot handle large packer sizes.
Conditions:
Need a CLI command option to set the SNMP packet size.
Workaround:
None
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 4.2(7.62)S0, 4.2(7.67)S0, 5.0(4.16)S0, 5.0(4.30)S0, 5.1(0.224)S0, 5.1(0.236)S0, 5.1(1), 7.0(1)ZD(0.3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsy14845 | Title: | Callhome: descriptive alert messages for syslog-group-port |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Need to add functionality for generating descriptive alert messages for syslog-group-port.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 3.3(2) |
|
Known Fixed Releases: * | 4.2(0.203), 4.2(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsr17024 | Title: | N7K: Need ACL support in "snmp-server community" command. |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Need ACL support with "snmp-server community" command.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.0(2) |
|
Known Fixed Releases: * | 4.2(0.166), 4.2(0.206), 4.2(1), 7.0(1)ZD(0.3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsy42923 | Title: | Need counter for number of cache entries in acl logging |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Enhancement request to add number of cache entries installed in the output of show logging ip access-list cache
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.1(3) |
|
Known Fixed Releases: * | 4.2(3.44), 4.2(4), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti62141 | Title: | Need Source-IP check with HSRP |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Enhancement request for HSRP to do source-iP address check on HSRP hello packets, to discard router orginated HSRP hellos looped back by devices.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(6) |
|
Known Fixed Releases: * | 4.2(8)S1, 4.2(8.2)S0, 5.1(1.4)S0, 7.0(0)ZD(0.123), 7.0(1)ZD(0.3), 7.1(0)ZD(0.95), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCte07484 | Title: | N7K: Timezone is not displayed in syslog and debug |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Time Zone is not displayed in syslog and debug messages irrespective of the configuration.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 4.2(4), 4.2(4.35), 4.2(5), 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf72503 | Title: | Need CBQos Mib on N7k |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: |
Symptom:Observing following errors on N7k running 5.1(5E2)
2013 Apr 10 19:14:15 iad12-12-ws-cor-r201 %USER-3-SYSTEM_MSG: Exception at: qosmgr_get_sys_def_tmap/86 - ipqosmgr
2013 Apr 10 19:14:15 iad12-12-ws-cor-r201 %USER-3-SYSTEM_MSG: Exception at: qosmgr_pss_recover_sys_def_tmap/3753 - ipqosmgr
Conditions:If you were previously running NXOS 5.2 or later and then downgraded the image to 5.1 using ISSU. Issue will not be seen, if you use 'reload' after the downgrade of NXOS to 5.1
Workaround:Reload the switch, instead of ISSU, if you need to downgrade from 5.2.x to 5.1
More Info:iad12-12-ws-cor-r201# show system reset-reason
----- reset reason for Supervisor-module 9 (from Supervisor in slot 9) ---
2) At 86086 usecs after Wed Apr 10 12:02:01 2013
Reason: Reset due to upgrade
Service:
Version: 5.2(5) ======> Downgraded from 5.2(5) to 5.1(5E2)
iad12-12-ws-cor-r201# show system internal ipqos event-history errors
4) Event:E_DEBUG, length:77, at 374848 usecs after Sat Sep 14 21:36:40 2013
[114] qosmgr_pss_show_startup (1724):No code to gen ascii config for type: 35
5) Event:E_DEBUG, length:77, at 374825 usecs after Sat Sep 14 21:36:40 2013
[114] qosmgr_pss_show_startup (1724):No code to gen ascii config for type: 35
Above Error Type 35 is not defined in 5.1 code, while it points to "QOSMGR_PSS_RUNTIME_SNMP_CONFIG_INDEX_NODEID = 35" in 5.2, as part of new feature/code . After you downgraded the NXOS, this is causing the PSS(Config storage) sync issue and these errors.
This issue caused due to use of "install all" command to downgrade the code and then executing "show startup-config" after that at some point of time.
So there are two triggers for the issue
1. install all command
2. show startup-config ( in 5.1.5)
You can avoid this issue by changing the boot statements and reloading ( not doing install all ), but we still recommend to the following steps to avoid any other weirdness that make occur from the downgrade.
1:Write erase ( will remove start up configuration)
2:Relod the switch
3:Re-apply the old configuration { old config here means startup or running configuration before reload }
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 5.2(0.166)S0, 5.2(0.166)S1, 5.2(0.168)S0, 7.0(1)ZD(0.3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc35020 | Title: | NX-OS doesn't have "telnet" with "source-interface" |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
NX-OS doesn't support "telnet" with "source-interface" option.
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 5.0(0.311), 5.0(1), 5.0(1.1), 5.0(2), 5.0(2.18), 7.0(1)ZD(0.3), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt32509 | Title: | N7K ENH: increase NTP authentication key limit |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The key limit has been increased to 15 characters. But in the older versions the have the limit as 8 characters.
- So after downgrade, consequent ascii replay may fail for authentication key config.
- After downgrade, deleting a longer key might fail.
Conditions:
ISSD
Workaround(s):
- Delete the key and then downgrde.
- (or) After ISSD overwrite the longer key with a smaller key. After this the key can be deleted too.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 5.1(3)N1(1), 5.2(1)N1(1), 5.2(3)S4, 5.2(3.4)S0, 6.0(2)S17, 6.1(0.160)S0, 7.1(0)ZN(0.231), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub53825 | Title: | Thirdparty cores handling |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
This bug completes the fix introduced in CSCth31107.
A log message can now be seen in the 'sh logging log' when a process which is not managed by NxOS crashes and produces a core.
This core should be seen under /var/sysmgr/log and can be cleared through 'clear core'.
This wasn't possible through CSCth31107.
Conditions:
Observed when a third party process crashes.
Workaround:
None.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.2(5), 6.1(1) |
|
Known Fixed Releases: * | 6.0(2)N3(0.330), 6.0(2)N3(1), 6.1(1.75)S0, 6.1(2), 6.2(0.285), 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCte54283 | Title: | Add banner to alert upcoming license expiry after successful user login |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom: Users don't get a warning about license expiration at login time.
Status: License expiry warning messages will be displayed at the time of user login when license expiry is less than 15 days. If expiry time is less than 7 days, then the users should acknowledge that, they understand the risk when license expires, to proceed further.
Workaround (for older releases): Run "show license usage" after login.
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.0(0.296) |
|
Known Fixed Releases: * | 5.0(2), 5.0(2.11), 5.0(2.21), 5.0(2.28), 7.1(0)BF(0.74), 7.1(0)ZD(0.158), 7.1(0)ZD(0.225), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg00438 | Title: | Need a way to syslog per-class COPP drops based on thresholds |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Enhancement request to provide syslogging of CoPP drops, based on configured threshold, on a per class basis.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 5.1(0.154)S0, 5.1(0.221)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl74196 | Title: | NX-OS - Commands required to disable SNMP coldstart and warmstart traps |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Nexus OS does not provide a way to turn off SNMP warmstart and SNMP coldstart traps. They are enabled by default and cannot be disabled.
Conditions:
N/A
Workaround:
None
|
|
Last Modified: | 16-JUN-2016 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: * | 5.2(0.227)S0, 6.2(0.2)S0, 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn96236 | Title: | 7k enh: FHR should send PIM registers until register-stop is received |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Currently n7k will send register packets until it has created an entry in hardware.
The current enhancement will cause FHR to send register packets until Register stop is received per RFC 4601
Conditions:
PIM Sparse mode registration process at First Hop Router.
Workaround:
None.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(6) |
|
Known Fixed Releases: * | 4.2(8)S11, 4.2(8)S15, 4.2(8.44)S0, 4.2(8.56)S0, 5.2(0.248)S0, 5.2(0.249)S0, 5.2(0.255)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg27778 | Title: | CISCO-INTERFACE-XCVR-MONITOR-MIB should be part of central snmpinfra |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
A new MIB was introduced into NX-OS "CISCO-INTERFACE-XCVR-MONITOR-MIB".
This mib provides monitoring information about the transceivers plugged into interface on a system. SNMP agent receives traps of 1.3.6.1.4.1.9.9.706 from admin-down ports that affects
device management operation of customers.
Conditions:
- configurations necessary for snmp trap
- transceivers are inserted
Workaround(s):
Currently there is no options to disable the traps from admin-down ports.
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.0(2) |
|
Known Fixed Releases: * | 5.0(4.10)S0, 5.1(0.216)S0, 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto57603 | Title: | OSPFV3-4-IF_ERR when creating multiple OSPFv3 processes |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Following message is logged when multiple OSPFv3 processes are created
%OSPFV3-4-IF_ERR:ospfv3-2 [2904] Packet from received on non-ospf-enabled interface
Conditions:
Multiple OSPFv3 processes are created
Workaround:
Changing logging level to 3 or higher, the message will not be logged.
switch(config)# logging level ospfv3 3
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.2(1)S6, 5.2(1.8)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb73380 | Title: | NX-OS should allow redistribution into EIGRP based on next-hop |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Redistribution with match ip next-hop is not supported in NX-OS. When this condition is used, all the routes will be redistributed, not just the ones that match the next-hop condition.
Conditions:
Match ip next-hop only works for BGP currently with NX-OS. This does not work for any other protocols.
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.1(5) |
|
Known Fixed Releases: * | 5.1(0.92), 5.1(1), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg85948 | Title: | PIM rp-address route-map not granular, no deny option |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:Current CLI does not provide an intuitive means to configure granular PIM RP-to-group policies when using a route-map to set mappings. There is no method to DENY one or more non-contiguous group(s), and then permitting the balance of the group address block.
Conditions:
Workaround:Use a static route to null0, and map the groups to a RP address within this static route. An example is, for policy to map all groups to RP 10.7.7.7 EXCEPT group 239.1.1.1
ip route 10.1.1.1 255.255.255.255 null0
ip pim rp-address 10.1.1.1 route-map xyz
ip pim rp-address 10.7.7.7 route-map abc
!
route-map xyz permit 10
match ip multicast group 239.1.1.1/32
!
route-map abc permit 10
match ip multicast group 224.0.0.0/4
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 5.2(0.236)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts14201 | Title: | Enable Freetown features [Was: RPM: Disable Freetown features from Edinb |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Disable set distance, set ip[v6] address prefix-list commands from Edinburgh.
Conditions:
None
Workaround:
None
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(0.1) |
|
Known Fixed Releases: * | 6.0(0.31)S0, 6.0(0.42)S0, 6.2(0.168)S0, 6.2(2), 7.1(3)ZN(0.312), 7.2(0)ZN(0.111), 8.3(0)CV(0.144) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun62888 | Title: | Add POAP support for Leaf behavior on N7K platforms |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Add POAP support for Leaf behavior on N7K platforms for inband ports.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-JUN-2016 |
|
Known Affected Releases: | 6.0(2)N3(1), 7.1(0)D1(0.12), 7.1(0)D1(0.52), 7.1(0)ZN(90.4) |
|
Known Fixed Releases: * | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.109), 7.1(0)D1(0.85), 7.1(0)NF(0.28), 7.1(0)PDB(0.38), 7.1(0)SDN(0.6), 7.1(0)ZD(0.138), 7.1(3)ZN(0.313), 7.2(0)D1(1), 7.2(0)ZN(0.112) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv67713 | Title: | Make MTU Change for FabricPath Transit switch to allow for VN-Seg |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Traffic from VN-Segment enabled Leaf switches gets dropped on the Spine when the network is configured for a default MTU of 1500.
Conditions:
Leaf switch vlans are configured for VN-Segmentation
Workaround:
Configure "system jumbomtu 1542" and configure "mtu 1542" on the N7K Spine interfaces.
Any value greater then 1542 can be used as well including 9216.
Further Problem Description:
|
|
Last Modified: | 21-JUN-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.44), 7.2(2)D1(0.45), 7.2(2)D1(0.67), 7.2(2)ZD(0.137) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux19585 | Title: | Increase the auto-recovery to 1 day (86400 secs) |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The maximum current delay time for vpc auto-recovery is 1 hour (3600 secs) only which could be a bottleneck sometimes in larger topologies with more and more number of vpc legs. We need the maximum delay time to be 24 hrs (86400 secs).
Conditions:
When the auto-recovery reload-delay is about to be configured.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 6.2(14)S24 |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.2(2)D1(0.43), 7.2(2)ZD(0.132), 7.3(0)D1(0.198), 7.3(0)D1(1), 7.3(0)HIB(0.3), 7.3(0)RSP(0.7), 7.3(0)TSH(0.99), 7.3(0)ZD(0.225) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo67369 | Title: | show lldp dcbx interface comand for fex interfaces throws error |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
lldp commands for fex are not working
Conditions:
-
Workaround:
-
Further Problem Description:
|
|
Last Modified: | 22-JUN-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.129) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(2)FG(0.15), 7.0(2)FG(0.17), 7.0(2)FIP(0.4), 7.1(0)D1(0.168), 7.1(0)D1(0.169), 7.1(0)D1(0.170), 7.1(0)FC(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum10900 | Title: | NX-OS "show ntp information" |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Implement a show command that will have the ability to reveal the NTP version currently running on the box, similarly to IOS command "show ntp information"
Conditions:
Any platform running NX-OS
Workaround:
As of now, we can capture the NTP packets using ethanalyzer to verify the version of NTP we are using.
Further Problem Description:
|
|
Last Modified: | 24-JUN-2016 |
|
Known Affected Releases: | 6.2(0.265), 6.2(0.284) |
|
Known Fixed Releases: * | 7.0(3)IED5(0), 7.0(3)IED5(0.137) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy31282 | Title: | XMLization support for HSRP MGO and HSRP Anycast features |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | In case of following CLI, there will be error in XML output :
1>show hsrp anycast summary
2> show hsrp mgo [name | brief]
3> show hsrp anycast [ { ipv4|ipv6|both} ] [brief]
4> show hsrp anycast interface { vlan | bdi }
5> show hsrp anycast remote-db [ { ipv4|ipv6|both } ]
Symptom:
For following CLI, XMLization is not supported:
1>show hsrp anycast summary
2> show hsrp mgo [name | brief]
3> show hsrp anycast [ { ipv4|ipv6|both} ] [brief]
4> show hsrp anycast interface { vlan | bdi }
5> show hsrp anycast remote-db [ { ipv4|ipv6|both } ]
Conditions:
If following CLI's are executed with | XML option, not proper XML output will be generated
1>show hsrp anycast summary
2> show hsrp mgo [name | brief]
3> show hsrp anycast [ { ipv4|ipv6|both} ] [brief]
4> show hsrp anycast interface { vlan | bdi }
5> show hsrp anycast remote-db [ { ipv4|ipv6|both } ]
Workaround(s):
Use CLI to get the output
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-JUN-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.77), 7.3(0)ZN(0.97) |
|
Known Fixed Releases: * | 7.3(1)DX(0.55), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc36684 | Title: | Enh: Need "feature scheduler" in Nexus 5000 |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
This is an enhancement request filed to get scheduler support for Nexus 5000/5500/5600.
Conditions:
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: | 7.2(0.9), 8.3(0)CV(0.99) |
|
Known Fixed Releases: * | 8.3(0)CV(0.525) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva28129 | Title: | stale entry of track Id 65537UP upon show track brief |
|
Status: * | Other |
|
Severity: * | 6 Enhancement |
Description: * | Symptom:
stale entry of track Id 65537UP upon show track brief
Conditions:
stale entry of track Id 65537UP upon show track brief
Workaround:
stale entry of track Id 65537UP upon show track brief
Further Problem Description:
stale entry of track Id 65537UP upon show track brief
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 7.3(1)DX(0.64) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva29567 | Title: | ENH : Disabling the iBGP AS-PATH loop prevention feature in Nexus. |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When we get an update from an iBGP peer having the same AS in the AS-PATH as the receiving router.
The router(Nexus) will drop this update. This is due to the fact that Nexus does AS-PATH loop prevention check for the updates received from iBGP peers as well.
This behavior is different in regular IOS , which does not perform the AS-PATH loop prevention check from the updates received from iBGP peers.
Conditions:
There is no such condition , there is a behavioural difference in NxOS and regular IOS.
Workaround:
Customer uses allow-as in from updates received from the iBGP peer.
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts88978 | Title: | Need explicit log msgs instead of logging 'last msg repeated n times' |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
'last msg repeated n times' will be printed for repeating msg
Conditions:
Repeating back-to-back msgs
Workaround(s):
None
Workaround:
Further Problem Description:
This enhancement adds the below config knob to enable/disable log rate-limiting:
(config)# [no] logging rate-limit
By default rate-limiting will be enabled.
To verify:
# show logging rate-limit
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 5.2(1), 6.2(1.125)S3 |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(6)N1(0.276), 7.0(6)N1(1b), 7.0(7)N1(1), 7.0(7)ZD(0.139), 7.0(7)ZN(0.133), 7.0(7)ZN(0.135), 7.1(0)AV(0.38), 7.1(0)D1(0.337) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts52692 | Title: | 'ARP Probe' packets needs to be processed by NXOS |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When NX-OX receives NX OS 'ARP probe' (i.e. 'sender ip address' of ARP request has all-zero), NX-OS ignores/drops these packets and logs the following error message:
IP-4-DAD_FAILED_EVENT: Duplicate address detected for [chars] on [chars]
According to RFC 5227, 'ARP probe' can be used for in-run duplicate IP address detection.
Conditions:
This bug affects all software up to 5.2.
Workaround(s):
None
|
|
Last Modified: | 01-JUL-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 6.0(0.59)S0, 7.1(3)ZN(0.312), 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCva32379 | Title: | Name resolution (DNS) does not resolve in the management VRF for POAP |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The customer tries to download the poap script from a tftp server in the mgmt vrf based on the servers domain name. Since the DNS resolution fails, customer is not able to download the poap script, and poap fails outright.
Conditions:
Upon receiving a DHCP Offer containing DNS information from the management VRF, we program the name-server to be in the default VRF (not the management like it should)
Workaround:
Use I.P address of server to run POAP
The working configuration should be "vrf context management ; ip name-server x.x.x.x"
Further Problem Description:
|
|
Last Modified: | 02-JUL-2016 |
|
Known Affected Releases: | 6.2(16) |
|
Known Fixed Releases: | |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论