| |
Bug Id: | CSCun57894 |
Title: | Memory leak is seen in the 'adjmgr' process |
|
Description: | Symptom:
Memory held by 'adjmgr' may increase over time and eventually be exhausted within the process. Alternatively, the following errors may be seen even though memory looks stable in the process -
am[3378]: Warning! Malloc Failure in ../routing-sw/libs/timers/active_timer.c[927] for size 8196
%ADJMGR-3-ATIMERS_ERROR: malloc failed in heap_create
Conditions:
No specific conditions or triggers are known at this time. This appears to occur during normal NX-OS operation.
Workaround:
None.
Further Problem Description:
To check memory within the process, the following command can be used -
show process memory | in adjmgr
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 7.1(0.1) |
|
Known Fixed Releases: | 7.0(1)N1(0.146), 7.0(1)N1(1), 7.0(1)ZD(0.145), 7.0(1)ZN(0.201) |
|
|
| |
| |
Bug Id: | CSCur03040 |
Title: | N7K - OTV crashes at isis_otv-default |
|
Description: | Symptom:
Nexus 7000 may experience a process crash with OTV configuration.
Reason: Reset triggered due to HA policy of Reset
System version: 6.2(8a)
Service: Service "__inst_001__isis_otv" in vdc 2 hap reset
Conditions:
OTV must be configured. This issue was first seen on 6.2(8).
Workaround:
Unknown.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 6.2(8a), 7.1(0)SIB(99.39) |
|
Known Fixed Releases: | 6.0(2)A6(0.59), 6.0(2)A6(1), 6.0(2)U6(0.59), 6.0(2)U6(1), 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.10), 6.2(12)FT(0.5), 7.0(0)BZ(0.46), 7.0(0)HSK(0.357) |
|
|
| |
| |
Bug Id: | CSCum18198 |
Title: | restrictions for wccp redirect access-list and such other limitations |
|
Description: | Symptom:
restrictions for wccp redirect access-list and such other limitations
Conditions:
restrictions for wccp redirect access-list and such other limitations
Workaround:
restrictions for wccp redirect access-list and such other limitations
Further Problem Description:
restrictions for wccp redirect access-list and such other limitations
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 6.2(6)S9 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue92562 |
Title: | Memory Leak in "clp_fwd" Process |
|
Description: | Symptom:
N7K-F248XP-24 module running NX-OS 6.0.1 crashes due to clp_fwd
Conditions:
Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
Workaround(s):
None
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 6.0(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu27341 |
Title: | Post ISSU to 7.2, shared ports i/f bind fails in FCoE VDC on mod reload |
|
Description: | Symptom:
On N7K/ N7700 all ports of a module will fail to bind to FCoE VDC. show vdc membership status shows "module has become offline" though the module status is ok
Conditions:
ISSU from 6.2 to 7.2 with shared interfaces from F2e or F3 module to FCoE VDC. After ISSU do Module Reload/Poweroff-powerOn. When the module comes up again notice that no port from that module is available in FCoE VDC.
Workaround:
To recover from the problem:
Reload module one more time and the issue gets resolved. Alternatively, a switch reload will resolve the affected module as well as prevent any other modules that may be susceptible.
To prevent the problem choose any of the following:
(1) Cold boot upgrade to 7.2 (instead of ISSU)
(2) Unconfigure the port sharing in 6.2 prior to ISSU and reconfigure it in 7.2
(3) Perform a switch reload after ISSU (and prior to any of the line cards being individually powered off/on)
Further Problem Description:
Issue is observed only on the first module reload/ poweroff-poweron. Issue gets resolved on a consecutive reload and does not reoccur
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu59455 |
Title: | ports were error-disabled sequence timeout with MTS_SAP_ETH_PORT_SEC |
|
Description: | Symptom:
Interfaces were error disabled due to sequence timeout communicating with MTS_SAP_ETH_PORT_SEC
Conditions:
interfaces enabled port-security and this problem was found in 6.2(10).
Workaround:
disable port-security feature on affected interface.
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 1 Catastrophic |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu63346 |
Title: | vPC leg no BD after multiple link flaps |
|
Description: | Symptom:
vPC leg (on one side) ended up without BD after a particular sequence of link flap. The other side, vPC leg is in STP BLK state.
vPC status
---------------------------------------------------------------------
id Port Status Consistency Active VLANs Active BDs
----- ------------ ------ ----------- ---------------- --------------
100 Po100 up success - - <<< No BD
200 Po200 up success - 100-107
A#
Conditions:
Happens with below particular sequence:
vPC Peerlink down -> A vPC leg(100) down -> vPc peerlink up -> A vPC leg(100)up
Workaround:
The sequence of recovery steps that will avoid the system coming into this unrecoverable bad state is to bring up the primary vpc leg up first followed by the peer link. This will ensure consistency and correctness in the final state.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 02-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj86229 |
Title: | Fexes reloading due to watchdog timeout |
|
Description: | Symptom:
Fexes bouncing due to 'watchdog timeout' reset reason
Conditions:
Using 6.2(2) and multiple fexes are bouncing due to watchdog timeout
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.1(0)FE(0.49), 6.2(0)FH(0.146), 6.2(0)HS(0.10), 6.2(5.58)S0, 6.2(6), 7.1(0)ZD(0.71), 7.1(0)ZD(0.74) |
|
|
| |
| |
Bug Id: | CSCug44109 |
Title: | FT:aclmgr core at aclmgr_intf_run_iter |
|
Description: | Symptom:
aclmgr crashes while executing the command:
install all kickstart bootflash:n7000-s2-kickstart.6.2.2.bin system bootflash:n7000-s2-dk9.6.2.2.bin
or
show install all impact kickstart bootflash:n7000-s1-kickstart.6.2.6.bin system bootflash:n7000-s1-dk9.6.2.6.bin
Ignore the versions used.
This is applicable to any version in 6.2 train and for both Sup 1 and Sup 2.
Conditions:
If user configuration has a mac packet-classify configuration under any interface, while doing an ISSU aclmgr will crash.
Workaround:
To perform an ISSU upgrade or check ISSU impact to Release 6.2(2)
1. Enter the show running-config aclmgr inactive-if-config command for all VDCs.
2. Enter the clear inactive-config acl command for all VDCs.
3. If configuration has any "mac packet-classify" configuration, remove this configuration from all interfaces using the no command.
4. Start the ISSU procedure.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.1(2), 6.2(1.121)S1, 6.2(1.121)S2 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu60878 |
Title: | IFTMC cores with pvlan configuration secondary configs |
|
Description: | Symptom:
IFTMC cores with pvlan configuration secondary configs
Conditions:
IFTMC cores with pvlan configuration secondary configs
Workaround:
IFTMC cores with pvlan configuration secondary configs
Further Problem Description:
IFTMC cores with pvlan configuration secondary configs
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut17447 |
Title: | SPAN dest port load balancing doesn't work with M2 as span src |
|
Description: | Symptom:
If SPAN source is on M2 module in the RX direction, then load balancing on SPAN destination port-channel does not work.
Hostname(config-monitor)# sh port-channel traffic interface po X
NOTE: Clear the port-channel member counters to get accurate statistics
ChanId Port Rx-Ucst Tx-Ucst Rx-Mcst Tx-Mcst Rx-Bcst Tx-Bcst
------ --------- ------- ------- ------- ------- ------- -------
19 Eth8/18 100.00% 65.15% 40.00% 100.00% 0.0% 0.0%
19 Eth8/19 0.0% 34.84% 59.99% 0.0% 0.0% 0.0%
Hostname(config-monitor)#
Conditions:
SPAN source is on M2 module and SPAN direction in RX only
This problem is seen on 6.2 code when ISSU was performed from 6.1 code.
Workaround:
This problem is not seen when N7K was upgraded to code 6.2 code traditionally or N7K is reloaded after ISSU to 6.2
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtr74930 |
Title: | lldp process crashes on executing "show lldp entry <system-name>" |
|
Description: | Symptom:
lldp crash
Conditions:
LLDP crashes when user issues "show lldp entry" and system-name tlv was de-selected.
Workaround:
Enable system-name tlv
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 5.2(1)S84 |
|
Known Fixed Releases: | 6.0(0.14)S0 |
|
|
| |
| |
Bug Id: | CSCuj56624 |
Title: | OIL not programmed in MFDM |
|
Description: | Symptom:
Routed multicast traffic gets black-holed on a Nexus 7000. The Multicast Routing Table (MRIB) has the correct interfaces in the S,G outgoing interface list (OIL), but they are missing from Multicast Forwarding Distribution Manager (MFDM).
MRIB:
Nexus7000# sho ip mroute 10.1.1.100 239.192.100.100
IP Multicast Routing Table for VRF "default"
(10.1.1.100/32, 239.192.100.100/32), uptime: 1w1d, pim mrib ip
Incoming interface: port-channel383, RPF nbr: 10.113.255.53
Outgoing interface list: (count: 4)
Vlan100, uptime: 1d11h, mrib
Vlan101, uptime: 1d11h, mrib
Vlan102, uptime: 1d11h, mrib
Vlan400, uptime: 1d11h, mrib, pim
MFDM:
Nexus7000# sho forwarding distribution ip multicast route source 10.1.1.100 | b 239.192.100.100
(10.1.1.100/32, 239.192.100.100/32), RPF Interface: port-channel383, flags:
Received Packets: 23430091 Bytes: 22011464043
Number of Outgoing Interfaces: 1
Outgoing Interface List Index: 63
Vlan400
Conditions:
This may be seen in a multicast environment after a multicast source feed is stopped then restarted, such as during a server reload.
Workaround:
clear ip mroute for the misprogrammed group
Further Problem Description:
MFDM programs the mroute OIFs on the line card forwarding engine. Since the OIFs are missing in MFDM, they are not programmed on the ingress forwarding engine Multicast Forwaridng Information Base (MFIB) on the line cards.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.2(2a)S11, 6.2(2a)S19, 6.2(5.49)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5)BF(0.41), 6.2(5.45)S5, 6.2(5.50)S0, 6.2(5.52)S0, 6.2(6), 7.0(0)BNZ(0.23), 7.0(0)KM(0.37), 7.0(0)ZD(0.131), 7.0(0)ZN(0.29) |
|
|
| |
| |
Bug Id: | CSCuu59408 |
Title: | Gibraltor:post ISSU, reload F2 -fex uplink results in DCBX ACK lost |
|
Description: | Symptom:
On Nexus 7018 switch with software 7.2.0 release, where Fabric Extender N2232PP uplink is connected to the only one F2 Module ports and the host interface connected to the physical host UCS is shared with the storage virtual device (VDC).
If reload of F2 module is performed post module up the host interface connected to the UCS host will see that DCBX PDU ACK gets lost.
Conditions:
Nexus 7000 series switch F2 only one module having uplink of fabric extender FEX N2232PP and host interface of FEX is shared with the storage VDC.
Workaround:
To resolve the issue, in the owner virtual device ( vdc) of nexus 7018 switch ,flap the host interface (HIF) port of Fabric extender FEX, So that the DCBX exchange will get reinitialized.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCum89436 |
Title: | n7k:6.2.6a:mvpn traffic not forwarded on the encap PE on the mti int |
|
Description: | Symptom:
-
Conditions:
-
Workaround:
-
Further Problem Description:
-
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.2(6a)S4 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup82982 |
Title: | N7K: M1 linecard reload observed due to leak in ipfib |
|
Description: | Symptom:
A N7K M1 linecard may reset because of a generic sysmgr reset. No core file/service crash has been written as the result of this incident. The exception log shows:
System Errorcode : 0x401e008c sysmgr on linecard had an internal error
Error Description : send_redun_heartbeat: Unable to start send redundancy timer.
It is suspected this was triggered by a leak with ipfib service. To see how much memory is held by ipfib, attach to the module and collect "show forwarding internal mem-stats detail" and "show system internal processes memory"
Conditions:
OTV is enabled
Workaround:
Due to OTV code restructuring in 6.2.x releases, this leak should not been see there.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur40034 |
Title: | N7K - F2 Clipper Card "IFTMC" Crashes When Freeing a Deleted Index |
|
Description: | Symptom:A Nexus 7k with an F2 card may experience a crash in the "IFMC" process if another linecard in the chassis is undergoing an OIR event (either a physical reseating or a soft reset.) Eg:
== Module 1 OIR event ==
%PLATFORM-5-MOD_STATUS: Module 1 current-status is MOD_STATUS_ERRDOWN
%PLATFORM-2-MOD_PWRFAIL_EJECTORS_OPEN: All ejectors open, Module 1 will not be powered up (Serial number XXX)
== Module 2 crashes ==
%SYSMGR-SLOT2-2-SERVICE_CRASHED: Service "iftmc" (PID XXXX) hasn't caught signal 11 (core will be saved).
Conditions:Another card in the chassis is either being soft or hard reset triggering a global VLAN delete event. When this update propagates to the forwarding table of an F2 card, under certain conditions, it can trigger a crash.
This issue is not seen in NX-OS versions 6.2(6) or later, this was addressed by code changes committed as part of CSCty30696 software enhancement.
Workaround:None known.
More Info:
|
|
Status: | Other |
|
Severity: | 1 Catastrophic |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.1(4a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj42636 |
Title: | igmp cored in if (avl_insert(igmp_snoop_cfs_fex_groups_tree |
|
Description: | Symptom:
core happens after mct flap
Conditions:
sh not sh of mct causes crash.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 1.1(0.226) |
|
Known Fixed Releases: | 6.0(2)N3(0.327), 6.0(2)N3(1), 7.0(0)BNZ(0.23), 7.0(0)KM(0.37), 7.0(0)ZD(0.106), 7.0(1)N1(0.47), 7.0(1)N1(1), 7.0(3)I1(0.2), 7.0(3)I1(1), 7.1(0)ARP(0.2) |
|
|
| |
| |
Bug Id: | CSCut25162 |
Title: | VPLS VC's don't come after delete/add VFI's in EFP scale setup |
|
Description: | Symptom:
Few VPLS PW's remain down
Conditions:
With L2VPN VFI's scaled, delete all VFIs and Re-add all VFI's.
Workaround:
clear l2vpn service vfi all
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.422), 7.2(0)D1(0.430) |
|
Known Fixed Releases: | 15.5(1)S0.17, 15.5(1)S1.1, 15.5(1)S2, 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)IB(122), 7.1(0)LR(0.4), 7.1(0)SIB(99.109), 7.2(0)AB(9), 7.2(0)BA(0.12) |
|
|
| |
| |
Bug Id: | CSCuj89847 |
Title: | CB-40: Service "pim6" crashed when v6 mcast traffic running |
|
Description: | Symptom:
Pim6 crash
Conditions:
Test - IPV6 mcast N-N test
Started the traffic on 20 ports - pim6 crashed
Workaround:
None yet
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.2(5.27)S0, 6.2(5.49)S0 |
|
Known Fixed Releases: | 6.0(2)N3(0.358), 6.0(2)N3(1), 6.2(0)HS(0.10), 6.2(5)BF(0.59), 6.2(5.66)S0, 6.2(6), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)KM(0.37), 7.0(0)ZD(0.154) |
|
|
| |
| |
Bug Id: | CSCty30696 |
Title: | Changes in IFTMC for Flanker ASIC |
|
Description: | Symptom:
F-Series linecard may experience a core of the IFTMC component, and generate a core file. This may also lead to a HAP (High Availability Policy) reset of the linecard.
Conditions:
Error in hardware index management.
Exact triggers for issue are not clear, so the fix is in the IFTMC component handling.
Workaround:
N/A
Fix is in 6.2(6) and later codes.
More Info:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 6.1(4a), 7.0(0)FT(0.1) |
|
Known Fixed Releases: | 6.2(0.214)S0, 6.2(0.228)S0, 6.2(0.233)S9, 6.2(0.243)S3, 6.2(0.247)S0, 6.2(0.248)S0, 6.2(0.253)S0, 6.2(0.260)S0, 6.2(0.282)S0, 6.2(0.61)S16 |
|
|
| |
| |
Bug Id: | CSCut43413 |
Title: | DCi: HSRP Virtual MAC Flapping through FHRP Isolation PACL |
|
Description: | Symptom:
FHRP hello causing vMAC to flap between local interface and Layer 2 vPC DCi.
Conditions:
- FHRP isolation PACL on Layer 2 vPC DCi interface
- Device acting as L2 vPC DCi is not FHRP gateway
Workaround:
Two options dependent on the design of the network:
- If the DCi device is only connected to the FHRP gateway, a VACL with an ARP inspection filter is recommended to isolate the data centers.
- If the DCi device has connections to other devices in the local data center using the PACL with a static MAC entry is the only option. This will not stop the duplicate gateway gratuitous ARPs between the two sites.
Further Problem Description:
This is a hardware limitation. The MAC learning process takes place before the PACL drops the HSRP hello.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtq30996 |
Title: | KGDB: CONFIG_KMALLOC_ACCOUNTING bug |
|
Description: | Symptom:
Supervisor crash and reload due to Kernel Panic.
Conditions:
System is running low on memory.
Workaround:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 5.2(0.905) |
|
Known Fixed Releases: | 5.2(1)S20, 5.2(1.23)S0 |
|
|
| |
| |
Bug Id: | CSCut12851 |
Title: | CPU HOG with STEC M2+ CF 9.0.2 |
|
Description: | Symptom:
CPU HOG could occur with certain "STEC M2+ CF 9.0.2" model log flash in a N7K SUP1 systems.
Conditions:
presence of "STEC M2+ CF 9.0.2" log flash in SUP1 N7K system.
Workaround:
replace log flash
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 6.1(4a)E2, 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo62072 |
Title: | Nexus WCCP crash due to corrupted redirect assignment packets |
|
Description: | Symptom:
WCCP process crash on Nexus 7K may be seen due to corrupted redirect assignment packets from the cache engine.
Conditions:
WCCP is configured
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 6.2(2)S42 |
|
Known Fixed Releases: | 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, 6.2(9)FM(0.73) |
|
|
| |
| |
Bug Id: | CSCum05295 |
Title: | BGP multipath entry in uRIB does not get updated after attribute change |
|
Description: | Symptom:
There are two symptoms that can be seen for this bug.
1. The following error message can be seen in syslog and IGP redistributing BGP routes may fail.
2013 Dec 13 01:21:58 PTAINTS410 %OSPF-3-RPM_LIB_API_FAILED: bgp_lookup_ext_attr() - failed in rpm_acquire_bgp_shmem_lock()
2. A route with a stale metric in the routing table exists
`DC1-CORE-3# sho ip bgp 10.10.63.0
BGP routing table information for VRF default, address family IPv4 Unicast
BGP routing table entry for 10.10.63.0/25, version 127677
Paths: (6 available, best #1)
Flags: (0x00001a) on xmit-list, is in urib, is best urib route
Multipath: eBGP iBGP
Path type: internal, path is valid, received and used, not best reason: Router Id, multipath
AS-Path: NONE, path sourced internal to AS
1.1.2.3 (metric 101) from 1.1.2.3 (1.1.2.3)
Origin IGP, MED 409, localpref 100, weight 0 <====== MED 409 should match routing table
DC1-CORE-3# sho ip route 10.10.63.0
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF
10.10.63.0/25, ubest/mbest: 5/0
*via 1.1.2.2, [200/409], 00:10:12, bgp-65001, internal, tag 65001
*via 1.1.2.5, [200/409], 00:43:22, bgp-65001, internal, tag 65001
*via 1.1.2.6, [200/409], 00:43:22, bgp-65001, internal, tag 65001
*via 1.1.2.7, [200/409], 00:43:22, bgp-65001, internal, tag 65001
*via 1.1.2.8, [200/409], 00:43:22, bgp-65001, internal, tag 65001
via 1.1.2.3, [200/65940], 00:15:17, bgp-65001, internal, tag 65001 <<======= OLD MED 409 not updated
Conditions:
1. IGP (e.g., OSPF) redistributes BGP routes.
2. The redistribution uses route-map to evaluate community associated with the routes.
3. Maximum-paths command is configured.
4. BGP receives paths with only attribute (e.g., AS-PATH,MED) change.
Workaround:
A few possible workarounds:
1. Post-fault (impact low->high): clear ip route , clear ip bgp and restart BGP process.
2. Do not configure multi-paths (maximum-paths command).
3. Do not use redistribution route-map to match community/other BGP attributes.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 6.1(1) |
|
Known Fixed Releases: | 6.1(4.112)S0, 6.1(5), 6.2(0)HS(0.10), 6.2(7.7)S0, 6.2(8), 6.2(8)CM(0.2), 6.2(9)FM(0.37), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)ZD(1.18) |
|
|
| |
| |
Bug Id: | CSCuh42629 |
Title: | CSCuh42629SNMPd crashed in idle state |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCut47891 |
Title: | NVT: Missing (S,G) between MSDP peers, when there are 4 spine with MSDP |
|
Description: | Symptom:
(S,G) entries are not in between MSDP peers
Conditions:
Four Spine devices configured as MSDP peers
Workaround:
no workaround
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtt14198 |
Title: | ERROR: Get port-channel database failed with show vlan cmd post switover |
|
Description: | Symptom:
when enter sh vlan in CLI, the following error message is displayed.
ERROR: Get port-channel database failed
Conditions:
The problem is reported in 5.2(1).
Workaround:
You can view the same essential output with the following commands:
show spanning-tree vlan X
or for fabricpath:
show fabricpath isis interface brief
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 6.0(1) |
|
Known Fixed Releases: | 5.2(3)S7, 5.2(3.6)S0, 6.0(2)S11, 6.1(0.148)S0 |
|
|
| |
| |
Bug Id: | CSCti95293 |
Title: | Due to EOBC Congestion, PortLoopback test failed to threoshold times |
|
Description: | Symptoms:
Consecutive PortLoopback failure message reported. As a result, linecards may
be reported as faulty.
Conditions:
Nexus7000 running 5.0 or 5.1 releases.
Workaround(s):
None.
Further Problem Description:
As this issue is due to EOBC congestion, following symptoms may also be seen:
- Unable to login to module(s)
%IPQOSMGR-4-QOSMGR_LC_SESSION_ERROR_MSG: Linecard returned the
following error for statistics session: Operation timed out.
- Configuration change is not updated, or saving configuration fails
E.g., After "shutdown" command issued for an interface, it stays up.
- Interface status is not updated
E.g., After removing SFP, interface status still shown as UP.
- Unsuccessful Sup engine failover.
- Changes in software state are not propagated to hardware on some modules (STP state, LTL, CBL, RBH, etc...)
AIPC timeouts due to EOBC congestion can cause PIXM to remove the module from the active linecard mask. This can be verified via "show system internal pixm info global | i "active LC"
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 5.0(2a), 5.1(1) |
|
Known Fixed Releases: | 5.0(5)S7, 5.0(5.27)S0, 5.1(1)S29, 5.1(1.26)S0, 5.1(1.32)S0 |
|
|
| |
| |
Bug Id: | CSCuh33729 |
Title: | Memory leak on snmp get: libport_m |
|
Description: | Symptom:
Memory leak is seen on CISCO-ENTITY-SENSOR-MIB.
snmpd is crashed finally by memory leak.
Conditions:
SNMP client try get-request to OID of CISCO-ENTITY-SENSOR-MIB.
Workaround:
Do not use SNMP to poll these OID.
Further Problem Description:
Example configuration for blocking all of CISCO-ENTITY-SENSOR-MIB:
snmp-server community communityString group name
role name name
rule 1 permit read
rule 2 deny read oid 1.3.6.1.4.1.9.9.91
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 5.2(9), 6.1(3)S32, 6.1(4), 6.2(2)S19 |
|
Known Fixed Releases: | 5.2(9.206)S0, 5.2(9a)E1, 6.1(4.97)S0, 6.1(4a), 6.1(4a)S7, 6.1(5.32)S0, 6.2(2), 6.2(2)S23, 6.2(5.2)S0, 7.0(0)ZD(0.84) |
|
|
| |
| |
Bug Id: | CSCus51150 |
Title: | Some created MSDP SA cache data are not updated immediately |
|
Description: | Symptom:
When new mcast traffics are coming into N7K side(MSDP RP), new created S,G entries should be transmitted to MSDP peer immediately, however, some of entries of SA cache data are not transmitted to peer device.
The remained entries are updated at next MSDP update period of time(maximum 60seconds later).
Conditions:
Running MSDP RP
many S,G entries are created within very short period of time at once
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: | 6.0(2)A6(0.43), 6.0(2)A6(1), 6.0(2)U6(0.43), 6.0(2)U6(1), 6.1(2)I3(3.74), 6.1(2)I3(4), 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.0(0)KM(0.119), 7.1(0)AV(0.74) |
|
|
| |
| |
Bug Id: | CSCtg90112 |
Title: | N7k Linecard is reset due to "Metro fatal interrupt in device 79" |
|
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 and multiple packet replication of the same packets.
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
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 07-JUN-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun92129 |
Title: | VPLS::sh int pw - throwing invalid range |
|
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.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
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)S, 15.4(3)SN1a, 15.5(0.16)T, 15.5(0.16.1)CG, 15.5(0.20)PI27a, 15.5(1.2.1a)GB |
|
|
| |
| |
Bug Id: | CSCuo86388 |
Title: | NXOS-VPC-VPLS Scale-after Core LC OIR,subset of PW Remain in Down state |
|
Description: | Symptom:
In a setup with scaled VFI's & PW's, some PW's may not come up.
Conditions:
Line Card OIR
Workaround:
clear l2vpn service all
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 7.1(0)ZD(0.181) |
|
Known Fixed Releases: | 15.4(3)M2.1, 15.4(3)M3, 15.4(3)S0.7, 15.4(3)S1, 15.4(3)S2, 15.4(3)SN1a, 15.5(0.18)S0.8, 15.5(1)S, 15.5(1)SN, 15.5(1)T1.1 |
|
|
| |
| |
Bug Id: | CSCus02026 |
Title: | PIM crash seen on with high scale mcast source on VPC |
|
Description: | Symptom:
PIM may crash with high number of sources per group in VPC setup
Conditions:
High scale of sources per group
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.0(2)A6(0.44), 6.0(2)A6(1), 6.0(2)U6(0.44), 6.0(2)U6(1), 6.2(12), 6.2(12)S2, 6.2(12.4)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110) |
|
|
| |
| |
Bug Id: | CSCut44571 |
Title: | VPC Excessive packet loss during tcn or clear mac address |
|
Description: | Symptom:
On a nexus 7000 series switch, packet loss towards a vpc may be seen for a few seconds after a spanning-tree topology change or a manual clearing of the mac addresses table.
Conditions:
- VPC is configured
- "no port-channel limit" is configured under vpc domain
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCub96980 |
Title: | ipfib core found during ISSU from 5.1.6 to 5.2.7 |
|
Description: | Symptom:
During ISSU upgrade to 5.2(7) or later, we may see these error messages:
%IPFIB-SLOT2-2-FIB_TCAM_HA_ERROR: FIB recovery errors, please capture 'show
tech forwarding l3 unicast' and 'show tech forwarding l3 multicast'
This can accompany with ipfib crash also.
Conditions:
ISSU from any previous code (5.0.x or 5.1.x) to 5.2(1), 5.2(3a), 5.2(4), 5.2(5)
later may trigger this issue.
For eg:
ISSU upgrade from 5.1.3 to 5.2.1. Then make some configuration changes when
running 5.2.1 and then ISSU upgrade to 5.2.7 or 6.1.1 can trigger this issue
Workaround:
This can be impacted even if LISP is not running
1) Before the upgrade is attempted, please do the following to avoid hitting
this bug.
feature lisp
Configure "ip lisp etr" for all vrfs followed by "no ip lisp etr"
no feature lisp
2) In the problem state(if Nexus 7000 is hit by this bug), reload the affected
modules and this should resolved the issue
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.2(7) |
|
Known Fixed Releases: | 5.2(7), 5.2(7)S15, 5.2(7.21)S0, 6.1(2), 6.1(2)E10, 6.1(2)E10.4, 6.1(2)S9, 6.1(2.14)S0, 6.1(2.27), 6.2(0.285) |
|
|
| |
| |
Bug Id: | CSCtq93304 |
Title: | Observing ARP service crash @arp_adj_timer_callback |
|
Description: | Symptoms:
Nexus7000 report crash in the ARP service.
Conditions:
This issue is observed in Nexus7000 running 5.x releases.
Workaround(s):
None.
This issue should be fixed in 5.2(1) release onwards.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.0(2), 5.0(3)N2(2), 5.2(1) |
|
Known Fixed Releases: | 5.2(1)S43, 5.2(1.48)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCut63393 |
Title: | Border Leaf needs to advertise hash-len for BSR |
|
Description: | Symptom:
Border Leaf doesn't advertise the correct hash-len as advertised by PIM running @ the Border-Leafs for BSR in Vinci Asti Multicast.
Conditions:
BSRs listen and accumulate candidate RP announcements. For every group range known, the BSR builds a set of candidate RPs, including all routers that advertised their willingness to service this range. This is called group range to RP set mapping. The resulting array of group range to RP set mappings is distributed by the BSR. Ultimately, the bootstrap messages containing Group to RP-set mappings are received by every multicast router in the domain and used to populate their RP caches. It's up to the routers to select the best matching RP from the sets advertised by the BSR router. It is important that all routers select the same RP for the same group, otherwise the multicast sources might miss receivers. Based on a consistent hash-len information sent from the BL's the routers will ensure they pick the same RP for the same group.
In the present Janjuc image, although PIM advertises a hash-len to be chosen for BSR, this communication doesn't get sent to NGMVPN @ Border-leaf node which results in PIM @ all leaf nodes using a default hash-len of 0 to calculate the RP for the group. This causes mismatch in hash-len information between PIM @ Border-Leaf vs PIM @ Leaf node.
Workaround:
Work-around is not to configure the candidate-RP's in the RP-set for BSR case with the same priority.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 7.2(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo68846 |
Title: | aclqos crash on LC due to FU_MEM_hashtable_node_array_t continuous alloc |
|
Description: | Symptom:
Following errors are logged on the switch:
%SYSMGR-SLOT10-2-SERVICE_CRASHED: Service "aclqos" (PID 12914) hasn't caught signal 6 (core will be saved).
%SYSMGR-SLOT10-5-SUBPROC_TERMINATED: "System Manager (core-client)" (PID 17560) has finished with error code SYSMGR_EXITCODE_CORE_CLIENT_ERR (11).
After the crash, monitoring memory usage on LCs, following object is showing continuous allocations:
FU_MEM_hashtable_node_array_t continuous
Module 10
4/28
module-10# sh processes memory |i aclqos
12914 247832576 0 350027776 7fe2da50/7fe2c500 aclqos
module-10# sh system internal aclqos mem-stats detail
Private Mem stats for UUID : FSM Utils(53) Max types: 82
--------------------------------------------------------------------------------
TYPE NAME ALLOCS BYTES
CURR MAX CURR MAX
13 FU_MEM_hashtable_node_array_t 71108 71108 145906852 145906852
34 ACLQOS_MEM_parse_cntx_t 71103 71103 18202368 18202368
36 ACLQOS_MEM_fltrlist_t 71103 71103 29010024 29010024
117 ACLQOS_MEM_aclqos_fhdl_list_t 71103 71103 1990884 1990884
-======================================
4/29
module-10# sh processes memory |i aclqos
12914 292724736 0 394919936 7fe2da50/7fe2c500 aclqos
module-10# sh system internal aclqos mem-stats detail
Private Mem stats for UUID : FSM Utils(53) Max types: 82
--------------------------------------------------------------------------------
TYPE NAME ALLOCS BYTES
CURR MAX CURR MAX
13 FU_MEM_hashtable_node_array_t 86763 86763 178030912 178030912
34 ACLQOS_MEM_parse_cntx_t 86758 86758 22210048 22210048
36 ACLQOS_MEM_fltrlist_t 86758 86758 35397264 35397264
117 ACLQOS_MEM_aclqos_fhdl_list_t 86758 86758 2429224 2429224
-======================================
4/29 - Evening
module-10# sh processes memory | i aclqos
12914 302288896 0 404484096 7fe2da50/7fe2c500 aclqos
Private Mem stats for UUID : FSM Utils(53) Max types: 82
--------------------------------------------------------------------------------
TYPE NAME ALLOCS BYTES
CURR MAX CURR MAX
13 FU_MEM_hashtable_node_array_t 90114 90114 184907164 184907164
34 ACLQOS_MEM_parse_cntx_t 90109 90109 23067904 23067904
36 ACLQOS_MEM_fltrlist_t 90109 90109 36764472 36764472
117 ACLQOS_MEM_aclqos_fhdl_list_t 90109 90109 2523052 2523052
-======================================
4/30 - Morning
module-10# sh processes memory | i aclqos
12914 337563648 0 439758848 7fe2da50/7fe2c500 aclqos
module-10# sh system internal aclqos mem-stats detail
Private Mem stats for UUID : FSM Utils(53) Max types: 82
--------------------------------------------------------------------------------
TYPE NAME ALLOCS BYTES
CURR MAX CURR MAX
13 FU_MEM_hashtable_node_array_t 102427 102427 210173440 210173440
34 ACLQOS_MEM_parse_cntx_t 102422 102422 26220032 26220032
36 ACLQOS_MEM_fltrlist_t
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 6.2(6a)S17 |
|
Known Fixed Releases: | 6.1(2)I3(2), 6.2(10), 7.0(3)I1(1) |
|
|
| |
| |
Bug Id: | CSCud02139 |
Title: | Access to nexus7k via vty may get lost at random times with tacacs+ |
|
Description: | Symptom:
TACACS+ services(authen/author/acct)) would fail due to child defunt process getting stuck without cleanup
Conditions:
1. Not Reproducible
2. For every five minutes there is an internal procedure that does an address resolution(forking a child process) of the TACACS server and caches the same for 5 minutes
3. This issue would occur, only if these child process are failed to cleanup(Max allowed failed child process: 64), we could say this is a rare corner case
Workaround:
disable and re-enable the feature or switchover SUP or Reboot the switch
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 5.2(5)S23 |
|
Known Fixed Releases: | 5.2(1)N1(5), 5.2(9), 5.2(9)S11, 5.2(9.21)S0, 6.0(2)A1(1b), 6.1(3), 6.1(3)S8, 6.1(3.15)S0, 6.1(3.23), 6.2(0.304) |
|
|
| |
| |
Bug Id: | CSCuu68022 |
Title: | VPC:Duplicate traffic after config and unconfig feature vpc |
|
Description: | Symptom:
Duplicate traffic for the receivers after doing deconfiguration and reconfiguration of feature vpc
Conditions:
PIM protocol is up and the user is doing "no feature vpc" and feature vpc along with vpc relatted commands.
When the chassis role is being changed, PIM is not able to get the proper role information due to sdb lookup failure. This causes PIM to think that VPC is not enabled and hence does not do necessary steps like RPF source election etc and depending upon the placement of receivers and sources, there will be duplicate traffic.
Workaround:
restart PIM using "restart pim" command will fix the problem.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud10012 |
Title: | Unexpected reload of nexus 7000 due to res_mgr hap reset |
|
Description: | Symptoms
A nexus 7000 may unexpectedly reload due to a res_mgr hap reset.
The logs of the switch will show several cores for the res_mgr process prior to
the hap reset:
%SYSMGR-2-SERVICE_CRASHED: Service "res_mgr" (PID 4055) hasn't caught signal 11
(core will be saved).
Conditions
Steps to recreate
(1) Create a large VLAN range, for eg. 1000-2000
(2) Delete VLANs in between such as "no VLAN 1005" followed by "no VLAN 1010" and so forth.
If you show the list of VLANs in the format "1000-1004,1006-1009,............" there are 19 characters to show the string "1000-1004,1006-1009" alone (1 for 1, 1 for 0, 1 for 0, 1 for 0, 1 for -, 1 for 1, 1 for 0, 1 for 0, 1 for 0, 1 for 4, 1 for ,, 1 for 1 and so forth). If you have too many VLAN or VRF ranges such that the representation in a string in the fashion above takes more than 512 characters, the problem will happen.
(3) For the problem to happen, after (1) and (2), you have to issue "show vdc resources".
Workaround
None known at this time.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S20, 5.2(9.38)S0, 6.1(3), 6.1(3)S21, 6.1(3.31)S0, 6.2(1.93), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCuu68969 |
Title: | UIN-1::Seeing multicast traffic loss as forwarding has null OIF in H/W |
|
Description: | Symptom:
Traffic lose is seen in some routes because of mrib and mfdm go out of sync in these routes.
Conditions:
ISSU from 6.2.10 to 7.2.0.D1.1.S14 followed by reload of all 10 LCs may hit the issue.
Workaround:
Use "clear ip mroute" for the affected routes will fix the issue.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur32209 |
Title: | LDP should not remove/free entries while walking the xos radix tree |
|
Description: | Symptom:
LDP can encounter memory corruption or process crash.
Conditions:
Because of the nature of the bug, the problem can happen at any point, unexpectedly.
Workaround:
No workarounds.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 7.1(0)ZD(0.341) |
|
Known Fixed Releases: | 6.2(10)E5, 6.2(14)FB(0.65), 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.119), 7.1(0)AV(0.38), 7.1(0)ES(0.7), 7.1(0)EV(0.125), 7.1(0)OTT(0.41) |
|
|
| |
| |
Bug Id: | CSCun26418 |
Title: | OTV encapsulation fails for multicast/broadcast traffic |
|
Description: | Symptom:
The replication ASIC responsible for SPAN, OTV encapsulation, and multicast replication stops replicating all traffic. As a result, each of the above features will also fail. This is particular to the SPAN/multicast replication pipeline so customer in an OTV environment will see that multicast traffic (including link-local multicast 224.0.0.0/24), along with broadcast traffic are not forwarded across the overlay.
Conditions:
This has been observed in OTV environment with a high rate of traffic egressing the OTV join-interface with ERSPAN configured to span the join-interface, which is very rare.
Workaround:
Once the issue has been encountered, a reload of the module is required to clear the problem. Removing the ERSPAN session will prevent the issue from reoccurring.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | 6.2(10)S47, 6.2(10)S48, 6.2(10)S57, 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.300), 7.1(0)EV(0.116), 7.1(0)OTT(0.41) |
|
|
| |
| |
Bug Id: | CSCue51797 |
Title: | N7K: Egress unicast traffic is polarized to single port-channel member |
|
Description: | Symptom:
Egress unicast traffic is polarized on FEX HIF port-channel.
Conditions:
This issue is observed when Nexus 2200 series FEX is single attached to Nexus 7000 F2 series modules.
Workaround:
None.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S50, 5.2(9.94)S0, 6.1(4.18)S0, 6.1(4a), 6.1(4a)S12, 6.2(1.38)S0, 6.2(1.93), 6.2(2), 7.0(0.6) |
|
|
| |
| |
Bug Id: | CSCun93402 |
Title: | PIM process leaking memory |
|
Description: | Symptom:
A Cisco Nexus switch may see a memory leak in the PIM process. The following command can be used to examine the memory being used by the PIM process:
show ip pim internal mem-stats detail
A sign of this leak is to see the PIM_MEM_RPF_SOURCE_IPC allocations growing without bound.
Conditions:
The current conditions to trigger the leak are unknown at this current time.
Workaround:
There is no workaround at this time. If the process in question consumes all of the allowed memory pim functions and commands may cease to work. If the process does not crash TAC can kill the process manually which will allow the process to restart and become operational.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.0(2)N3(0.111), 6.0(2)N3(1), 6.2(0)HS(0.10), 6.2(8), 6.2(8)S10, 6.2(8.5), 7.0(0)BNZ(0.23), 7.0(0)KM(0.64), 7.0(1)ZD(0.267), 7.0(1)ZN(0.581) |
|
|
| |
| |
Bug Id: | CSCuo05318 |
Title: | Vlan in blocking state (CBL) on one vpc leg |
|
Description: | Symptom:
VPC leg on N7K VPC Primary may be in STP Disable (DIS) state while the vpc leg is being brought up.
Conditions:
* VPC Leg on VPC Primary Switch
* There are one or more member link flaps while the VPC leg is being brought up.
Workaround:
Step 1: Shut the problem VPC leg on both Primary and Secondary.
Step 2: No-shut the problem VPC leg on both Primary and Secondary.
Further Problem Description:
When a VPC leg on a N7K is being brought up, if there are member-link flaps causing port-channel cleanups, the STP state for the VPC leg be in DIS state when the VPC leg is up. The issue is resolved by the above workaround.
The issue exists in 6.2(6) and 6.2(8). Issue is resolved in 6.2(10) and all later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 6.2(8)S1, 6.2(8)S11, 6.2(8)S30, 6.2(8)S33, 7.1(0)D1(0.82) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)EC(0.8), 6.2(10)FM(0.18), 6.2(10)NO(0.19), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.1(0)GF(0.36) |
|
|
| |
| |
Bug Id: | CSCuq90846 |
Title: | l2fm crash in scale frame-snooping trigger after vdc reload |
|
Description: | Symptom:
L2FM Crashing while handling stale AGE notifications from MTM.
Conditions:
Corner case scenario happened during all VDC reload.
Workaround:
None
Further Problem Description:
AGE notifications were getting processed for non-existing Vlans.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.254) |
|
Known Fixed Releases: | 7.1(0)D1(0.269) |
|
|
| |
| |
Bug Id: | CSCtt02688 |
Title: | 'fex' cores seen while issuing 'show fex transceiver detail' |
|
Description: | Symptom:
Switch may crash due to "fex hap reset" after issuing "show fex transceiver detail"
Conditions:
Workaround:
Do not issue "show fex transceiver detail"
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 6.0(1) |
|
Known Fixed Releases: | 6.0(1)S16, 6.1(0.113)S0 |
|
|
| |
| |
Bug Id: | CSCul45644 |
Title: | vlan_mgr crashed if dynamic reserved vlan range conflicts with vtp vlan. |
|
Description: | Symptom:
When reserved vlan range is within the VTP vlan range (vlan 2-1001) and
this vtp switch receives a vtp message from the network carrying a user vlan that has been locally configured as reserved, the new vlan creation message to vlan_mgr causes a crash.
Conditions:
This bug is hit with VTP enabled and reserved vlan range falls under VTP vlan range.
Example:
1. vdc1 and vdc2 have two trunks links between them.
2. vdc1 is vtp mode server, vdc2 is vtp client or server mode.
3. vdc2 has a reserved vlan range 100-227 configured.
ex: switch(config)>system vlan 100 reserve.
4. vdc1 creates vlan 100.
5. when vdc2 receives vtp add vlan message, vlan_mgr crashes.
Workaround:
Disable VTP or do not move the reserved vlan range into the VTP vlan range.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 6.2(5.52) |
|
Known Fixed Releases: | 6.2(6), 6.2(6)S2, 6.2(6.13)S0 |
|
|
| |
| |
Bug Id: | CSCuc16550 |
Title: | memory leak in ipqosmgr |
|
Description: | Symptom:
ipqosmgr service crashes
Service "ipqosmgr" (PID 4668) hasn't caught signal 6 (core will be saved).
Conditions:
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 5.2(5) |
|
Known Fixed Releases: | 5.2(7.30)S0, 5.2(9), 6.0(2)N2(1), 6.0(2)U1(1), 6.1(2), 6.1(2)E10, 6.1(2)E10.4, 6.1(2)S8, 6.1(2.13)S0, 6.1(2.27) |
|
|
| |
| |
Bug Id: | CSCuu20942 |
Title: | ACOS CCOS table is not programmed on Sup on n77 |
|
Description: | Symptom:
Once you assign a network qos template on the box and then change any Cos2Q map separately via config, that change is not getting reflected in the Sup card table.
Conditions:
Happens for 4Q4Q template for released code.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 7.1(0)AV(0.72) |
|
Known Fixed Releases: | 7.2(0)AV(0.89) |
|
|
| |
| |
Bug Id: | CSCuo73479 |
Title: | F348XP:1Gig interface remain up with copper SFP and cable pulled out |
|
Description: | Symptom:
Interface is remaining in "up/up" state when there is an SFP inserted into an F348XP line card running 6.2(8), even when the opposite end is admin down or the cable is removed from the SFP.
This was duplicated using an Avago??, GLC-T, and GE-T SFP.
Support for gig transceiver was introduced in 6.2.8
Conditions:
Issue seen for 1gig SFP on N77-F348XP-23 module.
Seen on 6.2.8
Issue seen when speed on interface is hardcoded to 1gig.
Workaround:
Admin down local interface.
configure speed auto on the interface.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.13), 6.2(8)E5, 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.12)S0, 6.2(9)FM(0.75) |
|
|
| |
| |
Bug Id: | CSCut86302 |
Title: | LIF entry incorrect (inconsistent) on F2 module |
|
Description: | Symptom:
LIF entry incorrect (inconsistent) on F2 module.
Conditions:
multi ISSU to 6.2(10)
Workaround:
Clear the route or
Reload the module
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur75014 |
Title: | ("sequence timeout") communicating with MTS_SAP_PVLAN for opcode |
|
Description: | Symptom:
When large number of PVLAN ports are brought down simultaneously either through cli or OIR of line module, or change of mode, sequence timeout errors occur and when the ports are brought back up traffic is not forwarded out of them.
%ETHPORT-5-IF_SEQ_ERROR: Error ("sequence timeout") communicating with MTS_SAP_PVLAN for opcode MTS_OPC_ETHPM_PORT_LOGICAL_CLEANUP (RID_PORT: Ethernet4/27)
%ETHPORT-5-IF_SEQ_ERROR: Error ("sequence timeout") communicating with MTS_SAP_PVLAN for opcode MTS_OPC_ETHPM_PORT_LOGICAL_CLEANUP (RID_PORT: Ethernet4/26)
Conditions:
Having more than 5 PVLAN ports (L2 trunk or PC) with any PVLAN mode other than "host"
Workaround:
There is no workaround.
Recovery step to clean database is to reload switch
Further Problem Description:
There is no way to avoid hitting issue if you match pre-conditions and triggers.
NXOS 6.1.2 until 6.2(10) is affected.
Fix is upcoming in 6.2(12)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 6.1(2), 6.1(4a), 6.2(10), 6.2(6b)S2, 6.2(8), 6.2(8a) |
|
Known Fixed Releases: | 6.1(2)I3(3.65), 6.1(2)I3(4), 6.2(12), 6.2(12)S2, 6.2(12.4)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.320) |
|
|
| |
| |
Bug Id: | CSCtz59944 |
Title: | Port Error disabled - ELTMc port structure doesn't exist on swover/upgr |
|
Description: | Symptom:
Unable to add ports to port-channel. Upon adding them, member links went error disabled.
Router(config-if)# sh int Eth x/y
Ethernetx/y is down (Error disabled, eltmc: Port structure doesn't exist.)
Router %ETHPORT-5-IF_SEQ_ERROR: Error ("Port structure doesn't exist.") communicating with MTS_SAP_ELTM for opcode MTS_OPC_ETHPM_PORT_PRE_CFG (RID_PORT: Ethernetx/y)
Conditions:
The scenario can happen when the port-channel/member gets deleted and the cleanup does not happen properly in ELTM. In this condition, after ISSU if there are new updates and/or port-channel configuration modified manually, then this issue happens.
Workaround:
Delet the port-channel, reload the modules that had member ports belonging to this port channel and re configure the port-channel
Further Problem Description:
This issue is resolved in 5.2(7) or later releases, in 5.2 train.
And, this issue can be carried over from earlier releases in ISSU.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 5.2(4.72) |
|
Known Fixed Releases: | 5.2(4.85)S0, 5.2(7) |
|
|
| |
| |
Bug Id: | CSCuo00442 |
Title: | WCCP redirect index misprogrammed on Nexus 7000 F2 |
|
Description: | Symptom:
WCCP misprogrammed on F2 line cards causing traffic to be dropped instead of being redirected
Conditions:
WCCP configured on F2 - the issue is seen after ISSU upgrade to 6.2(X)
Also seen when the box was running 6.2(x) and was reloaded.
Or when the line card reloads
Workaround:
Remove and reapply WCCP on the interface
no ip wccp 61 redirect in
ip wccp 61 redirect in
Issue is fixed in 6.2(8)
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu68733 |
Title: | N77/SNMP: show sys intern snmp mem-stats shows incremental user memory |
|
Description: | Symptom:
Continuous polling a range of OIDs
Conditions:
Continuously polling of OIDs from DCNM tool
Workaround:
snmpd is freeing up the memory acquired after returning the response query to the polling
Further Problem Description:
Leak is not that much to initiate a process crash because the analysis showed that the memory is going up but its also getting freed after sometime.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 14-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut26394 |
Title: | M148 vPC secondly drop packet |
|
Description: | Symptom:
when the vPC secondly configure as L2 ports , specific destination IP forwarding fail on M148 module.
Conditions:
when add the vlan information to vPC secondry :see the setting change logs
Workaround:
change the the dest dest IP ;VIP to SVI actual IP
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur21785 |
Title: | N7K - M1/M2 Egress Queuing behavior post 6.2(x) for control plane packet |
|
Description: | Symptom:
Control plane packet ( marked with DSCP value for Example PIM etc ) received on ACCESS port, and then get bridged into same VLAN do not queued in priority Queue on Egress port. The issue is not seen after doing "no ip igmp snooping"
Conditions:
- Nexus 7000 running 6.2(x) image; Earlier images like 5.2(x) do not see the same condition.
- Packet is coming in ACCESS port and getting bridged into same VLAN via ACCESS or Trunk port.
- M series Line cards
Workaround:
Not available yet
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc24368 |
Title: | Netstack - TCPUDP hang on to opcode 86017 for an extended amount of time |
|
Description: | Symptom:
The interface might be down due to Error disabled. Reason: fu unknown error.
Conditions:
The symptom is observed after reload with a scale setup wtih MIB polling and when MTS buffers is filled.
Workaround:
Once the MTS buffers is recovered, shut/no shut interface that is down will bring up the interface.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 6.1(2), 6.1(2)S1, 6.1(2)S27, 6.1(2)S3, 6.1(2)S8, 6.2(0.233)S7, 6.2(0.265)S4, 6.2(0.287)S4, 6.2(1X) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu77244 |
Title: | port-profile core at ppm_profile_global_level_2_acfg_gen after- sh start |
|
Description: | Symptom:
PPM will crash when issued show run or show start. This happens when there are lots of aging of profile and at the same time traffic is being sent and there are errors in the profiles being applied.
Conditions:
Happens when there are errors in application of network profiles like failure of command and aging happening at the same time.
Workaround:
System is already buggy. Do a write erase and reload.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu40239 |
Title: | ARP traffic sent out on incorrect VLAN |
|
Description: | Symptom:
ARP traffic sent out on incorrect VLAN
Conditions:
Mixed chassis with F1 & M1 cards
Workaround:
1. Shut and no shut the SVI that is having problems, or
2. Disable glean fast-path via the config command ? no ip arp fast-path, or
3. Disable and reenable glean fast-path
4. Reload the switch.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun40658 |
Title: | Nexus 7700-SPAN capturing in one direction when VLAN in fabricpath mode |
|
Description: | Symptom:
In Nexus 7000 systems running 6.2.2a/6.2.6 code, if fabric path traffic egressing out of a core port is captured using Egress SPAN sessions, the MiM header will not be stripped off at the SPAN destination. The reason for this particular enhancement is that, many times, capture the packet in its entirety, including the MiM header is desirable. But in 6.2.2a and 6.2.6 releases, there was no option to let the user decide whether MiM header should be preserved or not. Some end analyzers are not able to detect/parse MiM headers, hence the scenario looked like no egress copies were being generated for traffic going out of a core port.
Hence, 6.2.8 on wards, a new per-port CLI was provided which lets the user decide whether MiM/other internal headers should be preserved for the SPAN copy or not. Command to be used is "switchport monitor exclude header". More details for the command is present in the configuration guide.
Conditions:
Nexus 7000/Nexus 7700 switches with 6.2.2a or 6.2.6, traffic egressing out of a core port is being copied in the Egress SPAN Session and end analyzer does not have capability to parse MiM header.
6.2.8 on wards, traffic egressing out of a core port is being copied in the Egress SPAN Session, end analyzer does not have capability to parse MiM header and the CLI to enable stripping of internal headers "switchport monitor exclude header" is not applied on the SPAN destination port.
Workaround:
This is expected behavior and an enhancement has been put in place for 6.2.8 using CSCun74440 to enable user to pick whether MiM header should be seen at the destination or not, depending on the end analyzer capabilities.
This bug is now used to document the behavior.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.2(2a), 6.2(6) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S3 |
|
|
| |
| |
Bug Id: | CSCuh68097 |
Title: | aclqos hap-reset at aclqos_ses_dst_link_find |
|
Description: | Symptom:ACLQOS crashed while collecting show tech
Conditions:show tech run while there was an outstanding session.
Workaround:avoid collecting show tech output
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.2(1.136) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu72620 |
Title: | rise nam: sh rise detail does not dispaly which vdc the dataport belongs |
|
Description: | Symptom:
When RISE NAM is configured on the system, sometimes the vdc name is not visible in the "show rise detail" command output , there is no functional impact of this
Conditions:
unknown
Workaround:
User can run show vdc membership on default vdc to see which vdc contains the nam rise data port
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur38749 |
Title: | Connection to a non-existent host is consumed/precessed by xTR itself |
|
Description: | Symptom:
A vulnerability in Cisco Locator/ID Separation Protocol (LISP) feature of Cisco NX-OS could allow an authenticated, remote attacker to use SSH connection to a non-existent host covered by lisp mobile prefix
from outside of the DC and get presented with the xTR login prompt.
An attacker still needs to have login credentials for NX-OS device in order to be able to log in.
Conditions:
LISP mobility and lisp enabled interface need to be configured.
Workaround:
VTY ACL preventing login prompt to be displayed to the user connecting from the outside can
prevent unauthorized logins
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 3.5/2.9:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:S/C:P/I:N/A:N/E:F/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.11), 6.2(12)FT(0.5), 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)EV(0.112), 7.1(0)PDB(0.317), 7.2(0)D1(0.368) |
|
|
| |
| |
Bug Id: | CSCus42725 |
Title: | Breakout ports have 40G latency buffer carving values instead of 10G val |
|
Description: | Symptom:
Nexus 7ks running vPCs and utilizing breakout cables on the N7K-F312FQ-25 modules will hit this failure condition after some time(a relatively short period of time). The result is all vPCs will show a downed state because of the vPC peer link being down.
This issue is caused because of the misconfiguration of the latency buffers. We can see for the breakout ports has 40G latency buffer carving values, instead of the 10G breakout latency values. This results in corrupted packets and sometimes packet truncation.
Conditions:
Nexus 7ks running vPCs and utilizing breakout cables on the N7K-F312FQ-25 modules.
Workaround:
No current work-around.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(12), 6.2(12)S25, 6.2(12.4)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.422), 7.2(0)FM(0.3), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCtw98915 |
Title: | Cisco NX-OS Message Transfer Service DoS Vulnerability |
|
Description: | Symptom:
Advisory ID: cisco-sa-20140521-nxos
Revision 1.0
For Public Release 2014 May 21 16:00 UTC (GMT)
Summary
=======
Cisco Nexus, Cisco Unified Computing System (UCS), Cisco MDS 9000 Series Multilayer Switches, and Cisco 1000 Series Connected Grid Routers
(CGR) are all based on the Cisco NX-OS operating system. These products are affected by one or more of the following vulnerabilities:
* Cisco NX-OS Virtual Device Context SSH Privilege Escalation Vulnerability
* Cisco NX-OS Virtual Device Context SSH Key Privilege Escalation Vulnerability
* Cisco NX-OS-Based Products Smart Call Home Buffer Overflow Vulnerability
* Cisco NX-OS Message Transfer Service Denial of Service Vulnerability
Cisco has released free software updates that address these vulnerabilities.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140521-nxos
Conditions:
A device running an affected version of software.
Workaround:
None
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
7.1/5.9:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2014-2201 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.0(1), 6.0(2) |
|
Known Fixed Releases: | 6.0(2)S30, 6.0(2)S31, 6.1(0.174)S0, 7.0(1)ZD(0.3), 7.2(0)N1(1), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCur12912 |
Title: | rpm cores following module failure |
|
Description: | Symptom:
Following module bringup after failure, vmm timeout seen causing ports not getting allocated to vdc. RPM cored post that and VDC came up
Conditions:
none
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S90 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S93, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)PDB(0.317), 7.2(0)D1(0.358), 7.2(0)N1(1), 7.2(0)ZD(0.47) |
|
|
| |
| |
Bug Id: | CSCus62432 |
Title: | RP not treating itself as rp for remote source traffic. |
|
Description: | Symptom:
If the RP is rebooted, it's discarding PIM register messages from itself and the other PE:
2015 Jan 20 14:13:30.092655 pim: [8115] (default-base) Received Register from 10.1.1.18 for (10.1.1.18/32, 239.255.254.0/32)
2015 Jan 20 14:13:30.092702 pim: [8115] (default-base) We are not RP for group 239.255.254.0, message discarded
Conditions:
RP router reboot
AND
Customer has an interface configured with a primary AND secondary IP address, and the secondary address is used as the address called in the "ip pim rp-address" command.
There is a bug in the code that if the secondary address is configured AFTER the rp info is created by PIM, PIM does not identify itself as the RP.
It is possible during bootup that before IP component had a chance to configure the secondary address, PIM process reads the static RP configuration and then it receives the secondary address addition message and hence the bug.
Workaround:
1. Restart pim on the RP router
2. Remove and reconfigure "ip pim rp-address <>" in global configuration on the RP.
3. Configure the primary address to be the RP instead of the secondary address of the interface.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.2(9)S0 |
|
Known Fixed Releases: | 6.0(2)A6(0.44), 6.0(2)A6(1), 6.0(2)U6(0.44), 6.0(2)U6(1), 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.0(0)KM(0.119), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.422) |
|
|
| |
| |
Bug Id: | CSCus70619 |
Title: | aclqos crash in aclqos_commit at aclqos_ppf_common.c:1942 |
|
Description: | Symptom:
N7K-M132XP-12 module reloaded due aclqos crash
Conditions:
N7K-M132XP-12 module reloaded due aclqos crash
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.2(12)S29 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq82625 |
Title: | Eigrp classic/wide metric count incorrect leading to incorrect updates |
|
Description: | Symptom:
EIGRP Router configured with wide metric updates ("metric version 64bit")
is sending classic updates, which will be ignored by peer. Peer will
no longer add routes from that peer.
Conditions:
- Have configured "metric version 64bit" for the EIGRP process.
- Have invalid values for "classic / wide metric" peers in "show eigrp interface"
to where the # of classic peers is > then the number of total peers.
n7k1-1# sh ip eigrp interfaces
IP-EIGRP interfaces for process 100 VRF default
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Eth1/25 2 0/0 1 0/0 50 0
Hello interval is 5 sec
Holdtime interval is 15 sec
Next xmit serial
Un/reliable mcasts: 0/7 Un/reliable ucasts: 36/44
Mcast exceptions: 6 CR packets: 5 ACKs suppressed: 4
Retransmissions sent: 15 Out-of-sequence rcvd: 11
Authentication mode is not set
Use multicast
Classic/wide metric peers: 3/-1 <<<<<<<<<<<< We cannot have 3 classic peers if we only have a total of 2 peers.
Workaround:
- Unconfig and reconfig the eigrp instance
- no ip router eigrp and then reconfig ip router eigrp
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S84, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)D1(0.326), 7.1(0)EV(0.116), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283) |
|
|
| |
| |
Bug Id: | CSCud81736 |
Title: | EIGRP stops communicating until the SIAQueries are sent. |
|
Description: | Symptom:
EIGRP stops communicating between the Nexus devices) until the SIAQueries are sent.
Conditions:
seen between a pair of Nexus 7K's
In Nexus1, Nexus2 is being installed as a successor for 2001:420:1411::/48 even though it doesn't meet the Dual FC condition. This is because there's another path with same metric which passes Dual FC condition and during installation to RIB, the 2 paths are considered to be ECMP and FC condition is not checked again.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 5.2(7) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtg90667 |
Title: | OSPF service crashes @ip_get_secondary_count on restarting netstack |
|
Description: | Symptom:
When the netstack process crashed, existing BGP sessions may flap and routes may be re-learnt. This may cause traffic loss.
Conditions:
This only happens when the netstack process had crashed or was terminated ungracefully.
Workaround:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.1(0.288)S1, 6.1(2)S29, 6.2(0.166) |
|
Known Fixed Releases: | 5.0(0)MP1(0.332), 5.2(1)S1, 5.2(1.3)S0, 6.1(0.143)S0, 6.2(0.228)S0, 6.2(2), 7.2(0)N1(1), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCur31394 |
Title: | aclmgr crash seen when adding/removing ACL to many SVIs at the same time |
|
Description: | Symptom:
aclmgr crash is seen when applying/removing large ACL config to SVI, for example:
interface vlan 1-800
no ip access-list X
will see something like:
SYSMGR-2-SERVICE_CRASHED: Service "aclmgr" (PID 6058) hasn't caught signal 6 (core will be saved)
Conditions:
This is not traffic impacting.
Workaround:
apply ACL config in smaller chunks, for example:
interface vlan 1-100
no ip access-list X
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S100, 6.2(10)S102, 6.2(12)FT(0.26), 6.2(12)S21, 6.2(12)S25, 6.2(8a) |
|
Known Fixed Releases: | 6.0(2)A6(0.43), 6.0(2)A6(0.44), 6.0(2)A6(1), 6.0(2)U6(0.43), 6.0(2)U6(0.44), 6.0(2)U6(1), 6.1(2)I3(3.44), 6.1(2)I3(4), 6.2(10.21)S0, 6.2(12) |
|
|
| |
| |
Bug Id: | CSCuu73376 |
Title: | multicast traffic loss due to snooping entry programmed with wrong LTL |
|
Description: | Symptom:
After these set of triggers,
a)ASCII replay ( with mcast config on a vxlan setup)
b)switchover
c) LC ISSU ,
there may be loss of few mcast streams .
RCA-
Problem surfaces wherein we see some "pending" l2mcast entries in the LC. These pending entries look to be stale ones - those that were added before the ISSU. Pending entries are those routes psuhed to the LC by MFDM wherein the ltl index for the OIF is not resolved. MFDM typically sends an update after the ltl is resolved and these pending entries are popped off the list and progarmmed to hw.. Some how that never seems to happen for these entries and after the ISSU is done they will be recovered again with the stale RID info ( index for set of ltls) . Any update coming in for the RID after the ISSU will cause these entries to be programmed with wrong LTL.
Conditions:
The issue is ocassionally when the following sequence was done
1. ASCII replay - followed by
2. switchover - followed by
3. LC ISSU
Workaround:
To do away with the wrong entries LC reload is the only workaround
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtx54822 |
Title: | Specific SNMP GET request causes 'snmpd' service to crash on Nexus 7K |
|
Description: | Summary
Cisco Nexus, Cisco Unified Computing Systemn (UCS), Cisco MDS 9000 Series Multilayer Switches, and Cisco 1000 Series Connected Grid Routers
(CGR) are all based on the Cisco NX-OS operating system. These products are affected by one or more of the following vulnerabilities:
* Multiple Cisco Discovery Protocol Vulnerabilities in Cisco NX-OS-Based Products
* Cisco NX-OS Software SNMP and License Manager Buffer Overflow Vulnerability
* Cisco NX-OS Software SNMP Buffer Overflow Vulnerability
* Cisco NX-OS Software Jumbo Packet Denial of Service Vulnerability
Cisco has released free software updates that address these vulnerabilities.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130424-nxosmulti
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
9.0/7.4:
https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:L/Au:S/C:C/I:C/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2013-1180 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.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.2(1), 6.0(1) |
|
Known Fixed Releases: | 5.2(4.11)S0, 7.1(0)BF(0.74), 7.1(0)ZD(0.158), 7.1(0)ZD(0.225) |
|
|
| |
| |
Bug Id: | CSCuu89566 |
Title: | pvlan mcast traffic black-hole on ISSU from 6.2.8b to S28 GBR |
|
Description: | Symptom:
Multicast traffic drop in the SVI when Secondary VLANs are higher that primary VLAN for MD(multi-destination) packet
Conditions:
F2 or F2E linecards with PVLAN SVI.
Multicast packet egress in SVI with PVLAN.
Following show command gives the state that system is vulnerable state.
SDB ALIF should never exceed 12bits. In this case it is MSB has been set with 0x8000.
module-8# show system internal iftmc hardware lif detail | beg 0x0902025a
LIF : 0x1d , VDC : 2, IF Index : 0x0902025a, IF : Vlan602
---- -------- -------- -------------
INST LDB ALIF SDB ALIF SDB If Index
---- -------- -------- -------------
0x0 0x8823 0x8823 0x00000000
0x1 0x8001 0x8001 0x00000000
Workaround:
Option 1 : Flap SVI after ISSU to 6.2.10 or any later release.
Option 2 : LC reload
Further Problem Description:
Following show command gives the state that system is vulnerable state.
SDB ALIF should never exceed 12bits.
module-8# show system internal iftmc hardware lif detail | beg 0x0902025a
LIF : 0x1d , VDC : 2, IF Index : 0x0902025a, IF : Vlan602
---- -------- -------- -------------
INST LDB ALIF SDB ALIF SDB If Index
---- -------- -------- -------------
0x0 0x8823 0x8823 0x00000000
0x1 0x8001 0x8001 0x00000000
Following trace from MFIB shows that Index mapping is not programmed correct.
There will be multicast MultiDestination packets drop in that particular ASIC.
module-8# show forwarding internal errors
1) Event:E_DEBUG, length:210, at 228055 usecs after Wed Jun 17 11:53:45 2015
[111] clp_mfib_oif_create_or_update(4902):ERROR: Unable to allocate replicated LDB region: inst:0x1, index:0x25c, e_lif:0x881c syserr 0xffffffff Device Name:[0x3FF] Instance:[63] Error Type:[(null)] code:[255]
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu08389 |
Title: | R2D2:Speed patch failed & link not coming up(on etherchannel interfaces) |
|
Description: | Symptom:
- 2 interfaces eth7/1 and eth8/1 stopped working. Module 7 and 8 are of ?N7K-M148GT-11L?
- Shut/No Shut will not resolve the issue, but reload of modules resolved the problem
- Similar bugs CSCtq34950 & CSCtf84832 (R2D2:Speed patch failed and Interface not comming up), which matches the issue closely, but they seem to be fixed in the version (6.2.2a) in which the customer is running.
- Trigger is unknown at this point.
Conditions:
Workaround:
Reload of module
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 6.2(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq25337 |
Title: | Broadcast & multicast fail after multiple ISSU, no port select for LTL |
|
Description: | Symptom:Broadcast / multicast traffic may not egress out port channel members and/or physical ports.
pixm pss has duplicate entries for BD LTLs after multiple ISSU
slot 4 show hardware intern ltl start-index 0x802b end-index 0x802b egress-port 6
----------------------------------------------------------------
|fp ports|inst| ltl | rbh| vqi |mi(v5)|mi(v4)|drop|eg ports|
|--------------------------------------------------------------|
| 5- 8 | 1| 802b| 0| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 1| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 2| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 3| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 4| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 5| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 6| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 7| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 8| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 9| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 10| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 11| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 12| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 13| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 14| | c9| ca| 0|no port selects
| 5- 8 | 1| 802b| 15| | c9| ca| 0|no port selects
Conditions:Multiple ISSUs causing incorrect setting of the port bitmaps due to pss key corruption.
For example, lets take a 2 ISSUs case from 6.2.8 to 6.2.8a to 6.2.10
- Switch loaded with 6.2.8 image.
- On a BD ltl operation if any, upon updation of the pss entry in the pss file, there is a mismatch between the pixmc internal data structure and the pss entry.
- After ISSU from 6.2.8 to 6.2.8a, the restoration of BD LTL is done based on the mismatched state. This results in inconsistency between pixmc internal sw state and its pss file only without affected the hardware programming.
- Now, any BD ltl operation on the above affected BD LTL will result in creation of a duplicate key in the pss file.
- Another ISSU from 6.2.8a to 6.2.10 will result in restoration of an invalid PSS entry (because of duplicate pss key) which has stale port bitmaps set for that BD LTL.
Workaround:Bounce the port channel members which do not have the port selects set properly to cause reprogramming of the affected BD LTL due to the port-channel membership change.
OR
Flap the affected vlan to cause reprogramming of the BD LTL with the right port selects.
OR
Resetting the affected module(s)
More Info:Double ISSU is a commonly seen condition. This issue can also be seen after an ISSU followed by M1-to-M2 replacement (which involves port-channels flap)
The fix for this is in 6.2(10). This means that:
a) ISSU from any prior release to 6.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 6.1(2), 6.2(10)S38, 6.2(2a), 6.2(6a), 6.2(8), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S45, 7.1(0)AV(0.38), 7.1(0)D1(0.267), 7.1(0)OTT(0.36), 7.1(0)PDB(0.206) |
|
|
| |
| |
Bug Id: | CSCut78387 |
Title: | l2fm crash @l2fm_rvtep_free_entry after shut/no shut nve interface. |
|
Description: | Symptom:
l2fm crash
Conditions:
shut/no shut nve interface
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471) |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.2(0)D1(0.482), 7.2(0)ZD(0.162), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCut84904 |
Title: | Process "mtm" Cores on F3 Cards Shortly After Boot |
|
Description: | Symptom:
Repeated "mtm" cores on an F3 linecard
Conditions:
Unknown, first seen after an ISSU from 6.2(8b) to 6.2(10)
Workaround:
Unknown
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj29140 |
Title: | frequent aclmgr crash when applying L4 protocol filtering racl |
|
Description: | Symptom:
While applying acl with L4 protocol filtering, aclmgr crashes frequently causing switch overr and vdc reload
it will happend when we have "stale" entries in the state-cache.
by issuing show command - "show system internal aclmgr state-cache" , we will see state-cache entries in the aclmgr.
Conditions:
applying L4 Protocol ACL to interface with stale entry
Workaround:
ascii reload would resolve the problem.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.5), 6.2(12)FT(0.5), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.117), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)NF(0.28) |
|
|
| |
| |
Bug Id: | CSCuj48042 |
Title: | N7K-OFF-DIAG:Sup 2:spine_diagdsp falure w. BIOS v.2.12 |
|
Description: | Symptom:
a
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
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)TSH(0.4) |
|
|
| |
| |
Bug Id: | CSCuu58892 |
Title: | Traffic loss observed after changing VPLS-id |
|
Description: | Symptom:
After changing the VPLS-id, Traffic loss is being observed over the PW's.
Conditions:
# Change VPLS-ID on PE-a
# Change VPLS-ID on PE-b & PE-c
# Revert VPLS-ID to default on all Pes
Workaround:
clear l2vpn service
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu87265 |
Title: | OTV UDP ISSU: Packet decap is broken on ISSU from S28 to UPG |
|
Description: | Symptom:
While OTV UDP encapsulation mode enabled, after ISSU there is a traffic interrupt.
Conditions:
ISSU with OTV UDP encapsulation mode enabled.
Workaround:
None.
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq57457 |
Title: | Service clis cored after applying config to range of fex hif ports |
|
Description: | Symptom:
clis process crash and core generated:
%SYSMGR-2-SERVICE_CRASHED: Service "clis" (PID 7590) hasn't caught signal 11 (core will be saved).
%SYSMGR-STANDBY-2-SERVICE_CRASHED: Service "clis" (PID 7586) hasn't caught signal 11 (core will be saved).
Conditions:
the issue was seen when applying config to range of fex hif ports
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S58 |
|
Known Fixed Releases: | 6.1(2)I3(3.68), 6.1(2)I3(4), 6.2(10), 6.2(10)S69, 6.2(10.16)S0, 7.1(0)D1(0.326), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283), 7.2(0)ZD(0.21), 7.2(0)ZN(0.22) |
|
|
| |
| |
Bug Id: | CSCus71454 |
Title: | PVLAN VPC: peer-link flap causes primary legs in PVLAN host mode to flap |
|
Description: | Symptom:
In a Private-Vlan VPC setup in private-vlan host mode, when peer link flaps, VPC leg in private-vlan host mode also flaps and comes back up in some time. There will be traffic loss from the VPC leg until the leg bringup happens again.
Conditions:
The VPC legs have to be private-vlan host mode as follows: "switchport mode private-vlan host"
Example configuration:
interface port-channel10
switchport
switchport mode private-vlan host
switchport private-vlan host-association 2 3
vpc 1
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 6.2(12)S29 |
|
Known Fixed Releases: | 7.2(2)PVF(0.6) |
|
|
| |
| |
Bug Id: | CSCuu68566 |
Title: | NVT-DC1:IGMP snooping for VLANs disabled in hardware |
|
Description: | Symptom:
IGMP Snooping remains disabled in hardware. In some VPC setup, there could be duplicate traffic also.
Conditions:
There are some IGMP snooping related commands for a vlan but the vlan itself is not present in the running config. ie the vlan is not created either through CLI or VTP. When such configs are present, it is possible that IGMP may pack updates for such vlans along with explicitly created vlans to m2rib module for hardware programming. But that message might be rejected by m2rib due to some vlans not explicitly created.
If the update contained snooping status info, then, we will end up with snooping status unchanged in the hardware.
Workaround:
Deleting all unnecessary configs and restarting igmp will fix the problem.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuu88922 |
Title: | partial configuration applied after configuring fabric-control on pvlan |
|
Description: | Symptom:
Trying to configure/unconfigure a vlan as fabric-control which is initially configured as a private-vlan irrespective of primary or isolated or community. Such a config is not supported and ideally vlan_mgr needs to log an error or warning on the console. If such a config is applied then pixm_vl crashes.
Conditions:
vlan need to be private vlan and configure it as fabric-control and then again remove fabric-control.
vlan 10
fabric-control
exit
vlan 10
no fabric-control
exit
Workaround:
N/A
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(0)D1(1.14), 7.2(0)ZD(0.221) |
|
|
| |
| |
Bug Id: | CSCus96878 |
Title: | Nexus7700 FEX interface link flap with FET-10G |
|
Description: | Symptom:
Nexus7700 FEX interface may link flap with FET-10G
Conditions:
Nexus7706
N77-F348XP-23
Nexus2232TM
FET-10G
NXOS 6.2.10
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua50779 |
Title: | admin vdc migration CLI stuck due to the banner config |
|
Description: | Symptom:
User doesn't get router prompt back after attempting an admin-vdc migration with a Nexus 7000 router
Conditions:
Occurs when banner motd is in configuration
Workaround:
Remove banner motd line from configuration
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 6.1(1)S10 |
|
Known Fixed Releases: | 6.1(1)S12, 6.1(1.11)S0, 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCuc23279 |
Title: | SYSTEST:FCoE:core detected due to hwclock crash on standby sup |
|
Description: | Symptom:
Core detected due to hwclock crash on standby sup.
Conditions:
None
Workaround(s):
No impact reported.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 6.1(2), 6.1(2)S11, 6.1(2)S41, 6.1(4a)S14, 6.2(1.42), 6.2(1.59)S2, 6.2(1.59)S5, 6.2(1.69), 6.2(1.69)S5, 6.2(1.83)S5 |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(5.9)S0, 6.2(0.304), 6.2(1.72)S0, 6.2(1.84)S0, 6.2(2), 7.0(0.7), 7.1(0)D1(0.14) |
|
|
| |
| |
Bug Id: | CSCup55118 |
Title: | ORIB buffer exhaustion on IGMP join/leave |
|
Description: | Symptom:
ORIB buffer exhaustion when we receive continuous IGMP join/leave
show ip igmp snooping internal ribs
IGMP Snooping internal RIB information
RIB name: M2RIB (type 0), ready: Yes No , xid 0x1f6cd
Max. outstanding buffers: 4
Current outstanding buffers: 0
Max. OMF entries per buffer: 400
Max. OMF route entries per buffer: 50
Max. route entries per buffer: 400
Fabricpath redist instance: 1
Used buffer queue count: 0
Free buffer queue count: 10
Buffer: 0x0x98650ac, type: none, xid: 0x0, count: 0
Buffer: 0x0x9869f04, type: none, xid: 0x0, count: 0
Buffer: 0x0x986ed5c, type: none, xid: 0x0, count: 0
Buffer: 0x0x9873bb4, type: none, xid: 0x0, count: 0
Buffer: 0x0x985174c, type: none, xid: 0x0, count: 0
Buffer: 0x0x984c8f4, type: none, xid: 0x0, count: 0
Buffer: 0x0x9847a9c, type: none, xid: 0x0, count: 0
Buffer: 0x0x98565a4, type: none, xid: 0x0, count: 0
Buffer: 0x0x985b3fc, type: none, xid: 0x0, count: 0
Buffer: 0x0x9860254, type: none, xid: 0x0, count: 0
TXLIST member version: 0
RIB name: ORIB (type 1), ready: Yes No , xid 0x10009
Used buffer queue count: 10
Buffer: 0x0x97ff7ac, type: route, xid: 0x10000, count: 1
Buffer: 0x0x9804604, type: route, xid: 0x10001, count: 1
Buffer: 0x0x980945c, type: route, xid: 0x10002, count: 1
Buffer: 0x0x980e2b4, type: route, xid: 0x10003, count: 1
Buffer: 0x0x981310c, type: route, xid: 0x10004, count: 1
Buffer: 0x0x97e6ff4, type: route, xid: 0x10005, count: 1
Buffer: 0x0x97ebe4c, type: route, xid: 0x10006, count: 1
Buffer: 0x0x97f0ca4, type: route, xid: 0x10007, count: 1
Buffer: 0x0x97f5afc, type: route, xid: 0x10008, count: 1
Buffer: 0x0x97fa954, type: route, xid: 0x10009, count: 1
Free buffer queue count: 0
TXLIST member version: 69545
Conditions:
this issue is seen in OTV environment
Workaround:
restart igmp process
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 5.2(1), 6.1(4), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S32, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.189), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)N1(0.240), 7.1(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCup42943 |
Title: | DMAC 0000.0000.0000 loops endlessly between fabricpath peers |
|
Description: | Symptom:
In a mixed VDC M2/F2E running fabricpath, a frame with DMAC 0000.0000.0000 is looping endlessly between the fabricpath peers.
A mac flap can be seen between the GPC and peer SW.ID
This could increase the bandwidth utilizaiton on the link.
Conditions:
Issue seems to be seen in a M2/F2E chassis running fabricpath. This bug applies to 6.2(6) and 6.2(8) only.
Workaround:
downgrade to 6.2(2a) OR
upgrade to 6.2.8a or 6.2.6b or 6.2.8e6 or 6.2.10
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 6.2(6), 6.2(8)S2 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S8, 6.2(10.5), 7.1(0)D1(0.186), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)NF(0.32), 7.1(0)OTT(0.14), 7.1(0)RTG(0.12), 7.1(0)SIB(99.6) |
|
|
| |
| |
Bug Id: | CSCtu28085 |
Title: | mac-flap may cause address learning not be updated on all linecards |
|
Description: | Symptom:
In certain rare situations, L2 forwarding table (mac address) might become inconsistent between linecards on Nexus 7000. This leads to blackholing of traffic destined to the affected mac address.
Conditions:
Problem was encountered following a mac-flap event (external trigger).
Workaround:
Clearing the affected mac address from the L2 table will restore connectivity (address will be learned on the correct interface).
clear mac address-table dynamic [address ]
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 5.1(3), 5.1(4), 5.2(1), 6.0(1) |
|
Known Fixed Releases: | 5.2(3.57)S0, 5.2(3.59)S0 |
|
|
| |
| |
Bug Id: | CSCuq81832 |
Title: | l2mcast process crashes during Vlan entry cleanup |
|
Description: | Symptom:
Modules may experience l2mcast process crashes:
2-SERVICE_CRASHED: Service "l2mcast" (PID 1220) hasn't caught signal 11 (core will be saved).
A process crash may occur multiple times over multiple modules
Conditions:
The issue was first seen with v2 joins (*,G) and v3 joins (S,G) and has OMF disabled on the fabric path vlan 182. We see a bunch of leaves coming in for the (*,G)s on vlan 182. Since there are v3 joins as well , some of the (*,G)s have corresponding (S,G) s. Ideally , if a (*,G) delete comes in we wouldn't be deleting the (*,G) from our software db if we have an (S,G) entry for the same group and that (S,G) delete is yet to come . Only when all the (S,G) leaves comes in and number of Source specific entries for that Group becomes zero , we cleanup the (*,G) entry node in our software. Once all the Groups in a Vlan are cleaned up , we will go ahead and clean up the Vlan entry in our sw db. To be able to do so in a correct manner we keep count of number of G entries per Vlan per ftag and number of S entries per G etc. { note : S is short for Source , and G is multicast group address}
Workaround:
Enabling OMF is the workaround only if the customer has the following combination
1) f3 only vdc - only f3 cards
2) f2e f3 vdc - combination of f2e and f3 cards in the vdc
If there are other cards like f2 , this workaround of enabling omf will NOT work as it will disrupt Ipv6 traffic
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S74, 6.2(10.16)S0, 7.1(0)AV(0.38), 7.1(0)D1(0.276), 7.1(0)EV(0.116), 7.1(0)OTT(0.36), 7.1(0)PDB(0.215) |
|
|
| |
| |
Bug Id: | CSCuu53383 |
Title: | Multicast IP packet with Unicast dmac is punted to the control plane |
|
Description: | Symptom:
High RX rate on the inband interface due to IP multicast packets.
Conditions:
IP multicast packet (224.0.0.0/4) with a unicast destination mac address of which the Nexus 7000 ingress L3 interface owns.
Workaround:
None.
Further Problem Description:
This traffic should be dropped in hardware by the parser as it violates packet format standards. This traffic should not be sent to the control plane for processing.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a), 6.2(8b) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj45281 |
Title: | Crafted LLDP packet causes an interface to go error-disable |
|
Description: | Symptom:
A vulnerability in the Link Layer Discovery Protocol (LLDP) code of Cisco NX-OS Software could allow an unauthenticated, adjacent attacker to cause the switch port on which the packet is received to stop forwarding traffic.
The vulnerability is due to an error in processing a malformed LLDP packet. An attacker could exploit this vulnerability by sending a specially crafted, malformed LLDP packet to an interface enabled for LLDP packet processing. Other ports on the switch are not affected.
Conditions:
LLDP is enabled on the interface on which the malformed packet is received.
Workaround:
There are no workarounds
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 3.3/3.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:U/RC:C
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
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu93235 |
Title: | ipfib service resets |
|
Description: | Symptom:
On a nexus 7000/7700 series switch, ipfib service may reset on linecards. Such reset is noticeable by the following log in the main VDC :
%SYSMGR-SLOT4-2-SERVICE_CRASHED: Service "ipfib" (PID 1200) hasn't caught signal 6 (core will be saved).
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu53392 |
Title: | Multicast IP packet with Unicast dmac is punted to the control plane |
|
Description: | Symptom:
High RX rate on the inband interface due to IP multicast packets.
Conditions:
IP multicast packet (224.0.0.0/4) with a unicast destination mac address of which the Nexus 7000 ingress L3 interface owns.
Workaround:
None.
Further Problem Description:
This traffic should be dropped in hardware by the parser as it violates packet format standards. This traffic should not be sent to the control plane for processing.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 19-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus83584 |
Title: | ISIS crashes due to corruption of stack on scale setup |
|
Description: | Symptom:
ISIS cored
Conditions:
change interface priority on scale setup
Workaround:
no workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.383), 7.2(0)D1(0.444) |
|
Known Fixed Releases: | 7.2(1)PIB(0.13) |
|
|
| |
| |
Bug Id: | CSCuj86243 |
Title: | CB-40/vPC+ Dynamic MAC insert failed syslog with just 4K dynamic MACs |
|
Description: | Symptom:
The following syslog is seen on an F series system with only 4,000 dynamic macs:
2013 Oct 16 12:10:55 sw144-n7k1 %L2FM-6-L2FM_DYN_MAC_INS_FAILED: Dynamic mac insertion failure!fail_cnt: 4 Slot:3
2013 Oct 16 12:10:55 sw144-n7k1 %L2FM-6-L2FM_DYN_MAC_INS_FAILED: Dynamic mac insertion failure!fail_cnt: 4 Slot:2
2013 Oct 16 12:10:55 sw144-n7k1 %L2FM-6-L2FM_DYN_MAC_INS_FAILED: Dynamic mac insertion failure!fail_cnt: 3 Slot:3
2013 Oct 16 12:10:55 sw144-n7k1 %L2FM-6-L2FM_DYN_MAC_INS_FAILED: Dynamic mac insertion failure!fail_cnt: 6 Slot:3
2013 Oct 16 12:10:55 sw144-n7k1 %L2FM-6-L2FM_DYN_MAC_INS_FAILED: Dynamic mac insertion failure!fail_cnt: 2 Slot:3
2013 Oct 16 12:10:56 sw144-n7k1 %L2FM-6-L2FM_DYN_MAC_INS_FAILED: Dynamic mac insertion failure!fail_cnt: 2 Slot:2
2013 Oct 16 12:10:56 sw144-n7k1 %L2FM-6-L2FM_DYN_MAC_INS_FAILED: Dynamic mac insertion failure!fail_cnt: 4 Slot:2
2013 Oct 16 12:10:56 sw144-n7k1 %L2FM-6-L2FM_DYN_MAC_INS_FAILED: Dynamic mac insertion failure!fail_cnt: 2 Slot:8
Conditions:
F series LC and a dynamic mac count less than the verified scale limit of 16,000 macs per SoC.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUN-2015 |
|
Known Affected Releases: | 5.2(5), 6.2(5.27)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5)FH(0.57), 6.2(5.64)S0, 6.2(6) |
|
|
| |
| |
Bug Id: | CSCue19535 |
Title: | Fabric Sync loss brings resets all the modules |
|
Description: | Symptom:
All linecards fail to sync to a single fabric module, causes the modules to be reset, instead of
the fabric module being powered down.
Conditions:
As above.
Workaround:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUN-2015 |
|
Known Affected Releases: | 4.2(8), 5.2(7), 6.1(2) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S41, 6.1(4), 6.1(4)S6, 6.1(4.8)S0, 6.2(1.93), 6.2(2), 7.1(0)D1(0.14) |
|
|
| |
| |
Bug Id: | CSCut72659 |
Title: | SSH connection failure with 'no matching cipher found ' syslog |
|
Description: | Symptom:
SSH connections initiated form the device fails with the below syslog
switch# ssh admin@10.196.98.73 vrf management
no matching cipher found: client aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr
switch#
Upon failed ssh connections connection, similar syslog is reported at the server also.
switch(config)# e2015 Mar 9 10:03:55 $ VDC-1 %$ %DAEMON-2-SYSTEM_MSG: fatal: no matching cipher found: client aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr - dcos_sshd[18259]
Conditions:
The issue occurs only if the server does not support any CBC ciphers.
Workaround:
The workaround is to add the client CBC ciphers in sshd_config/dcos_sshd_config file of the server to re-enable them, so that there will be matching ciphers.
Edit the following files in the server from Linux prompt:
/isan/etc/dcos_sshd_config
+ # Secure Ciphers and MACs
+ Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
/isan/etc/sshd_config
+ # Secure Ciphers and MACs
+ Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
Further Problem Description:
Fix Description
=================
As per openssh6.7 code, FIPS-approved ciphers are the following:
aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
For NXOS SSH client, ctr ciphers were not enabled by default on FIPs mode.
Fixed the issue by setting the FIPS mode flag for ctr ciphers.
On Nexus 7000 this problem can manifest itself also in the following way:
can not attach to rise nam from sup
N7K-6# attach rise slot 332
Attaching to RISE 332 ...
Username:root
no matching cipher found: client \
aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc server \
aes128-ctr,aes192-ctr,aes256-ctr
N7K-6#
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUN-2015 |
|
Known Affected Releases: | 6.2(13)FM(0.66), 6.2(13)S12, 7.2(0)D1(0.430), 7.2(0)D1(0.451) |
|
Known Fixed Releases: | 5.2(8g)S9, 6.2(13)S15, 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.81), 7.2(0)D1(0.487), 7.2(0)D1(0.489), 7.2(0)N1(0.183), 7.2(0)N1(0.185), 7.2(0)N1(0.187) |
|
|
| |
| |
Bug Id: | CSCuu73828 |
Title: | ipfib crash upon ISSU from 6.2.10 to GBR |
|
Description: | Symptom:
IPFIB crash on ISSU.
Conditions:
sh ipv6 route 14:211:1::
14:211:1::/64, ubest/mbest: 2/0, attached
*via 14:211:1::1, Vlan964, [0/0], 15:38:20, direct,
*via 14:211:1::8, Vlan964, [0/0], 06:10:04, direct,
When there is a direct and attached route with an ECMP of PATHs, IPFIB process will crash during ISSU(recovery).
This is because we do NOT expect a Direct route with an ECMP of PATHs.
Also we can see that clearing the route does not add the ECMP again, in which case we should NOT see the crash.
n7k-fex1-f3# sh ipv6 route 14:211:1::
14:211:1::/64, ubest/mbest: 2/0, attached
*via 14:211:1::1, Vlan964, [0/0], 16:13:11, direct,
*via 14:211:1::8, Vlan964, [0/0], 06:44:55, direct,
n7k-fex1-f3# clear ipv6 route 14:211:1::/64
Clearing 14:211:1::/64
n7k-fex1-f3# sh ipv6 route 14:211:1::
14:211:1::/64, ubest/mbest: 1/0, attached
*via 14:211:1::1, Vlan964, [0/0], 00:00:07, direct,
n7k-fex1-f3#
Workaround:
if we notice any Direct route with an ECMP of paths we can clear the route, which will fix the # of paths. And then if we do the ISSU, we should NOT see IPFIB crash.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur52940 |
Title: | N7K - snmpd cores cause Supervisor HAP reset - transceivers |
|
Description: | Symptom:
The "snmpd" process may crash continuously leading to a supervisor HAP reset.
Conditions:
Polling "ciscoEntitySensorMIB", that result in reading DOM information from 10G or 40G or 100G transceiver, during (re)initialization of the transceiver.
(Re)Initialization of transceiver happens only when -
- The transceiver is being reseated
- The linecard in which the transceiver is seated is reseated or reloaded
- The switch itself is being reloaded
Workaround:
Block ciscoEntitySensorMIB from being polled. This can be done by creating a new role, as follows:
(config)# role name skipEntSensor <--------------------- name can be anything.
(config-role)# rule 1 permit read
(config-role)# rule 2 deny read oid 1.3.6.1.4.1.9.9.91
(config-role)# end
(config)# snmp-server community safeWalk group skipEntSensor <-------------- safeWalk in this example is the community name. Change it to whatever is used in production.
After this when a snmpwalk (getnext) is done ciscoEntitySensorMIB is skipped.
All community strings configured on the switch will need the
role group skipEntSensor applied to include public, private, etc. community strings
Further Problem Description:
The snmpd crash is caused by invalid data returned by port-client due to an internal timeout when reading the DOM of a transceiver that is still initializing.
This problem is seen only on 6.2.10 software version.
DOM is not accessible through CLI when the port/transceiver is still initializing.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(10)E6, 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.14), 6.2(12)FT(0.20), 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)EV(0.137) |
|
|
| |
| |
Bug Id: | CSCud75360 |
Title: | F2 module fails to install routes after CLP_FIB_TCAM_PF_INSERT_FAIL seen |
|
Description: | Symptom:
A Nexus 7000 with F2 modules may experience an issue with the following message:
2012 Nov 30 16:38:31 switch %IPFIB-SLOT3-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 4
2012 Nov 30 16:38:31 switch %IPFIB-SLOT2-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 5
2012 Nov 30 16:38:31 switch %IPFIB-SLOT3-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 5
2012 Nov 30 16:38:31 switch %IPFIB-SLOT2-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 7
2012 Nov 30 16:38:31 switch %IPFIB-SLOT3-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 7
2012 Nov 30 16:38:31 switch %IPFIB-SLOT2-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 8
2012 Nov 30 16:38:31 switch %IPFIB-SLOT2-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 10
2012 Nov 30 16:38:31 switch %IPFIB-SLOT3-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 8
2012 Nov 30 16:38:31 switch %IPFIB-SLOT2-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 11
2012 Nov 30 16:38:31 switch %IPFIB-SLOT3-4-CLP_FIB_TCAM_PF_INSERT_FAIL: FIB TCAM prefix insertion failed for IPV6 unicast on instance 10
After this log appears, it is possible that the fib tcam may freeze, and no new prefixes can be inserted.
Conditions:
This issue occurs when the fib capacity is near the upper advertised limit of the F2 module, even if only for a brief period of time
Workaround:
To prevent the issue it is required to reduce the fib size. The only way to recover is to reload the module affected.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: | 6.1(2)E4, 6.1(4), 6.1(4)S4, 6.1(4)S5, 6.1(4.25)S0, 6.1(4.39)S0, 6.2(1.93), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCuu53575 |
Title: | sh vlan id 1 shows incorrect ports after doing ASCII replay twice |
|
Description: | Symptom:
Any port which is not in mode trunk should not have config for trunk allowed vlan's under it. For exmaple
int po10
switchport
switchport mode fabricpath
switchport trunk allowed vlan 11-20
no shutdown
Conditions:
Only happens when "switchport trunk allowed vlan " is done after the mode is changed to no trunk mode.
Workaround:
Do no switchport trunk allowed vlan in case of fabricpath/pvlan mode as this config is of no use.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu11602 |
Title: | M2 linecard reset due to EOBC heartbeat failure |
|
Description: | Symptom:
A M2 linecard may be reset by the supervisor due to EOBC heartbeat being missed by the linecard
Conditions:
1. There should be NO cpu/eobc hog on LC.
2. Upon LC bring up, post_code should be in range 0x00 and 0xf0 only. (sh mod internal act mod shows PWR_MGMT_POST_CODE_REG(0xb) = 0xab)
Workaround:
Further Problem Description:
This was fixed in 6.2(10) via CSCup20959, but the problem is still seen
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut76387 |
Title: | FEX crashed at "satctrl" process |
|
Description: | Symptom:
FEX crashed at "satctrl" process
Conditions:
UNKOWN
Workaround:
NONE
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup19405 |
Title: | targeted ldp session fails when frr is in use |
|
Description: | Symptom:
Targeted ldp session is up when the primary tunnel is up, but goes down when frr goes active.
Conditions:
"In the scenarios where the MPLS core interface is a SVI or a sub-interface, packets coming in with two or more NULL labels and bound to the Supervisor card will be dropped"
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.151), 7.2(0)D1(0.456) |
|
Known Fixed Releases: | 7.1(0)AV(0.81), 7.2(0)D1(0.475), 7.2(0)D1(0.507), 7.2(0)D1(0.510), 7.2(0)ZD(0.186), 7.2(0)ZD(0.190), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCuh75899 |
Title: | N7K -core in xbar_driver_usd |
|
Description: | Symptom:
Process xbar_driver_usd on a module will leak memory, and eventually core.
The module will reboot.
Eventually, after three occurrences of running out of memory and then rebooting, the module will remain powered off.
A log message similar to the following will be generated:
1970 Jan 1 00:00:00.000 switch %MODULE-1-MOD_DIAG_FAIL: Module 1 (Serial number: JAF0000ABCD) reported failure due to Service on linecard had a hap-reset in device DEV_SYSMGR (device error 0xfe)
A core file for xbar_driver_usd will be generated and saved in logflash:core/
switch# show cores
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
1 1 1 xbar_driver_usd 2182 1970-01-01 00:00:00
On the module, show logging onboard will have the following error:
module-1# show logging onboard
Exception Log Record : Sun Jan 1 00:00:00 1970 (000000 us)
Device Id : 34304
Device Name : 0x8600
Device Error Code : fe000000(H)
Device Error Type : NULL
Device Error Name : NULL
Device Instance : 0
Sys Error : (null)
Errtype : CATASTROPHIC
PhyPortLayer : 0x0
Port(s) Affected :
Error Description : xbar_driver_usd hap reset
DSAP : 0
UUID : 16777216
Time : Sun Jan 1 00:00:00 1970
(000000 usecs 00000000(H) jiffies)
Conditions:
Polling ciscoSwitchFabricMIB with SNMP
Executing commands beginning with show hardware fabric-utilization internal snmp
Walking ciscoSwitchFabricMIB roughly 1000-2000 times will use all 100MB of available memory for the xbar_driver_usd process.
Workaround:
Restrict access to the following:
show hardware fabric-utilization internal snmp
ciscoSwitchFabricMIB (1.3.6.1.4.1.9.9.803)
More Info:
Memory usage can be monitored with the following command:
slot slot show processes memory | grep xbar_driver_usd
2182 3051520 MemoryLimit CurrentMemoryUsage 7fe3aa80/7fe3a460 xbar_driver_usd
Example configuration for blocking only ciscoSwitchFabricMIB:
role namename
rule 1 permit read
rule 2 deny read oid 1.3.6.1.4.1.9.9.803
snmp-server community communityString group name
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 6.1(4), 6.1(4.9)S0, 6.2(1.143)S3, 6.2(1.159)S1, 6.2(5.7), 7.0(0.50)S0 |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(4a), 6.1(4a)S1, 6.1(5.32)S0, 6.2(2), 6.2(2)S1, 6.2(3)S1, 6.2(3.5)S0, 6.2(5.2)S0, 7.0(0)ZD(0.84) |
|
|
| |
| |
Bug Id: | CSCty86291 |
Title: | MTS buffer exhaustion with sequential add of large vlans. |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCuu60496 |
Title: | NVT: mroute stuck in pending after sso |
|
Description: | Symptom:
MRIB routes seem to be in pending state. "show ip mroute" will show routes with pending flag.
Conditions:
when a "pim restart" command is issued, in rare occasions, it is possible that PIM does not a proper mrib_deregister() and when it restarts, does mrib_register instead of mrib_reregister. This makes PIM a sort of invalid client of MRIB and MRIB does not send any updates to PIM and also postpones sending any update to hardware.
Workaround:
The workaround for this issue is "restart pim" command itself. This command will restart and MRIB should see PIM as a valid client. It is possible that under various scenarios, this workaround might have to be done multiple times.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul44262 |
Title: | Ping over fabric-control-svi b/w N6K leaf and N7K RR spine may not work |
|
Description: | Some times Nexus 6000 DFA leaf may not establish the communication with Nexus 7000 BGP route-reflector node.
Symptom:
Any ping can not be executed successfully between Nexus 6000 DFA leaf and Nexus 7000 DFA Route-Reflector Spine nodes. The BGP session will not be established and the Nexus 6000 DFA node will be isolated from the network if it does not have redundant BGP RR session.
Conditions:
A reload on either Nexus 6000 or Nexus 7000 may cause that to happen, or interface flaps over fabric control-segment may also cause it.
The Nexus 7000 switch must be running 6.2.6 code for this to happen where this BGP RR spine feature was first introduced.
Workaround:
The work-around is to flap the fabric control-segment SVI once at the Nexus 6000 DFA leaf node.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(6a), 6.2(6a)S4, 6.2(7.7)S0, 6.2(8), 6.2(8)CM(0.6), 6.2(9)FM(0.37), 7.0(0)GI(0.5), 7.0(1)FVL(0.80), 7.0(2)NF(0.17) |
|
|
| |
| |
Bug Id: | CSCul63398 |
Title: | Shutting down a Vrf staying in Admin Down pending forever |
|
Description: | Symptom:
Shutting down a VRF staying in Admin Down pending forever
Conditions:
In a non-default VRF, BGP is redistributing HMM route. Now do a "no vrf context xxx" or shut down the VRF and then the problem will happen.
Workaround:
Restart BGP will recover (proceed to shut down the VRF which is stuck in Admin Down Pending state).
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(1), 6.2(0)PF(0.296), 7.0(0)ZN(0.104), 7.0(1)ZN(0.36) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)N1(0.420), 7.0(0)N1(1), 7.0(0)ZD(0.179), 7.0(0)ZN(0.142), 7.0(1)N1(0.58), 7.0(1)N1(1), 7.0(1)ZD(0.113), 7.0(1)ZN(0.126) |
|
|
| |
| |
Bug Id: | CSCug37665 |
Title: | "copy r s" causes ifmgr crashes |
|
Description: | Symptom:
ifmgr crashes after reload and issuing "copy r s"
Conditions:
reload switch with titanium images, and then issue "copy r s"
Workaround:
no
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(0)PF(0.231) |
|
Known Fixed Releases: | 6.2(0)PF(0.245), 7.0(0)BNZ(0.23), 7.0(2)NF(0.17), 7.1(0)D1(0.14), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCug71873 |
Title: | ip addr/ip route command fails in the second time configuration |
|
Description: | Symptom:
The second ip addr/ip route configuration will fail on pf_dev1.
Conditions:
Load with pf_dev1 images without ip configured. Configure ip addr/ip route, and then configure it again. The second configuration fails.
Workaround:
no
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(0)PF(0.242) |
|
Known Fixed Releases: | 6.2(0)PF(0.267), 7.0(0)BNZ(0.23), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCug43851 |
Title: | F2/F2E: Capture-filter not filtering any pkts |
|
Description: | Symptom:
Conditions:
Workaround:
Since there is an additional 12 bytes of recirc-header added to Ethernet header, the capture-filter is failing for packets coming from F1,F2 and F2E cards. The common workaround will be using display-filters. The display-filter syntax can be obtained from wireshark's website.
For capture-filter :
If the filter string "ether proto " is used, then "ether[24:2] = " is the workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.1(1), 6.1(2), 6.1(5)S2, 6.2(1.74)S4 |
|
Known Fixed Releases: | 6.2(5.7)S0, 6.2(6), 7.0(0)FM(0.11), 7.0(0)FM(0.7), 7.0(0)FM(0.8), 7.0(0.51)S0, 7.1(0)D1(0.14), 7.1(0)D1(0.15), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul52014 |
Title: | OF cmds timeout without proper error message |
|
Description: | Symptom:
Openflow show commands hang in scale scenario and do not return any output
Conditions:
When Large number of flows are being modified/deleted, simultaneously "show openflow ..." command will get stuck until the modification/deletion is complete. Commands hang for 30 seconds and come out without any output. Retrying command after some time provides the output properly.
Workaround:
Retry command after some time.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)ZD(99.55) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.243), 7.1(0)OTT(0.31), 7.1(0)PDB(0.191), 7.1(0)RTG(0.32), 7.1(0)ZD(0.292), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul53494 |
Title: | vzw 6.2.6 EFT: PIM over GRE not working |
|
Description: | Symptom:
IP multicast ping over GRE tunnel doesn't work. The ping packets are getting dropped at the tunnel destination.
Conditions:
The first two (or few) packets are reaching SUP with proper SHIM header at the remote side until (S,G) route is installed in the hardware. All further packets are going to hit this (S,G) and punt to SUP without SHIM header, which caused these packets to be dropped by packet manager. This is a special case where we have (S,G) with punt flag and no OIFs associated with the route. Problem is only there for tunnel interface which needs a decap at the tunnel end. Multicast ping over non-tunnel interface will not have this problem.
Workaround:
No workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(5.41)S4 |
|
Known Fixed Releases: | 6.2(10)E8, 7.0(0)BNZ(0.23), 7.0(0)GI(0.5), 7.1(0)ARP(0.2), 7.1(0)BF(0.17), 7.1(0)D1(0.47), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCug99362 |
Title: | EEM : Timer events are triggered twice - once for active and standby |
|
Description: | Symptom:
Timer events are triggered twice - once for active and standby
Conditions:
Timer events are triggered twice - once for active and standby
Workaround:
Dont use timer ed.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(0)PF(0.264) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)KM(0.37), 7.0(0)ZD(0.37), 7.0(2)NF(0.17), 7.1(0)D1(0.14), 7.1(0)EVN(0.18), 7.2(0)D1(1), 7.2(0)N1(1), 7.2(0)ZN(0.112), 7.2(0)ZN(0.28) |
|
|
| |
| |
Bug Id: | CSCul66222 |
Title: | pixm_vl service crash on Nexus 7000 |
|
Description: | Symptom:
The pixm_vl service may crash unexpectedly and result in a reload (with single sup) or a switchover (with dual sups).
2014 Jul 18 14:49:42 N7K %$ VDC-2 %$ %SYSMGR-2-SERVICE_CRASHED: Service pixm_vl" (PID 8053) hasn't caught signal 11 (core will be saved).
Conditions:
The following actions may trigger the issue:
- Deleting one or more VLANs
- Shutting down an interface
There may be other as-yet-unknown conditions.
Workaround:
No workaround.
Further Problem Description:
Although the code fix for this defect is included in NX-OS release 6.2(6), it is possible for this issue to carry through an ISSU from a vulnerable release to a fixed release. For example, this was seen on a customer device after an ISSU from 6.2(2a) [vulnerable] to 6.2(8a) [fixed].
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.60), 6.2(5.65)S1, 6.2(8)S0, 7.1(0)D1(0.22) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5.67)S0, 6.2(6), 7.0(0)FVX(0.66), 7.0(2)NF(0.17), 7.1(0)ARP(0.2), 7.1(0)D1(0.37), 7.1(0)ZD(0.99), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCum18808 |
Title: | Backup paths updates are not notified to HMM |
|
Description: | Symptom:
Since BGP backup path updates are not sent to HMM by Urib, HMM mobility is broken and host move cannot be complete.
Conditions:
This scenario will be hit when the box is reloaded with the startup config and when host move is done.
Workaround:
1) While reloading the box with startup config, make sure BGP configs are done and BGP is up before applying enabling HMM feature.
2) After reloading the box with startup config, perform restart bgp on all the boxes
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(99.1)ZD |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)N1(0.449), 7.0(0)N1(1), 7.0(0)ZD(0.189), 7.0(0)ZN(0.162), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60), 7.1(0)SDN(0.6) |
|
|
| |
| |
Bug Id: | CSCul57133 |
Title: | N7K: ACLQOS crash observed in aclqos_uf_get_num_vls |
|
Description: | Symptom:
ACLQOS crash was observed and F2E line card was brought down when N7K running 6.2.2 is reloaded.
Conditions:
nq-7e policy is configured on a system that was previously configured with 8e policy.
Workaround:
The issue is fixed.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S38, 7.1(0)D1(0.238), 7.1(0)OTT(0.27), 7.1(0)PDB(0.175), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCui02949 |
Title: | pimv6 anycast RP not working due to checksum error |
|
Description: | Symptom:
100% traffic loss for multicastv6 group configured with anycast RP
Conditions:
PIMv6 anycast RP configured, last-hop-router sends a join to one RP in the anycast RP set, first-hop-router registers with the second RP in the anycast RP set
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(1.155), 6.2(2a)S1, 6.2(2a)S4 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(2a), 6.2(2a)S11, 6.2(5.45)S0, 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)KM(0.37), 7.0(0)ZD(0.155), 7.0(0)ZN(0.78), 7.1(0)ARP(0.2) |
|
|
| |
| |
Bug Id: | CSCul43908 |
Title: | LISP ACL: VRF forwarding broken on egress; acl issue |
|
Description: | Symptom:
Shared and parallel mode VRF forwarding broken on egress, after LISP decapsulation
Conditions:
The traffic is not matching any ACLs
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.52)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5.59)S0, 6.2(6), 7.1(0)ZD(0.74), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul50951 |
Title: | vlan mgr crash -applying an encap template to VSI with 25bd-vni mapping |
|
Description: | Symptom:
Issue is due to memory corruption while free.
Conditions:
Happens only when there are multiple writes to lpss at a single instance.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)FVL(0.12), 7.0(1)FVL(0.13), 7.0(2)FD(0.41) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)GI(0.5), 7.0(1)FVL(0.15), 7.0(1)FVL(0.9), 7.0(2)NF(0.17), 7.1(0)D1(0.55), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul87609 |
Title: | I:392:FP non-default topo doesn't works after ISSU downgrade I to H+ |
|
Description: | Symptom:
I:392:FP non-default topo doesn't works after ISSU downgrade I to H+
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(1) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)N1(0.433), 7.0(0)N1(1), 7.0(0)ZD(0.183), 7.0(0)ZN(0.150), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul33530 |
Title: | Apex10: FCOE license is getting installed after reload |
|
Description: | Symptom:
Nexus 7000 shows F2 FCOE license installed even if it was not installed
Example
7710-1# sh lic usa
Feature Ins Lic Status Expiry Date Comments
Count
--------------------------------------------------------------------------------
MPLS_PKG No - Unused -
STORAGE-ENT No - Unused -
VDC_LICENSES Yes 4 In use Never -
FCOE-N7K-F248XP Yes 4 Unused Never 4 license(s) missing
ENHANCED_LAYER2_PKG No - Unused -
TRANSPORT_SERVICES_PKG Yes - Unused Never -
LAN_ENTERPRISE_SERVICES_PKG Yes - Unused Never -
--------------------------------------------------------------------------------
**** WARNING: License file(s) missing. ****
7710-1#
If you do "show file [license file name]" command you will see FCOE license was not installed.
It has been also seen that even if F2 line card in not installed in the system this error is seen.
Conditions:
TRANSPORT_SERVICES_PKG license installed in the system
Workaround:
"clear license sprom" command will clear the problem but it will re-appear after reload
Further Problem Description:
This happens because of an error in the license specfile. Because of overlapping bit positions FCOE is falsely turned on. The license spec file has been fixed. With these specfile after doing "clear license sprom" the problem should not happen.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.45)S3 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S77, 6.2(10.16)S0, 6.2(10.502)S0, 6.2(11)FM(0.26), 7.1(0)D1(0.278), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuh24768 |
Title: | PVLAN-vPC: Xlation entries messed up for a TS vPC; has entry Vi ->Vp egr |
|
Description: | Symptom:
The VLAN translation table entries might not be correct for VPC leg port-channels with PVLAN mode configured
This might cause incorrect VLAN translation in egress direction for PVLAN VPC legs.
Conditions:
This will be seen if VPC leg is in some PVLAN mode and PVLAN port mapping is configured. Now if mode is changed say from Trunk promiscuous to Trunk secondary, and TS port mappings are added on the VPC leg PC, VLAN translation tables may contain both translations, for the previous TP mode too and for the current TS mode too.
The correct behavior would have been for the VPC leg to have only the Translation table programming specific to the current port-mode.
Workaround:
Deleting the VPC leg port-channel and recreating it using "channel-group X" command for member ports will cleanup the stale translation table entries, and restore translation table entries according to the current port mode of the VPC leg port-channel
1. Delete port-channel
switch-two(config)# no interface port-channel 10
switch-two(config)#
2. Recreate port-channel using the member port-config:
switch-two(config)# int e7/1-2
switch-two(config-if-range)# channel-group 10
switch-two(config-if-range)#
3. The translation table entries will be correct after this
4. Make the port-channel 10 a vpc again:
switch-two(config-if-range)# int po10
switch-two(config-if)# vpc 1
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(1.121), 6.2(8)S17 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.20), 6.2(10)S21, 6.2(8)TS(0.28), 6.2(9.1)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.238), 7.1(0)NF(0.32), 7.1(0)OTT(0.27) |
|
|
| |
| |
Bug Id: | CSCul98625 |
Title: | Prefix present in (AM) sh ip arp but not in (URIB) sh ip route |
|
Description: | Symptom:
unicast drops seen after reload access switches several times.
HB-L3EDC-CARMEL-2# sh plat afm info copp | grep glean
36 glean 128000 4687 8976371536 507761370
00
HB-L3EDC-CARMEL-2# sh plat afm info copp | grep glean
36 glean 128000 4687 8976593024 507943467
68
HB-L3EDC-CARMEL-2#
Conditions:
see eng notes
Workaround:
workaround on carmel-2
int po34000
shut/no sh
traffic will resume
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(2)UI(0.2) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)N1(0.491), 7.0(0)N1(1), 7.0(0)ZD(0.208), 7.0(0)ZN(0.200), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60), 7.1(0)SDN(0.6) |
|
|
| |
| |
Bug Id: | CSCui35602 |
Title: | traffic drops with rbh enabled on m/f2e vdc |
|
Description: | Symptom:
Packets received on a port for a DCE VLAN will experience drops.
Conditions:
The modulo rbh will not work if there is a vdc with MX and F2e linecards when it is operating in proxy mode.
Workaround(s):
None. Recommend not to use modulo rbh in proxy vdc.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(5.15)S0, 6.2(6), 7.0(0)FF(0.2), 7.1(0)D1(0.14), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul03740 |
Title: | Install remove <package> fails after switchover |
|
Description: | Symptom:
install remove operation fails after switchover
Conditions:
install remove operation fails after switchover
Workaround:
None
Further Problem Description:
install remove operation fails after switchover. Deactivation of package done before switchover.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)ZD |
|
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.53), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul94195 |
Title: | timeout while configuring 4K policer-classmaps in a policy |
|
Description: | Symptom:
timeout while configuring 4K policer-classmaps in a policy
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2)S42, 6.2(6)S3 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.5)S0, 6.2(7.7)S0, 6.2(8), 6.2(8)AA(0.7), 6.2(8)FM(0.10), 6.2(8)FM(0.12), 6.2(9)FM(0.37), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.109) |
|
|
| |
| |
Bug Id: | CSCul51350 |
Title: | Traffic blackhole w/ dataMDT cfg & src starts few mins after IGMP join |
|
Description: | Symptom:
Traffic blackhole on ingress PE with data MDT configuration
Conditions:
1. Topology (RP and source behind the same PE):
Src------CE1 (FHR and RP) --------PE1-----Core------PE2------Rcvr
2. Data MDT configured
3. Src starts traffic few minutes after IGMP join received from Rcvr
Workaround:
Multiple workarounds:
1) retart pim
2)
Stop traffic and joins and wait for routes to time out
Start traffic and joins at around the same time.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5)BF(0.61) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S34, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.214), 7.1(0)FC(0.2), 7.1(0)N1(0.267), 7.1(0)N1(1), 7.1(0)NF(0.32) |
|
|
| |
| |
Bug Id: | CSCuj98135 |
Title: | N7K: FP Proxy L2 Learning breaks Proxy L3 Forwarding For Unicast Traffic |
|
Description: | Symptom:
After configuring Fabricpath Proxy l2 Learning and dynamic mac entries are flushed from the mac table Proxy L3 Routing is affected. Unicast traffic sent from the supervisor or from an M Series line card towards a fabricpath core port may be dropped because the fabricpath Outer Destination Address is misprogrammed during encapsulation.
Conditions:
Nexus 7000 running NX-OS 6.2(2)a in mixed chassis VDC where M1/M2 and F2e modules are used with proxy l2 learning.
Workaround:
Enable FabricPath core port MAC learning. The egress module must have the destination mac address programmed to avoid this issue.
cli config:
hardware fabricpath mac-learning module [port-group ]
Further Problem Description:
This bug is specific to F2 and F2E only in NX-OS release 6.2(2)a
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2a)S20, 6.2(5.38)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5.38)S1, 6.2(5.40)S0, 6.2(5.43)S0, 6.2(6), 7.1(0)ZD(0.74), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul33688 |
Title: | ipqosmgr cores and runs into weird state in a sequence with pc/brk-out |
|
Description: | Symptom:
A Nexus 7000 system may not be able to save its configuration and log the following
errors:
switch# copy r s
[################################## ] 83%
%SYSMGR-3-CFGWRITE_SRVFAILED: Service "ipqosmgr" failed to store its configuration (error-id 0x41170008).
[########################################] 100%
%SYSMGR-2-CFGWRITE_ABORTED: Configuration copy aborted.
Configuration update aborted: request was aborted
%SYSMGR-3-CFGWRITE_FAILED: Configuration copy failed (error-id 0x401E0000).
switch#
switch# show system error-id 0x41170008
Error Facility: DDB Library
Error Description: Deleting a linked node
switch# show system error-id 0x401E0000
Error Facility: sysmgr
Error Description: request was aborted
Conditions:
Unknown
Workaround:
Steps tp recover:
1. Manually backup the current config
2. Erase the config with "write erase"
3. Reload the box
4. Manually restore the configuration
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.50)S1 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5.58)S0, 6.2(6), 7.1(0)ZD(0.74), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul48837 |
Title: | SSTE: Clis Core Observed on 6.2(5.59)S0 |
|
Description: | Symptom:
clis core is observed on default vdc with l2vpn config
Conditions:
On N7k reload
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.55)S2, 6.2(5.59)S0, 7.1(0)D1(0.58), 7.1(0)D1(0.64) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5.67)S0, 6.2(6), 7.1(0)D1(0.64), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul96643 |
Title: | npacl core seen while adding rmap entry with Detailed logging enabled |
|
Description: | Symptom:
npacl service crash
Conditions:
This has been seen on N7K running 6.2(6), npacl service crash while adding route-map/acl with logging detailed enabled.
Workaround:
Disable logging detailed.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5)BF(0.66) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.7)S0, 6.2(8), 6.2(8)CM(0.5), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul25514 |
Title: | VPC port in Root Blocking state |
|
Description: | Symptom:
Spanning tree marks a vPC port as "Root BLK" if it receives a superior BPDU
# sh span int po1
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN20 Root BLK 1 128.4096 (vPC) P2p
Conditions:
This issue occurs on a Nexus 7000 running vPC
It has been seen after upgrade to 6.2.
Occurs when the N7k vPC pair loses root bridge election off a vPC
Workaround:
make the N7K vPC pair the root bridge by giving it a superior priority
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.45)S3, 6.2(5.49)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5.52)S2, 6.2(5.55)S0, 6.2(6), 7.1(0)ZD(0.74), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul11180 |
Title: | BGP session is closed due to fd read error |
|
Description: | Symptom:
BGP flapping on N7K running 6.2.2 due to fd read error
sh bgp internal event-history events |inc "Read error from peer"
[8682]: [8693]: (default) EVT: Read error from peer : No buffer space available
N7K#show ip bgp neighbors show
Connections established 1000, dropped 999<<<<<<
Last reset by us 00:00:18, due to fd read error<<<<<<<<<
Reset error value 64
Last reset by peer never, due to No error
Conditions:
Issue is seen in Nexus7000 with 6.2 releases., what conditions to see this ?
Workaround:
Reload the VDC or Switch.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(0)PF(0.296), 6.2(5.41)S2 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.5)S0, 6.2(7.7)S0, 6.2(8), 6.2(8)BF(0.24), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.109), 7.0(0)N1(0.514), 7.0(0)N1(1), 7.0(0)ZD(0.217) |
|
|
| |
| |
Bug Id: | CSCuj18321 |
Title: | F3: Adjacency allocation failed on instance 0 with mcast scale 12K |
|
Description: | Symptom:
2013 Sep 11 23:20:38 %$ VDC-1 %$ %IPFIB-SLOT9-4-FLN_FIB_ADJ_EXHAUSTED: Adjacency allocation failed on instance 0
Conditions:
Using pim
More than a few hundred multicast routes or a loop impacting the modules with the routes
Workaround:
Reload affected modules once loop or route churn is no longer present
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.7), 7.0(0.50)S0 |
|
Known Fixed Releases: | 6.2(5.15)S0, 6.2(6), 7.0(0)FF(0.8), 7.1(0)D1(0.14), 7.1(0)D1(0.15), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCui63440 |
Title: | Interface bdi command not appearing in latest zd7_0 |
|
Description: | Symptom:
Interface bdi was not appearing after the sync
Conditions:
BDI could not be configured as a result
Workaround:
None
Further Problem Description:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(0)ZD(0.56) |
|
Known Fixed Releases: | 7.0(0)FV(0.69), 7.0(0)ZD(0.53), 7.0(0)ZD(0.59), 7.0(1)ZD(0.3), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCui85485 |
Title: | EIGRP IPv6 neighborship in non-default VRF fails in certain scenarios |
|
Description: | Symptom:
EIGRP IPv6 neighborship in non-default VRF fails in certain scenarios
Conditions:
This is only seen
1. with SVIs
2. when we execute "no interface " followed by "interface ".
3. in non-default VRF
Workaround:
unconfigure and re-configure EIGRP under the interface
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2)S40 |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)ZD(0.146), 7.0(0)ZN(0.49), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.1(0)ZD(0.95), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCui11913 |
Title: | ARP req dropped on secondary switch after shut on vPC leg of primary sw |
|
Description: | Symptom:
When Spanning-tree is disabled on certain vlans on a vpc-leg, when the vpc-leg is shut on the primary, STP on the secondary sets the vpc-leg to disable for those vlans.
Conditions:
*Spanning-tree must be disabled on the vlans of a vpc leg
*Happens only for VPC legs on the secondary switch
Workaround:
Flap the vpc leg on the secondary.
Further Problem Description:
Issue is found only in 6.2.2 and 6.2.2a and has been resolved in 6.2.6
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2)S4, 6.2(2a), 6.2(5.7), 7.0(0.30) |
|
Known Fixed Releases: | 6.2(5.7)S0, 6.2(6), 7.0(0)FI(0.3), 7.0(0.37)S0, 7.1(0)D1(0.14), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuj53029 |
Title: | port-sec crashes when static mac port-sec configured on po-channel |
|
Description: | Symptom:
When port-security is configured with a static mac-address on a port-channel, shows Service not responding and then eth-port-sec process crashes and generates cores
Conditions:
The bug is verified exists in 7.0(0)ZD(0.90)
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(0)ZD(0.90) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)KM(0.37), 7.0(0)ZD(0.129), 7.0(2)NF(0.17), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.1(0)ZD(0.95), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul34935 |
Title: | SAL crashed while disabling cts caching mode 1 |
|
Description: | Symptom:
disabling sgt-mode 2 caching
Conditions:
disabling sgt-mode 2 caching
Workaround:
disabling feature
Further Problem Description:
disabling sgt-mode 2 caching - results in crash
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.53)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5.56)S0, 6.2(6), 7.1(0)ZD(0.74), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul36627 |
Title: | hmm crash by mts_opc_version_get () |
|
Description: | Symptom:
scaled
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(1) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)BF(0.77), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)N1(0.130), 7.1(0)N1(1), 7.1(0)NF(0.28), 7.1(0)OTT(0.6) |
|
|
| |
| |
Bug Id: | CSCul36036 |
Title: | Unable to modify VLAN Failed to run the commands. Please try again later |
|
Description: | Symptom:
Unable to change VLAN mode to fabricpath
gf-agg2# conf
Enter configuration commands, one per line. End with CNTL/Z.
gf-agg2(config)# vlan 501-1000
gf-agg2(config-vlan)# mode fabricpath
gf-agg2(config-vlan)#
Failed to run the commands. Please try again later.
Conditions:
Workaround:
Issue the command in enable mode
"terminal reset vlan-config-mutex"
After this you will be able to change VLAN mode
Further Problem Description:
none.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.50)S0, 6.2(5.55)S3, 7.1(0)D1(0.91) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.7)S0, 6.2(8), 6.2(8)CM(0.3), 7.0(0)BNZ(0.23), 7.1(0)D1(0.132), 7.1(0)FC(0.2), 7.1(0)PDB(0.94), 7.1(0)ZD(0.179), 7.1(0)ZD(0.200) |
|
|
| |
| |
Bug Id: | CSCul59318 |
Title: | Memory leak with otv isis during shut/no shut of otv join interface |
|
Description: | Symptom:
isis_otv process crashes when a new LSP is created.
Conditions:
memory leak encountered with isis_otv which could be triggered when the OTV join interface bounces
Workaround:
There is no workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2a)S9, 6.2(5.52)S0 |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)ZD(1.31), 7.0(0)ZN(1.68), 7.0(1)N1(0.36), 7.0(1)N1(0.47), 7.0(1)N1(1), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.1(0)ZD(0.95) |
|
|
| |
| |
Bug Id: | CSCuj17443 |
Title: | Inherit command on Nexus is not working with TACACS authorization |
|
Description: | Symptom:
Unable to add inherit command
N7K(config)# interface port-channel1006
N7K(config-if)# inherit port-profile Blade-Servers
ERROR: Failed to write VSH commands
N7K(config-if)# exit
Conditions:
H/W: cisco Nexus7000 C7009 (9 Slot) Chassis ("Supervisor Module-1X")
S/W: 6.0(4) to 6.2(1)
ACS: 5.3 patch 6
Inherit command on Nexus is not working with TACACS authorization enabled.
Workaround:
Remove TACACS authorization commands
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(1) |
|
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)EC(0.16), 6.2(8)NO(0.6), 6.2(8)S9, 6.2(8.5), 6.2(9)FM(0.37), 7.0(0)BZ(0.46) |
|
|
| |
| |
Bug Id: | CSCum10921 |
Title: | Norca64 (SPINE)- IGMP core @igmp_group_expiry |
|
Description: | Symptom:
In rare cases, when an IGMP group ages out, the IGMP process can crash.
Conditions:
Memory is being accessed immediately after free. If it gets used for some other purposes immediately after free, then the invalid access can cause a crash
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(0.350) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)KM(0.37), 7.0(0)ZD(1.30), 7.0(0)ZN(1.66), 7.0(1)N1(0.36), 7.0(1)N1(0.47), 7.0(1)N1(1), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.1(0)ZD(0.95) |
|
|
| |
| |
Bug Id: | CSCul84608 |
Title: | N7K-L2VPN VPLS Scale-No switchover after 4 times l2vpn Process crash |
|
Description: | Symptom:
According to the HA policy, the router should perform an RP failover when the
L2VPN process crashes and tries restarting 3 times, but instead it doesn't perform
the failover and remains at the failure state.
Conditions:
L2VPN crashes 4 or more times.
Workaround:
No workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)BF(0.2), 7.1(0)ZD(0.181) |
|
Known Fixed Releases: | 15.4(2)S2, 15.4(2.17)S0.8, 15.4(3)M2.1, 15.4(3)M3, 15.4(3)S, 15.4(3)SN1a, 15.5(0.16)T, 15.5(0.16.1)CG, 15.5(0.20)PI27a, 15.5(0.8)S |
|
|
| |
| |
Bug Id: | CSCui43441 |
Title: | 6.9.0.29.S75:Error with:MTS_SAP_PLCMGRwhile allocating interfaces to vdc |
|
Description: | Symptom:
plcmgr timeout
Conditions:
mixed mode
Workaround:
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.9(0.28), 6.9(0.29)S0 |
|
Known Fixed Releases: | 6.9(0.31)S0, 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)KM(0.37), 7.0(2)NF(0.17), 7.1(0)ARP(0.2), 7.1(0)BF(0.23), 7.1(0)D1(0.43), 7.1(0)ZN(0.181), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuj64873 |
Title: | QOS Time out causing VDC creation failure or module to come up |
|
Description: | Symptom:
Line cards fail to come up
VDC creation failure
Conditions:
Large scale of ports or port-channels
QOS Policy configurations on ports
With at least 5 line cards F2/F2E (48 ports) user will see this problem on switch reload. 5th linecard might fail to come up.
Workaround:
Bring up cards one at a time or maximum of four line cards at a time.
Or
Use 8q default queueing policy and in default
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2)S42 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(8), 6.2(8)S0, 6.2(8.1)S0, 6.2(9)FM(0.45), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul54387 |
Title: | BDI not coming up:RTM not sendin MTS_OPC_RTM_L2_TOPO_ACTIVE_VLANS to SVI |
|
Description: | Symptom:
BDI not coming up if doing out of order execution to bring up the BDI
Conditions:
Out of order Execution, mainly add the vni to the bridge-domain at the very end.
Workaround:
Flap the physical interface
Further Problem Description:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(2)FD(0.49) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FV(0.122), 7.0(0)GI(0.5), 7.0(1)FVL(0.11), 7.0(2)NF(0.17), 7.1(0)D1(0.14), 7.1(0)D1(0.55), 7.1(0)ZD(0.37), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCul44598 |
Title: | Multicast group stats not getting updated on core switch |
|
Description: | Symptom:
Intermittent traffic loss for hosts with spt-threshold infinity configured in a network which also has sparse mode hosts.
Conditions:
This issue is seen when the Host with spt-threshold infinity and the sparse mode host have the common intermediate router which is in the shared tree path for both the hosts and also in the (S, G, R) prune path from the sparse mode host while it sends joins to the source tree.
Workaround:
Make shared tree and source tree the same path for the sparse mode host or have spt-threshold infinity hosts only.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.55)S2, 6.2(5.59)S0 |
|
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)EC(0.16), 6.2(8)NO(0.3), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuj70143 |
Title: | PPF out of sync between SUP and LCs |
|
Description: | Symptom:
The following error can be seen when applying ACL changes:
"Failed to complete Verification: Link exists" or
"Database Internal error"
Conditions:
Applying a large amount of config change.
Workaround:
Reload the module, or change the name of the ACL/object-group
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 5.2(9) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.8), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.96), 7.1(0)BNB(0.1), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)N1(0.153) |
|
|
| |
| |
Bug Id: | CSCun90491 |
Title: | VLAN BD change causes Traffic outage on 'untouched' VLAN IGMPV3 S entry |
|
Description: | Symptom:
Traffic loss will be observed on IGMPV3 (G,S) entries for untouched VLAN's on F3 modules.
Conditions:
1) IGMP snooping enabled and working in IGMPv3 mode (and)
2) Delete of VLAN (and)
3) Deleted VLAN's HW_BD should be same as the mac table HW BD field value of any other VLAN's S entry.
Under the above conditions traffic loss on IGMPV3 (G,S) entries will be seen. The traffic loss is not applicable when IGMPV2 (G,*) entries are used. This issue happens very rarely because of condition 3.
Workaround:
1) IGMPV3 leave and join for the untouched VLAN's that got affected [OR]
2) Do a shut / no shut on the affected VLAN.
This issue is fixed in image version 6.2.10
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)S4 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S77, 6.2(10.16)S0, 7.1(0)AV(0.38), 7.1(0)D1(0.291), 7.1(0)EV(0.116), 7.1(0)OTT(0.40), 7.1(0)PDB(0.226), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo86477 |
Title: | LISP crash due to mts buffers leak |
|
Description: | Symptom:
LISP service crash due to mts buffer leaks in SAP associated with LISP UFDM MTS queue
Conditions:
Feature LISP is configured on the switch and MTS buffers leak causing the crash
Workaround:
Disable feature lisp
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.22), 6.2(8)TS(0.28), 6.2(9.1)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)OTT(0.6) |
|
|
| |
| |
Bug Id: | CSCup00538 |
Title: | nfp cored after ISSD from 7.1.D1.147 to 6.2.8.S35 |
|
Description: | Symptom:
Nfp process cored.
Conditions:
During ISSD.
Workaround:
no workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.147) |
|
Known Fixed Releases: | 7.1(0)D1(0.154), 7.1(0)D1(0.156), 7.1(0)FC(0.2), 7.1(0)GF(0.14), 7.1(0)IF(99.16), 7.1(0)ZD(0.207), 7.1(1)SP(0.4), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo83041 |
Title: | N7K : getnext cbeDot1dTpVlanAgingTime for partial value system crashes |
|
Description: | Symptom:
Performing getnext operation on cbeDot1dTpVlanAgingTime with the index value more than 4094 will system crash.
Conditions:
Performing getnext operation on cbeDot1dTpVlanAgingTime with the index value more than 4094
Workaround:
Avoid using invalid index value more than 4094 for performing getnext operation on cbeDot1dTpVlanAgingTime.
Further Problem Description:
The problem exists in 6.2.x release.
Fixes has been integrated into 6.2(10) and later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.139) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S14, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.177), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)OTT(0.11), 7.1(0)PDB(0.100), 7.1(0)VX(0.3) |
|
|
| |
| |
Bug Id: | CSCup89222 |
Title: | F3: PBR causes misprogramming of route |
|
Description: | Symptom:
FIB programming on the module does not match with the RIB. This causes traffic to be blackholed.
Conditions:
N7k running 6.2.8a.
PBR is applied on the ingress SVIs.
F3 module in use and was reloaded.
Workaround:
remove PBR and reapply it causes the programming to be corrected.
Further Problem Description:
N7k# sh ip route 129.186.254.131
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF
129.186.254.131/32, ubest/mbest: 1/0, attached
*via 129.186.254.131, Vlan254, [250/0], 16:19:07, am
Module 5 is F3. There are 6 instances on the module.
N7k# sh sys intern for ipv4 route 129.186.254.131 module 5 det
RPF Flags legend:
S - Directly attached route (S_Star)
V - RPF valid
M - SMAC IP check enabled
G - SGT valid
E - RPF External table valid
129.186.254.131/32 , Vlan254
Dev: 0 , Idx: 0x109d6 , Prio: 0x62db , RPF Flags: VS , DGT: 0 , VPN: 7
RPF_Intf_5: Vlan254 (0x7 )
AdjIdx: 0x5c , LIFB: 0 , LIF: Vlan254 (0x7 ), DI: 0x0
DMAC: 002a.6aa4.98c3 SMAC: 002a.6aa4.d0c3
129.186.254.131/32 , Vlan34
Dev: 1 , Idx: 0xd587 , Prio: 0x5b11 , RPF Flags: VS , DGT: 0 , VPN: 7
RPF_Intf_5: Vlan254 (0x22 )
AdjIdx: 0x5a , LIFB: 0 , LIF: Vlan34 (0x7 ), DI: 0x0 >>>>>> INCORRECT LIF
DMAC: 002a.6aa4.98c3 SMAC: 002a.6aa4.d0c3
129.186.254.131/32 , Vlan34
Dev: 2 , Idx: 0x171fb , Prio: 0x48e3 , RPF Flags: VS , DGT: 0 , VPN: 7
RPF_Intf_5: Vlan254 (0x23 )
AdjIdx: 0x5a , LIFB: 0 , LIF: Vlan34 (0x7 ), DI: 0x0 >>>>>> INCORRECT LIF
DMAC: 002a.6aa4.98c3 SMAC: 002a.6aa4.d0c3
129.186.254.131/32 , Vlan34
Dev: 4 , Idx: 0x1278f , Prio: 0x4b73 , RPF Flags: VS , DGT: 0 , VPN: 7
RPF_Intf_5: Vlan254 (0x22 )
AdjIdx: 0x5a , LIFB: 0 , LIF: Vlan34 (0x7 ), DI: 0x0 >>>>>> INCORRECT LIF
DMAC: 002a.6aa4.98c3 SMAC: 002a.6aa4.d0c3
129.186.254.131/32 , Vlan254
Dev: 5 , Idx: 0xe187 , Prio: 0x5ebe , RPF Flags: VS , DGT: 0 , VPN: 7
RPF_Intf_5: Vlan254 (0x7 )
AdjIdx: 0x73 , LIFB: 0 , LIF: Vlan254 (0x7 ), DI: 0x0
DMAC: 002a.6aa4.98c3 SMAC: 002a.6aa4.d0c3
Some of the instances have incorrect programming
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S21, 6.2(6)S21, 6.2(7.28)S0, 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S52, 6.2(10.16)S0, 7.1(0)AV(0.38), 7.1(0)D1(0.271), 7.1(0)OTT(0.36), 7.1(0)PDB(0.209), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo96373 |
Title: | ipfib crash while recovering from NNHOP frr in fln lfib delete adj |
|
Description: | Symptom:
Thread 1 (process 1205):
#0 0x1030363c in fln_lfib_delete_mpls_adj (pi_handle=0x15b81170, hardware_handle=0x80000062,
platform_space=0x15b81206) at ../platform/dc3/flanker/fln_fib/fln_lfib.c:1789
#1 0x101c4620 in lfib_platform_delete_adj (adj=)
at ../feature/forwarding-sw/fib/lfib_platform.c:289
#2 0x101eaa08 in lfib_adj_destroy (adj=0x15b81170) at ../feature/forwarding-sw/fib/lfib_adj.c:946
#3 0x100d0f64 in ufib_obj_delete (ups_object=0x0, object=0x15b81170)
at ../feature/forwarding-sw/fib/ufib_obj.c:228
#4 0x100d11f8 in ufib_obj_unlink_objects (from_object=, delete_now=1)
at ../feature/forwarding-sw/fib/ufib_obj.c:305
#5 0x10219988 in lfib_te_related_adj_obj_destroy (te_related_adj_obj=0x15bba194)
at ../feature/forwarding-sw/fib/lfib_te.c:5125
#6 0x100d0f8c in ufib_obj_delete (ups_object=0x0, object=0x15bba194)
at ../feature/forwarding-sw/fib/ufib_obj.c:240
#7 0x100d11f8 in ufib_obj_unlink_objects (from_object=, delete_now=1)
at ../feature/forwarding-sw/fib/ufib_obj.c:305
#8 0x101fe214 in lfib_te_destroy_backup_adj (te_node_p=0x15b947b8)
at ../feature/forwarding-sw/fib/lfib_te.c:1215
#9 0x1021ca40 in lfib_te_normalize_adj (vdb=0x15305048, te_node_p=0x15b947b8, nhlfe_p=0xbf9452ec)
at ../feature/forwarding-sw/fib/lfib_te.c:2853
#10 0x1021e080 in lfib_te_update_non_normal (vdb=0x15305048, te_node_p=0x15b947b8,
nhlfe_p=0xbf9452ec) at ../feature/forwarding-sw/fib/lfib_te.c:3116
#11 0x1021f618 in lfib_te_update (vdb=0x15305048, te_node_p=0x15b947b8, nhlfe_p=0xbf9452ec,
rr_info=0x0) at ../feature/forwarding-sw/fib/lfib_te.c:3413
#12 0x10220620 in lfib_te_get_create (vdb=0x15305048, fec_def_p=,
nhlfe_p=0xbf9452ec, rr_info=0x0) at ../feature/forwarding-sw/fib/lfib_te.c:3639
#13 0x101ede3c in lfib_get_create_fec_te (vdb=, fec_op=Cannot access memory at
ddress 0x0
)
at ../feature/forwarding-sw/fib/lfib_fec.c:1128
#14 0x101f3e9c in lfib_get_create_fec (vdb=0x15305048, fec_op=
{operation = 0 '\0', fec_type = 5 '\005', fec = {if_index = 571473931, option_b = {rd = 245461844161560576, addr = {ip_addr = 0, v6_addr = '\0' }, label_space_id = 0, label_i
= 0}, lsp_id_v4 = {tunnel_ipv4_source = 571473931, tunnel_ipv4_dest = 0, tunnel_id = 0, ext_tunnel_
d = 0, lsp_id = 0}, lsp_id_v6 = {tunnel_ipv6_source = "\"\020\000\v", '\0' , tunne
_ipv6_dest = '\0' , tunnel_id = 0, ext_tunnel_id = 0, lsp_id = 0}, v4_prefix = {ta
le_id = 571473931, prefix = 0, prefix_len = 0 '\0'}, v6_prefix = {table_id = 571473931, prefix = '\0
, prefix_len = 0 '\0'}, deagg = {table_id = 571473931}, cbts = {master_tunnel = 5
1473931, member = {0, 0, 0, 0, 0, 0, 0, 0}}}, tlv = {num_tlvs = 0, tlv = 0xbf946b22}},
nhlfe=0xbf9452ec, nhlfe_v6=0xbf945aec, num_nhlfe=1 '\001', num_labels=0 '\0',
fec_obj=0xbf944f9c, next_obj=0xbf944f98, nh_count=0xbf944f92 "", rr_info=0x0)
at ../feature/forwarding-sw/fib/lfib_fec.c:1465
#15 0x101f68f4 in lfib_fec_update (vdb=0x15305048, fec=0x4b83928d, rr_info=)
at ../feature/forwarding-sw/fib/lfib_fec.c:1815
#16 0x101f75d8 in lfib_bulk_label_update (vdb=0x15305048, update=)
at ../feature/forwarding-sw/fib/lfib_fec.c:2470
#17 0x100828c0 in ufib_ufdm_label_update (event=,
ret_fsm_event_list=) at ../feature/forwarding-sw/fib/ipfib_msg
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)MPL(0.24) |
|
Known Fixed Releases: | 7.1(0)D1(0.151), 7.1(0)D1(0.161), 7.1(0)FC(0.2), 7.1(0)GF(0.14), 7.1(0)IF(99.16), 7.1(0)NF(0.28), 7.1(0)OTT(0.4), 7.1(0)ZD(0.213), 7.1(1)SP(0.4), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCun11657 |
Title: | zd7_1_0_bf_bundle breakage likely due to some infra/new_installer commit |
|
Description: | Symptom:
Build failure
Conditions:
Build
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)BF(0.21) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)GI(0.5), 7.0(0)KM(0.37), 7.0(2)NF(0.17), 7.1(0)ARP(0.2), 7.1(0)D1(0.47), 7.1(0)PDB(0.13), 7.1(0)ZN(0.181), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo84700 |
Title: | Option B Same RD - ASBR does not reflect PE client routes to remote ASBR |
|
Description: | Symptom:
From below topology, vrf1 uses same RD across the PE's and ASBR's
PE1(vrf1) ----------- ASBR1 (vrf1) ----------- BGP 3107 ----------- ASBR2 (vrf1) ----------- PE2 (vrf1)
ASBR1 does not reflect PE1 learnt vpn routes (vrf1) to ASBR2.
Conditions:
This symptom is seen on Nexus 7000 Series Switch acting as ASBR/PE/RR.
Workaround:
Use unique RD.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)E1 |
|
Known Fixed Releases: | 6.2(8)E1, 7.2(0)D1(1), 7.2(0)ZD(0.44), 7.2(0)ZN(0.52) |
|
|
| |
| |
Bug Id: | CSCum87318 |
Title: | non-default vrf ping not working |
|
Description: | Symptom:
non-default vrf ping not working
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)FVL(0.41) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)GI(0.5), 7.0(0)GI(0.6), 7.0(0)KM(0.37), 7.0(1)FVL(0.48), 7.0(1)FVL(0.49), 7.0(2)NF(0.17), 7.1(0)D1(0.55), 7.1(0)PDB(0.13), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCun04290 |
Title: | Multicast Vinci: sparse mode with BL load balancing, packets duplication |
|
Description: | Symptom:
multicast packets might get duplicated
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)KM(0.64), 7.0(1)N1(0.93), 7.0(1)N1(1), 7.0(1)ZD(0.130), 7.0(3)I1(0.2), 7.0(3)I1(1), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28) |
|
|
| |
| |
Bug Id: | CSCur80369 |
Title: | Iplus Build 405 : Ospf hap reset on clear ip route * |
|
Description: | Symptom:
clear ip route *
Conditions:
System reset due to OSPF hap
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.405) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110), 7.0(2)FIP(0.6), 7.1(0)AV(0.38), 7.1(0)N1(0.416), 7.1(0)N1(1), 7.1(0)ZD(0.373), 7.1(0)ZN(0.491), 7.1(1)N1(0.34) |
|
|
| |
| |
Bug Id: | CSCug40707 |
Title: | 6.1(4) / 6.2(1) - Multiple Process crash - SIGABRT not setting heartbeat |
|
Description: | Symptom:
Multiple Services crashing with the following log messages:
2013 Jun 12 09:26:10.467 TAA-RZ-2 %SYSMGR-3-HEARTBEAT_FAILURE: Service "bgp" sent SIGABRT for not setting heartbeat for last 4 periods. Last heartbeat 148.45 secs ago.
2013 Jun 12 09:28:42.938 TAA-RZ-2 %SYSMGR-3-HEARTBEAT_FAILURE: Service "bgp" sent SIGABRT for not setting heartbeat for last 4 periods. Last heartbeat 150.07 secs ago.
++ This is followed by several other process to crash.
++ The VDC becomes unresponsive with the following log messages:
++ Due to multiple crash of the service, the supervisor switchover takes place.
++ In a single supervisor, the device may reload.
Reason: Reset triggered due to HA policy of Reset
Service: Service "bgp" in vdc 2 hap reset
Version: 6.1(4)
Conditions:
++ Customer device is running 6.1(4) or 6.1(4a) or 6.2(1).
++ Customer tries to execute the command which tears down the BGP session.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.1(4), 6.2(1.100)S5, 6.2(1.103)S8, 6.2(1.74)S3 |
|
Known Fixed Releases: | 6.0(2)U2(1), 6.0(2)ZD(0.7), 6.1(4)S19, 6.1(4.97)S0, 6.1(4a), 6.1(5.6)S0, 6.2(2) |
|
|
| |
| |
Bug Id: | CSCun14548 |
Title: | IM 83: vlans removed from non-default topo after dis ISSU from hmaint |
|
Description: | Symptom:
vlans removed from non-default topo after dis ISSU from hmaint
Conditions:
Dis ISSU from hmaint to iluka or imaint.
Workaround:
After the ISSU, reconfigure the interface topology member using the new syntax.
Further Problem Description:
The topology member CLI has changed for better readability.
That is, not to be confused with the topology creation CLI.
interface
fabricpath topology
to
interface
fabricpath topology-member
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.109), 7.0(1)N1(0.105), 7.0(1)N1(1), 7.0(1)ZD(0.132), 7.0(1)ZN(0.172), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60) |
|
|
| |
| |
Bug Id: | CSCup60051 |
Title: | Qos policy stats not working in 6.2.10 S7 for F3 |
|
Description: | Symptom:
QOS stats is not incrementing in 6.2.10 S7 for F3
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S14, 6.2(10)S7 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S24, 7.1(0)D1(0.229), 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.283), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo63409 |
Title: | FP Flood LTL entry misprogramed after reload spine VDC with transit mode |
|
Description: | When fabricpath spine node is configure in "transit" mode, this issue could cause misprogramming of flood LTL that cause traffic outage.
Symptom:
This is issue is specific to "fabricpath mode transit" configuration. Traffic outage would be observed as a result with drop occuring at the transit spine.
Conditions:
The is issue is more likely to occur in a scaled testbed, with more number of vlans, SVIs or L2 mcast group entries. Reload or vdc restart can also trigger the same on a scale bed.
Workaround:
As a workaround, when transit mode is configured on the spine remove the rest of the vlan's from the node and then reload.
[In this case 1-3900 vlans are configured, remove them all].It resolves the issue.
The above workaround is suggested because is not neccesary to have the FP vlans configured on the spine when in transit mode. But the transit node needs to be connected to more than 1 leaf, simply because FP topology needs to have more than 1 node with vlans configured for the FP mcast trees to come up.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8) |
|
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(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.162), 7.1(0)FC(0.2), 7.1(0)GF(0.14), 7.1(0)NF(0.28) |
|
|
| |
| |
Bug Id: | CSCup88022 |
Title: | G bit is not set on SUP but set on LC after vPC peer-link flap |
|
Description: | Symptom:
Unicast arp reply destined to vPC peer's mac is forwarded to the RPC in a mixed mode VDC instead of peer-link DI. The arp reply is then forwarded to the peer-link DI by the M-series LC and dropped on egress of the PL interfaces under the following:
slot x quoted "show hardware internal errors"
73 EB credited packet drop 0000000000000004 23-24 -
506 Egress crdt pkts LTL/Forwarding drop 0000000000000004 23-24 -
Conditions:
Peer gateway disabled
Peer-link flap
Module reload of module that has peerlink
Workaround:
Shut/No shut the impacted SVI on the peer with the incorrect programming in the hardware mac table
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.162) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S34, 7.1(0)D1(0.196), 7.1(0)D1(0.210), 7.1(0)D1(0.215), 7.1(0)FC(0.2), 7.1(0)NF(0.32), 7.1(0)OTT(0.18), 7.1(0)RTG(0.12), 7.1(0)VX(0.3) |
|
|
| |
| |
Bug Id: | CSCun68731 |
Title: | n7k F3 vpcp: isis_fabricpath core found @isis_ha_lsp_db_pss_recover |
|
Description: | Symptom:
The bug is hit on performing a switchover of the active SUP with fabricpath isis configured along with multiple topologies. When the bug is hit, fabricpath isis process crashes while recovering the LSP database from its PSS for stateful recovery
Conditions:
Configuration - Multiple topologies and then perform a switchover
Problem frequency - rare
Network conditions - fabricpath isis process is respawned and performs a graceful restart after crashing
Workaround:
The bug is not seen if multiple topologies aren't configured. When the bug happens farbicpath isis respawns on its own and fixes the issue.
Further Problem Description:
This bug is not seen every time we configure multiple topologies and perform a switchover but only sometimes. QA performed multiple iterations and mentioned that this situation was rarely hit.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)FM(0.24), 6.2(7.23)S0 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S13, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)D1(0.329), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283), 7.1(0)SIB(99.68), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo27488 |
Title: | ipv6 forward command does not enable ipv6 on the i/f |
|
Description: | Symptom:
v6 forwarding will not work on the core
Conditions:
Workaround:
Enable ipv6 address on fabric control segment
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)ZN(0.120) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.80), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)N1(0.130), 7.1(0)N1(1), 7.1(0)NF(0.28), 7.1(0)OTT(0.6), 7.1(0)PDB(0.115) |
|
|
| |
| |
Bug Id: | CSCup05713 |
Title: | IGMP: Invalid XML output - BF113 status |
|
Description: | Symptom:
IGMP: Invalid XML output - BF113 status
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)BF(0.112) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)BF(0.124), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)OTT(0.6), 7.1(0)PDB(0.115), 7.1(0)VXE(0.2) |
|
|
| |
| |
Bug Id: | CSCun86081 |
Title: | 7.X Ping to SVI fails with CMD/SGT encapsulation |
|
Description: | Symptom:
Pings to a nexus 5000 series switch SVI may fail when the packet is coming with a CMD/SGT tag
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.1(0)D1(0.237), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.183), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup43563 |
Title: | [GBR HA] Back to back SWO suffers with impact from interface-vlan |
|
Description: | Symptom:
The standby stuck in boot/init and doesn't become ha-standby
Conditions:
During the event of switchover triggered manually or automatic and sometimes it may require more than one swo to see this issue (eg., back-back swo)
Workaround:
Unknown
Further Problem Description:
na
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.169), 7.1(0)D1(0.174) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.179), 7.1(0)D1(0.185), 7.1(0)D1(0.186), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)IF(99.16), 7.1(0)NF(0.32), 7.1(0)OTT(0.14) |
|
|
| |
| |
Bug Id: | CSCun65741 |
Title: | HMM Entry for locally connected host is not available |
|
Description: | Symptom:
HMM local host DB is not updated. Issue was caused because of the CSCun57894 fix in AM.
Conditions:
When Vinci forwarding mode is configured under an SVI. Local hosts are not discovered by HMM as AM is not notifying HMM about the local adjacencies.
Workaround:
Remove the Vinci forwarding mode and reapply. But new adjacencies will not be discovered. To discover new adjacencies one must remove and reapply the forwarding mode again for every new adjacency.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(1)ZN(0.204) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(1)N1(0.152), 7.0(1)N1(1), 7.0(1)ZD(0.149), 7.0(1)ZN(0.209), 7.1(0)D1(0.181), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)N1(0.230) |
|
|
| |
| |
Bug Id: | CSCup65296 |
Title: | Memory leak detected in 'svi' component - 41256 (Bytes) |
|
Description: | Symptom:
After perturbing FabricPath VLANs in the FP network, the interface_vlan component leaks memory.
Conditions:
The VLAN perturbance involves VLAN addition/deletion, VLAN shut/no shut, VLAN mode change. Perturb the FabricPath VLANs, the memory starts to leak.
Workaround:
There is no workaround.
Further Problem Description:
The problem is resolved!
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S7 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S79, 6.2(10.16)S0, 6.2(12)BFP(0.9), 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.232), 7.1(0)D1(0.280) |
|
|
| |
| |
Bug Id: | CSCun20061 |
Title: | FEX : Incorrect ucdidvif table programming on F2 upon fpc flap |
|
Description: | Symptom:
Unicast traffic destined to egress a FEX Host Interface (HIF) may be dropped due to the incorrect programming of the Unicast Destination Index to Destination Virtual InterFace (ucdidvif) table on the egress module.
Conditions:
- Nexus 7000 running NX-OS version 6.2(2) or higher
- Nexus 7000 F2 or F2E series modules
- Nexus 2000 Fabric Extenders (FEX) connected to the F2/F2E modules
- LTL Indexes not allocated contiguously to the FEX HIFs by PIXM
Workaround:
Affected Versions:
1) Bring down all FEXs in the system.
2) Bring up FEXs sequentially based on number of HIFs from greatest to smallest.
- I.e. Bring up all 48 port FEXs, then 32 port FEXs.
Resolved Versions:
The issue has been resolved in NX-OS versions 6.2(8) and higher for the Nexus 7000.
Note:
This behaviour will persist through an In Service Software Upgrade (ISSU) to a resolved version. After performing an ISSU, reload all F2/F2E modules with FEXs attached.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)FM(0.20) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.30)S0, 6.2(8), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCun03978 |
Title: | STP Sends CBL + BD Ops Request on Secondary Vlan (PVlan) |
|
Description: | Symptom:
Flood LTL Index missing after removing private-vlan from port-channel
CBL state for private-vlan goes to blocking state after removing private-vlan from the port-channel
Conditions:
Vlan type is Private vlan
Workaround:
shut and no shut of the port-channel can fix Flood LTL Index miss programming
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6a)S10, 7.1(0)D1(0.104), 7.1(0)D1(0.64) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(8), 6.2(8)S0, 6.2(8.1)S0, 6.2(9)FM(0.45), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.109), 7.1(0)D1(0.100), 7.1(0)FC(0.2), 7.1(0)NF(0.28) |
|
|
| |
| |
Bug Id: | CSCum81252 |
Title: | Merge XOS/LPSS with NXOS pss2: XOS/LPSS part |
|
Description: | Symptom:
Need to merge xos/lpss@dev1 to NXOS. There are some small issues fixed in this merger
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.162), 7.1(0)ZN(0.22) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(3)I1(0.64), 7.0(3)I1(1), 7.1(0)BF(0.107), 7.1(0)BF(0.108), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)IF(99.16) |
|
|
| |
| |
Bug Id: | CSCum41587 |
Title: | Cost community value incorrect with communityid higher than 127 |
|
Description: | Symptom:
when you try to configure Pre-bestpath cost using route-map for community ID 127 or higher, then switch will change the cost value to "4294967295" , irrespective of what costs user tries to enter.
Conditions:
Community ID should be higher that 127 and cost should be tried to change using route-map
Workaround:
none known so far.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(0)N1(0.400) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.112), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)N1(0.188), 7.1(0)N1(1), 7.1(0)NF(0.28), 7.1(0)OTT(0.6), 7.1(0)PDB(0.115) |
|
|
| |
| |
Bug Id: | CSCum74698 |
Title: | n7k detailed acl logging affecting system cli operation |
|
Description: | Symptom:
n7k running nxos version 6.2.6 and configured for detailed ip acl logging (logging ip access-list detailed) fills up /var/tmp part of the disk which affect system cli.
Conditions:
show tech output cannot be collected or various other show cli are not producing expected output with error message 'No space left on device'.
Workaround:
No Workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.7)S0, 6.2(8), 6.2(8)CM(0.9), 6.2(9)FM(0.37), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.108), 7.1(0)D1(0.171), 7.1(0)FC(0.2) |
|
|
| |
| |
Bug Id: | CSCup94791 |
Title: | vlan crashed @ mts_vlan_bridge_domain_tech_check |
|
Description: | Symptom:
NA
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)PDB(0.154), 7.1(0)ZD(0.260) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.201), 7.1(0)D1(0.207), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)NF(0.32), 7.1(0)OTT(0.18), 7.1(0)RTG(0.12), 7.1(0)VX(0.3) |
|
|
| |
| |
Bug Id: | CSCum46336 |
Title: | Cos2q Mapping is changed after ISSU 6.1.4a to 6.2.6 with Single Sup |
|
Description: | Symptom:
Cos to Queue and DSCP to queue Mapping will not be same as before ISSU.
Conditions:
Seen after ISSU from 6.1.3 and above 6.1.3 to 6.2.X and above 6.2.X
Seen after ISSU with Single Sup
With Dual Sup after ISSU the Cos/DSCP to queue mapping will be ok but after further change on Cos/DSCP to queue mapping the programming will not reflect the mapping anymore
Specific to 8e-4q4q template
Workaround:
1) Remove all DSCP to queue Mapping using
class-map type queuing match-any 4q1t-8e-4q4q-in-q-default
match dscp 0-63
no match dscp 0-63
2) Remove All Queuing policies associated with interfaces (if any)
3) Change the Qos Template to default 8e using
system qos
service-policy type network-qos default-nq-8e-policy
4) Perform ISSU (single/dual sup) to 6.2.X Code
5) if DSCP to queue is used enable "hardware qos dscp-to-queue ingress module-type f-series" before step 6)
6) Restore QoS template
7) Restore Cos/DSCP to queue Mapping which were removed before ISSU
8) Restore Queuing policies on interfaces which were removed before ISSU
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2), 6.2(6) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(6)E1, 6.2(6a), 6.2(6a)S10, 6.2(7.7)S0, 6.2(8), 6.2(8)CM(0.9), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup60247 |
Title: | Memory leak detected in 'isis_l2mp' compon in FP setup - 194898 (Bytes) |
|
Description: | Symptom:
Leak detected when we get EthPM triggers for interface down
Conditions:
We would leak memory for a message
Workaround:
restarting of ISIS would get rid of the leak as long as port is not flapped again
Further Problem Description:
Fixed in 6.2.10
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S7 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S19, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)D1(0.329), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283), 7.1(0)SIB(99.68), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup43085 |
Title: | BD is down after copy r s reload with all configs intact |
|
Description: | Symptom:
Na
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.169), 7.1(0)D1(0.172), 7.1(0)D1(0.174) |
|
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.179), 7.1(0)D1(0.186), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)IF(99.16), 7.1(0)NF(0.32), 7.1(0)OTT(0.14) |
|
|
| |
| |
Bug Id: | CSCup65294 |
Title: | Memory leak detected in 'vlan' component - 870268 (Bytes) |
|
Description: | Symptom:
After perturbing FabricPath VLANs in the FP network, the VLAN leaks memory.
Conditions:
The VLAN perturbance involves VLAN addition/deletion, VLAN shut/no shut, VLAN mode change. Perturb the FabricPath VLANs, the memory starts to leak.
Workaround:
There is no workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S12, 6.2(10)S7 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S79, 6.2(10.16)S0, 6.2(12)BFP(0.9), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.232), 7.1(0)D1(0.280), 7.1(0)EV(0.116) |
|
|
| |
| |
Bug Id: | CSCuo77566 |
Title: | OTV Overlay Interface stuck at "Cleanup in Progress" |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCun27512 |
Title: | Nexus: reload due to PIM process crash |
|
Description: | Symptom:
A Nexus device may reload. Last reload reason is seen as "pim hap reset":
Nexus# show system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 62610 usecs after Mon Dec 9 16:35:07 2013
Reason: Reset triggered due to HA policy of Reset
Service: pim hap reset
Version:
Conditions:
PIM is configured. The crash occurs when a particular timing condition is encountered during the processing of PIM Join and Prune messages.
Workaround:
None known at this time.
Further Problem Description:
This defect tracks this PIM issue in the N7K/PI case only. For the Nexus 5000 and 6000, please refer to CSCuj36520.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 5.2(1), 6.0(2) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)KM(0.64), 7.0(1)N1(0.121), 7.0(1)N1(1), 7.0(1)ZD(0.137), 7.0(1)ZN(0.184), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60) |
|
|
| |
| |
Bug Id: | CSCup35771 |
Title: | 7.1.0.D1.162.S3: After switchover on leaf vni config is missing from bd |
|
Description: | Symptom:
After switchover on leaf vni config is missing from bd
Conditions:
switchover
Workaround:
reconfigure after doing copy r s and reload
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.162), 7.1(0)D1(0.172), 7.1(0)D1(0.174) |
|
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.169), 7.1(0)D1(0.174), 7.1(0)D1(0.175), 7.1(0)D1(0.186), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)IF(99.16) |
|
|
| |
| |
Bug Id: | CSCuo44890 |
Title: | OTV FC: Inter-op between ASR1K and N7K failed |
|
Description: | Symptom:
OTV routes are not exchanged between a Nexus 7000 switch running 6.2(x) image and an ASR1K device. The overlay adjacency comes up fine, however no OTV routes are exchanged.
Conditions:
Nexus 7000 switch running 6.2(x) image
Workaround:
None so far. The fix would be integrated into the 6.2(12) release. 6.1(x) image work fine with the latest IOS code.
Another option for the customer is to use older IOS code - XE 3.12 with 6.2(x), as the interop issue exists
between XE 3.13 and 6.2(x).
Further Problem Description:
The fix that has been integrated into the 6.2(12) code needs to be implemented as follows.
N77-1(config)# inter overlay 1
N77-1(config-if-overlay)# shut (<<<N77-1(config-if-overlay)# otv-isis default
N77-1(config-router)# interop-enable
N77-1(config-router)# end
N77-1(config)# inter overlay 1
N77-1(config-if-overlay)# no shut
N77-1(config-if-overlay)# end
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8a), 7.1(0)OTV(0.5) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.11), 6.2(12)FT(0.5), 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)D1(0.330), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283) |
|
|
| |
| |
Bug Id: | CSCup60557 |
Title: | F2 / F2e does not send ICMP unreachable for ip length 1501-1516 bytes |
|
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 in the range of 1501-1516 Bytes (includes IP Header, ICMP Header and ICMP payload). On the wire, up to 1534 bytes (1516 + 18 Bytes for L2 header).
Conditions:
Issue will only occur when PMTU discovery is required between networks where jumbo MTU support is required, but connecting device is not able to accept packets with ip length greater than 1500 bytes.
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.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCuo50084 |
Title: | 6.2.10 :ERROR: internal error: Failed to get if record on ASCII |
|
Description: | Symptom:
The following error messages may be seen occasionally when applying an ascii config to switch which contains a large number of HSRP groups:
"ERROR: internal error: Failed to get if record"
"ERROR: HSRP V6 groups are not supported on HSRPV1 interface"
Conditions:
Issue only occurs when there are HSRP groups configured on interfaces that are VRF members.
Workaround:
The failed HSRP config can be reapplied manually afterwards and will be accepted.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)FM(0.20), 6.2(10)FM(0.24), 6.2(12)E2, 6.2(12)FM(0.8) |
|
Known Fixed Releases: | 6.2(12)E1, 6.2(12)E5, 7.1(0)BF(0.123), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)OTT(0.6), 7.1(0)PDB(0.115), 7.1(0)VXE(0.2), 7.1(0)ZD(0.225) |
|
|
| |
| |
Bug Id: | CSCun16347 |
Title: | banner motd with "!" and "#" may cause admin vdc migration to hang |
|
Description: | Symptom:
CLI hangs, to get back CLI, either need to power cycle or need to reload the router by telnet to the mgmt ip.
Conditions:
1. This happens in 6.2.6 with "system admin-vdc migrate xxx" when user has banner motd configurations with "!" and "#" as delimiter.
2. "#" and "!" work in all other releases except 6.2.8. The following characters are known to cause similar issue:
[ $ ^ . | ? \ >
The following characters works fine
{}]*+<
Workaround:
1. Before migrate to admin VDC, it's recommended to remove CLI "banner motd " from the config, or use known working characters like "*", "+", "{" or "}" as delimiter. banner command can be applied after vdc migration.
2. Once CLI hangs, either need to power cycle or need to reload the router by telnet to the mgmt ip. Don't save the configuration before reload.
Further Problem Description:
bug CSCur12074 has similar appearance, but happens for other delimiters like "^", "." and "$"
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(5.52)S0, 6.2(6), 6.2(6a)S12 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.17), 6.2(7.17)S0, 6.2(7.19)S0, 6.2(8), 6.2(8)EC(0.8), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo19840 |
Title: | Anycast HSRP in initial state after supervisor failover |
|
Description: | Symptom:
Anycast HSRP in initial state after supervisor failover
Conditions:
Supervisor switchover
Workaround:
Further Problem Description:
Switch# sh hsrp anycast
Anycast bundle - 1 (IPv4)
Admin Status: Up Oper Status: Down
Reason: Invalid switch-id Cfged, :
Anycast Switch ID XXX
%HSRP_ENGINE-3-BUNDLE_ASID_REG_FAIL: Switch-id:XXX DRAP registration failed for bundle:1.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)S15 |
|
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) |
|
|
| |
| |
Bug Id: | CSCun74514 |
Title: | bridge-domain remains down after shut/no-shut |
|
Description: | Symptom:
na
Conditions:
na
Workaround:
na
Further Problem Description:
na
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(0)FVX(0.68) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.80), 7.1(0)D1(0.117), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)SDN(0.6), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCun23230 |
Title: | Imaint: v4 ping failure from host to the leaf |
|
Description: | Symptom:
Seeing the error message -
arp: arp_handle_arp_request: VINCI: No configured gateway anycast mac
ARP process may not be able to handle the request
Conditions:
Intermittent issue.
This happens because of timing problem where the ARP does not receive the HMM anycast gateway mac config notification. As a result arp does not have the anycast mac and it fails to process the received request.
Workaround:
The issue is fixed now.
ARP uses the cached HMM api to get the relevant information.
Further Problem Description:
Explained
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)KM(0.64), 7.0(1)N1(0.120), 7.0(1)N1(1), 7.0(1)ZD(0.137), 7.0(1)ZN(0.183), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60) |
|
|
| |
| |
Bug Id: | CSCuo71245 |
Title: | BD is up if switch reloaded with vni shutdown |
|
Description: | Symptom:
BD remains up if we do a copy r s reload with vni in shut state
Conditions:
vni has to be down,
Workaround:
do a shut / no shut on bd again to bring back the bd.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.130) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.189), 7.1(0)FC(0.2), 7.1(0)IF(99.16), 7.1(0)NF(0.32), 7.1(0)OTT(0.14), 7.1(0)PDB(0.141), 7.1(0)RTG(0.12), 7.1(0)SIB(99.6) |
|
|
| |
| |
Bug Id: | CSCup83732 |
Title: | N7K: PIM crash on shutdown loopback interface on egress PE in MVPN ASM |
|
Description: | Symptom:
PIM process crashed
Conditions:
loopback interface which used by BGP and multicast, is shutdown.
Workaround:
no workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.188) |
|
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.214), 7.1(0)FC(0.2), 7.1(0)N1(0.267), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.18), 7.1(0)PDB(0.163) |
|
|
| |
| |
Bug Id: | CSCun00533 |
Title: | Seeing ipqosmgr crash when applied to range of vlan's |
|
Description: | Symptom:
On configuring the vlan for 4k class-map, the ipqosmgr is crashing
Conditions:
the time taken is very long
Workaround:
nothing, decrease the class-maps and see
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)FM(0.17) |
|
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.6), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo37800 |
Title: | N7K - SNMP snmpd core when blank community string snmpCommunityName |
|
Description: | Symptom:
NOne
Conditions:
None
Workaround:
None
Further Problem Description:
Fix needed in 7.1 release
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)S31, 7.1(0)D1(0.131) |
|
Known Fixed Releases: | 6.2(10), 6.2(8)KR(0.8), 6.2(8.13)S0, 6.2(9)FM(0.55), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.109), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)NF(0.28) |
|
|
| |
| |
Bug Id: | CSCuo10029 |
Title: | Traffic drop to VPC+ host on M1/F1 DI driving GPC instead of Peer-link |
|
Description: | Symptom:
Upon a VPC+ peer reload, in a mixed chassis scenario [M*F1/M*F2] routed traffic ingressing on M card will blackhole as the DI will not drive the peer switch switchID and will drive ES switchID. This DMAC was learnt on the other peer and was not installed correctly on this peer upon reload.
Conditions:
VPC+, Reload, Mixed Chassis, Routed East-West traffic
Workaround:
Clear mac address dynamic for the destination MAC.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2), 6.2(2)S22, 6.2(6)S18, 6.2(6a), 6.2(7.23)S0, 6.2(8)S13, 7.0(1) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)EC(0.10), 6.2(10)EC(0.11), 6.2(10)FM(0.18), 6.2(10)NO(0.19), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.1(0)D1(0.108) |
|
|
| |
| |
Bug Id: | CSCun46513 |
Title: | SSTE: BGP set nh incorrectly with inbound RPM set ip nh peer-address |
|
Description: | Symptom:
BGP set the nexthop incorrectly when the inbound route-map with set ip nexthop peer-address is configured.
Conditions:
The symptoms are observed when the prefixes are learned from rfc5549 v6 RRC neighbors and advertised to rfc5549 v4 RRC neighbor when v4 RRC has the set ip next-hop peer-address configured.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(7.12)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.23)S0, 6.2(8), 6.2(9)FM(0.37), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(3)I1(0.272), 7.0(3)I1(1), 7.1(0)BF(0.81), 7.1(0)D1(0.171) |
|
|
| |
| |
Bug Id: | CSCum89825 |
Title: | switchover reloads both sup with iscm cores . |
|
Description: | Symptom:
iscm crash on switchover , reloads the standby active both ,
GNU GRUB version 0.97
Autobooting bootflash:/n7000-s2-kickstart.6.2.8.FH.0.36.gbin bootflash:/n7000-s
2-dk9.6.2.8.FH.0.36.gbin...
Filesystem type is ext2fs, partition type 0x83
Booting kickstart image: bootflash:/n7000-s2-kickstart.6.2.8.FH.0.36.gbin....
........................................
telnet> q
Connection closed.
and-sw-ibuild4:138>
and-sw-ibuild4:138> dd1
Trying 10.106.29.33...
Connected to 10.106.29.33.
Escape character is '^]'.
Password OK
2014 Jan 31 05:11:29 india-29 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "iscm" (PID 6178) hasn't caught signal 11 (core will be saved).
2014 Jan 31 05:11:29 india-29 %$ VDC-1 %$ %LICMGR-2-LOG_LIC_NO_LIC: No license(s) present for feature LAN_ENTERPRISE_SERVICES_PKG. Application(s) shut down in 108 days.
2014 Jan 31 05:11:29 india-29 %$ VDC-1 %$ %LICMGR-2-LOG_LICAPP_NO_LIC: Application pbr running without LAN_ENTERPRISE_SERVICES_PKG license, shutdown in 108 days
2014 Jan 31 05:11:31 india-29 %$ VDC-1 %$ %SYSMGR-2-LAST_CORE_BASIC_TRACE: : PID 6213 with message iscm(non-sysmgr) crashed, core will be saved .
2014 Jan 31 05:11:31 india-29 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "iscm" (PID 6213) hasn't caught signal 11 (no core).
2014 Jan 31 05:11:32 india-29 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "iscm" (PID 6239) hasn't caught signal 11 (core will be saved).
Conditions:
GNU GRUB version 0.97
Autobooting bootflash:/n7000-s2-kickstart.6.2.8.FH.0.36.gbin bootflash:/n7000-s
2-dk9.6.2.8.FH.0.36.gbin...
Filesystem type is ext2fs, partition type 0x83
Booting kickstart image: bootflash:/n7000-s2-kickstart.6.2.8.FH.0.36.gbin....
........................................
telnet> q
Connection closed.
and-sw-ibuild4:138>
and-sw-ibuild4:138> dd1
Trying 10.106.29.33...
Connected to 10.106.29.33.
Escape character is '^]'.
Password OK
2014 Jan 31 05:11:29 india-29 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "iscm" (PID 6178) hasn't caught signal 11 (core will be saved).
2014 Jan 31 05:11:29 india-29 %$ VDC-1 %$ %LICMGR-2-LOG_LIC_NO_LIC: No license(s) present for feature LAN_ENTERPRISE_SERVICES_PKG. Application(s) shut down in 108 days.
2014 Jan 31 05:11:29 india-29 %$ VDC-1 %$ %LICMGR-2-LOG_LICAPP_NO_LIC: Application pbr running without LAN_ENTERPRISE_SERVICES_PKG license, shutdown in 108 days
2014 Jan 31 05:11:31 india-29 %$ VDC-1 %$ %SYSMGR-2-LAST_CORE_BASIC_TRACE: : PID 6213 with message iscm(non-sysmgr) crashed, core will be saved .
2014 Jan 31 05:11:31 india-29 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "iscm" (PID 6213) hasn't caught signal 11 (no core).
2014 Jan 31 05:11:32 india-29 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "iscm" (PID 6239) hasn't caught signal 11 (core will be saved).
Workaround:
iscm crash on switchover , reloads the standby active both
GNU GRUB version 0.97
Autobooting bootflash:/n7000-s2-kickstart.6.2.8.FH.0.36.gbin bootflash:/n7000-s
2-dk9.6.2.8.FH.0.36.gbin...
Filesystem type is ext2fs, partition type 0x83
Booting kickstart image: bootflash:/n7000-s2-kickstart.6.2.8.FH.0.36.gbin....
........................................
telnet> q
Connection closed.
and-sw-ibuild4:138>
and-sw-ibuild4:138> dd1
Trying 10.106.29.33...
Connected to 10.106.29.33.
Escape character is '^]'.
Password OK
2014 Jan 31 05:11:29 india-29 %$ VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "iscm" (PID 6178) hasn't caught signal 11 (core will be saved).
2014 Jan 31 05:11:29 india-
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)FH(0.36) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.11)S0, 6.2(8), 6.2(8)EC(0.6), 6.2(8)NO(0.12), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup01813 |
Title: | FEX : arp reply fails on F2-FEX L3 interface due to incorrect port-grp |
|
Description: | Symptom:
issue can happen for any traffic
Conditions:
trigger so far is FEX reload (but it do not happen always after reload and it is not simple hit) , link down on remote site also trigger this problem
Workaround:
There is no workaround as issue is not always happen after FEX reload you can try to reload FEX again or remove port-group from VDC put it back and connect fex again and see if it still happening.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)FM(0.32) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.28), 6.2(8)TS(0.28), 6.2(9.2)S0, 7.1(0)GF(0.11) |
|
|
| |
| |
Bug Id: | CSCup80317 |
Title: | GBR-Bundle->GBR-Bugfix sync:switch got stuck during bridge domain config |
|
Description: | Symptom:
NA
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.179), 7.1(0)D1(0.231), 7.1(0)PDB(0.138) |
|
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.196), 7.1(0)D1(0.201), 7.1(0)D1(0.204), 7.1(0)D1(0.215), 7.1(0)D1(0.221), 7.1(0)D1(0.232), 7.1(0)FC(0.2) |
|
|
| |
| |
Bug Id: | CSCup17536 |
Title: | GBR-BUGFIX->GBR-top sync::fabric-control config is absent under run-cfg |
|
Description: | Symptom:
Just a show issue.
Conditions:
A fag is not set when configuring fabric-control.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.160), 7.1(0)D1(0.162) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.162), 7.1(0)D1(0.164), 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)VXE(0.2), 7.1(0)ZD(0.217) |
|
|
| |
| |
Bug Id: | CSCuo13444 |
Title: | IP Packets are dropped at LC when one sub interface is deleted |
|
Description: | Symptom:
Traffic breaks for all sub-interfaces under a parent interface when we remove a sub-interface under that parent interface.
Conditions:
Sub-interfaces configured on F2 linecard
Workaround:
shut/no shut another configured sub-interface
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.85), 7.1(0)ZD(0.193) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.19), 6.2(8)TS(0.28), 6.2(9.1)S0, 7.1(0)D1(0.153), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)ZD(0.204), 7.1(1)SP(0.4), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup97286 |
Title: | vlans crash @ subbmp_find_bit |
|
Description: | Symptom:
NA
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.196), 7.1(0)D1(0.201) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.196), 7.1(0)D1(0.201), 7.1(0)D1(0.219), 7.1(0)D1(0.220), 7.1(0)FC(0.2), 7.1(0)NF(0.32), 7.1(0)OTT(0.20), 7.1(0)VX(0.4) |
|
|
| |
| |
Bug Id: | CSCun60481 |
Title: | snmpbulkwalk : Error: OID not increasing: IP-FORWARD-MIB for IPV6 |
|
Description: | Symptom:
SNMP bulkwalk fails with an error indicating that OID is not increasing in IP-FORWARD table.
Conditions:
This occurs in particular v6 topology that are complete and contains L3VPN configuration.
Workaround:
There is no workaround this issue. However, should have no impact on traffic or any other functionality.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.1(5)S4 |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.245), 7.1(0)OTT(0.31), 7.1(0)PDB(0.194), 7.1(0)RTG(0.17), 7.1(0)ZD(0.294), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo36343 |
Title: | N7K-SUP1 ipqosmgr process crash after upgrading from 6.1.3 to 6.2.2a |
|
Description: | Symptom:
N7K-SUP1 experience ipqosmgr crashed after upgrading from 6.1.3 to 6.2.2a.
Conditions:
dual N7K-SUP1 running 6.1.3 which was upgraded to 6.2.2a.
Workaround:
no workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S59, 6.2(10.16)S0, 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.314), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup72846 |
Title: | monitor hap reset on deleting VLAN |
|
Description: | Symptom:One or both supervisors in a Nexus 7000 chassis might reload unexpectedly. Reset reason is shown as 'monitor hap reset'
`show system reset-reason`
----- reset reason for module 2 (from Supervisor in slot 2) ---
1) At 781550 usecs after Thu Jul 3 07:49:04 2014
Reason: Reset triggered due to HA policy of Reset
Service: monitor hap reset
Version: 6.2(2a)
Conditions:This might happen only with VLAN addition/deletion,
AND when SPAN is configured,
AND the SPAN source contains a FPC interface.
Workaround:avoid the multiple conditions above.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S19, 7.1(0)D1(0.227), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.162), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo89198 |
Title: | post SSO fabric_mcast process is not running on the new active sup |
|
Description: | Symptom:
configure 'ip multicast fabric-forwarding' causes stdby goes to init
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCun34206 |
Title: | CLI and VSH cores after configuring 'switchport' |
|
Description: | Symptom:
Nexus switch crashes after switchport configuration.
Conditions:
This was seen while configuring switchport on an interface of a non default VDC.
Workaround:
Unknown
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)EC(0.23), 6.2(10)FM(0.17), 6.2(10)NO(0.12), 6.2(8)KR(0.8), 6.2(8.9)S0, 7.1(0)D1(0.117), 7.1(0)FC(0.2), 7.1(0)PDB(0.65), 7.1(0)ZD(0.166) |
|
|
| |
| |
Bug Id: | CSCuo90184 |
Title: | NXOS/OTV: ARP ACL Applies to all VLAN without Arp inspection Filter |
|
Description: | Symptom:
ARP packets will not processed and all ARP packets will be dropped due to block ACL due to the following ARP access-list,
N7k-TEST(config)# arp access-list OTV-BLOCK-HSRP-ARP
N7k-TEST(config-arp-acl)# 10 deny ip any mac 0000.0c07.ac00 ffff.ffff.ff00
N7k-TEST(config-arp-acl)# 20 deny ip any mac 0000.0c9f.f000 ffff.ffff.f000
N7k-TEST(config-arp-acl)# 30 permit ip any mac any
without calling the arp inspection filter(ip arp inspection filter OTV-BLOCK-HSRP-ARP vlan), the ARP access-list will be applied to all vlans and block ARP.
Conditions:
The issue is seen after the ip arp inspection filter command is applied twice on the same vlan and then if we try to remove the config.
ip arp inspection filter OTV-BLOCK-HSRP-ARP vlan 1-10
ip arp inspection filter OTV-BLOCK-HSRP-ARP vlan 1-10
no ip arp inspection filter OTV-BLOCK-HSRP-ARP vlan 1-10
Workaround:
Reload ASCII
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2a), 6.2(8)S8, 6.2(8)S9 |
|
Known Fixed Releases: | 6.2(12)E2, 6.2(14)FB(0.7), 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.422), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.350) |
|
|
| |
| |
Bug Id: | CSCun87659 |
Title: | In large vlan scale setup SPM is timing out causing issues |
|
Description: | Symptom:
VDC creation may take long time
Conditions:
Any port bring up activity on a scale testbed of total 400+ vlans and 500 L2 ports or port-channels
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)S3 |
|
Known Fixed Releases: | 7.1(0)AV(0.38), 7.1(0)D1(0.343), 7.1(0)EV(0.125), 7.1(0)OTT(0.47), 7.1(0)PDB(0.280), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCum82162 |
Title: | "show nice detail" struck or not return to prompt after adding 15 nodes |
|
Description: | Symptom:
"show nice detail" struck or not return to prompt after adding 15 nodes
Conditions:
"show nice detail" struck or not return to prompt after adding 15 nodes
Workaround:
"show nice detail" struck or not return to prompt after adding 15 nodes
Further Problem Description:
after configuration of basic wccp the programming on LC is not present .
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)FH(0.35), 6.2(8)FM(0.17) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.5)S0, 6.2(7.7)S0, 6.2(8), 6.2(8)CM(0.3), 6.2(8)CM(0.5), 6.2(8)CM(0.6), 6.2(8)FM(0.20), 6.2(9)FM(0.37), 7.1(0)ZD(0.200) |
|
|
| |
| |
Bug Id: | CSCuo67870 |
Title: | VTP Pruning causes traffic outage in a vPC when primary leg is flapped |
|
Description: | Symptom:
vPC VLANs on a trunk interface are incorrectly pruned by VTP on the vPC Operational Secondary Nexus 7000. The interface can be configured as a vPC leg or as a vPC Orphan port.
Conditions:
This issue will only occur on a Nexus 7000 vPC setup running NX-OS version 6.2(6) or higher that is also configured to use VTP for VLAN pruning.
The trigger for the issue is a flap of a vPC leg on the vPC Operational Primary switch. After the link flap, VTP does not successfully process join messages for the VLANs, resulting in a timeout and the VLANs being pruned from the link.
Workaround:
1) Flap any vPC leg on the vPC Operational Secondary switch to force a VTP to recalculate the pruning state
2) Remove and re-add the VTP Pruning configuration*
* Note: When VTP is removed, all broadcast traffic for VLANs in the trunk allowed list is allowed expectedly to be flooded out of the interface
The issue is resolved in the 6.2(10) release of NX-OS for the Nexus 7000.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6), 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S59, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.238), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.176), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo90941 |
Title: | Unable to add vlan to trunk on port-profile post upgarde from 6.0 to 6.2 |
|
Description: | Symptom:
The following error is returned when executing a "switchport trunk allowed vlan add" command in following two scenarios:
- under a port-profile
- under an interface inheriting a port-profile
N7KA(config-port-prof)# switchport trunk allowed vlan add 6
ERROR: This form of the command has no effect on the current system
N7KA(config-port-prof)#
Conditions:
- This occurs after an upgrade of NX-OS via ISSU or disruptive upgrade
- The Port-profile being modified or inherited must have been created prior to the upgrade
Workaround:
- The user can re-apply the original trunk allowed list under the port-profile that existed before the ISSU. Then the new vlans can be added or old vlans removed without seeing any issues.
- Delete and recreate port-profile from scratch after the ISSU.
- Reboot is not effective workaround. Condition remains after reloading switch.
Further Problem Description:
- you may see duplication of lines in the running configuration under virtual port-channel
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.1(4)S26, 6.2(10)E3, 6.2(2a), 6.2(8a)S3 |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.2(0)BA(0.12), 7.2(0)D1(0.401), 7.2(0)D1(1), 7.2(0)OTT(0.5), 7.2(0)PDB(0.345), 7.2(0)RTG(0.91), 7.2(0)ZD(0.88) |
|
|
| |
| |
Bug Id: | CSCum96491 |
Title: | 6.2.8.FM.0.17.S0:XBOW F3:Seeing few BFD sessions going down after SSO |
|
Description: | Symptom:
Seeing few BFD sessions going down after SSO
Conditions:
Its seen on supervisor switchover very rarely
Workaround:
LC reload
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6a)S17, 6.2(8)FM(0.17), 6.2(8)S33 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.19)S0, 6.2(8), 6.2(8)EC(0.16), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup06023 |
Title: | u6route-mem allocation failure even though there is plenty of headroom |
|
Description: | running into u6route mem allocation failure even though there's plenty of memory left.
e.g. A-VDC1# sh vdc resource u6route-mem detai
u6route-mem 6 used 134 unused 202 free 68 avail 208 total
-------------
Vdc Min Max Used Unused Avail
--- --- --- ---- ------ -----
AB-VDC1 24 24 1 23 23
A-1-B-VDC1 100 100 1 99 99
Test-VDC3 4 4 1 3 3
Test-VDC4 4 4 1 3 3
Test-VDC5 4 4 1 3 3
Test-VDC6 4 4 1 3 3
Symptom:
A-1-B-VDC1# sh log last 10
get warning messages with failure to allocate shared memory:
Failed to allocate shared memory for route trie node
2014 May 27 17:59:33 A-1-B-VDC1 %U6RIB-2-NOSMEM: u6rib [9610] (default-base)
Failed to allocate shared memory for recursive nexthop trie node
2014 May 27 17:59:43 A-1-B-VDC1 %U6RIB-4-SYSLOG_SL_MSG_WARNING: U6RIB-2-NOSME
M: message repeated 30671 times in last 121 sec
2014 May 27 18:00:23 A-1-B-VDC1 %BGP-5-ADJCHANGE: bgp-64896 [9979] (default)
neighbor cafe:1890:e000:1::10 Down - holdtimer expired error
2014 May 27 18:00:26 A-1-B-VDC1 %U6RIB-2-NOSMEM: u6rib [9610] (default-base)
Failed to allocate shared memory for route trie node
2014 May 27 18:00:36 A-1-B-VDC1 %U6RIB-4-SYSLOG_SL_MSG_WARNING: U6RIB-2-NOSME
M: message repeated 14688 times in st 52 sec
A-1-B-VDC1#
Conditions:
Verified with scale with 30k ipv6 and 655K ipv4 routes.
and with a hard swithover
Workaround:
N/A
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)E1, 6.2(10)S70, 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.271), 7.1(0)OTT(0.36), 7.1(0)PDB(0.219) |
|
|
| |
| |
Bug Id: | CSCun78718 |
Title: | N7k 6.2(2) Port-Profile modification removing the entire VDC config-tion |
|
Description: | Symptom:
An incorrect rollback of failed Port-Profile modification might be seen in some very specific cases on N7k devices. As a result of this incorrect PPM rollback, significant part of running configuration might be negated on the device. Reloading the device recovers it from the issue as the device gets re-initialized from its startup configuration.
Conditions:
This is a scalability-related issue. The problem might be seen on heavily over-configured N7k devices with lots of attached FEXes (~1,5K interfaces on the system, ~10K lines in "show run all", ~200 interfaces managed by a single Port-Profile). Under these specific conditions some port-profile operations can take several minutes to be completed, or even just to be rejected.
The problem could be triggered if two different port-profiles are being modified simultaneously from two different management sessions to the N7k device (VDC), and both of the two PPM modifications are failed. In this very specific case two PPM rollback operations could be initiated simultaneously thus breaking the normal PPM rollback operation and resulting in incorrect completion of the PPM rollback operation.
Workaround:
1. Ensure that only one person is modifying configuration on such system, avoid initiating a new Port-Profile modification before the previous Port-Profile modification is completed;
2. Consider any ways to reduce the amount of interfaces handled by a single Port-Profile;
3. Follow Cisco-verified Scalability Guide for the setup.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S37, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.263), 7.1(0)OTT(0.34), 7.1(0)PDB(0.208), 7.1(0)SIB(99.16), 7.1(0)ZD(0.312), 7.1(0)ZN(0.411) |
|
|
| |
| |
Bug Id: | CSCup35883 |
Title: | Multicast Vinci A/B: SG stuck when RP on border router |
|
Description: | Symptom:
Multicast Vinci A/B: SG stuck when RP on border router after traffic stop
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(1), 7.1(0)D1(0.162), 7.1(0)D1(0.163), 7.1(0)D1(0.179) |
|
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.186), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)N1(0.238), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.14) |
|
|
| |
| |
Bug Id: | CSCus73066 |
Title: | M2 linecard reset due to EOBC heartbeat failure |
|
Description: | Symptom:
A M2 linecard may be reset by the supervisor due to EOBC heartbeat being missed by the linecard
Conditions:
Unknown
Workaround:
None
Further Problem Description:
The defect is similar to CSCup20959 which should be fixed in 6.2(10) code but still seen in 6.2(10)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.1(4), 6.2(10), 6.2(12), 6.2(6), 6.2(8) |
|
Known Fixed Releases: | 6.2(10)E5, 6.2(10)E8, 6.2(12)E2, 6.2(14)FB(0.14), 6.2(8)E10, 7.1(0)AV(0.74), 7.2(0)D1(0.469), 7.2(0)PDB(0.395), 7.2(0)PDB(0.396), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCun58253 |
Title: | SSTE: ipfib crashed at ufib_vobj_init after restart ipfib on LC |
|
Description: | Symptom:
ipfib on the LC might crash
Conditions:
The symptoms is observed after ipfib on the LC is restarted
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(7.16)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.30)S0, 6.2(8), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup18117 |
Title: | vlan_mgr cored after ISSD |
|
Description: | Symptom:
NA
Conditions:
ISSD
Workaround:
NONE
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.160), 7.1(0)D1(0.162) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)IF(99.16), 7.1(0)NF(0.28), 7.1(0)OTT(0.6), 7.1(0)PDB(0.115), 7.1(0)RT(95.2), 7.1(0)VXE(0.2) |
|
|
| |
| |
Bug Id: | CSCun42840 |
Title: | F3+brkout: ospf cores observed during cfd verification |
|
Description: | Symptom:
OSPF crashes when trying to add a route that changes its type from either discard-internal or discard-external to a different route type (other than NONE). ONLY OSPFv2 in 6.2.6a is affected by this bug.
Conditions:
This issue is related to the presence of discard routes that OSPF adds into the RIB. When the discard route changes its type from discard internal(also discard-external) to some other type (other than NONE), which may be the case if the area range or summary address overlap with one of the component routes, OSPF can crash.
Both internal and external discard routes are affected by this bug. ONLY OSPFv2 in 6.2.6a is affected.
Workaround:
The following steps may be taken to minimize the exposure to this bug.
1. Configuring an area range/summary address that is less specific than all component routes.
2. Suppressing discard route may help in avoiding this crash;
Recovery: OSPF automatically recovers from this crash by doing a stateful recovery.
Further Problem Description:
Some additional questions answered.
1) Summary address is typically less specific than the component routes. Is the issue seen only when the summary address is the same as a component route?
The problem would be seen if the route-type changed from (a) discard-internal to some other type (e.g., inter or intra), or (b) from some other type (e.g., inter or intra) to discard-internal . Now, let us take the example of route-type changing from discard-internal to intra. This would be the case if there is a component in that area range that has the same prefix/masklen. If you have a area range that is strictly less specific than each one of the component routes, then, the route-type can only change from discard-internal to NONE, or NONE to discard-internal, and this will NOT cause the crash.
We can draw similar conclusions for discard-external routes also.
2) Would there be a crash if route changes *to* discard-*?
Yes. This would also result in a next-hop being deleted for the summarized route (e.g., intra) and another one added (discard-*) subsequently.
3) Can the router run into constant crashes? In which theoretical scenario?
In the stable network, we would only see this once. Once the route-type changes from (or changes to) a discard-*, then, we will not see further crashes. On the flip side though, each time the route-type changes from (or changes to) a discard-* , we will see the crash.
Example:
Let us say that the router is an ABR that summarizes everything under 123.123.123.0/24 coming in area 1.
router ospf 1
area 1 range 123.123.123.0/24
This will cause the following route to be installed in the RIB.
123.123.123.0/24, ubest/mbest: 1/0
*via Null0, [220/0], 00:00:02, ospf-1, discard
Due to this bug, OSPF will crash when trying to install an intra-area route that overlaps with the configured area range, such as the one below:
123.123.123.0/24, ubest/mbest: 1/0
*via 192.168.10.3, Eth2/7, [110/80], 00:00:02, ospf-1, intra
A similar problem will be seen with summary-address/external routes also. See the Unit test attachment for some more examples.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(7.10)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.30)S0, 6.2(8), 6.2(9)FM(0.37), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.72), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)N1(0.120) |
|
|
| |
| |
Bug Id: | CSCun99687 |
Title: | VTY ACL not programmed after code upgrade to 6.2.6 and switchover |
|
Description: | Symptoms:
This is a modification on the product to adopt new secure code best practices to enhance the security posture and resiliency of the product.
Conditions:
Device configured with default configuration.
Workaround:
Not applicable or available.
Further Problem Description:
None.
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)EC(0.23), 6.2(10)FM(0.17), 6.2(10)NO(0.12), 6.2(8)E10, 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(0)BZ(0.46) |
|
|
| |
| |
Bug Id: | CSCuo12118 |
Title: | NXOS-L2VPN-VPLS-PWs are down after remove then add VFI/PW |
|
Description: | Symptom:
PW to remote PE in VFI not present.
Conditions:
Following are the conditions in which the issue would be encountered:
- VFI is configured with BGP AD (AND)
- BGP session with Address family L2VPN is configured and BGP session is established (AND)
- PWs in the VFI are established
- L2VPN Process Restarts
- Reconfigure VFI (Un-configure/Configure VFI)
Workaround:
clear ip bgp *
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)BF(0.48) |
|
Known Fixed Releases: | 15.4(2.11)T, 15.4(2.12.1)PIH25, 15.4(2.16)S, 15.4(3)S, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.106), 7.1(0)BF(0.127), 7.1(0)D1(0.162), 7.1(0)FC(0.2) |
|
|
| |
| |
Bug Id: | CSCum69960 |
Title: | SNMP trap is disabled after upgrade to 626 |
|
Description: | Symptom:
cseFailSwCoreNotifyExtended trap is disabled from switch.
Conditions:
Reload/upgrade to 626
Workaround:
manually re enable trap :-
N7k(config)#snmp-server enable traps sysmgr cseFailSwCoreNotifyExtended
Further Problem Description:
No other trap is affected.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6) |
|
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)EC(0.16), 6.2(8)NO(0.11), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCut86729 |
Title: | vPC Multicast optimization doesn't work after disable/enable the CLI |
|
Description: | Symptom:
Multicast traffic flows through the MCT link (vpc peer-link) even though VPC Multicast optimization is enabled using CLI "no ip igmp snooping mrouter vpc peer-link".
Conditions:
VPC Multicast optimization is enabled using CLI -
"no ip igmp snooping mrouter vpc peer-link"
Workaround:
If vPc multicast optimization is required such that multicast traffic doesn't traverse MCT link and if this issue is observed in the network, enabling the command by configuring "ip igmp snooping mrouter vpc peer-link" and disabling the command after some time by using "no ip igmp snooping mrouter vpc peer-link" will work.
Further Problem Description:
Enabling Multicast optimisation through CLI doesn't take effect in a scale setup. No issue is seen if we do not enable VPC Multicast optimization. It is disabled by default.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.163) |
|
Known Fixed Releases: | 7.3(0)RTG(0.22) |
|
|
| |
| |
Bug Id: | CSCun11509 |
Title: | IPFIB crashes multiple times after ISSU |
|
Description: | Symptom:
When upgrading the N7K via ISSU there were unexpected crashes of the IPFIB application and core file were written out.
Conditions:
Upgrading the N7K via ISSU from the Command Line Interface (CLI).
Workaround:
Update the N7K by changing the boot variables and doing a reload.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)FM(0.20), 7.1(0)D1(0.136) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.21)S0, 6.2(8), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo93631 |
Title: | N7K MAC address in hardware but missing from software after ISSU |
|
Description: | Symptom:
Nexus 7000 does not learn new MAC addresses in software after ISSU.
"show hardware mac address-table " contains MAC entry in hardware (x = ingress module in question)
"show mac address-table" does not contain MAC entry in software
Conditions:
a) ISSU performed on N7K
b) In combination with ISSU, a new learn mac address caused by a new mac, or a flush of the mac table and re-learn of existing macs while system is undergoing ISSU.
Workaround:
Run the following command: "test l2fm pending-ack slot for all modules which have the "sup_ack_pend" bit set to 1. To check what the bit is set to run the following command:
- slot show system internal mtm info global | eg -i ack_pend
nl_mv_rd num_ack_pending 1 sup_ack_pending 1
age num_ack_pending 0 sup_ack_pending xxx
- any module with "ack_pending" status = "non-zero" is the module(s) to be reloaded
A reload of the module also resolves this issue.
Also, "clear mac address-table dynamic" resolves this issue
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.143), 7.1(0)D1(0.146), 7.1(0)D1(0.153) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S22, 7.1(0)D1(0.196), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)IF(99.16), 7.1(0)NF(0.32), 7.1(0)OTT(0.18), 7.1(0)RTG(0.12), 7.1(0)SIB(99.6) |
|
|
| |
| |
Bug Id: | CSCum84238 |
Title: | LISP ACL: Label2sel table incorrect for lisp decaps with mpls VPN |
|
Description: | Symptom:
LISP Parallel mode does not work on decaps when the locator VPN is a BGP/MPLS VPN
Conditions:
The top bit is set incorrectly in teh Label2sel table
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6), 6.2(8)AA(0.4), 6.2(8)FM(0.9), 7.1(0)ZN(0.99) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.7)S0, 6.2(8), 6.2(8)CM(0.3), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup74698 |
Title: | ipqosmgr crash @ mts_opc_get |
|
Description: | Symptom:
crash happening when qosmgr specific configuration done
Conditions:
When any configuration like priority flow control configuration on interface or any qosmgr specific configuration is done, the qosmgr was crashing
Workaround:
NA
Further Problem Description:
NA
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S16 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S17, 7.1(0)D1(0.285), 7.1(0)EV(0.116), 7.1(0)OTT(0.39), 7.1(0)PDB(0.235), 7.1(0)RTG(0.50), 7.1(0)SIB(99.52), 7.1(0)ZD(0.332), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo64219 |
Title: | bfd core @ bfd_disc_bmp_set_bit on applying config |
|
Description: | Symptom:
Crash due to asset failure when bfd session discriminator reaches(xxxxFFFF) before wrapping around.
Conditions:
Have 65535+ sessions per VDC so that discriminator reaches boundary condition which causes asset failure.
Workaround:
Have fewer than 65535 sessions
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.113), 7.1(0)D1(0.161) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.108), 7.1(0)D1(0.169), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)IF(99.16), 7.1(0)NF(0.28), 7.1(0)OTT(0.6), 7.1(0)PDB(0.115) |
|
|
| |
| |
Bug Id: | CSCup65916 |
Title: | F3 LC reload after system switchover due to xbar_manager timeout |
|
Description: | Symptom:
An F3 LC may reload after a system switchover
Conditions:
Unknown
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S12, 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S14, 6.2(10)S15, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.249), 7.1(0)OTT(0.32), 7.1(0)PDB(0.184), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup67732 |
Title: | N7K: some mroutes leftover on some vrfs on ingress PE under MVPN scale |
|
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.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCup19027 |
Title: | N7K Dual SUP lost configurations after power up |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCum64236 |
Title: | Bdi not coming up on spine even after there is no shut |
|
Description: | Symptom:
NA
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)FVL(0.36), 7.0(1)FVL(0.39) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)GI(0.5), 7.0(0)KM(0.37), 7.0(1)FVL(0.50), 7.0(2)NF(0.17), 7.1(0)D1(0.55), 7.1(0)PDB(0.13), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo55926 |
Title: | crash on mrib on VDC reload |
|
Description: | Symptom:
mrib crashes when VDC is reloaded
Conditions:
This issue may hit during MRIB bring up time (system boot up/vdc bring up) in rare cases.
Workaround:
On VDC reload, there is no workaround is required. ( VDC reload will happen) again. On cold boot case, system will reload due to this crash
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6), 6.2(6)S17, 6.2(8b)S4 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.9), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.12)S0, 6.2(9)FM(0.75), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)BF(0.104) |
|
|
| |
| |
Bug Id: | CSCuo02430 |
Title: | SSTE: hsrp process crashed with SSO trigger |
|
Description: | Symptom:
HSRP process on the standby sup becomes unresponsive and eventually crashes with heartbeat timeout when system switchover is performed. HSRP process is then restarted by sysmgr.
Conditions:
HSRP groups are configured on interfaces with invalid VRFs (i.e. where the VRF is shutdown or not defined). Switch is booted up with saved startup config. System switchover is performed.
Workaround:
Ensure VRFs are valid before system switchover, i.e. if the VRF is shutdown then "no shut" the VRF, and if VRF is not defined then define it.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8)S11, 6.2(8)S19, 6.2(8)S9, 7.0(3)I2(0.375) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)FM(0.28), 6.2(10)NO(0.18), 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(3)I2(0.390), 7.0(3)I2(1), 7.1(0)BF(0.98) |
|
|
| |
| |
Bug Id: | CSCup13170 |
Title: | The leaf0 is getting hang after configured "no vrf context vpn1" |
|
Description: | Symptom:
"no vrf context vpn1"
Upon giving this CLI, leaf0 hangs
Conditions:
Should configure the vrf context cli
Workaround:
No workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)BF(0.116), 7.1(0)BF(0.117), 7.1(0)BF(0.119), 7.1(0)D1(0.172), 7.1(0)D1(0.174), 7.1(0)ZD(0.227) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.179), 7.1(0)D1(0.188), 7.1(0)D1(0.191), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)IF(99.16), 7.1(0)OTT(0.14), 7.1(0)PDB(0.141) |
|
|
| |
| |
Bug Id: | CSCtq34950 |
Title: | R2D2 : Speed patch failed - no frames transmitted |
|
Description: | Symptom:
Ports randomly lose connectivity with error messages
%MODULE-2-MOD_SOMEPORTS_FAILED: Module 2 (serial: XXXXXXXX) reported failure on
ports 2/36-2/36 (Ethernet) due to R2D2 : Speed patch failed - no frames
transmitted in device 143 (error )
Conditions:
Issue is seen with N7K-M148GT-11 module.
Workaround:
Move connected device to another port.
Further Problem Description:
This issue is triggered by physical layer event (link up, link down or speed
change) and occurs due to a race condition. It should be fixed in 5.1(5) or
later, and 5.2(2) or later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: | 5.1(10.37)S0, 5.1(5)S1, 5.2(2)S2, 5.2(2.4)S0, 6.0(0.17)S0, 6.0(0.4)S17 |
|
|
| |
| |
Bug Id: | CSCup20769 |
Title: | Pause not getting enabled for VL3 in Gibraltor image |
|
Description: | Symptom:
NA
Conditions:
NA
Workaround:
NA
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.123), 7.1(0)D1(0.64), 7.1(0)GF(0.10) |
|
Known Fixed Releases: | 7.1(0)GF(0.29), 7.1(0)QFF(0.1), 7.1(0)QFF(0.2), 7.1(0)QFF(0.3), 7.1(0)ZD(0.225), 7.1(0)ZN(0.271), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo20605 |
Title: | SVI stuck in delete |
|
Description: | Symptom:
NA
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(0)FVX(0.98) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.110), 7.0(0)KM(0.64), 7.1(0)D1(0.117), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)SDN(0.6), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCun32066 |
Title: | On "no bridge-domain 100" vnsegment_mgr is sending a BD_PORT_DELETE |
|
Description: | Symptom:
bd port delete is sent out if there are any vsis under the bd
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)FVL(0.84), 7.1(0)D1(0.58) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.69), 7.0(0)GI(0.7), 7.0(0)KM(0.37), 7.0(1)FVL(0.91), 7.0(2)NF(0.17), 7.1(0)D1(0.117), 7.1(0)D1(0.60), 7.1(0)D1(0.64), 7.1(0)FC(0.2) |
|
|
| |
| |
Bug Id: | CSCuh09675 |
Title: | 6.1(4)/(4a)/6.2(1): BGP Service Crash cause multiple processes to crash |
|
Description: | Symptom:
BGP service crashes with following log messages:
%SYSMGR-3-HEARTBEAT_FAILURE: Service "bgp" sent SIGABRT for not setting heartbeat for last 4 periods. Last heartbeat 148.45 secs ago.
%SYSMGR-3-HEARTBEAT_FAILURE: Service "bgp" sent SIGABRT for not setting heartbeat for last 4 periods. Last heartbeat 150.07 secs ago.
This is followed by several other process to crash.
The VDC becomes unresponsive with the following log messages:
Due to multiple crash of the service, the supervisor switchover may take place.
In a single supervisor, the device may reload.
Reason: Reset triggered due to HA policy of Reset
Service: Service "bgp" in vdc 2 hap reset
Version: 6.1(4)
Conditions:
Nexus 7000 switch running 6.1(4), 6.1(4a) or 6.2(1).
This issue is normally seen when an IGP (OSPF, EIGRP etc.) and/or BGP convergence is triggered in the network.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(1.111)S5 |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(5), 6.1(5.31)S0, 6.2(1.135)S0, 6.2(2) |
|
|
| |
| |
Bug Id: | CSCup95948 |
Title: | LISP crash in lisp_build_eid_notify due to two EIS Notify GWs configured |
|
Description: | Symptom:
The N7K unexpectedly wrote out a LISP core file.
Conditions:
The N7K is configured with LISP Multihop, the node is acting as First Hop and two eid_notify gateways are configured.
Workaround:
Configured just one eid_notify gateway (if the Network design allows)
Further Problem Description:
The core file will only happen for certain numbers of dynamic prefixes. The length of the generated UDP packet must be a multiple of 256, which makes it hard to predict when this defect is triggered.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S28, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.228), 7.1(0)D1(0.271), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.179) |
|
|
| |
| |
Bug Id: | CSCum58258 |
Title: | BGP stuck after modifying vrf RD with traffic running |
|
Description: | Symptom:
BGP stuck after modifying vrf RD with traffic running
Conditions:
In vinci scenario, BGP redistributes hmm routes under ipv6 address-family in a VRF. When RD changes, the hmm routes cannot be deleted and hence the VRF/table cleanup is never complete.
Workaround:
Restart BGP process
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(0)ZN(0.199) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)N1(0.503), 7.0(0)N1(1), 7.0(0)ZD(0.212), 7.0(0)ZN(0.210), 7.0(1)N1(0.58), 7.0(1)N1(1), 7.0(1)ZD(0.113), 7.0(1)ZN(0.126), 7.1(0)D1(0.104) |
|
|
| |
| |
Bug Id: | CSCuo77146 |
Title: | port-profile crashed while reloading leaf vdc |
|
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.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCun24092 |
Title: | Changing the speed of in with 4k-classmap seeing ipqosmgr core |
|
Description: | Symptom:
Changing the speed of in with 4k-classmap seeing ipqosmgr core
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(7.7)S0 |
|
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)EC(0.16), 6.2(8)NO(0.9), 6.2(9)FM(0.37), 7.1(0)ZD(0.200), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo62938 |
Title: | fabricpath: LID for l3 control mcast packets uses 0x10e5 instead 0xffff |
|
Description: | Symptom:
Networks with N7k gateway devices running software versions between 6.2.2 and 6.2.8 using F1 M1 with Fabricpath may have other N7k nodes notice persistent mac moves.
The continuous mac moves further cause high CPU usage which lead to other problems for the control and data plane.
The gateway macs will change their association between the gateway device's local switchID.0.SUP Lid and gateway device's local switchID.0.ffff
Conditions:
To be affected by this issue:
[1] N7k Gateway devices must be using F1 M1 with Fabricpath
[2] N7k leaf devices must be using F1 or F1 with M1
[3] Gateway devices must be running s/w versions between 6.2.2 and 6.2.8
Workaround:
Segregating the VLANs carrying the routed traffic by having dedicated "transit" VLANs, by adding another layer of routing at the leaf switches, as the traffic comes from and goes back to hosts will prevent the issue from being encountered.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.11), 6.2(10)FM(0.35), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.12)S0, 6.2(9)FM(0.75), 7.1(0)D1(0.162), 7.1(0)FC(0.2), 7.1(0)GF(0.14) |
|
|
| |
| |
Bug Id: | CSCun79573 |
Title: | Multicast: Invalid XML output - BF48 status |
|
Description: | Symptom:
6 multicast CLIs give invalid XML outputs
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)BF(0.48) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)BF(0.76), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)N1(0.125), 7.1(0)N1(1), 7.1(0)NF(0.28), 7.1(0)OTT(0.6) |
|
|
| |
| |
Bug Id: | CSCup42401 |
Title: | control packet on mpls tunnel (te and pw) not transmitted after PM crash |
|
Description: | Symptom:
On pktmgr crash, control packet on mpls tunnel (te and pw) not transmitted
Conditions:
Pktmgr crash
Workaround:
Restart Netstack after PM crash
Further Problem Description:
Committed to 7.1 train as well
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S1, 7.0(1)S1, 7.1(0)ZN(0.333), 7.1(1)BF(196) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S11, 6.2(10.5), 7.1(0)D1(0.191), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)N1(0.241), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.14) |
|
|
| |
| |
Bug Id: | CSCuo50598 |
Title: | VDC reload may cause F3 line card to flap links and corrupt PDUs |
|
Description: | Symptom:
Nexus 7000 with F3 module may experience link flaps on port-channels upon VDC reload.
We also see STP BPDU, LACP, UDLD issues as these packets could be potentially corrupted.
Conditions:
Port-channel config on F3 module with active traffic
Workaround:
Reload LC
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(6a), 6.2(8), 7.1(0)D1(0.138), 7.1(0)D1(0.161) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.6), 6.2(10)S2, 6.2(10)S9, 6.2(10.5), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.12)S0, 6.2(9)FM(0.75), 7.0(0)BZ(0.46) |
|
|
| |
| |
Bug Id: | CSCun60221 |
Title: | F2/F3 redirect policy config failure causing aclqos crash |
|
Description: | Symptom:
Aclqos crashes and Linecard goes to failure state.
Conditions:
The problem happens in following scenario,
1. A multi-instance card, like F2/F3 where any redirection feature is configured on multiple instances.
2. There is not enough space in the tcam on one of the instances where the policy will get programmed as well.
3. Atomic update goes through on one of the instance, but fails on next.
4. Non-atomic update is turned on, that also fails on the next instance.
5. During recovery path, aclqos will crash.
Workaround:
Avoid tunnel programing in cases when tcam in any instance is completely full and the programing is likely to fail. Check the utilization of the tcam before programming a tunnel policy.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S36, 6.2(10)S8, 6.2(6)S10, 6.2(7.19)S0, 6.2(8)ES(0.3) |
|
Known Fixed Releases: | 7.1(0)D1(0.243), 7.1(0)NF(0.32), 7.1(0)OTT(0.31), 7.1(0)RTG(0.32), 7.1(0)ZD(0.292), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup90903 |
Title: | vlan_mgr core seen on GBR-196S2 |
|
Description: | Symptom:
NA
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
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.196), 7.1(0)D1(0.201), 7.1(0)D1(0.210), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)NF(0.32), 7.1(0)OTT(0.18), 7.1(0)RTG(0.12) |
|
|
| |
| |
Bug Id: | CSCun19859 |
Title: | Imaint: nd debug msgs show vlan not vinci-enabled |
|
Description: | Symptom:
ND proxy/anycast stops working on switch boot-up because of a timing issue.
Conditions:
Because of a timimg iusse during system bootup, ND API returns Vinci not enabled if below 3 conditions are not set: AMAC, fwdmode:proxy/anycast, switch role:Leaf
Because of a timing issue during boot-up, ICMPv6 process misses the AMAC config notifications from HMM because
before HMM adds icmpv6 as its client, these notificaions are already sent.
Workaround:
Manually need to remove and reconfigure the HMM anycast gateway mac commands.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(1)N1(0.113), 7.0(1)N1(1), 7.0(1)ZD(0.135), 7.0(1)ZN(0.178), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60), 7.1(0)SDN(0.6) |
|
|
| |
| |
Bug Id: | CSCun80740 |
Title: | vlan_mg crashed @ vlan_bitset_copy |
|
Description: | Symptom:
NA
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.64) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.86), 7.0(0)KM(0.64), 7.0(1)FVL(0.113), 7.1(0)D1(0.108), 7.1(0)D1(0.117), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.65), 7.1(0)SDN(0.6) |
|
|
| |
| |
Bug Id: | CSCun74507 |
Title: | bridge-domain is in down state after deleting tenant-vni & reconfig |
|
Description: | Symptom:
When the issue happens, bridge domain is missing VSI and in down state.
Conditions:
Repetitively config and delete VNI.
Workaround:
n/a
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(0)FVX(0.84), 7.1(0)D1(0.64) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)KM(0.64), 7.1(0)D1(0.114), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.65), 7.1(0)SDN(0.6), 7.1(0)ZD(0.166), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCun76034 |
Title: | FCoE-FEX:Ser SAP Plcmgr Err 0x40480003 (no such pss key) in if_bind seq |
|
Description: | Symptom:
In XBOW running 7.1(0)D1(0.64)S1 observing that the allocation of interfaces to eth vdc failed due to GIM returned 40480003 [no such pss key] after reload.
Conditions:
In XBOW running 7.1(0)D1(0.64)S1 observing that the allocation of interfaces to eth vdc failed due to GIM returned 40480003 [no such pss key] after reload.
Workaround:
N/A
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.64) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.109), 7.1(0)BF(0.102), 7.1(0)D1(0.99), 7.1(0)FC(0.2), 7.1(0)I1(0.17), 7.1(0)I1(1), 7.1(0)NF(0.28), 7.1(0)PDB(0.60), 7.1(0)ZD(0.144) |
|
|
| |
| |
Bug Id: | CSCum08767 |
Title: | WCCP:Interfaces level CLI configurations removed after invalid id to spm |
|
Description: | Symptom:
When wccp service groups are configured in closed mode, and a hia-timeout of less than or equal to 3 is set, a flap of the Cache Engine connected interface causes the wccp configs to be removed.
Conditions:
1. Closed mode
2. Hia timeout of equal to or less than 3 sec
example: ip wccp 61 mode closed service-list ser1 hia-timeout 2
3. Flap of CE connected interface
Workaround:
Configure HIA timeout to be more than 3 sec. Or use the default configuration of 10 sec.
ip wccp 61 mode closed service-list ser1
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N3(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo08118 |
Title: | 60 usec traffic loss at sup sw |
|
Description: | Symptom:
dc3s1# sh version internal build-identifier
Kickstart image file: bootflash:///n7000-s2-kickstart.7.1.0.D1.0.85.gbin : S2
System image file: bootflash:///n7000-s2-dk9.7.1.0.D1.0.85.gbin : S2
dc3s1#
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.85) |
|
Known Fixed Releases: | 7.1(0)D1(0.162), 7.1(0)FC(0.2), 7.1(0)GF(0.14), 7.1(0)NF(0.28), 7.1(0)OTT(0.4), 7.1(0)PDB(0.73), 7.1(1)SP(0.4), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo71517 |
Title: | mti tunnel info missing in PIM after vrf shut/no shut |
|
Description: | Symptom:
mvpn nbr not forming
Conditions:
When PIM is restarted for some reason when the mdt-source interface is down, it is possible that PIM does not process the OIM update message and is expecting a create-message instead. This causes the MVPN to be in pending state.
Workaround:
shut and unshut the mdt-source interface should fix the problem.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.1(0)MPL(0.11) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)BF(0.107), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)N1(0.178), 7.1(0)N1(1), 7.1(0)NF(0.28), 7.1(0)OTT(0.6) |
|
|
| |
| |
Bug Id: | CSCun86274 |
Title: | if_bind sequence failure due to RBACL |
|
Description: | Symptom:
Ports go to failure state and VMM Bind fails.
Conditions:
Rbacl configured on the system.
Qos Policies configured in Egress direction and Vacl configured in egress direction.
Enabled deny ace by the command "hardware access-list allow deny ace".
Linecard is reloaded with the configuration.
Workaround:
Disabled "hardware access-list allow deny ace"
Reload the module First.
The apply "hardware access-list allow deny ace"
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S12, 6.2(8)S1 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S74, 6.2(10.16)S0, 7.1(0)D1(0.242), 7.1(0)NF(0.32), 7.1(0)OTT(0.31), 7.1(0)RTG(0.32), 7.1(0)ZD(0.291), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuo05645 |
Title: | STP doesn't handle delete of all the VSI when bd/vni shut cmd is issued |
|
Description: | Symptom:
When we have two VSI present in the bridge-domain range and we do a shut on the bridge-domain, lim doesn't handle request for both VSI, it only takes care of removing one of them hence stp still has it.
Conditions:
Have multiple VSI mapped to same bd, and shutdown that bd.
Workaround:
remove the bridge-domain and recreate the vni membership.
Further Problem Description:
NA
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUN-2015 |
|
Known Affected Releases: | 7.0(1)FVL(0.118) |
|
Known Fixed Releases: | 7.0(0)FVX(0.107), 7.1(0)LZB(0.9), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCus21952 |
Title: | PVLAN:Forward table is not programmed with correct DI |
|
Description: | Symptom:
L3 traffic does not egress out of Trunk secondary port/PC/VPC
Conditions:
Routed traffic gets dropped and does not egress out of Private vlan Trunk Secondary port.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(12)S10 |
|
Known Fixed Releases: | 6.2(12), 6.2(12)S20, 6.2(12.4)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.320), 7.2(0)D1(0.387), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCus09312 |
Title: | PVLAN:VPC PO member (M1 LC) flaps. |
|
Description: | Symptom:
Port-channels which have
1) PVLAN trunk secondary config
and
2)LACP or other control protocols running,
could flap continuously, due to BPDU's not flowing. They don't flow because the native vlan is in CBL disabled state, instead of being in CBL Blocking state.
Conditions:
The issue is specific to M1 module since the programming model is different on F2/F3 LC's.
There is no issue on F2 and F3 modules.
Even if the customer uses M1 module there is NO issue, if customer is allowing native VLAN on VPC Leg.
Below are the 3 conditions that need to be satisfied to hit this bug:
1) PVLAN port mode should be TRUNK Secondary
2) Native VLAN is NOT allowed on VPC Leg
3) LC Module should be M1 module
Workaround:
Workaround is to have customer have the native vlan in allowed list for the port, by configuration.
For a private-vlan port, the command to add trunk allowed vlan 1 would be:
switchport private-vlan trunk allowed vlan 1
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S102, 6.2(12)FT(0.7) |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.2(0)D1(0.459), 7.2(0)D1(1), 7.2(0)PDB(0.382) |
|
|
| |
| |
Bug Id: | CSCus24030 |
Title: | F3/100G: CRC errors when pkts sent from dot1q/FP to untagged/access intf |
|
Description: | Symptom:
CRC errors and packet drop on traffic received from 100G F3 interface.
Conditions:
The issue happens when a packet is received on a trunk enabled interface (trunk port or Fabricpath port or layer 3 sub-interface) and has to exit on an interface with no tag. Even if it arrives on the native vlan or main interface on the input interface without a tag it will still cause CRCs on the next hop device.
Workaround:
Configure the egress port as trunk with dot1q tagging
This issue is resolved in 6.2(12) or later releases.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8b) |
|
Known Fixed Releases: | 6.2(12), 6.2(12)S17, 6.2(12.4)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.314), 7.2(0)D1(0.387), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCur69114 |
Title: | HSRP PACL Filter Broken - Packets are flooded to layer2 domain |
|
Description: | Symptom:
HSRP hello is passing through interface with PACL in place to drop these packets.
Conditions:
6.2(10)
Workaround:
None.
Further Problem Description:
This issue is only affects 6.2(10) and is resolved in 6.2(12).
A similar issue relating to VACL filtering HSRP packets: CSCut75457
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.16), 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.301), 7.2(0)D1(0.387), 7.2(0)D1(1), 7.2(0)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCus29686 |
Title: | Mcast Bidir - LHR lost DF after flapping ssm config |
|
Description: | Symptom:
By correcting an SSM misconfig, it breaks bidir functionality
Conditions:
By correcting an SSM misconfig, it breaks bidir functionality
Workaround:
restart pim
Further Problem Description:
By correcting an SSM misconfig, it breaks bidir functionality, and as a results no bidir states are form and traffic are all dropped
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.360) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110), 7.1(0)AV(0.38), 7.1(0)PDB(0.317), 7.1(0)SIB(99.82), 7.2(0)D1(0.378), 7.2(0)D1(1), 7.2(0)N1(0.56), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCus15529 |
Title: | OTV trunk intf err-disabled due to "IFTMC PD commit db search failed" |
|
Description: | Symptom:
Interface getting error disabled on changing native vlan
Conditions:
It happens in a OTV enabled VDC with a trunk port carrying OTV extended vlans.
Workaround:
shut/no shut of interface
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12)S6 |
|
Known Fixed Releases: | 7.1(0)AV(0.38), 7.1(0)PDB(0.301), 7.2(0)D1(0.387), 7.2(0)D1(1), 7.2(0)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCur83912 |
Title: | Multiple private vlan crashes after reload |
|
Description: | Symptom:
After switch reload PVLAN was crashing. This crash will only be seen in gdb images, and will not affect final images. This happens when PVLAN is already in an errored state and no PVLAN config is going through due PVLAN being in locked state.
Conditions:
The setup was already in an errored state where some of the port-channels in PVLAN db were in an errored state, whereas the member ports of the same port-channels were in a good state with the pvlan mapping saved in PSS. When box reload was done, the PC and member port config did not match, hence when HW programming request for PC was sent after reload, it did not find any PVLAN mappings on PC from PSS and asserted.
Workaround:
This issue has been resolved.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(12)FT(0.14) |
|
Known Fixed Releases: | 6.2(12), 6.2(12)S1, 6.2(12.4)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.320), 7.2(0)D1(0.387), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCur96497 |
Title: | VLAN translation not programmed on hardware |
|
Description: | Symptom:
A newly configured port-channel for vlan translation does not seem to forward traffic.
Conditions:
order of config where the port-channel member has the vlan translation commands defined before the port is added to a channel-group
Workaround:
Re-configure the port-channel with the correct order. That is, delete the port-channel and add the member port to the channel-group. Add the vlan translation commands under the port-channel.
In some cases, removing the translation commands under the port-channel and adding them back also resolves the problem.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(12), 6.2(12)S2, 6.2(12.4)S0, 7.1(0)AV(0.38), 7.1(0)PDB(0.293), 7.2(0)D1(0.362), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCur70861 |
Title: | F3 - Ports should not be err-disabled for TCAM single bit ECC errors |
|
Description: | Symptom:
If F3 module experiences repeated single bit ECC errors it will error-disable the associated ports with that forwarding instance.
exception information --- exception instance 1 ----
Module Slot Number: 5
Device Id : 197
Device Name : Flanker L3 Driver
Device Errorcode : 0xcc503600
Device ID : 197 (0xc5)
Device Instance : 03 (0x03)
Dev Type (HW/SW) : 06 (0x06)
ErrNum (devInfo) : 00 (0x00)
System Errorcode : 0x429b0026 failure recovery threshold
Error Type : Minor error
PhyPortLayer : Ethernet
Port(s) Affected : Ethernet5/25-32
Error Description : FLN_FW_INT_STATUS_TCAM_MATCH0_ECC_0
DSAP : 0 (0x0)
UUID : 0 (0x0)
Time : Tue Nov 11 16:37:55 2014
(Ticks: 546281B3 jiffies)
Conditions:
When repeated single-bit ECC errors are detected.
Workaround:
No known workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.16), 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.301), 7.2(0)D1(0.387), 7.2(0)D1(1), 7.2(0)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCur92755 |
Title: | "l2fm" cores at "l2fm_static_mac_ins_del" on configuring "peer-gateway" |
|
Description: | Symptom:
l2fm cores are seen
Conditions:
triggers should be peer gw enable.
The number of static macs n system should be greater than 3.6K.
This defect affects all releases which do not have the fix, it is a scale issue.
Workaround:
For the fix, upgrade to integrated release recommended.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10)E3 |
|
Known Fixed Releases: | 6.2(10)E3, 6.2(12), 6.2(12)S2, 6.2(12.4)S0, 7.1(0)AV(0.38), 7.1(0)PDB(0.293), 7.2(0)D1(0.362), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCut23832 |
Title: | Netconf output of show bgp statistics miss information |
|
Description: | Symptom:
Netconf/XML output of "show bgp statistics" does not match its regular CLI output, which contains a lot of internal BGP output.
Conditions:
No conditions.
Workaround:
No workarounds.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0.1) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)SIB(99.109), 7.2(0)AB(9), 7.2(0)BA(0.12), 7.2(0)D1(0.446), 7.2(0)D1(1), 7.2(0)FM(0.3) |
|
|
| |
| |
Bug Id: | CSCus96272 |
Title: | pvlan Channel-group members add/remove fails . |
|
Description: | Symptom:
pvlan Channel-group members add/remove fails .
Conditions:
pvlan Channel-group members add/remove fails .
Workaround:
pvlan Channel-group members add/remove fails .
Further Problem Description:
pvlan Channel-group members add/remove fails .
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0.8) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.2(0)D1(0.469), 7.2(0)D1(1), 7.2(0)PDB(0.390), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCus78697 |
Title: | N7K wrong source-interface selected for IPv6 logging after device reload |
|
Description: | Symptom:
logging source-interface seems to be non-working with v6 syslog server on N7K after device reload even the loggingsource-interface pointing to the loopback0 interface
Conditions:
After device reload
Workaround:
reapply logging source-interface loopback0
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.1(5), 6.2(10) |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.443), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)N1(1), 7.2(0)PDB(0.379), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6), 7.2(0)ZD(0.126) |
|
|
| |
| |
Bug Id: | CSCut47663 |
Title: | SSTE: OSPF Adj are struct in TWO-WAY state after ospf process restart |
|
Description: | Symptom:
OSPF Adj are struct in TWO-WAY state
Conditions:
restart opsf 100. If there is no BDR.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.444) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.74), 7.2(0)D1(0.468), 7.2(0)D1(1), 7.2(0)N1(1), 7.2(0)PDB(0.401), 7.2(0)VZD(0.26), 7.2(0)VZN(0.34), 7.2(0)ZD(0.147) |
|
|
| |
| |
Bug Id: | CSCus56648 |
Title: | EIGRP crash in ipigrp2_get_tmap_distance |
|
Description: | Symptom:
EIGRP crash in ipigrp2_get_tmap_distance
Conditions:
Crash is seen with table map if redistributed route is learnt when the corresponding dndb is active
Workaround:
Unconfigure table-map
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.1(0)IB(103) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.408), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)N1(1), 7.2(0)PDB(0.353), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCus53498 |
Title: | lc_port_channel crashed, when storage vdc reloaded on 383 S1 |
|
Description: | Symptom:
Storage VDC reload after doing a "write erase" of the start-up configuration can cause crash in PCM client on line card.
Conditions:
Clearing of the start-up config and a subsequent reload of the storage VDC causes the port channels in the VDC to be removed. While the port channels are being removed , it may cause a failure to delete the port-channel from the PSS. This is because the Ethernet Port Channel type in N7k wasn't properly handled in the Line card. The following Debug log indicates this failure:
lc_port_channel_pss_delete_data: unknown type being stored into pss 22 for ifindex
Port channel ifindex can be read from the show port-channel internal info interface port-channel , command.
When this failure occurs its likely that some stale members and port-channel will be left behind in the Line card memory with the same ifindex. When subsequently, the configuration is restored for the storage VDC for the same port-channel and member, it finds the stale port-channel member pointing to an existing port as indicated in the error logs in symptoms. It then tries to delete this stale member from the stale port channel causing the crash.
Workaround:
Restarting the port-channel process or reloading the line card will clear out the stale interfaces, after the reload of the VDC with empty config. This will ensure that there's no crash when the VDC subsequently reloads with config.
Further Problem Description:
The lc_port_channel process on the line card throws segmentation violation exception aborts while the VDC is reloading with the following error messages on the console: (Note: here Slot Number is marked with a X)
%LC_PORT_CHANNEL-SLOTX-3-LC_PORT_CHANNEL_MBR_PC_INFO_INCORRECT: member pc info for interface EthernetX/Y pointing to old pc
%SYSMGR-SLOTX-2-SERVICE_CRASHED: Service "lc_port_channel" (PID X) hasn't caught signal 11 (core will be saved).
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.383) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)SIB(99.92), 7.2(0)BA(0.12), 7.2(0)D1(0.409), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.353) |
|
|
| |
| |
Bug Id: | CSCus50427 |
Title: | 7.2.0: eigrp crashes when trying to print mem-stats |
|
Description: | Symptom:
EIGRP crashes when printing mem-stats
Conditions:
When printing mem-stats or running the CLI as part of show tech
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.381), 7.2(0)D1(0.386), 7.2(0)D1(0.395), 7.2(0)D1(0.397), 7.2(0)ZD(0.27) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)SIB(99.92), 7.2(0)AB(2), 7.2(0)BA(0.12), 7.2(0)D1(0.397), 7.2(0)D1(0.404), 7.2(0)D1(0.409) |
|
|
| |
| |
Bug Id: | CSCus66218 |
Title: | Deleted vlans are still showing in show fabricpath output |
|
Description: | Symptom:
Delete the vlan from the global database, but still it be present in the Fb database.
Conditions:
if the vlan is part of the Port-channel
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.81) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(1)ZN(0.744), 7.0(6)N1(0.244), 7.0(6)N1(0.4), 7.0(6)N1(0.5), 7.0(6)N1(1), 7.1(0)AV(0.38), 7.1(0)SIB(99.92), 7.1(1)N1(0.454) |
|
|
| |
| |
Bug Id: | CSCut83358 |
Title: | nve memory leak@ libnve_pd in n7k-platform |
|
Description: | Symptom:
nve memory leak
Conditions:
nve peer down and up
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.2(0)D1(0.475), 7.2(0)D1(0.476), 7.2(0)D1(1), 7.2(0)N1(0.168), 7.2(0)N1(1), 7.2(0)PDB(0.408), 7.2(0)ZD(0.155), 7.2(0)ZN(0.171) |
|
|
| |
| |
Bug Id: | CSCus34642 |
Title: | RIB sets LOCAL flag while importing a LISP /32 route in VRF |
|
Description: | Symptom:
When LISP added /32 route is imported in other VRF that time RIB is setting LOCAL flag incorrectly while downloading routes to FIB. It makes FIB to punt all packets to
SUP for this prefix.
Conditions:
Importing LISP /32 route in another VRF
Workaround:
None
Further Problem Description:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.1(1) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.2(0)D1(0.396), 7.2(0)D1(1), 7.2(0)N1(1), 7.2(0)OTT(0.5), 7.2(0)PDB(0.345), 7.2(0)RTG(0.55), 7.2(0)ZD(0.82) |
|
|
| |
| |
Bug Id: | CSCuu29773 |
Title: | Crash in the pim process after exceeding 32K multicast routes |
|
Description: | Symptom:
Multiple pim process crashes seen resulting in a hap-reset that restarts the system
Conditions:
This issue occurs after exceeding the limit of 32K multicast routes and PIM assert message for a new S,G arrives.
show ip mroute detail vrf all`
IP Multicast Routing Table for VRF "default"
Total number of routes: 44037
Total number of (*,G) routes: 141
Total number of (S,G) routes: 43895
Total number of (*,G-prefix) routes: 1
Also saw many SLAB memory errors which could potentially be the result of a memory leak:
2015 May 6 18:11:09 CVC-1-1761C-BR-0-2 %PIM-3-SLAB_ALLOC: pim [15748] Slab alloc of type pim_routetype failed in pim_build_pim_ro
ute()
2015 May 6 18:11:09 CVC-1-1761C-BR-0-2 %PIM-3-CREATE_ROUTE: pim [15748] Couldn't create PIM route for (141.214.83.211/32, 239.255
.255.253/32) in join notification
2015 May 6 18:11:19 CVC-1-1761C-BR-0-2 %PIM-4-SYSLOG_SL_MSG_WARNING: PIM-3-SLAB_ALLOC: message repeated 1349 times in last 7710408
sec
2015 May 6 18:11:19 CVC-1-1761C-BR-0-2 %PIM-3-SLAB_ALLOC: pim [15748] Slab alloc of type pim_routetype failed in pim_build_pim_ro
ute()
2015 May 6 18:11:29 CVC-1-1761C-BR-0-2 %PIM-4-SYSLOG_SL_MSG_WARNING: SYSLOG-4-SL_MSG_WARNING: message repeated 1 times in last 7710
418 sec
2015 May 6 18:11:30 CVC-1-1761C-BR-0-2 %PIM-3-SLAB_ALLOC: pim [15748] Slab alloc of type pim_routetype failed in pim_build_pim_ro
Workaround:
Reduce the total mulitciast routes to less than 32K
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(14)FB(0.58), 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)N1(0.215), 7.2(0)N1(1), 7.2(0)ZD(0.196), 7.2(0)ZN(0.215), 7.2(1)PIB(0.3) |
|
|
| |
| |
Bug Id: | CSCuu05012 |
Title: | Post ISSU : EXP based classification is not working |
|
Description: | Symptom:
Before fixing the issue ISSU from 6.2.x to 7.2, qos was not working properly.
Conditions:
The hardware initialization is modified in 7.2 and if did ISSU from 6.2.x to 7.2 with flanker card, hardware is with still old 6.2.x programming and in some qos cases may not work properly in 7.2, since ISSU do not touch the hardware.
To fix this qos tables are reprogrammed at the time of ISSU when moved to 7.2.
Workaround:
Reload LC.
Further Problem Description:
There may be some packet drops while doing ISSU from 6.2.x to 7.2 till qos tables get reprogrammed in the hardware.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | 7.2(0)D1(0.496), 7.2(0)D1(1), 7.2(0)ZD(0.178), 7.3(0)IB(0.19), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCus67594 |
Title: | EIGRP with v6 crashes in igrp2_destroy_iidb after LC reload |
|
Description: | Symptom:
EIGRP crash after LC reload
Conditions:
EIGRP v6 neighborship exists
Workaround:
No workarounds exist
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.386), 7.2(0)D1(0.437) |
|
Known Fixed Releases: | 6.2(14)FB(0.44), 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)SIB(99.109), 7.2(0)AB(9), 7.2(0)BA(0.12), 7.2(0)D1(0.437), 7.2(0)D1(0.444), 7.2(0)D1(0.449) |
|
|
| |
| |
Bug Id: | CSCus77610 |
Title: | N7710G: ports down due to UDLD empty echo after neighbor LC reloaded |
|
Description: | Symptom:
Link may go to errdisable state with "UDLD empty echo" very rarely when line card reload
Conditions:
On 10G board, configure
1. UDLD protocol enabled
2. Option "system default link-fail laser-on" enabled
3. interface debounce time is set to 0
then reload the line card.
Workaround:
1. shut/no shut the port that in "errdisable" state, or
2. configure the link debounce time to 10ms or larger, or
3. disable the UDLD protocol, or
4. configure "no system default link-down laser-on" option
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.2(0)D1(0.453), 7.2(0)D1(1), 7.2(0)PDB(0.373), 7.2(0)VOF(0.2), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCut07477 |
Title: | IPLUS_469_VXLAN:NVE PD crash while sending traffic |
|
Description: | Symptom:
NVE crash on vpc secondary.
Conditions:
while reloading vpc primary.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.1(0)ZN(91.469) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.1(1)N1(0.483), 7.1(1)N1(1), 7.1(1)ZD(0.19), 7.1(1)ZN(0.34) |
|
|
| |
| |
Bug Id: | CSCut20914 |
Title: | EIGRP IPv6 neighbour sessions flaps after LC reload |
|
Description: | Symptom:
EIGRP ipv6 neighbor sessions flap
Conditions:
After LC reload
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.1(0)IB(103) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)IB(120), 7.2(0)D1(0.481), 7.2(0)D1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCuu29945 |
Title: | SSTE: m2rib core on POAP + autoconfig |
|
Description: | Symptom:
m2rib core
Conditions:
POAP + autoconfig
Workaround:
NA
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.499) |
|
Known Fixed Releases: | 7.1(0)AV(0.81), 7.2(0)D1(0.506), 7.2(0)D1(0.510), 7.2(0)D1(1), 7.2(0)ZD(0.190) |
|
|
| |
| |
Bug Id: | CSCut35336 |
Title: | after reload itd needs restart , means the user has to typein sh nosh |
|
Description: | Symptom:
after n7k box reload the service needs restart , means the user has to typein shut and noshut
Conditions:
after n7k box reload the service needs restart , means the user has to typein shut and noshut
Workaround:
after n7k box reload the service needs restart , means the user has to typein shut and noshut
Further Problem Description:
after n7k box reload the service needs restart , means the user has to typein shut and noshut
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.430) |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.2(0)BA(0.12), 7.2(0)D1(0.444), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)RTG(0.129), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCut09489 |
Title: | Distribute-list out not working for set tag with route-type match |
|
Description: | Symptom:
Distribute-list out not working for set tag
Conditions:
when route-type is used for match
Workaround:
use a different criteria for match
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.1(0)IB(103) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)IB(120), 7.2(0)D1(0.481), 7.2(0)D1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCut61977 |
Title: | Crash after show forwarding route adjacency <interface> <ip address> |
|
Description: | Symptom:
A ipfib process crash is seen. This may lead a HAP-Reset which could reload a module:
Nexus# sh core vdc-all
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
1 4 1 ipfib 18455 2015-03-26 11:06:19
1 4 1 ipfib 2173 2015-03-26 11:06:23
1 3 1 ipfib 12089 2015-03-26 11:06:29
1 3 1 ipfib 2173 2015-03-26 11:06:3
Conditions:
This occurs after the show forwarding route command is entered with the adjacency options.
Workaround:
Avoid using the show forwarding route adjacency command
Further Problem Description:
This is similar to the CSCur91392 bug but additional changes are needed.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(14)FB(0.41) |
|
|
| |
| |
Bug Id: | CSCus76724 |
Title: | NVT-DC1:PVLAN traffic block-hole upon Primary VLAN remove/add |
|
Description: | Symptom:
On M1XL linecards, when some vlan config causes a private-vlan association to be non-operational , private-vlan trunk secondary port sees traffic loss. Similarly, when the trunk association is unconfigured and re-configured on private-vlan trunk-secondary port, the issue might be observed.
Conditions:
This issue is seen on M1XL linecards. Will not be seen with M1 and F-series line cards
Example config and trigger:
Config:
switch(config-if)# show running-config interface e3/3
!Command: show running-config interface Ethernet3/3
!Time: Wed Feb 4 00:38:51 2015
version 6.2(12)
interface Ethernet3/3
switchport
switchport mode private-vlan trunk secondary
switchport private-vlan association trunk 2 3
no shutdown
The issue will be seen after any of the following triggers
1. Delete and recreate of primary vlan
switch(config-if)# no vlan 2
switch(config)# vlan 2
switch(config-vlan)# private-vlan primary
switch(config-vlan)# private-vlan association 3
switch(config-vlan)# ex
2. Delete and recreate secondary vlan
switch(config-if)# no vlan 3
switch(config)# vlan 3
switch(config-vlan)# private-vlan isolated
switch(config-vlan)# ex
3. Delete and re-add trunk association on the port
switch(config)# int e3/3
switch(config-if)# no switchport private-vlan association trunk 2 3
switch(config-if)# switchport private-vlan association trunk 2 3
Workaround:
Workaround is to do a shut no-shut on the port or PC or VPC leg where the issue is observed
switch(config)# int e3/3
switch(config-if)# shutdown
switch(config-if)# no shutdown
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(12)S32 |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.439), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.364), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCut25648 |
Title: | N7K - SNMP - large 180,224 memory leak in vlan_mgr w mibwalk ciscoVtpMIB |
|
Description: | Symptom:
Mem leak when running the below snmp cli's
1.) snmpwalk -v2c -c private plat17 ciscoVtpMIB
2.) snmpbulkwalk -v2c -c private -Cr50 plat17 ciscoVtpMIB
Conditions:
Happens only when there are access port and the above 2 snmp cli's are run
Workaround:
N/A
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.424) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.2(0)BA(0.12), 7.2(0)D1(0.443), 7.2(0)D1(1), 7.2(0)FM(0.3) |
|
|
| |
| |
Bug Id: | CSCut94069 |
Title: | libbmp memory leak because libnve_pd calls libbmp incorretly |
|
Description: | Symptom:
libbmp memory leak
Conditions:
nve peers flapping
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.2(0)D1(0.475), 7.2(0)D1(0.485), 7.2(0)D1(1), 7.2(0)N1(0.179), 7.2(0)N1(1), 7.2(0)ZD(0.166), 7.2(0)ZN(0.182), 7.2(1)N1(0.1) |
|
|
| |
| |
Bug Id: | CSCus69869 |
Title: | NVT:traffic blackhole for receiver on sec. Vlan when one vpc-leg is down |
|
Description: | Symptom:
Traffic black-hole for receivers in secondary vlan on non-forwarder peer when source is in core.
Conditions:
On forwarder peer VPC leg is down and there are no other port on secondary Vlan on this box
Workaround:
Bring the vpc leg up on forwarding peer. OR make sure source has better metric to non-forwarding peer.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(12)S29 |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)SIB(99.92), 7.2(0)AB(2), 7.2(0)BA(0.12), 7.2(0)D1(0.404), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCus97711 |
Title: | Unable to delete files from /tmp directory using filesys delete |
|
Description: | Symptom:
Can not delete files from /tmp/var directory on Line cards using filesys delete cli
Conditions:
n/a
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(14)FB(0.37), 7.1(0)AV(0.81), 7.2(0)D1(0.492), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.174), 7.3(0)IB(0.19), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCuf60213 |
Title: | F2 card reload with "clp_mac" cores |
|
Description: | Symptom:
F2 crashes due to the "clp_mac" process. Within the core file, we see the EEM is trying to process an error message "CLM_CFG_PARITY_ERR".
Conditions:
Issue is triggered by a port config register parity error. Current code only gracefully handles ASIC-level parity errors, not port-level errors -- this will be changed.
Workaround:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.1(2), 6.2(1.79)S2 |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(5), 6.1(5.5)S0, 6.2(1.101)S0, 6.2(2), 7.0(0)ZD(0.53), 7.0(0)ZD(0.55) |
|
|
| |
| |
Bug Id: | CSCut37620 |
Title: | VXLAN VPC pair reboot con if peer cnt slightly more thank 1k |
|
Description: | Symptom:
NVE crash
Conditions:
NVE peer count slightly more thank 1k.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.131) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.2(0)AB(9), 7.2(0)BA(0.12), 7.2(0)D1(0.446), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCup22563 |
Title: | Vulnerabilities in OpenSSL: LDAP over SSL |
|
Description: | Symptom:
The following Cisco products
Cisco Nexus 7000 series switches
Cisco MDS 9000 series switches
running software versions:
7.1(0), 6.2(8), 6.2(7), 5.2(8d)
are affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-0076 - Fix for the attack described in the paper "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
CVE-2014-0195 - DTLS invalid fragment vulnerability
CVE-2014-0221 - DTLS recursion flaw
CVE-2014-0224 - SSL/TLS MITM vulnerability
CVE-2014-3470 - Anonymous ECDH denial of service
This bug has been opened to address the potential impact on this product. The above list of versions are not exhaustive.
Conditions:
Devices using LDAP in SSL mode, say, the ones with the following command may be vulnerable:
ldap-server host {ipv4-address | ipv6-address | host-name} [enable-ssl]
All versions prior to the first fixed version of a train are affected by one or more of the above CVE's.
Workaround:
Not available. Either a patch has to be applied or the entire package has to be upgraded.
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 10/9.5:
https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 5.2(8d), 6.2(7), 6.2(8) |
|
Known Fixed Releases: | 5.2(8e), 5.2(8e)S4, 6.2(10), 6.2(10)S79, 6.2(10)S80, 6.2(10.16)S0, 6.2(12)BFP(0.8), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97) |
|
|
| |
| |
Bug Id: | CSCuu77709 |
Title: | LISP: map-caches entries to non-routable RLOCs are installed in fwd |
|
Description: | Symptom:
A LISP map-cache entry on a xTR lists a group of locators as being in state "up" even while the routing table does not have an entry to reach them. They should be listed in state "no-route".
These locators are pushed down to the forwarding table and flows that match this forwarding entry are blackholed.
Conditions:
The main condition to see this problem is that the setup has a "split" RLOC view, i.e. the eTR registering the lisp database entry is able to see the RLOCs while the iTR is not.
From there the following needs to happen simultaneously to face this problem:
(1) Multiple map-cache entries in the xTR have the same locator set
(2) Some of the RLOCs in this locator set are permanently unreachable (no routing entry in RIB) from iTR
Workaround:
Enabling RLOC probing, which will complement the information from the routing table.
"lisp loc-reach-algorithm rloc-probing"
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq98748 |
Title: | Nexus 7000 evaluation for CVE-2014-6271 and CVE-2014-7169 |
|
Description: |
Symptom:
The Nexus 7000 includes a version of bash that is affected by the vulnerabilities
identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-6271
CVE-2014-6277
CVE-2014-7169
CVE-2014-6278
CVE-2014-7186
CVE-2014-7187
This bug has been opened to address the potential impact on this product.
All current versions of NX-OS on this platform are affected unless otherwise stated
.
Exposure is not configuration dependent.
Authentication is required to exploit this vulnerability.
This bug is fixed in NX-OS versions specified below:
5.2(9a)
6.1(5a)
6.2(8b)
6.2(10) and above
Conditions:
A user must first successfully log in and authenticate via SSH to trigger this vulnerability.
Workaround:
Not available.
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 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 4.2(8), 5.2(9), 5.2(9a)S3, 6.1(5), 6.2(12)FF(0.4), 6.2(6), 6.2(8a), 7.0(2), 7.1(0)ZN(91.98), 7.1(0)ZN(91.99) |
|
Known Fixed Releases: | 5.2(4)FD(0.46), 5.2(4)FD(0.47), 5.2(9a), 5.2(9a)S1, 5.2(9a)S2, 5.2(9a)S3, 5.2(9a)S4, 5.2(9a)S6, 6.1(4)E2, 6.1(5a) |
|
|
| |
| |
Bug Id: | CSCuu96175 |
Title: | L2FM/MCEM/CFS need more robust registration & retry infra |
|
Description: | Symptom:
This is to address possible timeouts between L2FM and CFS under failure condition (CFS crash, control plane congestion) that could cause registration issues between applications.
Conditions:
This may occur under high control plane load.
Workaround:
Perform Supervisor Switchover or reload device
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(6b) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu72109 |
Title: | MSDP TCP connection doesn't establish properly |
|
Description: | Symptom:
A MSDP session may not establish properly on a Nexus platform due to the TCP connection repeatedly closing prematurely. The error that will be seen from 'show ip msdp internal event-history tcp' is as follows -
Resetting connection with peer X.X.X.X ,reset reason: Received reset in TCP read
Conditions:
MSDP is configured. It may also require that the Nexus device is in 'Listening' state for the peer and is therefore passive, not active.
Workaround:
Restart the MSDP process -
restart msdp
If this does not work, remove the feature and re-add it -
no feature msdp
feature msdp
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu58619 |
Title: | IPFIB vrf dependency database doesnt cleanup on VDC reload |
|
Description: | Symptom:
Traffic drops can be seen for multicast and/or unicast flows.
Conditions:
In the presence of Vinci configurations, when a VDC is reloaded, we can get into this condition of unicast/multicast routes not getting updated in certain asic instances
Workaround:
reloading of the affected LC.
Further Problem Description:
n/a
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu24710 |
Title: | ISSU failed 6.2(10) to 6.2(12) on a non-existing FEX |
|
Description: | Symptom:
ISSU from 6.2(10) to 6.2(12) failed on a no longer existing FEX 110.
This physical device - N2K [fex 110] - was reused in another vdc and had a new fex number there.
Module 10:
Upgrading bios/loader/bootrom.
Warning: please do not remove or power off the module at this time.
-- SUCCESS
FEX image downloading in progress.
-- SUCCESS
Non-disruptive upgrading.
Module 161 upgrade completed successfully.
Non-disruptive upgrading.
-- SUCCESS
Non-disruptive upgrading.
Module 110 upgrade failed. >>>>>>>>>>>>>>>module 110 is not existing.
Non-disruptive upgrading.
-- FAIL.
Conditions:
Fex was present in one vdc and then later was moved to another VDC with a different fex number.
Workaround:
TBD
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(0)D1(0.490) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur04856 |
Title: | Cisco Nexus 7000 Series evaluation for CVE-2014-6271 and CVE-2014-7169 |
|
Description: | Symptom:
Symptoms:
The Cisco Nexus 7000 Series switches includes a version of bash that is affected by the vulnerabilities
identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-6271
CVE-2014-7169
This bug has been opened to address the potential impact on this product.
Conditions:
Devices with default configuration.
Workaround:
Not Available.
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 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
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.0(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus42054 |
Title: | after eigrp restart on CE, some neighbors get struck in waiting for init |
|
Description: | Symptom:
EIGRP neighbors are stuck in waiting for init
Conditions:
After EIGRP process restart when the GR helper peer does not have any routes to be advertised to the peer undergoing restart
Workaround:
Clear the neighborship by flapping the interface or using clear command
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.85) |
|
Known Fixed Releases: | 11.1(0.168), 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.397), 7.2(0)D1(0.404), 7.2(0)D1(0.408), 7.2(0)D1(1), 7.2(0)FM(0.3) |
|
|
| |
| |
Bug Id: | CSCuu10618 |
Title: | Traffic loss on some vlans after line card reload |
|
Description: | Symptom:
after reload there is 100% packet drop on a few vlans
Conditions:
LC reload on scaled setup
Workaround:
clear l2vpn service all
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471), 7.2(0)D1(0.475) |
|
Known Fixed Releases: | 15.5(2.20)T, 15.5(2.21)S0.5, 15.6(0.2)S, 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.81), 7.2(0)D1(0.504), 7.2(0)D1(1), 7.2(0)N1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCus98916 |
Title: | BGP Vinci: For 0.0.0.0/0, BGP installs non-best/multi paths in URIB |
|
Description: | Symptom:
In a vinci setup, customer is not able to chose one out of two Border Leaf because URIB is doing ECMP for both paths learnt via BGP.
Conditions:
1. Two paths in BGP vrf table for 0.0.0.0/0 from two Border Leaf.
2. First path is marked as best-path.
3. Second path is not marked as multi-path or best-path
4. BGP installs both paths in URIB vrf table.
5. URIB sees both paths having exact same metrics and interprets ECMP.
Workaround:
Config can be reworked in a way that the Leaf only receives one path via BGP.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.1(1)N1(0.481), 7.1(1)N1(1), 7.1(1)ZD(0.18), 7.1(1)ZN(0.33), 7.2(0)D1(0.487), 7.2(0)D1(1), 7.2(0)N1(0.134), 7.2(0)N1(0.183) |
|
|
| |
| |
Bug Id: | CSCuu32375 |
Title: | SSTE:Traffic loss is observed after doing ISSU followed by module reload |
|
Description: | Symptom:
EoMPLS services may not come up
Conditions:
Consider a VDC that has multiple LCs and EoMPLS configurations with all the EoMPLS ports (AC and PW interfaces) on only one LC. Say LC1 has the AC and PW ports, while LC2, which is a part of the VDC, does not have any ports. When LC1 is reloaded, it is possible that the services may not get deleted properly in LC2 resulting in an inconsistent state, subsequently causing the control plane to withdraw the xconnects.
Workaround:
Reloading of mod LC2 after LC1 has come up will resolve the issue.
Further Problem Description:
This problem is intermittent in nature.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.499), 7.2(0)D1(0.501) |
|
Known Fixed Releases: | 7.2(0)D1(1), 7.2(0)D1(1.14), 7.2(0)ZD(0.221) |
|
|
| |
| |
Bug Id: | CSCut75759 |
Title: | ACL change fail "hardware resource allocation failure" |
|
Description: | Symptom:
unable to modify/remove ACL from SVI. getting the following error: "ERROR: Module 1 returned status: hardware resource allocation failure"
Conditions:
Issue is seen when modification is done to ACL attached to SVI. This is due to memory leak in policer being allocated by qos. With each modification to ACL number of policer in QOS keeps on increasing. It reaches a point where there are not sufficient quantity of policers free and error is generated.
Workaround:
Remove the QOS policy from VLAN config, this results in deallocation of all allocated policers for that vlan.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(14)FB(0.42), 7.2(0)D1(0.495), 7.2(0)D1(1), 7.2(0)ZD(0.177), 7.3(0)IB(0.19), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCut13324 |
Title: | pvlan scale configs results in %PIXM-3-PIXM_SYSLOG_MESSAGE_TYPE_ERR: |
|
Description: | Symptom:
pvlan scale configs results in %PIXM-3-PIXM_SYSLOG_MESSAGE_TYPE_ERR:
Conditions:
pvlan scale configs results in %PIXM-3-PIXM_SYSLOG_MESSAGE_TYPE_ERR:
Workaround:
pvlan scale configs results in %PIXM-3-PIXM_SYSLOG_MESSAGE_TYPE_ERR:
Further Problem Description:
pvlan scale configs results in %PIXM-3-PIXM_SYSLOG_MESSAGE_TYPE_ERR:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0.8) |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.442), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.368), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCut99084 |
Title: | Expecting egress queue mismatched on F2E card of Crossbow(6.2.10) |
|
Description: | Symptom:
When sending traffic with COS3 ( port trust COS , and no DSCP rewrite) or sending traffic with ip precedence 3
( have DSCP rewrite) , then issue show policy-map interface "F2E port" command.
Checking egress queue match , streams hit incorrect queue "8e-4q8q-out-q2". The correct queue for COS3 should be "8e-4q8q-out-q5".
Hardware and OS version: Crossbow N77XX (6.2.10) , F2E linecard.
Conditions:
When apply the following service-policy on F2E card of N77XX , and send traffic with COS 3 and IP precedence 3.
Class-map:
class-map type queuing match-any 8e-4q8q-in-q1
match cos 5-7
match dscp 40-63
class-map type queuing match-any 8e-4q8q-in-q-default
match cos 0-1
match dscp 0-8
class-map type queuing match-any 8e-4q8q-in-q3
match cos 3-4
match dscp 24-39
class-map type queuing match-any 8e-4q8q-in-q4
match cos 2
match dscp 9-23
class-map type queuing match-any 8e-4q8q-out-q1
match cos 5
class-map type queuing match-any 8e-4q8q-out-q2
match cos 7
class-map type queuing match-any 8e-4q8q-out-q3
match cos 6
class-map type queuing match-any 8e-4q8q-out-q4
match cos 4
class-map type queuing match-any 8e-4q8q-out-q5
match cos 3
class-map type queuing match-any 8e-4q8q-out-q6
match cos 2
class-map type queuing match-any 8e-4q8q-out-q7
match cos 1
class-map type queuing match-any 8e-4q8q-out-q-default
match cos 0
Policy-map:
policy-map type queuing NAC_TEST_IN8e-4q8q-in
class type queuing 8e-4q8q-in-q1
queue-limit percent 10
bandwidth percent 80
class type queuing 8e-4q8q-in-q-default
queue-limit percent 40
bandwidth remaining percent 35
class type queuing 8e-4q8q-in-q3
queue-limit percent 30
bandwidth remaining percent 45
class type queuing 8e-4q8q-in-q4
queue-limit percent 20
bandwidth remaining percent 20
policy-map type queuing NAC_Eg8e-4q8q-out
class type queuing 8e-4q8q-out-q1
priority level 1
shape average percent 50
class type queuing 8e-4q8q-out-q2
bandwidth remaining percent 1
class type queuing 8e-4q8q-out-q3
bandwidth remaining percent 25
class type queuing 8e-4q8q-out-q4
bandwidth remaining percent 15
class type queuing 8e-4q8q-out-q5
bandwidth remaining percent 10
class type queuing 8e-4q8q-out-q6
bandwidth remaining percent 10
class type queuing 8e-4q8q-out-q7
bandwidth remaining percent 4
class type queuing 8e-4q8q-out-q-default
bandwidth remaining percent 35
Workaround:
no workarounds
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu12677 |
Title: | ISL down from show topology after changing service policy of Eth port |
|
Description: | Symptom:N7706 and N7710 connected using a 10G F3 ISL Link and the ISL is up. The ISL goes off from the show topology after some time.
Conditions:When a queuing policy is attached/removed/edited to an interface in ISL, the ISL goes off from the topology.
Workaround:The work around is to do a shut-no shut on the interface on which the queuing policy is attached.
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.485) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup52842 |
Title: | bgp flapping with fd read error |
|
Description: | Symptom:
014 Jun 20 18:32:24.386535 bgp: 64896 [9115] (default) EVT: 172.23.96.107 peer connection retry timer expired
2014 Jun 20 18:32:24.386607 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Triggered active open for peer
2014 Jun 20 18:32:24.387329 bgp: 64896 [9115] (default) EVT: 172.23.96.107 went from Idle to Active (Active setup)
2014 Jun 20 18:32:24.388533 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Schedule wait for connect
2014 Jun 20 18:32:24.388563 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Wait (30 sec) for session setup response
2014 Jun 20 18:32:24.850982 bgp: 64896 [9115] (default) EVT: 172.23.96.107 connect to peer is successful
2014 Jun 20 18:32:24.851013 bgp: 64896 [9115] (default) EVT: 172.23.96.107 sending OPEN message to peer
2014 Jun 20 18:32:24.851060 bgp: 64896 [9115] (default) EVT: 172.23.96.107 went from Active to OpenSent (Active setup)
2014 Jun 20 18:32:24.851101 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Wait (30 sec) for session setup response
2014 Jun 20 18:32:24.851498 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Process OPEN message from peer
2014 Jun 20 18:32:24.851573 bgp: 64896 [9115] (default) EVT: 172.23.96.107 went from OpenSent to OpenConfirm (Active setup)
2014 Jun 20 18:32:24.851617 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Wait (30 sec) for session setup response
2014 Jun 20 18:32:24.852853 bgp: 64896 [9115] (default) EVT: 172.23.96.107 went from OpenConfirm to Established (Active setup)
2014 Jun 20 18:32:24.852898 bgp: 64896 [9115] (default) EVT: 172.23.96.107 cleaning up active peer setup, thread id 0x0
2014 Jun 20 18:32:24.852991 bgp: 64896 [9115] (default) EVT: 172.23.96.107 went from Idle to Established
2014 Jun 20 18:32:24.853018 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Scheduling peer 172.23.96.107 for soft refresh out
2014 Jun 20 18:32:25.867395 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] 172.23.96.107 [peer index 245]
2014 Jun 20 18:32:25.879017 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Adding peer 172.23.96.107 for update gen
2014 Jun 20 18:32:25.879032 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Insert marker dest 0xe1525d64 into xmitlist for 172.23.96.107 with 0 routes on new list and 10475 routes on Tx list
2014 Jun 20 18:32:26.652 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Mark AF update completion for peer 172.23.96.107 (sent prefixes: 4670)
2014 Jun 20 18:32:27.054140 bgp: 64896 [9115] (default) EVT: Read error from peer 172.23.96.107: Broken pipe
2014 Jun 20 18:32:27.054221 bgp: 64896 [9115] (default) EVT: Reset by us (fd read error) in session to 172.23.96.107, value 187, state was Established
2014 Jun 20 18:32:27.054242 bgp: 64896 [9115] (default) EVT: 172.23.96.107 Stopping keepalive, hold timers, peer state Established
2014 Jun 20 18:32:27.054261 bgp: 64896 [9115] (default) EVT: peer:172.23.96.107, state: Established, peer GR STATE: none, AF GR state: none, saved flags: 0
2014 Jun 20 18:32:27.054275 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] 172.23.96.107 Close AF session, gr state none saved flags 0
2014 Jun 20 18:32:27.054290 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Requesting cleanup thread to delete/stale routes for peer 172.23.96.107, with index 245
2014 Jun 20 18:32:27.054303 bgp: 64896 [9115] (default) EVT: [IPv4 Unicast] Requ
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(8)S33, 6.2(9), 7.1(0)D1(0.169) |
|
Known Fixed Releases: | 6.1(2)I3(2.42), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 6.2(10), 6.2(10)S18, 6.2(8)E9, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(3)I1(0.248) |
|
|
| |
| |
Bug Id: | CSCuu49365 |
Title: | Wrong set of bd's are sent in TMC when no bridge-domain is done |
|
Description: | Symptom:
Here proper set of bd's or vlan's are not sent in port affected notif to ethpm for bringing them down.
This will lead to inconsistency in peer-link i.e. vpc_mgr, ethpm and vlan components.
This only pertains to vxlan setup and not vinci/autoconfig.
Conditions:
Only on "no bridge-domain " and vxlan setup.
This is not seen in vinci and autoconfig setup.
Workaround:
For peerlink do shut/no shut i.e. flap the port.
For normal ports aswell do the same flap them.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.512), 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(0)D1(1), 7.2(0)D1(1.14), 7.2(0)ZD(0.221), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCut17793 |
Title: | SSTE:Traffic loss observed after flapp mpls interf with 7.2(0)D1(0.422) |
|
Description: | Symptom:
Few VPLS PWs are down
Conditions:
Flap MPLS interface used by PWs
Workaround:
clear l2vpn service all
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.422), 7.2(0)D1(0.484) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.81), 7.2(0)D1(0.503), 7.2(0)D1(1), 7.2(0)N1(0.196), 7.2(0)N1(1), 7.2(0)VZD(0.26), 7.2(0)VZN(0.34), 7.2(0)ZD(0.183) |
|
|
| |
| |
Bug Id: | CSCui72592 |
Title: | N7k: F3 module reloads due to Kernel Panic |
|
Description: | N7K / F3 module may reload unexpectedly due to a kernel panic at 'InstructionTLBError47x'. The following symptoms will be observed:
(1) Syslogs will indicate the module was unresponsive, and was reset.
2014 Aug 21 20:20:08 NEXUS7K %MODULE-2-MOD_NOT_ALIVE: Module 2 not responding... resetting (Serial
number: XXXXXXXXXXX)
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-2-MOD_DETECT: Module 2 detected (Serial number XXXXXXXXXXX)
Module-Type 10/40 Gbps Ethernet Module Model N77-F324FQ-25
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-2-MOD_PWRUP: Module 2 powered up (Serial number XXXXXXXXXXX
)
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-5-MOD_STATUS: Module 2 current-status is MOD_STATUS_POWERED
_UP
2014 Aug 21 20:21:57 NEXUS7K %BIOS_DAEMON-SLOT2-5-BIOS_DAEMON_LC_PRI_BOOT: System booted from Pri
mary BIOS Flash
2014 Aug 21 20:24:03 NEXUS7K %VDC_MGR-5-VDC_STATE_CHANGE: vdc 1 state changed to updating
2014 Aug 21 20:24:03 NEXUS7K %VDC_MGR-5-VDC_STATE_CHANGE: vdc 1 state changed to active
2014 Aug 21 20:24:32 NEXUS7K %PLATFORM-5-MOD_STATUS: Module 2 current-status is MOD_STATUS_ONLINE/
OK
(2) The output of 'show logging onboard module internal reset-reason' will indicate that the reload reason was due to a kernel panic.
Reset Reason for this card:
Image Version : 6.2(8a)
Reset Reason (LCM): Line card not responding (60) at time Thu Aug 21 20:21:59 2014
Reset Reason (SW): Kernel Panic (19) at time Thu Aug 21 20:19:28 2014
Service (Additional Info): Kernel Panic
Reset Reason (HW): System reset by active sup (by writing to PMFPGA regs) (100) at time Thu Aug 2
1 20:21:59 2014
Last log in OBFL was written at time Thu Aug 21 19:32:39 2014
(3) The output of 'show logging onboard module stack-trace' will provide the kernel stack trace. The top function on this stack will be 'InstructionTLBError47x'. The running process and the rest of the stack are not relevant.
Example:
---------------------------------
Module: 2 stack-trace
---------------------------------
------------------ LOG 01 -------------------
Logging time: Thu Aug 21 20:19:28 2014
1408670368:500000000 process xxxxxxxx (1219), jiffies 0xb79c1f6
Machine Check in kernel mode : Process xxxxxxxxx (1219)
MCSR: 0x0 MCAR: 0x0 MCSSR0: 0xc040100c MCSSR1: 0x21000
STACK
CPU 1 Call Trace:
[]InstructionTLBError47x+0x6c/0xa8 <------------- HERE
Symptom:N7K / F3 module may reload unexpectedly due to a kernel panic at 'InstructionTLBError47x'. The following symptoms will be observed:
(1) Syslogs will indicate the module was unresponsive, and was reset.
2014 Aug 21 20:20:08 NEXUS7K %MODULE-2-MOD_NOT_ALIVE: Module 2 not responding... resetting (Serial
number: XXXXXXXXXXX)
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-2-MOD_DETECT: Module 2 detected (Serial number XXXXXXXXXXX)
Module-Type 10/40 Gbps Ethernet Module Model N77-F324FQ-25
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-2-MOD_PWRUP: Module 2 powered up (Serial number XXXXXXXXXXX
)
2014 Aug 21 20:20:19 NEXUS7K %PLATFORM-5-MOD_STATUS: Module 2 current-status is MOD_STATUS_POWERED
_UP
2014 Aug 21 20:21:57 NEXUS7K %BIOS_DAEMON-SLOT2-5-BIOS_DAEMON_LC_PRI_BOOT: System booted from Pri
mary BIOS Flash
2014 Aug 21 20:24:03 NEXUS7K %VDC_MGR-5-VDC_STATE_CHANGE: vdc 1 state changed to updating
2014 Aug 21 20:24:03 NEXUS7K %VDC_MGR-5-VDC_STATE_CHANGE: vdc 1 state changed to active
2014 Aug 21 20:24:32 NEXUS7K %PLATFORM-5-MOD_STATUS: Module 2 current-status is MOD_STATUS_ONLINE
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(5.41)S0, 6.2(5.41)S1, 6.2(5.41)S2, 6.2(5.41)S3, 6.2(5.7), 6.2(8a), 7.0(0.33)S0, 7.1(0)D1(0.169) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S32, 6.2(10)S9, 6.2(10.5), 6.2(6b)E2, 6.2(8)E4, 6.2(8)E5, 7.1(0)D1(0.232), 7.1(0)NF(0.32), 7.1(0)OTT(0.27) |
|
|
| |
| |
Bug Id: | CSCut87473 |
Title: | bfd crash @bfd_sys_get_remote_ip_info on BDI/peer link i/f shut/unshut |
|
Description: | Symptom:
bfd crash
Conditions:
On BDI/VPC peer link interface shut/no shut few times with scaled configuration
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471), 7.2(0)D1(0.490) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.2(0)D1(0.504), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.184), 7.2(1)PIB(0.14), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCuu59073 |
Title: | UIN-1::Seeing ifmgr core @ ethpm_get_max_port_speed |
|
Description: |
Symptom:
User triggered command for sub-interface causing ifmgr core
Conditions:
Using invalid data for the sub-interface with uninitialized value.
Workaround:
None
Further Problem Description:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)ZD(0.209), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCuq96869 |
Title: | CNH programmed to 0/0, Null0 |
|
Description: | Symptom:
Some routes may either be missing or mis-programmed.
Conditions:
At VDC reload some early new route updates might be processed and dropped before processing the vdc-create. this causes ipfib to ignore the messages since they will be treated as invalid. Issue is seen during line card reload and during issu as well.This is a corner case timing issue and very rare
Workaround:
re download the routing table using 'clear ip route *' and 'clear ip arp' . In some cases flapping the layer 3 interface/interface vlan which is used to reach the next-hop can also clear the problem. Finally if the above workaround does not work reload of the module will be required.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S73, 6.2(8b) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.11), 6.2(12)FT(0.5), 7.1(0)AV(0.38), 7.1(0)D1(0.306), 7.1(0)OTT(0.45), 7.1(0)PDB(0.241), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuu08730 |
Title: | DAI: ARP Response dropped when the local vPC leg is down |
|
Description: | Symptom:
A nexus 7000 series switch in a vpc/vpc+ environment configured for dynamic arp inspection may drop arp replies targetted to itself under certain conditions
Conditions:
- The local vpc leg is down causing the arp reply to be sent to the peer and tunneled to the switch that sent the arp request.
- The vpc is trusted for dynamic arp inspection
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 7.2(0)N1(0.217) |
|
Known Fixed Releases: | 6.2(10)E3, 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)N1(1), 7.2(0)ZD(0.199), 7.2(0)ZN(0.218), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCuu21836 |
Title: | Port was Error disabled, Reason:Port not found when NAM module installed |
|
Description: | Symptom:
If there is a NAM module installed and when a dce (core/edge) interface belonged to an another module flaps, then Port Client process in NAM sends "Port Not found".
This makes the EthPM to put the port to ErrDisable state
Example syslog:
============
ETHPORT-5-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/41 is down (Error disabled. Reason:Port not found)
Conditions:
NAM module is present on the box
dce (core/edge) interface belonged to an another module flaps
Workaround:
If Customer could afford to reload the NAM module, secure a maintenance window and reload the NAM module.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(9c), 7.2(0)D1(0.392) |
|
Known Fixed Releases: | 6.2(14)FB(0.51), 7.1(0)AV(0.81), 7.2(0)D1(0.504), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.184), 7.2(1)PIB(0.14), 7.3(0)IB(0.19), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCuu96337 |
Title: | N5672UP NFM crash after config change |
|
Description: | Symptom:
N5672UP rebooted causeed by nfm crash after config and save.
Conditions:
Nexus5672UP
NXOS7.0(6)N1(1)
Workaround:
unknown
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.0(99)ZD(99.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud91672 |
Title: | Nexus7000: DEV_LOCAL_SAC_ASIC (device error 0xc910026d) [Sup2+M2] |
|
Description: | Symptom:
Nexus7000 module reports:
%MODULE-4-MOD_WARNING: Module (Serial number: ) reported warning on ports
due to SAC sync lost in device DEV_LOCAL_SAC_ASIC (device error 0xc910026d)
Conditions:
Issue is seen only with M2 modules in Nexus7000 with SUP1 or SUP2 engines running 6.x releases
Workaround:
None
Issue is fixed in 6.1(4) and 6.2(2) or later releases.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.1(3)S32 |
|
Known Fixed Releases: | 5.2(9.95)S0, 6.1(4), 6.1(4)S3, 6.1(4.25)S0, 6.2(1.41)S0, 6.2(1.93), 6.2(2), 7.0(0.6) |
|
|
| |
| |
Bug Id: | CSCub73193 |
Title: | BGP routes stuck in delete state blocked by ulib flow control |
|
Description: | Symptom:
Under rare situation, BGP bestpath run may stall due to a bug
in the BGP-ULIB flow control logic. To confirm the problem, search
the 'show tech bgp' or 'show tech l3vpn' for:
Last xid sent to ULIB: 4294967295
Last xid received from ULIB: 65535
ULIB flow control blocks: 5 (currently blocked)
Conditions:
This can only happen to MPLS deployments where label allocation
is required (L3VPN, 6VPE, 6PE).
There is an integer wrap-around bug in the BGP-ULIB flow control
logic. If during the wrap-around period, ULIB is busy and slow to
respond, the BGP bestpath run will be blocked indefinitely.
This problem is very time sensitive and the window is very small.
It is not guaranteed to happen every time.
This is no specific trigger, as long as new labels are continuously allocated
from ULIB (new prefixes, label mode change, etc), it may hit the wrap-around
condition.
Workaround:
There's no workaround. To recover from the situation, perform 'restart bgp'.
A less disruptive recovery method is to use 'per-vrf' label mode by configuring
a dummy l3vpn vrf context. Example:
vrf context dummy
rd
router bgp <>
vrf dummy
address-family ipv4 unicast
label-allocation-mode per-vrf
This should unblock the BGP bestpath run. If not, try adding another dummy vrf (without removing the previous one). After BGP bestpath run had been unblocked, the dummy vrfs can be removed.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 5.2(5), 5.2(5)S19 |
|
Known Fixed Releases: | 5.2(7), 5.2(7)S3, 5.2(7.6)S0, 6.0(2)N2(1), 6.0(2)U1(1), 6.1(1.66)S0, 6.1(2), 6.1(2.27), 6.2(0.285), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCuu11726 |
Title: | LIM flush clears non VxLAN macs on the BD affected |
|
Description: | Symptom:
For silent orphan hosts, we can see traffic drops if traffic reaches other VPC peer.
We can also experience flooding if it reaches the peer containing the silent host.
Conditions:
PeerLink shut, Dismembering VNI from BD, NVE flap
BD should be common for VxLAN and non VxLAN hosts.
Workaround:
ReARP the silent hosts after the flush
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus26870 |
Title: | December 2014 ntpd CVEs for Nexus 5k/6k/7k/MDS |
|
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
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 |
|
|
| |
| |
Bug Id: | CSCup16103 |
Title: | N7k: Copp fails to rate limit Pause frames from Hosts on 2248TP type FEX |
|
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)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(6a), 6.2(8) |
|
Known Fixed Releases: | 7.2(0)N1(0.172), 7.2(0)N1(1), 7.2(0)VZN(0.34), 7.2(0)ZN(0.174), 7.3(0)N1(0.25), 7.3(0)N1(1), 7.3(0)ZN(0.24) |
|
|
| |
| |
Bug Id: | CSCut34478 |
Title: | unicast route for the NVE peer loopback IP is missing on some ASIC inst |
|
Description: | Symptom:
This issue is specific to Vxlan - Flood and Learn. When the peer LC goes down and it is the only core facing LC on the peer switch, the peer route is not programmed properly on all the instances and hence the traffic fails.
Conditions:
This issue is specific to Vxlan - Flood and Learn.
The peer route must be programmed on the VDC instances. This is achieved through the following two updates -
a. URIB route update for programming the route on core vrf instances.
b. NVE Manager peer add updates for programming the route on the VDC instances.
This issue is observed when the peer LC goes down and it is the only core facing LC on the peer switch. In such a scenario, when OSPF timeouts, URIB triggers an unlearn for the peer route.
However, the MAC Table timeout is longer than the OSPF timeout. Hence, the MAC table still has the Remote host MAC entry - thus the NVE peer is still seen in NVE Manager.
When the peer LC is up again, OSPF sends an update for the peer route. However, NVE manager doesn't resend the peer route update since it already has the peer update. As a result, we end up with the peer route programmed only on the URIB notified VRF instances and not the other instances in the VDC.
Workaround:
clear ip route vrf all
shut / no shut on the nve interface.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.424) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtq62339 |
Title: | NX-OS 5.1 Kernel Memory Leak |
|
Description: | Symptom:
Nexus7000 may report platform memory alert due to high memory utilization:
%PLATFORM-2-MEMORY_ALERT: Memory Status Alert: MINOR. Usage 85% of Available Memory
%PLATFORM-2-MEMORY_ALERT: Memory Status Alert: SEVERE. Usage 90% of Available Memory
N7K# sh system internal memory-status
MemStatus: Severe Alert
N7K# sh system internal memory-alerts-log | inc "ALERT INFO|MemTotal|MemFree|LowTotal|LowFree"
MINOR ALERT INFO
MemTotal: 8254672 kB
MemFree: 4295324 kB
LowTotal: 727120 kB
LowFree: 109332 kB
SEVERE ALERT INFO
MemTotal: 8254672 kB
MemFree: 4255408 kB
LowTotal: 727120 kB
LowFree: 72392 kB
Conditions:
CSCtq62339 is only being encountered if the following conditions are true:
Switch is running a release between 5.1(1) to 5.1(3).
>>>>=====
On these releases, the bug will be exposed
irrespective any feature enabled/disabled.
There is no precondition for this.
<<<<<====
Memory alert log shows only a snapshot of kernel memory *when* the alert threshold (85,90,95%) is crossed. Historical information can be misleading and needs to be understood clearly.
To calculate the CURRENT kernel memory, use the following procedure:
N7K# show system internal kernel memory usage | in Low
Low memory condition is logged when the following formula is at/above the logging threshold:
(LowTotal - LowFree) ?? LowTotal x 100
Ex: (727120 - 72392 ) ?? 727120 x 100 = 90% (threshold reached due to utilization in low region)
Low memory condition has been seen after approximately 3 months of supervisor uptime.
Workaround(s):
Reload of the active supervisor will clear the issue in a setup with two supervisor cards.
Reload of the switch will clear the issue in a setup with a single supervisor.
Software upgrade to fixed release, 5.1(4) or 5.2(1) or later.
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and determined it 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
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 5.1(1), 5.1(2), 5.2(1) |
|
Known Fixed Releases: | 5.1(10.4)S0, 5.1(4)S3, 5.2(1)S36, 5.2(1.43)S0 |
|
|
| |
| |
Bug Id: | CSCus52139 |
Title: | post L3, l2 flood traffic not going out on peer-link |
|
Description: | Symptom:
Post L3 Flood to BD packet are not forwarded in the Peer Link
Conditions:
VPC setup with VxLAN configuration.
Workaround:
MAC table should be populated.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.383) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud42302 |
Title: | SNMP process crash with DCNM discovery |
|
Description: | Symptom:
Device sees a snmpd process crash. The log might show something similar to:
%SNMPD-2-CRITICAL: SNMP log critical : netsnmp_tcp_send : TRACE - send returned error : rc(-1), errno(11)
%SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 28261) hasn't caught signal 11 (core will be saved).
Conditions:
The issue appears to occur with DCNM discovery
Workaround:
Possible workaround is to disable DCNM discovery
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.0(4)S20 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun24082 |
Title: | N7K - GARP Storm Detection is not working as expected |
|
Description: | Symptom:
With default configuration(ip arp garp-storm timer 1 count 100), when sever NIC is failovered, a ARP entry is to be Storm status without updating with new mac(failovered NIC mac) even GARP pps rate of the entry is just 1pps. This issue occurs intermittently.(If the customer tries to do failover test 10 times, this issue occurs 2-3 times)
Conditions:
- NX-OS: 6.2(2)
- Default Configuration of GARP storm
Workaround:
Disable GARP Storm function(no ip garp garp-storm)
Further Problem Description:
please see the documentation for behavior details
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(2)S42 |
|
Known Fixed Releases: | 5.2(9.280)S0, 6.0(2)A4(0.764), 6.0(2)A4(1), 6.0(2)A5(0.943), 6.0(2)A5(1), 6.0(2)U4(0.764), 6.0(2)U4(1), 6.0(2)U5(0.943), 6.0(2)U5(1), 6.1(5.9)S0 |
|
|
| |
| |
Bug Id: | CSCus08720 |
Title: | DHCP_SNOOP service crash after apply DHCP relay agent cnofig on SVI |
|
Description: | Symptom:
dhcp_snoop service crash
Conditions:
This has been seen on N7K running 6.2(10) code.
This happens when smart relay is enabled and a DHCP operation fails after a DHCP Discover packet is received and no Offer is received for the same.
The probability of occurrence of this crash is low.
Workaround:
Disable Smart relay.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.0(2)A6(0.43), 6.0(2)A6(1), 6.0(2)U6(0.43), 6.0(2)U6(1), 6.1(2)I3(3.71), 6.1(2)I3(4), 6.2(12.4)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38) |
|
|
| |
| |
Bug Id: | CSCuq55749 |
Title: | HSRP MGO: Slave may enter Init due to 'No Master for Slave' |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCuo81646 |
Title: | N77-F348XP-23 port 41-48 link remain up even cable disconnected |
|
Description: | Symptom:
port 41-48 link remain up even cable disconnected or partner device is admin down
Conditions:
1G Optics or 1G copper are used on N77-F348XP-23 port 41-48
Workaround:
there is no work around
upgrade to fixed version
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(10)FM(0.27) |
|
Known Fixed Releases: | 6.2(10), 6.2(8)E5, 6.2(8.12)S0 |
|
|
| |
| |
Bug Id: | CSCuu20761 |
Title: | Delete MAC sync issue after LC module reload that does not have PL |
|
Description: | Symptom:
VxLAN Mac inconsistency across VPC peers OR
Stale vxlan mac on one side of VPC complex
Conditions:
LC reload which contains VxLAN coreports but does not contain the peerlink.
Workaround:
clear mac address dynamic.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo80937 |
Title: | Nexus 7000 Stuck Sending TCNs Every 2 Seconds |
|
Description: | Symptom:
If there is any TC after upgrade to 6.2.(6), 6.2.(6a) or 6.2.(8), then after approximately 90 days of active supervisor uptime, STP TC BPDUs are sent out every 2 seconds for a long period of time.
Conditions:
Nexus 7000 or 7700 running 6.2(6), 6.2.(6a), or 6.2(8).
Workaround:
In order to circumvent this issue until an upgrade to fixed code can be performed,
execute the appropriate workaround depending on whether you have a dual-supervisor or single-supervisor
configuration before each 90 days of Active supervisor uptime.
For dual-supervisor setups:
1. Reload the standby supervisor using cli "reload module x" where x is standby supervisor slot number.
2. Use the 'show module' command to confirm that the standby supervisor is up and in the ha-standby mode.
3. Use the 'system switchover' command to switch to the standby supervisor.
For single-supervisor setups:
1. Upgrade to 6.2.6b or 6.2.8a, depending on your business requirements.
2. Reload the switch.
Further Problem Description:
Active Supervisor Uptime can be found from "show system uptime":
N7K-7009-3# show system uptime
System start time: Fri Oct 25 09:40:58 2013
System uptime: 236 days, 8 hours, 56 minutes, 59 seconds
Kernel uptime: 110 days, 23 hours, 7 minutes, 49 seconds
Active supervisor uptime: 110 days, 23 hours, 2 minutes, 23 seconds <<<<<<<<<<<
-----------------
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(10)E1, 6.2(6) |
|
Known Fixed Releases: | 6.1(2)I3(1), 6.2(10), 6.2(10)S5, 6.2(10.5), 6.2(6)E2, 6.2(6b), 6.2(6b)S1, 6.2(8)E1, 6.2(8)E2, 6.2(8)E5 |
|
|
| |
| |
Bug Id: | CSCua82201 |
Title: | BGP process fail due to constant BGP socket open/close state changes |
|
Description: | Symptom
BGP process fails due to constant BGP socket open/close state changes. If there are several idle peers, over a period of time due to excessive churn of netstack client for BGP sockets, newly provisioned BGP session fail to come up with the following error
BGP-3-SOCKCREATE: bgp-XXXX [24958] Cannot create socket for peer X.X.X.X: Bad file descriptor, stats: 28391553/496156/28887500/14303942/14143771
Workaround
If BGP graceful restart is configured, then clear all BGP neighbors may clear the issue
If BGP graceful restart is not configured then disabling and enabling 'feature bgp' from the active configuration will clear this issue
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.0(2)S31 |
|
Known Fixed Releases: | 6.0(2)U2(1), 6.0(2)ZD(0.6), 6.1(2), 6.1(2)E10, 6.1(2)E10.4, 6.1(2)S6, 6.1(2.11)S0, 6.2(0.285), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCth40877 |
Title: | NxOS: OSPF DR not sending out network LSAs |
|
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
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.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCui02208 |
Title: | stp techsupport on X.1 causes stp disputes & BA_block |
|
Description: | Symptom:
On a scale setup with a high number of logical ports, when stp tech-support is collected, stp spends a lot of time in dumping out the event-history for all ports from the backend. This could lead to a delay in sending bpdus in stp, thus causing STP Disputes.
Conditions:
This condition happens when there are a large number of logical ports, in either Rapid Spanning or Multiple Spanning tree configurations.
Workaround:
The workaround is to collect show tech-support binary all.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(1.157)S0, 6.2(2)S42, 6.2(8a) |
|
Known Fixed Releases: | 7.1(163)GVB(0.3) |
|
|
| |
| |
Bug Id: | CSCue36257 |
Title: | AAA crash and leading to possible hap reset |
|
Description: | AAA Crash observed.
Symptom:
AAA Process Crash.
Conditions:
When we execute show accounting log command.
Workaround:
No Work Around and It is very corner case.
Further Problem Description:
When the accounting log file in logflash becomes more than 250,000 bytes , it is moved to archive file. But when the current accounting logfile size also becomes more than 250,000 and 'show accounting log' command was executed at this time(No accounting message before show accounting log) , then due to buffer overflow , crash happens.But if instead of 'show accounting log ' command , if any other command is executed , then an accounting update message will be sent to aaa which will move the current accounting log to archive and old archive file will be removed. Due to this , the total size of the accounting log will be less than 500 k and hence the bug was not seen everytime .
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 6.2(0.304)S15, 6.2(1.111) |
|
Known Fixed Releases: | 6.0(2)U3(0.641), 6.0(2)U3(1), 6.0(2)U4(0.60), 6.0(2)U4(1), 6.1(4.97)S0, 6.1(5), 6.1(5.32)S0, 6.2(1.146)S0, 6.2(2), 7.0(0)ZD(0.84) |
|
|
| |
| |
Bug Id: | CSCur12364 |
Title: | N5K:ISSU fails 5.1(3)Nx(x)/5.2(1)N1(x) -> 6.0(2)Nx(x)/5.2 -> 7.0(x)N1(1) |
|
Description: | Symptom:
When performing ISSU with this path: 5.1(3)N1(1) / 5.1(3)N1(1a) => 6.0(2)N2(5) => 7.0(3)N1(1)
This issue is hit with ISSU upgrade path of 5.1.x->5.2.x->7.x as well. Not necessary that 6.0 should be interim.
We can see that 1st step is fine. But when switch is rebooted on the second step for upgrade 6.0(2)N2(5) => 7.0(3)N1(1) switch is crashing at boot at URIB process.
And this error is shown:
show install all status
This is the log of last installation.
Need to perform cleanup of failed upgrade.
Install has failed. Return code 0x40930039 (aborting due to failed upgrade).
Conditions:
Issue seen with these conditions:
- N5K VPC pair with AA FEX
- perform ISSU: 5.1(3)N1(1) -> 6.0(2)N2(5) -> 7.0(3)N1(1) or 5.1.x->5.2.x->7.x (without reload between after intermediate upgrade)
Workaround:
Issue is not seen when N5K pair booted 6.0(2)N2(5) and configured from clear config.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUN-2015 |
|
Known Affected Releases: | 5.1(3)N1(1a), 6.0(2)N2(5), 7.0(3)N1(0.125) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.0(7)ZN(0.112), 7.1(0)AV(0.81), 7.1(2)N1(0.549), 7.1(2)ZD(0.6), 7.1(2)ZN(0.8), 7.2(0)D1(0.505), 7.2(0)D1(1), 7.2(0)N1(0.199), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCum30306 |
Title: | Security service crashes while configuring an SSH authentication key |
|
Description: | Symptom:
The security service crashes when configuring an SSH authentication key.
Configuring SSH keys multiple times within 10 minutes results in a HAP reset that resets the active supervisor.
Conditions:
This issue intermittently occurs when configuring an SSH authentication key.
Workaround:
To avoid the supervisor reset, do not configure more than 2 SSH keys per 10 minutes.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 5.2(8), 6.2(2a) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.5)S0, 6.2(7.7)S0, 6.2(8), 6.2(8)BF(0.21), 6.2(8)BF(0.24), 6.2(9)FM(0.37) |
|
|
| |
| |
Bug Id: | CSCuq20660 |
Title: | L3 PC Sub interface MTU not programmed/shown when Network Qos MTU exits |
|
Description: | Symptom:
Show interface will show wrong MTU on SubInterface in case Network QoS based MTU is configured. But this is only Show CLI issue. The HW is programmed correctly.
For Port-channel SI's, HW programming is also not happening
Conditions:
Network QoS is used to changed the Port MTU
Workaround:
Apply port MTU on port-Channel parent First and than on Subinterfaces.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S36 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue67277 |
Title: | Interface does not recover from err-disable state during ISSU from 5.2.7 |
|
Description: | Symptom:
During ISSU, if any ports flap they get error disabled and stay error disabled even after ISSU is completed.
Conditions:
Issue occurs only if ports flap while ISSU is in progress.
Workaround(s):
shut/no shut will bring up the error disabled ports.
Workaround:
Workaround for recovering error disabled ports :
- Wait till the ISSU is over. Once the system is ready, issue a "shut / no shut" on the ports to recover them to normal state.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 5.2(5)S2, 6.1(3)S47, 6.2(1.111)S4, 6.2(1.118)S1, 6.2(1.125)S5, 6.2(1.91)S7, 6.2(5.7), 7.0(0)FV(0.88), 7.0(0.1) |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(5), 6.1(5.20)S0, 6.2(1.121)S0, 6.2(1.127)S0, 6.2(2), 7.1(0)D1(0.14), 7.2(0)VZN(0.30) |
|
|
| |
| |
Bug Id: | CSCuo85450 |
Title: | Nexus 5000 crashed with arp hap reset |
|
Description: | Symptom:
switch reload with following log:
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 141764 usecs after Wed May 14 03:21:41 2014
Reason: Reset triggered due to HA policy of Reset
Service: arp hap reset
Version: 7.0(1)N1(1)
Conditions:
Gratuitious ARP storms are suspected as the trigger for this issue.
Workaround:
currently unknown
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(2) |
|
Known Fixed Releases: | 6.0(2)A5(0.943), 6.0(2)A5(1), 6.0(2)U5(0.943), 6.0(2)U5(1), 6.2(10), 6.2(10)S40, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(1)ZD(0.248) |
|
|
| |
| |
Bug Id: | CSCur32142 |
Title: | mcast traffic blackhole for upto 4min as assert cancel not sent by winne |
|
Description: | Symptom:
Multicast traffic blackhole for up to 4 minutes
Conditions:
If more than one router forwards traffic onto a LAN - in initial bootup phase or when 'ip multicast multipath' command is configured - PIM assert election happens and one router becomes the winner. This could be the non-PIM-DR having a PIM receiver. There may also be local IGMP receivers on this LAN.
Now, if the winner receives a PIM Prune message and no other PIM receivers exist on that LAN, the winner should send an assert cancel message, to conclude the election and let the PIM-DR on the LAN forward for local receivers.
Under certain circumstances, the winner does not always send out the assert cancel thereby causing traffic blackhole until the loser router ages out the winner's assert message. This could take up to 4 minutes.
Workaround:
clear ip mroute
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S102, 7.1(0)D1(0.324) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110), 7.1(0)AV(0.38), 7.1(0)D1(0.325), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283), 7.1(0)SIB(99.68), 7.2(0)D1(1), 7.2(0)N1(0.12) |
|
|
| |
| |
Bug Id: | CSCuu71685 |
Title: | N7k-Fex: Ethpm timed out on port sec with sticky config during bringup |
|
Description: | Symptom:
When member ports of port channels are configured with stick mac and during reload port security is trying to restore the stick mac of all ports causing delay in sending the response to ethpm resulting the ports and port channels to be in down state.
Conditions:
Workaround:
The work around is to un-configure the sticky mac as dynamic Mac learning is highly preferred than sticky. Removing the sticky mac configuration will resolve the sequence timing out issue.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu09287 |
Title: | SSTE: pixm critical message on 'no feature-set fabric' |
|
Description: | Symptom:
error message seen when no feature-set fabric is issued.
Conditions:
configure several feature sets and multiple VDCs.
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.484) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur68350 |
Title: | F3: MAC Address is not Learned in Software after ISSU |
|
Description: | Symptom:
A MAC address is present in hardware but not software. Since the MAC is not in software other processes and features are not notified of new MAC address. This can result in black-holed traffic.
Conditions:
- ISSU to 6.2(10)
- F3 module
- OTV or vPC
Workaround:
Upgrade via a traditional reload.
If issue is hit via ISSU, flap the interface. If they are part of a port channel that spans multiple forwarding engines (FE), flap the member interfaces one at a time force mac learning on a different FE.
If the internal interface is not a port channel or the members are on the same FE then flapping the interface in OTV will trigger OTV AED failover or in vPC shut down the vPC leg.
If you believe problem exist even after flapping the interface please contact TAC for further workaround.
Further Problem Description:
This impacts OTV as locally learned MAC address will not be advertised to the remote otv site and vPC as new MAC learns will not be advertised to the vPC peer
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.24), 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.303), 7.2(0)D1(0.387), 7.2(0)D1(1), 7.2(0)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCut51575 |
Title: | VPC breaks due to incorrect emulated switch-id after ISSU upgrade |
|
Description: | Symptom:
Emulated switch-id changed to default value(2750) instead of configured one causing network connectivity issue. Software shows the correct switch-id.
Software:
`show vpc`
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 150
vPC+ switch id : 2010--------------------------------------------->Correct value
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
vPC fabricpath status : peer is reachable through fabricpath
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : secondary
Number of vPCs configured : 85
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)
`show platform fwm info l2mp myswid`
switch id
-------------------------------------------------------------------
switch id manager
-------------------------------------------------------------------
vpc role: 0
my primary switch id: 1011 (0x3f3)
emu switch id: 2750 (0xabe)--------------------------------???instead of 2010
peer switch id: 1010 (0x3f2)
Conditions:
ISSU upgrade
Workaround:
Remove the switch-id and reconfigure the same.
Conf ter
Vpc domain 150
No fabricpath switch-id 2010
fabricpath switch-id 2010
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuf55953 |
Title: | vntagmgr crashed while configuring Fex ports |
|
Description: | Symptom:
Crash observed with vntag_mgr following changes made to an existing SPAN session
Conditions:
Active changes to the SPAN session configurgation
Workaround:
None at this time.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.2(1.52) |
|
Known Fixed Releases: | 6.2(1.61)S0, 6.2(2), 7.0(0)ZD(0.53), 7.0(0)ZD(0.55), 7.0(0.7) |
|
|
| |
| |
Bug Id: | CSCur26436 |
Title: | Nexus 7000 & MDS 9000 evaluation of SSLv3 vulnerability (POODLE) |
|
Description: | Symptom:
Nexus 7000 and MDS 9000 switches include a version of SSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-3566
Conditions:
A POODLE exploit requires a man in the middle attack between the switch (the LDAP client utilising the SSL client) and the LDAP server. Nexus 7000 and MDS 9000 both contain an SSL client with SSLv3 support. The client supports fallback to SSLv3 if negotiation with TLS 1.0 fails.
The LDAP SSL feature may be configured to utilise this client. This feature is disabled by default. Hence, this vulnerability only exists if the LDAP feature is enabled.
Workaround:
Disable the LDAP SSL feature with the ldap-server host ip_address enable-ssl command.
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:
MDS:
NX-OS 5.2 release - first fixed release is 5.2(8f), released on 18 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), projected to be available in Q3 2015
There are no fixed MDS NX-OS releases that are FICON certified yet.
Nexus 7000:
NX-OS 6.2 release - first fixed release is 6.2(12), released on 03 Feb 2015
There will not be any fixed releases for software trains that are past the end of software maintenance support.
The current fix is for the NX-OS SSL client to refuse to fall back to SSLv3. If the server tries to negotiate to SSLv3, the client will now terminate the SSL session. SSLv3 support will be completely removed in future releases.
A Cisco Security Advisory has been published to document this vulnerability at:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141015-poodle
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.6/2.5
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:F/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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.2(7), 6.2(8) |
|
Known Fixed Releases: | 5.2(8f), 5.2(8f)S3, 6.2(11b), 6.2(11b)S1, 6.2(11c), 6.2(11c)S2, 6.2(12), 6.2(12)S24, 6.2(12.4)S0, 6.2(13)FM(0.65) |
|
|
| |
| |
Bug Id: | CSCuu50227 |
Title: | LISP Mcast: RPF selection broken |
|
Description: | Symptom:
When mrib is learning RPF from LISP and a static null0 route is installed in the rib, whether more or less specific than the map-cache entry, we see mrib install RPF of null. If mrib was listening directly to the rib, we'd expect the rpf to be null0.
Conditions:
Miscommunication between LISP and MRIB
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.1), 7.2(1)PIB(0.12) |
|
|
| |
| |
Bug Id: | CSCur77280 |
Title: | N6k m2rib missing interfaces from OIFL |
|
Description: | Symptom:
Multicast/broadcast packet drops on certain vlans.
Conditions:
After flapping several links or recreating fabricpath vlans in specific order.
Workaround:
Remove and add back vlan, trying to start from the spines and then going to the leafs.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.2(0)ZN(99.81) |
|
Known Fixed Releases: | 7.0(1)ZN(0.736), 7.0(6)N1(0.236), 7.0(6)N1(0.4), 7.0(6)N1(1) |
|
|
| |
| |
Bug Id: | CSCut77411 |
Title: | Assess April 2015 NTPd vulnerabilities for N5k/N6k/N7k |
|
Description: | Symptom:
This has been opened to document the potential impact on the following products:
Cisco Nexus 5/6k switch family
Cisco Nexus 7k switch family
of the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-1798
CVE-2015-1799
Conditions:
Exposure is configuration dependent. The configuration that can expose the vulnerability are
ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234
ntp peer 1.2.3.4 key 1
Workaround:
Remove the applicable configuration.
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.2
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:P/A:N/E:U/RL:OF/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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.3), 7.3(0.9) |
|
Known Fixed Releases: | 5.2(1)N1(8.167), 5.2(1)N1(9), 6.0(2)N2(6.141), 6.0(2)N2(7), 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.0(7)ZN(0.108), 7.1(0)AV(0.74), 7.1(2)N1(0.545), 7.1(2)N1(0.546) |
|
|
| |
| |
Bug Id: | CSCuu30447 |
Title: | F2/F2E port will keep up even the rx power is -26dBm due to ISP break |
|
Description: | Symptom:
Topology:
N7K-c1(port e4/31)---15454-1===ISP===15454-2------(port4/3)N7K-c2
Software:
both N7K-c1 and N7K-c2 are running with 6.2.12.
module 4 is the N7K-F248XP-25E
Transceiver info:
both e4/31 and e4/3 are installed with GLC-SX-MMD.
Configuration for port e4/31 and e4/3:
interface Ethernet4/31
no shutdown
interface Ethernet4/3
no shutdown
Failure scenario:
if we break the ISP fiber, you might see one of the port e4/31 and e4/3 will be up while the other one is in link failure status.
N7K-3-c1# show int e4/31
Ethernet4/31 is down (Link not connected)
admin state is up, Dedicated Interface
Hardware: 1000/10000 Ethernet, address: 8478.ac56.4645 (bia 8478.ac5a.0fb2)
MTU bytes (CoS values): MTU 1500(0-2,4-7) bytes MTU 2112(3) bytes
BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, medium is broadcast
Port mode is routed
auto-duplex, auto-speed, media type is 1G
Beacon is turned off
Auto-Negotiation is turned on
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:26:03
Last clearing of "show interface" counters 02:27:02
8 interface resets
Load-Interval #1: 30 seconds
30 seconds input rate 0 bits/sec, 0 packets/sec
30 seconds output rate 0 bits/sec, 0 packets/sec
input rate 0 bps, 0 pps; output rate 0 bps, 0 pps
Load-Interval #2: 5 minute (300 seconds)
300 seconds input rate 0 bits/sec, 0 packets/sec
300 seconds output rate 0 bits/sec, 0 packets/sec
input rate 0 bps, 0 pps; output rate 0 bps, 0 pps
L3 in Switched:
ucast: 0 pkts, 0 bytes - mcast: 0 pkts, 0 bytes
L3 out Switched:
ucast: 0 pkts, 0 bytes - mcast: 0 pkts, 0 bytes
RX
76 unicast packets 90 multicast packets 0 broadcast packets
90 input packets 25587 bytes
0 jumbo packets 0 storm suppression packets
0 runts 0 giants 0 CRC/FCS 0 no buffer
0 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
TX
76 unicast packets 89 multicast packets 0 broadcast packets
89 output packets 19394 bytes
0 jumbo packets
0 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause
N7K-3-c1# show int e4/31 tran details
Ethernet4/31
transceiver is present
type is 1000base-SX
name is CISCO
part number is FTLF8519P3BNL-CS
revision is A
serial number is FNS17371AE5
nominal bitrate is 1300 MBit/sec
cisco id is --
cisco extended id number is 4
cisco part number is 10-2626-01
cisco product id is GLC-SX-MMD
cisco vendor id is V01
number of lanes 1
SFP Detail Diagnostics Information (internal calibration)
----------------------------------------------------------------------------
Current Alarms Warnings
Measurement High Low High Low
----------------------------------------------------------------------------
Temperature 38.44 C 90.00 C -10.00 C 85.00 C -5.00 C
Voltage 3.30 V 3.59 V 3.00 V 3.50 V 3.09 V
Current 7.13 mA 15.00 mA 1.00 mA 12.00 mA 2.00 mA
Tx Power -5.11 dBm 0.00 dBm -13.49 dBm -2.99 dBm -9.50
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(14)FB(0.64) |
|
|
| |
| |
Bug Id: | CSCur07245 |
Title: | Nexus switch may see repeated crashes of ntpd process |
|
Description: | Symptom:
NTP process may crash repeatedly on a Nexus switch.
Nexus7010# sh core
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
1 5 1 ntpd 19361 2015-01-31 05:18:22
1 5 1 ntpd 19348 2015-01-31 05:18:22
1 5 1 ntpd 19096 2015-01-31 05:18:22
1 5 1 ntpd 21817 2015-01-31 05:30:25
1 5 1 ntpd 21201 2015-01-31 05:31:20
1 5 1 ntpd 21196 2015-01-31 05:31:20
1 5 1 ntpd 21188 2015-01-31 05:31:20
1 5 1 ntpd 21208 2015-01-31 05:31:21
In some cases the cores may not be properly bundled and will pile up in the /var/sysmgr/tmp_logs directory. This may result in messages similar to the following:
2015 Mar 28 00:34:06.644 Switch %SYSMGR-3-VAR_SYSMGR_FULL: System Manager file storage usage is unexpectedly high at 100%. This may impact system functions.
2015 Mar 28 00:40:29.912 Switch %SYSMGR-2-CORE_SAVE_FAILED: zip_copy_file_to_logflash: PID 24109 with message Failed to copy 0x1201_ntpd_core.30892 to logflash. Error file
error (srcerr 0x0 dsterr 0x807b001c) .
2015 Mar 28 00:40:30.057 Switch %SYSMGR-2-CORE_SAVE_FAILED: zip_copy_file_to_logflash: PID 24109 with message Failed to copy 0x1201_ntpd_core.30914 to logflash. Error file
error (srcerr 0x0 dsterr 0x807b001c) .
2015 Mar 28 00:40:30.463 Switch %SYSMGR-3-CORE_OP_FAILED: Core operation failed: core_client_run_system_cmd: Command: /isan/bin/sysmgr_logmgr /var/sysmgr/tmp_logs 0 1>> /var/sysmgr/core_handling.log failed wi
Conditions:
This has been observed on Nexus 5000, 6000, and 7000 series switches.
It is more likely to occur if the device is being polled via IPv6 NTP requests. However, this also affects IPv4-only configurations.
It may also be more likely to occur if an unreachable NTP peer is configured.
Workaround:
If either of the above two conditions are present in the configuration (IPv6 NTP polling, or an unreachable NTP peer) then removing these may make the crash less likely to occur.
However, the only guaranteed workaround would be to disable the NTP feature completely (remove all NTP configuration from the affected switch).
Further Problem Description:
This problem occurs due to memory corruption in a receive buffer in memory which is used by NTP. NTP will crash repeatedly after the corruption occurs.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.25), 7.0(7)ZN(0.108), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(1)N1(0.495), 7.1(1)N1(1), 7.1(1)ZN(0.48), 7.2(0)AB(9) |
|
|
| |
| |
Bug Id: | CSCuu69821 |
Title: | Issue in configuring persistent logging and utilization alert |
|
Description: | Symptom:
Due to this bug user will not be able to configure "utilization-alert" and would observe below message popping on the screen.
"Exceeded persistent logging utilization threshold limit. Please cleanup old logs and try again !!"
Conditions:
User can configure Max 10 files each of it can be of Max 4MB. So there will actually be 11 file (10 backup and 1 current). In general there will always be 1 more file besides what user configures. Due to this bug user will not be able to configure utilization alert IFF, ((fileno+1)*filesize*utilization-alert) exceeds MAX value of INT32.
For example, lets assume fileno = 10, filesize = 4194304(4MB), utilization alert = 50%.
Now ((10+1)*4MB*50 = 2,306,867,200 )which is greater thanINT32_MAX value (2,147,483,647)
Workaround:
Any combination of ((fileno+1)*filesize*utilization-alert) which is less than INT32_MAX(2,147,483,647)
For Example, (fileno = 10, filesize = 4MB, utilization alert = 45%)
((10+1)*4194304*45 = 2076180480)
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.1), 7.2(1)PIB(0.11) |
|
|
| |
| |
Bug Id: | CSCuu90608 |
Title: | nvt: mcecm and vpc cores on doing a cold boot from S22 to S28 |
|
Description: | Symptom:
vPC process crashes
Conditions:
no graceful type-1 check configured and switch reloads
Workaround:
turn on graceful type-1 check by default
Further Problem Description:
This is memory overrun issue.
The issue is only hit when graceful type-1 check is disable. Because from 6.2.10, the check is enabled by default, we decided to fix after GBR.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut93487 |
Title: | OTV: AED stays inactive for all VLANs |
|
Description: | Symptom:
One AED stays inactive for all VLANs
Conditions:
Using OTV with 2 AEDs
Workaround:
Remove the vlans that won't come up and add them back to the OTV vdc.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo51846 |
Title: | N7K: 3rd party SFP-10G-SR reported as "Unsupported transceiver" |
|
Description: | Symptom:
3rd-party SFP-10G-SR reported as "Unsupported transceiver":
ETHPORT-3-IF_UNSUPPORTED_TRANSCEIVER Transceiver on interface Ethernet2/1 is not supported
To verify if its the same issue
module-7# sh hard int transceiver ins 0 sprom raw
+-------------------------------------------------------------------------------
| Get sprom/dom data for XCVR_USD Driver
SPROM in raw format:
-------------------
Comment Addr Value
------- ---- -----
Identifier 0 03
Ext. Identifier 1 04
Connector Type 2 07
10G Ethernet Compliance Code 3 00
ESCON/SONET Compliance Code 4 00 00
Ethernet Compliance Code 6 00
Transceiver (Fibre Channel) 7 40 >>>>> Having 7,8 and 9th bytes programmed with any non-zero number will result in this bug.
Transceiver (Fibre Channel) 8 40
Transceiver (Fibre Channel) 9 0c
Transceiver (Fibre Channel) 10 80
Conditions:
This is observed on a Nexus 7000 or 7700 port running a 6.2(8) release.Its not seen in any other releases
before 6.2.8 . Its fixed in 6.2.10
It is applicable for all LCs and only affects some of the 3rd party transceivers.
Workaround:
Use a Cisco Transceiver.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.4), 6.2(8)E1, 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.12)S0, 6.2(8a)E2 |
|
|
| |
| |
Bug Id: | CSCup89391 |
Title: | SNMP process crash |
|
Description: | Symptom:
SNMP crash causing device reload
Conditions:
N/A
Workaround:
- use SNMPv2 instead SNMPv3
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-JUN-2015 |
|
Known Affected Releases: | 5.2(8b), 6.2(8) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut08818 |
Title: | SNMPD crashes with role with only deny OIDs |
|
Description: | Symptom:
If the SNMP community name is associated with a role which has only a deny OID will cause SMNP to unexpectedly write out a core file when polled with a SNMP bulk request. If multiple SNMP crashes occur then the SUP will switchover and the SNMP configuration will be lost.
Conditions:
The N7K is configured with SNMP and a role which only denies OIDs.
Workaround:
For the configured role add in a permit OID.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(8a), 6.2(9a) |
|
Known Fixed Releases: | 6.2(14)FB(0.63), 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.1(2)N1(0.548), 7.1(2)ZD(0.6), 7.1(2)ZN(0.7), 7.2(0)D1(0.492), 7.2(0)D1(1), 7.2(0)N1(0.187), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuv05083 |
Title: | Vlan learnt SGT mappings not downloaded to HW after module comes online |
|
Description: | Symptom:
On a nexus 7000 series switches, IP to DGT mappings, may not be honored for vlan learnt SGT mappings following a supervisor switchover and a module reload.
Conditions:
Workaround:
clear ip arp x.x.x.x force
will allow the switch to correct the IP-SGT binding .
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtw72949 |
Title: | Slow drain of udp sock mts buffers for some bulk requests in bridge-mib |
|
Description: | Symptom:
On nexus 7000 series switch, polling at a sustained rate certain objects from
bridge-mib may cause a relatively high cpu for snmpd for some time after polling and new requests to time out.
On pre 5.2 NX-OS versions, this polling may cause internal messages for inter
process communications to be queued and affect other services.
This problem is also observed on Nexus 5xxx switch running 5.2 release. The fix
for this issue is in 5.2(1)N1(4) release of the 5k and 6.0(2)N1(2a) and later releases.
Conditions:
A large amount of SNMP access to the device against BRIDGE-MIB
Workaround:
Reduce the amount of SNMP traffic to a acceptable level.
If using Orion or Solarwinds Network Management Server uncheck option
Topology: L2.
Further Problem Description:
Problem exists in 5.2(1-3), 6.0(x) and earlier releases on Nexus 7000 switch.
Fixes had been integrated in 5.2(4), 6.1(1), 6.2(2) and later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 5.1(4), 5.2(1), 6.2(0.1) |
|
Known Fixed Releases: | 5.2(1)N1(4), 5.2(4)S3, 5.2(4.10)S0, 5.2(4.4)S0, 6.0(2)N1(2a), 6.0(2)N2(1), 6.0(2)U3(0.599), 6.0(2)U3(1), 6.1(0.205)S0, 6.1(0.209)S0 |
|
|
| |
| |
Bug Id: | CSCur17440 |
Title: | snmpwalk on cpmCPUTotalTable(1.3.6.1.4.1.9.9.109.1.1.1) failing |
|
Description: | Symptom:
On nexus 5500/6000 series switches, snmpwalk on 1.3.6.1.4.1.9.9.109.1.1.1( cpmCPUTotalTable) does not return the expected objects.
Conditions:
This is seen with 7.1 train, the issue does not exist with previous trains such as 7.0
Workaround:
An snmpget to the object will work, for instance to 1.3.6.1.4.1.9.9.109.1.1.1.1.8.1 for cpmCPUTotal5minRev
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.1(1)N1(0.8) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu66415 |
Title: | VINCI UI: ethpm receiving an empty vlan list from vlan_mgr |
|
Description: | Symptom:
vlan_mgr sends notifications to ethpm with empty interest list
Conditions:
happens during bridge-domain create
Workaround:
this has no operational impact
Further Problem Description:
this is an interaction between vlan_mgr and ethpm. the empty list becomes a NOP for ethpm and this has no impact on operation or functionality
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.2), 7.2(1)ZD(0.2) |
|
|
| |
| |
Bug Id: | CSCur97641 |
Title: | MPLS QoS:Show policy is showing Pkt count 0 where byte count is proper |
|
Description: | Symptom:
Sometimes when egress policy-map is applied to a VLAN, the "packets" count will not increment in "show policy map vlan"
N7K-1# sh policy-map vlan 100
***SNIP***
Class-map (qos): test (match-any)
Aggregate forwarded :
0 packets 82687055970 bytes <----bytes increment but packets don't
Conditions:
egress policy-map applied on vlan
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(8a), 7.1(0)D1(0.328) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.65), 7.1(0)AV(0.38), 7.2(0)D1(0.402), 7.2(0)D1(1), 7.2(0)OTT(0.5), 7.2(0)PDB(0.332) |
|
|
| |
| |
Bug Id: | CSCut03089 |
Title: | After ISSU from 6.2.10 to 6.2.12 Optical Modules doesn't show DOM info |
|
Description: | Symptom:
On N7K running 6.2.12 code, some of the DWDM optical modules will not show DOM info.
Example Output.
switch-core# sh int e1/25 trans de
Returning from 1
unknown error 0x40290003
Ethernet1/25
transceiver is present
type is DWDM-SFP10G-35.04
name is CISCO-FUJITSU
part number is FIM35060/201W53
revision is 0002
serial number is FLJ1718K016
nominal bitrate is 11100 MBit/sec
Link length supported for 9/125um fiber is 80 km
cisco id is --
cisco extended id number is 4
cisco part number is 10-2779-01
cisco product id is DWDM-SFP10G-35.04
cisco vendor id is V01
switch-core#
Conditions:
This behavior is seen only after ISSU from 6.2.10 to 6.2.12 on DWDM optical modules.
This behavior is not seen while performing traditional code upgrade from 6.2.10 to 6.2.12
Workaround:
Problem is not seen after traditional code upgrade from 6.2.10 to 6.2.12
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.20), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.439), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.365), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCus90226 |
Title: | 6.2.12: Route programming inconsistency between instances on a LC |
|
Description: | Symptom:
When the port-channel configured with LACP individual and shut and no shut of VPC or port-channel will trigger
Conditions:
LACP Individual configured on the port-channel
Workaround:
Remove the LACP Individual config for the Port-channel
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E2, 6.2(13.3)S0, 6.2(14)FB(0.4), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.430), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.358), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCuq46564 |
Title: | SSTE:LDP core observed after process restart LDP with 7.1(0)D1(0.232) |
|
Description: |
Symptom:
LDP crashes due to heartbeat failure following a proc restart of LDP.
Conditions:
Happens when user does a proc restart of LDP.
Workaround:
No workaround.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.232) |
|
Known Fixed Releases: | 6.2(10)E5, 6.2(13.3)S0, 6.2(14)FB(0.65), 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)OTT(0.45), 7.2(0)D1(0.417) |
|
|
| |
| |
Bug Id: | CSCuf47376 |
Title: | Trunk/FEX FPC port config removed by "system def switchport fabricpath" |
|
Description: | Symptom:
adding/removing 'system default switchport fabricpath' cli seems to affect the configuration of trunks/access/fex fabric ports.
On a system with this command, a disruptive upgrade/reload might also cause config issues
Conditions:
adding/removing 'system default switchport fabricpath' cli / reload/disruptive upgrade with this command
Workaround:
If reload/disruptive upgrade has to be done, take a config backup first to restore
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.37), 7.1(0)AV(0.38), 7.1(0)PDB(0.324), 7.2(0)D1(0.392), 7.2(0)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCut68515 |
Title: | SSTE: multiple port-profile cores with 7.2(0)D1(0.456) on autoconfig |
|
Description: | $$IGNORE
Symptom:
port-profile crash & switch hap reset.
Conditions:
auto config
Workaround:
NA
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.456), 7.2(0)D1(0.490) |
|
Known Fixed Releases: | 7.0(0)HSK(0.474), 7.1(0)AV(0.81), 7.2(0)D1(0.499), 7.2(0)D1(0.506), 7.2(0)D1(0.509), 7.2(0)D1(1), 7.2(0)ZD(0.188), 7.2(1)PIB(0.14), 7.3(0)D1(0.21) |
|
|
| |
| |
Bug Id: | CSCuu02941 |
Title: | linecard crashing due to clp_fwd hap reset |
|
Description: | Symptom:
N7K-SM-NAM-K9 and LCs with less than 12 instances of Clipper will have their clp_fwd process crash when the system has Fex with L2 mcast is active. I.e. when the Fex ports are flapped or when the LC itself is reloaded, then clp_fwd will crash.
Conditions:
The issue happens when we boot the module on 6.2(10)
Workaround:
None
Further Problem Description:
l2mcast assumes that in every line card 12 Forwarding instances are available. With this assumptions, when it sends a message to clp_fwd driver, the clp_fwd driver does not handle this error correctly. Hence, crash.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.43), 6.2(14)FB(0.47), 7.1(0)AV(0.81), 7.2(0)D1(0.494), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.176), 7.3(0)IB(0.19), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCus94535 |
Title: | SNMP crash during OIR of transceiver and walk ciscoEntitySensorMIB |
|
Description: | Symptom:
SNMP may crash on a Nexus 7000 switch during OIR of 1G, 10G, 40G DOM capable transceiver.
Conditions:
Process snmpd dumps core when the following steps are met:
1. SNMP walk CISCO-ENTITY-SENSOR-MIB when a DOM capable transceiver is inserted.
2. Remove the DOM capable transceiver
3. SNMP walk CISCO-ENTITY-SENSOR-MIB again
Workaround:
1. Insert any transceiver back to the port
2. Once snmpd crashed, the newly started snmpd will not have the issue
unless the steps described in "Conditions" happen again.
3. Disable SNMP walk for CISCO-ENTITY-SENSOR-MIB
Further Problem Description:
Problem exists in 6.2(12) only.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.3), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.422), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.352), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCuu27816 |
Title: | IPv6 prefixes of OSPFv3 interfaces not present in intra-area-prefix LSA |
|
Description: | Symptom:
IPv6 prefixes of interfaces part of OSPFv3 not present in intra-area-prefix LSA.
Conditions:
Interfaces without adjacency can run into this problem after interface flap or VDC reload
Workaround:
Use "redistribute direct" instead of configuring the interfaces in OSPFv3 if possible.
Further Problem Description:
Recovery is via clear ospfv3 neighbors.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.499) |
|
Known Fixed Releases: | 7.0(0)HSK(0.474), 7.1(0)AV(0.81), 7.2(0)D1(0.511), 7.2(0)D1(1), 7.2(0)N1(0.209), 7.2(0)N1(1), 7.2(0)ZD(0.191), 7.2(0)ZN(0.209), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCut49944 |
Title: | sw reload would put range of private-vlan are STP blocked state |
|
Description: | Symptom:
sw reload its observed that range of private-vlan are STP blocked state
Conditions:
sw reload its observed that range of private-vlan are STP blocked state
Workaround:
workaround : realod of LC
Further Problem Description:
sw reload its observed that range of private-vlan are STP blocked state
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.72), 7.2(0)D1(0.444) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.65), 7.1(0)AV(0.81), 7.2(0)D1(0.504), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.184), 7.2(1)PIB(0.14), 7.3(0)IB(0.19), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCuu10841 |
Title: | NXOS RPM crash due to the CLI "show ip prefix-list | xml" |
|
Description: | Symptom:
%SYSMGR-2-SERVICE_CRASHED: Service "rpm" (PID 4664) hasn't caught signal 11 (core will be saved).
Conditions:
In NXOS code 6.2.(12), running CLI "show ip prefix-list | xml" will cause RPM crash in case the prefix-list is not existing.
Workaround:
TBD
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E6, 6.2(13.3)S0, 6.2(14)FB(0.57) |
|
|
| |
| |
Bug Id: | CSCut96140 |
Title: | 6.2.12: L2 port channels not programmed correctly in LACP INDI |
|
Description: | Symptom:
Port configured as LACP individual mode.
ELTM does not have the PC member in the database after port becoming part of port-channel.
"show system internal eltm info interface port-channel xyx" does not contain all the PC members.
Conditions:
L2 port-channel with LACP Individual mode
Workaround:
Flap port-channel members which is not added to the PC member
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E5, 6.2(13.3)S0, 6.2(14)FB(0.36), 7.1(0)AV(0.74), 7.2(0)D1(0.485), 7.2(0)D1(1), 7.2(0)ZD(0.167), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCut43602 |
Title: | NXOS/VLAN: VLAN_MGR crash when large size of ranges are used in config |
|
Description: | Symptom:
vlan_mgr continue crash due to heartbeat failure during system boot (or VDC boot)
Conditions:
Problem happen only when string length of the vlan range in vlan configuration is larger than 4096 (including commas and dash in configuration)
Workaround:
Reduce vlan range such that the vlan representation string is size smaller than 4096
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.22), 7.0(3)I1(1.226), 7.0(3)I1(2), 7.0(3)IX1(1.93), 7.0(3)IX1(2), 7.1(0)AV(0.74), 7.2(0)D1(0.459), 7.2(0)D1(1), 7.2(0)PDB(0.381) |
|
|
| |
| |
Bug Id: | CSCup66750 |
Title: | BGP routes not advertised after "default address-family ipv4/6 unicast" |
|
Description: | Symptom:
Nexus 7k running with version 6.1.5 and 6.2.8 stops advertising the routes to neighboring peer as soon "default address-family ipv4/6 unicast" is issued under the neighbor statement.
router bgp xxxx
csw06d.lla1(config-router)# neighbor 10.46.177.47
csw06d.lla1(config-router-neighbor)# default address-family ipv6 unicast
csw06d.lla1(config-router-neighbor)# default address-family ipv4 unicast
end
Conditions:
Happens only when "default address-family ipv6 unicast" is issued under the neighbor statement for BGP.
Workaround:
Clear ip bgp soft * resolves the issue.
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.1(5) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.39), 7.0(3)I2(0.406), 7.0(3)I2(1) |
|
|
| |
| |
Bug Id: | CSCut21667 |
Title: | MIM header for F2 F2E F3 vdc type needs to be stripped |
|
Description: | Symptom:
Arp is incomplete for hosts on F3 LC
Control plane pkts going from fex connected hosts to CPU maybe dropped and not reaching SUP.
Conditions:
VDC is F2, F2E and F3 vdc type , but there is no F2 line card in vdc or chassis at all.
Have more number of links as part of port-channel towards Fex (FPC) than per port-channel towards host (HIFPC).
Workaround:
Flap Fabric port-channel and configure less or equal number of links in FPC as compared to the HIFPC.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8), 6.2(8a) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.17), 7.1(0)AV(0.74), 7.2(0)D1(0.453), 7.2(0)D1(1), 7.2(0)PDB(0.375), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCut50838 |
Title: | M2 VLAN Translation Not Translating Non-Native VLAN BPDUs |
|
Description: | Symptom:
Ingress non local VLAN BPDUs are dropped as "igr ifc: total pkts dropped due to cbl? and egress BPDUs are not tagged with translated VLAN causing both devices to see them self as spanning-tree root for translated VLAN
Conditions:
When VLAN translation is configured on N7K-M224XP-23L
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(8a) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.65) |
|
|
| |
| |
Bug Id: | CSCut06258 |
Title: | F1 card MTM misprogramming on "VLAN UP/Down" event |
|
Description: | Symptom:
MAC are not learned in HW on F1 card. From SUP , show mac address-table shows correct info, but show hardware mac address-table X for module X - is incorrect.
Affects on per VLAN/per port-pair basis (e.g. port-pairs are : 1,2 ; 3,4; ... 31,32. and some of them may stop learning MACs on some of the VLANs)
This lead to Unknown Unicast Flood scenario
Conditions:
shut/no shut of VLAN on a busy system (especially on many VLANs simultaneously). Removing and adding many VLANs at once.
Workaround:
Reload affected module
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E2, 6.2(13.3)S0, 6.2(14)FB(0.21), 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.2(0)D1(0.493), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.175), 7.3(0)IB(0.19) |
|
|
| |
| |
Bug Id: | CSCus54220 |
Title: | Service not responding when attaching ACLs to many SVIs at the same time |
|
Description: | Symptom:
This was found when verifying CSCur31394. Service not responding followed by router crash occurs when applying ACLs to many SVIs at the same time. (1000 SVIs and 140 port-channels) Details are shown in the attached log.
Conditions:
This happened when ACL is applied to large number of SVIs.
Workaround:
Apply ACL config in smaller chunks, for example:
interface vlan 1-100
ip access-list X
Further Problem Description:
Is it a duplicate of CSCur31394?
Probably not.
it might be moved to Aclmgr to either reduce the number or increase their memlimit.
It's not the same problem of CSCur31394, other than mem exhaustion.
But at a totally different point in code.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S102, 6.2(12)FT(0.26), 6.2(12)S21, 6.2(12)S25, 6.2(12)S31 |
|
Known Fixed Releases: | 6.2(12)E2, 6.2(13.3)S0, 6.2(14)FB(0.3), 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.0(3)I1(1.213), 7.0(3)I1(2), 7.0(3)ISH1(2), 7.0(3)ISH1(2.13), 7.0(3)IX1(1.93) |
|
|
| |
| |
Bug Id: | CSCus99375 |
Title: | OTV crashes with vlan process in crash core |
|
Description: | Symptom:
OTV crashes with vlan process in crash core
Conditions:
Unknown
Workaround:
Unknown
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(8.1) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.63) |
|
|
| |
| |
Bug Id: | CSCun50901 |
Title: | Service (FEX) "satctrl" (PID 1723) hasn't caught signal 9 (no core) |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
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) |
|
|
| |
| |
Bug Id: | CSCut14381 |
Title: | Inproper 16 way ECMP hasing with IPv6 traffic |
|
Description: | Symptom:
Traffic for the destination which is reachable via IPv6 ECMP with unresolved paths will experience traffic loss.
Conditions:
IPv6 adjacency for some of the ECMP next hop is in unresolved state
Workaround:
Execute the command "ping6" for each of the affected IPv6 ECMP next hop to get the ECMP next hop in resolved state.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S102, 7.2(0)D1(0.493) |
|
Known Fixed Releases: | 6.2(10)E7, 6.2(12)E1, 6.2(12)E2, 6.2(13.3)S0, 6.2(14)FB(0.8), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.439), 7.2(0)D1(1), 7.2(0)FM(0.3) |
|
|
| |
| |
Bug Id: | CSCut13349 |
Title: | EIGRP hap reset seen on primary vpc+ switch with Janjuc build 111 |
|
Description: | Symptom:
This issue is seen on L3 over Fabricpath testbed. N64P switches are vpc+ peers. P2 is primary and P1 is secondary.
Fwm reset happened on P1 (vpc secondary) and switch went for a reload. All the L3 protocols between P1 and P2 went down. Around 3 minutes later primary vpc switch (P2) went down due to eigrp hap reset.
No triggers executed this time. Switch was left idle with traffic on for around 12 hours. Then the fwm crash was seen on secondary switch and few minutes later eigrp hap reset was seen on primary vpc+ switch.
Conditions:
Eigrp hap reset seen
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.409), 7.2(0)N1(0.111) |
|
Known Fixed Releases: | 7.0(0)HSK(0.474), 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)N1(0.213), 7.2(0)N1(1), 7.2(0)ZD(0.194), 7.2(0)ZN(0.213), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCug39011 |
Title: | N7K: F2 may reset in case of receiving excessive error frames |
|
Description: | Symptom:
A faulty F2 module may cause resetting other multiple F2 modules
within the chassis.
Conditions:
very rare condition. the faulty F2 module may send out excessive error
frames to other F2 modules.
Workaround:
Module reload to recover. Isolate the faulty module and remove from the chassis.=
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | 6.2(10)E7, 6.2(10)E8, 6.2(13.3)S0, 6.2(14)FB(0.34), 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.2(0)D1(0.482), 7.2(0)VZD(0.26), 7.2(0)ZD(0.162), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCut06852 |
Title: | N7K - BGP using set metric-type internal under RM not triggering update |
|
Description: | Symptom:
The 'set metric-type internal' route-map configuration command causes BGP to advertise a MED that corresponds to the IGP metric associated with the next hop of the route
This command doesn't work properly in 6.1(4a), 6.2(12)
Whenever that command is applied to an BGP peer and there is change in the IGP cost of multiple ECMP in sequence, we don't always send an update to the peer with the new cost, so the eBGP neighbor is left with the old incorrect MED.
Conditions:
eBGP peering using an outbound route-map with 'set metric-type internal' and IGP cost change on multiple interfaces (ECMP) in sequence, ie
configure terminal
interface Eth1/1 ; ip ospf cost 1000
...
interface Eth1/8 ; ip ospf cost 1000
end
--
N7K# show ip bgp 10.39.176.0/21
10.38.0.5 (metric 1000) from 10.38.0.5 (10.38.0.5) << metric 1000 from above change IGP
Origin IGP, MED not set, localpref 100, weight 0
--
eBGP-peer# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>e10.39.176.0/21 100.65.97.64 2001 0 64801 i <<< metric 2001 is not refreshed
--
Workaround:
Use interface range:
configure terminal
interface Eth1/1 - 8
ip ospf cost 1000
end
Further Problem Description:
Note a soft bgp reset will trigger an update with correct MED
N7K# clear ip bgp 100.65.97.65 soft out
eBGP-peer# sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*>e10.39.176.0/21 100.65.97.64 1000 0 64801 i <<< metric 1000 correct
This bug is fixed from 6.2(14) onwards in 6.2 release.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.1(4a), 6.1(4a)E1, 6.2(12), 7.2(0)D1(0.406) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.25), 7.0(3)I1(1.211), 7.0(3)I1(2) |
|
|
| |
| |
Bug Id: | CSCuu93248 |
Title: | IPFIB core due to SW index leak in MFIB for F3 modules |
|
Description: | Symptom:
On a nexus 7000/7700 series switch, ipfib service may reset on a linecard as indicated by the following log in the main vdc :
%SYSMGR-SLOT4-2-SERVICE_CRASHED: Service "ipfib" (PID 1200) hasn't caught signal 6 (core will be saved).
Conditions:
This can possibly be seen when there has been a significant number of adjacencies updates on the system.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.79) |
|
|
| |
| |
Bug Id: | CSCur22627 |
Title: | 6210::Seeing EIGRP flap after SSO with authentication |
|
Description: | Symptom:
EIGRP neighborship flap after SSO due to Auth failure on the peer
Conditions:
EIGRP authentication is configured on the interface
Workaround:
Disable authentication
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S98, 6.2(10)S99, 7.1(0)ZD(0.95) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.44), 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)ES(0.7), 7.1(0)SIB(99.92), 7.2(0)AB(2), 7.2(0)BA(0.12), 7.2(0)D1(0.392) |
|
|
| |
| |
Bug Id: | CSCue11653 |
Title: | LC Reset due to LM_INT_CL1_TCAM_B_PARITY_ERR or LM_INT_L3_TCAM_PARITY |
|
Description: | Symptom
All the below three symptoms should be seen.
1. SYSMGR-SLOT8-2-SERVICE_CRASHED: Service "lamira_usd" (PID 1944) hasn't caught signal 6 (core will be saved).
2. In "show logging onboard mod 2 exception-log"
----------------------------
Module: 2
----------------------------
Exception Log Record : Mon Mar 4 11:25:32 2013 (602696 us)
Device Id : 81
Device Name : Lamira
Device Error Code : c5101210(H)
Device Error Type : ERR_TYPE_HW
Device Error Name : NULL
Device Instance : 1 <----- this should be 1
Sys Error : Generic failure
Errtype : INFORMATIONAL
PhyPortLayer : Ethernet
Port(s) Affected :
Error Description : LM_INT_CL1_TCAM_B_PARITY_ERR <---------!
DSAP : 211
UUID : 382
Time : Mon Mar 4 11:25:32 2013
(602696 usecs 513484AC(H) jiffies)
or
----------------------------
Module: 2
----------------------------
Exception Log Record : Mon Mar 4 11:25:32 2013 (602696 us)
Device Id : 81
Device Name : Lamira
Device Error Code : c5101210(H)
Device Error Type : ERR_TYPE_HW
Device Error Name : NULL
Device Instance : 1 <---------- this should be '1'
Sys Error : Generic failure
Errtype : INFORMATIONAL
PhyPortLayer : Ethernet
Port(s) Affected :
Error Description :LM_INT_L3_TCAM_PARITY <---------!
DSAP : 211
UUID : 382
Time : Mon Mar 4 11:25:32 2013
(602696 usecs 513484AC(H) jiffies)
3. Attach to linecard, and check this.
show logging onboard internal lamira
You will see something like this below.
ACLQOS: STAT Register Scan - No Correctable Error Found
or
IPFIB: STAT Register Scan - No Correctable Error Found
If all the above are seen the issue is that software reset the linecard due to an error in handling parity interrupt.
Symptom:
Conditions:
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 5.1(5), 6.0(4), 6.1(2) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S59, 5.2(9)S60, 5.2(9)S66, 5.2(9.107)S0, 5.2(9.115)S0, 5.2(91.1)S0, 6.1(4), 6.1(4)S3, 6.1(4)S5 |
|
|
| |
| |
Bug Id: | CSCut28707 |
Title: | stale/no MAC on Hw of F1 as FE not programmed on MTM due to DFTM |
|
Description: | Symptom:
Unicast flooding or traffic blackhole if the MAC is not programmed or programmed with wrong index respectively.
Conditions:
F1 module.
Workaround:
remove the affected ports from PC and add it back.
or
reload module
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.19), 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.2(0)D1(0.493), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.175), 7.3(0)IB(0.19), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCua43329 |
Title: | N7k - sysmgr crash - Service (FEX) "lacp" without core file generated |
|
Description: | Symptom:
A Nexus 2000 may crash when is receives a PDU larger than it expects.
Conditions:
This sill only be seen on a Nexus 2000 connected to a Nexus 7000. Nexus 2000
connected to Nexus 5000 are not effected.
Workaround:
None at this time.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.0(1) |
|
Known Fixed Releases: | 5.2(4)FD(0.21), 5.2(6.7)S0, 5.2(7), 6.1(0)FE(0.17), 6.1(1)S21, 6.1(1.20)S0, 7.0(2)FIP(0.4), 7.1(0)FGI(0.3), 7.3(0)FH(0.2) |
|
|
| |
| |
Bug Id: | CSCuu70292 |
Title: | N7000 iftmc crash after applying vacl redirect |
|
Description: | Symptom:
IFMTC crash when applying VACL redirect when the port is down
Conditions:
VACL redirect applied in the port which is down.
or
After applying VACL redirect, reload LC of the redirected port.
Workaround:
Remove the VACL redirect and reload the LC
Bringup the port before applying the VACL redirect policy.
Before reload LC, the VACL redirect policy must be removed.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.70), 7.2(0)D1(1.20), 7.2(0)ZD(0.226), 7.2(1)PGB(0.2) |
|
|
| |
| |
Bug Id: | CSCus62502 |
Title: | OTV Tunnel Depolarization causes traffic loss when some tunnels are down |
|
Description: | Symptom:
if OTV Tunnel Depolarization is implemented, traffic will be dropped when several OTV tunnels down
Conditions:
none
Workaround:
none
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.63) |
|
|
| |
| |
Bug Id: | CSCuu53826 |
Title: | MPLS QoS : not enough memory after vdc suspend/resume |
|
Description: | Symptom:
*With more 50% of aggregate policer usage and subinterface configuration, an vdc reload or suspend/resume event will trigger this issue.
Conditions:
*vdc suspend
no vdc suspend
reload vdc
Workaround:
*reload the module.
Further Problem Description:
*
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.65) |
|
|
| |
| |
Bug Id: | CSCut36425 |
Title: | F3 in FP transit mode - All traffic drop due to ports in CE mode |
|
Description: | Symptom:
All traffic is dropped on whole LC for various reasons - CBL drop, MIM on edge port etc - depending on interface configuration.
Conditions:
Issue can only on VDC/device in FabricPath in transit mode "fabricpath mode transit"
After removing the port-channel from the VPC configuration, the configuration is not wiped out in the LC.
Later when the Port-channel is used for any non-VPC configuration traffic is dropped.
Workaround:
Option 1 : Reload affected module
Option 2: Delete port-channel after making it non-VPC and then add the port-channel.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.20), 7.1(0)AV(0.74), 7.2(0)D1(0.459), 7.2(0)D1(1), 7.2(0)PDB(0.382) |
|
|
| |
| |
Bug Id: | CSCus91417 |
Title: | Nexus 7000 fails to trasmitt RSTP BPDUs consistently |
|
Description: | Symptom:
STP Instability in layer 2 domain with N7K (Rapid PVST)
Conditions:
unknown
Workaround:
enable peer-switch if N7K is the root to mitigate this issue
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12)S33 |
|
Known Fixed Releases: | 6.2(12)E1, 6.2(13)FM(0.52), 6.2(13)GS(0.13), 6.2(13.1)S0, 6.2(13.3)S0, 6.2(14)FB(0.21), 7.1(0)AV(0.74), 7.2(0)D1(0.453), 7.2(0)D1(1), 7.2(0)PDB(0.378) |
|
|
| |
| |
Bug Id: | CSCuu38580 |
Title: | 7.2.0.506.S2 UI - congestion on F2 LC after vdc reload |
|
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:
Workaround1(preferred as less traffic interrupt):
Copy the Applied network QoS Template:
1) find the applied tempalte
show policy-map system
Type network-qos policy-maps
============================
policy-map type network-qos default-nq-8e-policy template 8e
class type network-qos c-nq-8e
match cos 0-7
congestion-control tail-drop threshold burst-optimized
mtu 1500
2) Copy:
qos copy policy-map type network-qos default-nq-8e-policy prefix Copy_
3) Apply Ciopy to trigger reporgramming:
switch(config)# system qos
switch(config-sys-qos)# service-policy type network-qos Copy_nq-8e
4) Optional: Reapply back the previous template
switch(config)# system qos
switch(config-sys-qos)# service-policy type network-qos default-nq-8e-policy
Note: Applicable for any networkqos template. During Template Change traffic on All VDC which contain F cards will be disrupted for less than a Second
Workaround2: reload the LC after ISSU or
Workaround3: reload the LC after VDC reload
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.506) |
|
Known Fixed Releases: | 7.0(0)HSK(0.474), 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)ZD(0.202), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCut75457 |
Title: | HSRP VACL Filter Broken |
|
Description: | Symptom:
HSRP hello is passing through device with VACL in place to drop these packets.
Conditions:
6.2(10) or 6.2(12)
Workaround:
None.
Further Problem Description:
This behavior is seen in 6.2(10) and 6.2(12). It is not seen in 6.2(8b).
A similar issue relating to PACL filtering HSRP packets fixed in 6.2(12): CSCur69114
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.66) |
|
|
| |
| |
Bug Id: | CSCut57953 |
Title: | N7K "ipfib" process crash |
|
Description: | Symptom:
N7K line card crash with "ipfib" core file generated.
Conditions:
crash observed on N7K running ospfv3 on 6.2.12 code
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.58) |
|
|
| |
| |
Bug Id: | CSCut19573 |
Title: | some vpc portchannels are not up upon RAX config |
|
Description: | Symptom:
When the port-channel configured with LACP individual and shut and no shut of VPC or port-channel will trigger. Extented fix for CSCus90226
Conditions:
LACP Individual configured on the port-channel
Workaround:
Remove the LACP Individual config for the Port-channel
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12)E2 |
|
Known Fixed Releases: | 6.2(12)E2, 6.2(13.3)S0, 6.2(14)FB(0.11), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.442), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.368), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCut23557 |
Title: | N7K platform: netstack crash while saving tech-support in bootflash |
|
Description: | Symptom:
The netstack process on a Nexus 7000 switch running 6.2(8a) may unexpectedly crash while collecting a 'show tech' and redirecting it to bootflash
Conditions:
saving tech-support in bootflash
Workaround:
please do not save "show-tech" to bootflash.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a)S2 |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.28), 7.0(0)HSK(0.433), 7.2(0)D1(0.479), 7.2(0)D1(1), 7.2(0)ZD(0.159), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCus49797 |
Title: | Inter-Op BGP issue between N7K and juniper device |
|
Description: | Symptom:
6PE BGP peering establishes. After that, Juniper device sends a notification message saying that Cisco Nexus sent a non-negotiated IPV6 unicast update packet and tears down the BGP session.
Conditions:
6PE BGP session between N7k and Juniper device.
Workaround:
No known workarounds.
Further Problem Description:
The IPv6 unicast packets sent by NX-OS are due to backwards compatibility with legacy IOS devices.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(8b) |
|
Known Fixed Releases: | 6.2(12)E4, 6.2(13.3)S0, 6.2(14)FB(0.19), 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.0(3)I1(1.211), 7.0(3)I1(2), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.422) |
|
|
| |
| |
Bug Id: | CSCuu09362 |
Title: | OTV VLAN not extended after VLAN is removed from the overlay and SSO |
|
Description: | Symptom:
VLAN can not be extending over overlay after the VLAN is removed prior to SSO.
Conditions:
When a VLAN is removed from the overlay, copy run start vdc-all is entered and a supervisor switchover is performed, the VLAN that was removed can not be added back to the overlay.
Workaround:
Reload OTV VDC
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.63) |
|
|
| |
| |
Bug Id: | CSCur05565 |
Title: | Traffic loss for intermittent source as rcvr PE does not rejoin data MDT |
|
Description: | Symptom:
Traffic blackhole for intermittent source
Conditions:
1. Data MDT configured
2. Intermittent Source (source starts/ stops for few minutes/ starts again)
Workaround:
Stop traffic and joins and wait for routes to time out before restarting again.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S77 |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.64), 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.293), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.367) |
|
|
| |
| |
Bug Id: | CSCuu13344 |
Title: | Rackspace - pixmc crash and M2 LC - communication failure |
|
Description: | Symptom:
During the HA switch over of the supervisors, the neighbor switch crashed with pixmc core.
Conditions:
have a M2 LC and more than 128 interfaces within a BD LTL.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(12)E5, 6.2(13.3)S0, 6.2(14)FB(0.46), 7.1(0)AV(0.81), 7.2(0)D1(0.496), 7.2(0)D1(1), 7.2(0)ZD(0.178), 7.3(0)IB(0.19), 7.3(0)RTG(0.17) |
|
|
| |
| |
Bug Id: | CSCuq39448 |
Title: | Nexus EIGRP crash when distribute list is configured under interface |
|
Description: | Symptom:
A Nexus 5000, 6000, or 7000 switch may reload unexpectedly due to an EIGRP process crash. Reset reason will look similar to the following:
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 306358 usecs after Wed Sep 3 04:32:21 2014
Reason: Reset triggered due to HA policy of Reset
Service: __inst_001__eigrp hap reset
Version: 7.0(2)N1(1)
Conditions:
This crash can be hit when a distribute-list is configured on a physical interface or SVI. It will occur when a new neighborship is formed on that interface.
Workaround:
No known workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.17), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(1)ZN(0.693), 7.0(3)I2(0.414), 7.0(3)I2(1), 7.0(6)N1(0.202), 7.0(6)N1(1), 7.1(0)D1(0.253) |
|
|
| |
| |
Bug Id: | CSCus74176 |
Title: | boot loop w/ 'no logging logfile' in config w/ power outage/reload VDC3 |
|
Description: | Symptom:
core dump generated in boot loop when sudden power outage such as unplug power cord. soft reload worked fine. issue can be recreated with reload VDC 3
Conditions:
suddenly lost power when the command 'no logging logfile' is in the configuration
Workaround:
Remove 'no logging logfile' from the configuration
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 7.2(0)D1(0.430) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.40), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.443), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.379), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCut18721 |
Title: | gbr_422: urib core at urib_chlist_segv_handler |
|
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 *".
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUN-2015 |
|
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)FB(0.28), 7.1(0)AV(0.74), 7.1(0)SIB(99.109), 7.2(0)AB(9), 7.2(0)D1(0.451), 7.2(0)D1(0.463), 7.2(0)D1(0.479) |
|
|
| |
| |
Bug Id: | CSCtq89240 |
Title: | Packets destined to the VDC MAC may be dropped by F1 module on N7K |
|
Description: | Symptom:
On the n7k packets destined to the VDC MAC may be dropped when received on a F1 module.
Conditions:
N7k with F1 module. Packets destined to the VDC MAC will be dropped under the following conditions:
- no SVI present or admin down
- packets received on the F1 module
Likely scenarios to see this condition include:
- transparent firewall bridging
- hair pinning traffic
- L2 load balancers
Workaround:
Configure the SVI(s) with a user-configured mac address rather than using the default VDC MAC.
This problem is isolated to the F1 module regardless of the NXOS version of code.
This workaround is not applicable to FabricPath deployment as in FabricPath VLANs user SVI's inf F1 card go to RMM table due to CSCtc39594. Thus if transparent bridging has to be done with FP, workaround has to configure 32 user SVI's to fill up RMM table and continue with desired user SVI which will go to Mac table.
Are the HSRP/VRRP/GLBP virtual MAC addresses also inserted into the RMM table?
1) If yes, will we have same impact and drop packets if bridged through the FW (when packets arrive on F1 port that does not have the SVI)
No HSRP/VRRP/GLBP are not inserted in RMM. You will not have this issue for any other macs other than svi macs.
2) If HSRP vMAC is not in the RMM table, how does the F1 module know the packet has to be routed?
It is through mac table. G bit set will indicate routing has to be done.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 5.1(3), 6.2(6a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu68734 |
Title: | NVT: L3 oif DEL and ADD after SSO |
|
Description: | Symptom:
Timing out L3 IGMP oif's of a multicast flow on VxLAN L3 gateway.
Conditions:
Supervisor Switchover on Vxlan Gateway which is the only Gateway having connected hosts receiving traffic for this flow.
Workaround:
Increasing IGMP robustness to 3 on L3 Vxlan Gateway.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut44076 |
Title: | ISSU from 628/6212 to GBR:HMM-3-AUTO_CONF_PROFILE_ERROR |
|
Description: | Symptom:
HMM-3-AUTO_CONF_PROFILE_ERROR: hmm [16977] Data Snooping Host: Unable to find mapping for encap 31 on interface Ethx/y/z
Conditions:
Enable "feature-set fabric and feature vni after ISSU from 62x to GBR. Both of them must be enabled. If only one of them enabled, then issue not seen. Seen only with private-vlan pairs.
Packet start coming on secondary vlan , but since dhcp relay is configured only on primary vlan, it fails.
Delete secondary vlan, but primary vlan is pointing to a secondary vlan. Dhcp doesn't work at all for primary vlan since pktmgr sending packet on secondary vlan which is not present.
Workaround:
Try in the following order. If one doesn't work, move on to the next.
1) Disable one or both features (feature-set fabric or feature vni).
2) Delete secondary vlan and then recreate secondary vlan.
3) Delete and recreate the pvaln primary and secondary vlans.
3) "copy r s" switch reload.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.441) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut01933 |
Title: | default route not withdrawn after removing "default originate" |
|
Description: | Symptom:
Default route will not be withdrawn from vpnv4 table.
Conditions:
Multiple [no] default-originate command toggles being configured in addess-family vpnv4. More especifically, the following steps are the minimum required to hit the issue considering the vpnv4 unicast address-family is clean of any configurations:
1. default-information originate always rd route-target |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.2(0)ZN(0.36) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(2)N1(0.554), 7.1(2)ZD(0.9), 7.1(2)ZN(0.13), 7.2(0)D1(0.451), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu72286 |
Title: | ThReloading VDC has a timeout issue with scale configuration |
|
Description: | Symptom:
Reloading non-default VDC with Rackspace's scale configuration causes vdc timeout.
Conditions:
Using Rackspace's scale configuration.
Workaround:
Working on it.
Further Problem Description:
The problem happen when the non-default VDC is reloaded.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.2(12)E5 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup20959 |
Title: | M2 linecard reset due to EOBC heartbeat failure |
|
Description: | Symptom:A M2 linecard may be reset by the supervisor due to EOBC heartbeat being missed by the linecard
Conditions:NXOS versions prior to 6.2(10)
Workaround:None
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.1(4), 6.2(6), 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S84, 6.2(10.16)S0, 6.2(8)E10, 7.1(0)AV(0.38), 7.1(0)D1(0.306), 7.1(0)EV(0.116), 7.1(0)OTT(0.45), 7.1(0)PDB(0.241), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuu84358 |
Title: | N77/F3/MPLS: mcast traffic drop 6-8 secs after SSO |
|
Description: | Symptom:
traffic loss is seen after SSO
Conditions:
SSO is performed, traffic outage is seen for a very short duration and then recovers
Workaround:
no workaround
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu72468 |
Title: | UDLD-4-UDLD_SFP_TYPE_CHANGED: User changed SFP type from fiber to copper |
|
Description: | Symptom:
Switch may report below message when interface comes up although no changes are made:
%UDLD-4-UDLD_SFP_TYPE_CHANGED: User changed SFP type on Ethernet7/6 from fiber to copper, default udld port configuration was applied, 'copy running-config startup-config' recommended
Conditions:
Linkflap seems to trigger this message.
Workaround:
No known workaround
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut98473 |
Title: | PortLoopback test fails following EOBC congestion |
|
Description: | Symptom:
After seeing EOBC congestion in some rare circumstances it is possible to starting seeing false Gold port loopback failures
/* example of EOBC congestion */
2015 Apr 13 18:07:43 iad7-ws-dis-r2 %MODULE-4-MOD_WARNING: Module 18 reported
warning due to EOBC heartbeat failure in device DEV_EOBC_MAC (device error 0xc0a09145)
/* example of the false errors */
2015 Apr 13 18:07:43 iad7-ws-dis-r2 %MODULE-4-MOD_WARNING: Module 18 reported warning due to EOBC heartbeat failure in device DEV_EOBC_MAC (device error 0xc0a09145)
Conditions:
Problem occurs after heavy EOBC congestion and link flapping
Workaround:
To recover from the issue you can reload the affected LC
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu57637 |
Title: | FCOE traffic is dropped at FEX FPC if storage vdc is created after ISSU |
|
Description: | Symptom:
CRC giant-drops(ingress_giant_drops) seen on fex FPC ports on any qos template change after issu.
Conditions:
after issu if you do any qos template change and if you have fex in your setup, you will see MTU mismatch resuling in giant/CRC drops in the ingress of FPC ports.
Workaround:
configure/change qos template before issu.
or
shut/no-shut on fex FPC ports to reconfigure the mtu
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.514) |
|
Known Fixed Releases: | 7.2(0)D1(1), 7.2(0)D1(1.1), 7.2(0)ZD(0.205), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCtz65462 |
Title: | broadcast get dropped on F2, learning source broadcast frame |
|
Description: | Symptoms:
ARP requests and other Layer 2 traffic with a broadcast destination address is NOT flooded to all ports on the same VLAN.
In addition to that, the following message may be seen on the device logs:
%MTM-SLOT3-2-MULTICAST_SOURCE_MAC_LEARNT: Inserted dynamically learnt multicast source mac ff:ff:ff:ff:ff:ff!
Conditions:
Upon receiving a Layer 2 frame with a broadcast source address (FFFF.FFFF.FFFF), the F2 line card will learn and add this address to its hardware
table. Having this entry on the hardware table, Layer 2 traffic with a broadcast destination address (such as ARP requests) will be dropped on the
Nexus 7000 device because the ingress controller fails to flood it to the broadcast domain.
Workaround:
Clear the entry from the dynamic MAC address table by executing the following command from a privileged EXEC prompt:
clear mac address dynamic vlan x address ffff.ffff.ffff
Replace ''x'' with the appropriate VLAN number.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.1/5.8:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:U/RC:C
CVE ID CVE-2012-3048 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | 6.1(0.307)S0, 6.1(1)S23, 6.1(1.22)S0, 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCuu55233 |
Title: | Mac addresses not learnt after Port-security violation stops |
|
Description: | Symptom:
On a Nexus 7700 mac addresses are not learnt on an interface after port-security violation happens and then stops.
Conditions:
This issue has currently been observed on Nexus 7700 with F3 module running on 6.2(12).
Issue only happens after max. mac address violation occurs and then stops.
shut/no-shut of interface does NOT recover mac-learning.
Workaround:
Default-interface and reconfiguring interface fixes the problem.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.70) |
|
|
| |
| |
Bug Id: | CSCuu76634 |
Title: | CFS process crash with Eth and IPv4 distribution configured in VPC setup |
|
Description: | Symptom:
CFS process my crash if running:
- cfs ipv4 distribute
- cfs eth distribute
This configuration is not supported on Nexus 7000 with VPC configuration
Conditions:
If both IPv4 and Eth distribution are configured for CFS
Workaround:
Remove unsupported configuration, IPv4 is not required.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.2(6b), 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu37319 |
Title: | F3:QoS Policer is inconsistent in policing traffic to the desired rate. |
|
Description: | Symptom:
Traffic policing applied on a vlan is not providing the desired policing rate.
The actual traffic rate through the vlan with policing in place could be higher or lower than the configured limit.
Conditions:
issue seen on F3/6.2.8a
Workaround:
Remove and reapply the service policy on the vlan may work.
if it does not then please reach out to TAC for further troubleshooting
Further Problem Description:
Any subsequent member addition/deletion operation from a VLAN or a port-channel is triggering this problem.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.62) |
|
|
| |
| |
Bug Id: | CSCus55589 |
Title: | NX-OS IS-IS Net Command |
|
Description: | Symptom:
n7k-3a-wnlb-dcore-3a# conf t
Enter configuration commands, one per line. End with CNTL/Z.
n7k-3a-wnlb-dcore-3a(config)# router isis core
n7k-3a-wnlb-dcore-3a(config-router)# net 47.0124.0010.6301.0a00.0508.1103.2230.4100
^
% Invalid command at '^' marker.
n7k-3a-wnlb-dcore-3a(config-router)#
Conditions:
always present
Workaround:
adding 00 - but this is not accepted as it changes the area ID
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(12)E4, 6.2(13.3)S0, 6.2(14)FB(0.76), 7.0(0)BZ(0.46), 7.0(0)HSK(0.395), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.440), 7.2(0)D1(1), 7.2(0)FM(0.3) |
|
|
| |
| |
Bug Id: | CSCus44856 |
Title: | vdc-admin on N7K VDC can execute shell commands using tar |
|
Description: | Symptoms:
Cisco Nexus devices running an affected version of Cisco NX-OS software contain a local privilege escalation vulnerability within the command line interpreter (CLI) that could
allow an authenticated, local attacker to execute arbitrary commands on the underlying operating system with user privileges.
The vulnerability exists due to insufficient input sanitization of parameters passed to the tar command on the CLI of an affected device. An attacker could leverage this behavior to
execute arbitrary commands on the underlying operating system with the privileges of the user authenticated to the device.
Conditions:
Cisco Nexus devices running an affected version of Cisco NX-OS software.
Workaround:
Not available.
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 4.3/3.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:P/I:P/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2015-4232 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.0(2)A6(0.43), 6.0(2)A6(1), 6.0(2)U6(0.43), 6.0(2)U6(1), 6.1(2)I3(3.72), 6.1(2)I3(4), 6.2(12), 6.2(12)S21, 6.2(12.4)S0, 7.1(0)AV(0.74) |
|
|
| |
| |
Bug Id: | CSCue79881 |
Title: | SNMP crashes on SNMP bulk get query |
|
Description: | The SNMP process may crash with the following syslogs
%KERN-2-SYSTEM_MSG: mts_is_q_space_available_new():1416:Total mtsbuf size 10070872 for sap 28, exceeds limit 15 perc of 67108864 - kernel
%KERN-2-SYSTEM_MSG: mts_acquire_q_space() failing - no space in sap 28, uuid 26 send_opc 3176, pid 3616, proc_name sctpt_rx_thr - kernel
%KERN-2-SYSTEM_MSG: [sap 28][pid 4406][comm:snmpd] sap recovering failed and so Killed - kernel
%SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 4406) hasn't caught signal 6 (core will be saved).
Symptom:
The SNMP process may crash with the following syslogs
%KERN-2-SYSTEM_MSG: mts_is_q_space_available_new():1416:Total mtsbuf size 10070872 for sap 28, exceeds limit 15 perc of 67108864 - kernel
%KERN-2-SYSTEM_MSG: mts_acquire_q_space() failing - no space in sap 28, uuid 26 send_opc 3176, pid 3616, proc_name sctpt_rx_thr - kernel
%KERN-2-SYSTEM_MSG: [sap 28][pid 4406][comm:snmpd] sap recovering failed and so Killed - kernel
%SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 4406) hasn't caught signal 6 (core will be saved).
Conditions:
This has been observed when a monitoring device is using snmp-bulk-get requests on the entity-MIB for multiple FEX modules at one time. Also this can be observed if there is continuous
polling from multiple polling stations on slow mibs.
Even if FEX modules were not present if continuous snmpbulkwalk is getting done using multiple devices simultaneously on slow mibs for long time then it can happen.
Some mibs like qos mib, entity mib, entity-fru mib, bridge mib are little slow and continuous snmp bulk walk on these might affect.
To check if mts buffer size is increasing you can use
#show system internal mts buffers summary
and see notificaitons for sap 28 increasing.
Workaround:
Workaround(s):
Possible workaround is configuring the "no snmp-server counter cache enable" command. This command prevents SNMP bulk gets from getting cached via the use of MTS buffers. This will prevent the MTS buffers from getting consumed and resulting in a process crash. The result of the command is that the interface table might be slower to update the statistics (since caching is disabled). This is fixed in 5.2.9, 6.1.4 and in 6.2.1.
Note: This workaround is only available on Nexus 7000 switches.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.2(7), 5.2(7)S20, 6.1(1.66)S0, 6.1(3), 6.1(4)S17, 6.2(0.294)S11, 6.2(0.294)S12, 6.2(1.23) |
|
Known Fixed Releases: | 5.2(1)N1(5), 5.2(8g)S11, 5.2(9), 5.2(9)S53, 5.2(9.98)S0, 6.0(2)N1(2a), 6.0(2)U1(1) |
|
|
| |
| |
Bug Id: | CSCuv05652 |
Title: | itd scale swover SAP 230 (iscm sap not respod)" and stby powerup forever |
|
Description: | Symptom:
after itd scale switchover SAP 230 (iscm sap not respod)? and takes 3 m
Conditions:
after itd scale switchover SAP 230 (iscm sap not respod)? and takes 3 m
Workaround:
after itd scale switchover SAP 230 (iscm sap not respod)? and takes 3 m
Further Problem Description:
after itd scale switchover SAP 230 (iscm sap not respod)? and takes 3 m
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(14)FB(0.79), 7.2(0)D1(1.20) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut38574 |
Title: | Wrong EIGRP delay calculation |
|
Description: | Symptom:
Two port-channels with different bandwidth are being populated in the routing table as equal-path. And two port-channels with same bandwidth are not both populated as equal-path in the routing table.
Conditions:
Using EIGRP with 40G links/port-channels.
Workaround:
We figure out the issue. The delay value is getting cached and we are no updating it on b/w change.
I will fix this issue.
The main thing is we need to update delay on bandwidth change. Or we need to flush it. So it will get updated with correct value
corresponding to updated bandwidth.
Work around:
That can be done with,
#SVS-N7K-C1-61# conf t
#SVS-N7K-C1-61(config)# interface port-channel 12
#SVS-N7K-C1-61(config-if)# ip delay eigrp 100 200000 << some random value
#SVS-N7K-C1-61(config-if)#no ip delay eigrp 100 200000
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.23), 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)IB(120), 7.2(0)D1(0.481), 7.2(0)D1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCsv08579 |
Title: | TCP connections get stuck in FINWAIT1 state indefinitely |
|
Description: |
Symptom:
Multiple Cisco products are affected by denial of service (DoS) vulnerabilities that manipulate the state of Transmission Control
Protocol (TCP) connections. By manipulating the state of a TCP connection, an attacker could force the TCP connection to remain
in a long-lived state, possibly indefinitely. If enough TCP connections are forced into a long-lived or indefinite state, resources on a
system under attack may be consumed, preventing new TCP connections from being accepted. In some cases, a system reboot
may be necessary to recover normal system operation. To exploit these vulnerabilities, an attacker must be able to complete a
TCP three-way handshake with a vulnerable system.
In addition to these vulnerabilities, Cisco Nexus 5000 devices contain a TCP DoS vulnerability that may result in a system crash.
This additional vulnerability was found as a result of testing the TCP state manipulation vulnerabilities.
This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20090908-tcp24.shtml.
Conditions:
See PSIRT Security Advisory.
Workaround
See PSIRT Security Advisory.
Further Problem Description:
See PSIRT Security Advisory.
PSIRT Evaluation:
Cisco has released free software updates that address this vulnerability.
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.0(3) |
|
Known Fixed Releases: | 4.0(4), 4.1(1.51), 4.1(1.53), 4.1(3), 4.2(0.140), 4.2(1), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuo57743 |
Title: | N7k-M108-12L LC Err-disabling ports with X2-10GB-ER after ISSU to 6.1.4a |
|
Description: | Symptom:
Random Ports with non-cisco X2-10GB-ER ports go Error-disabled after ISSU upgrade to 6.1.4a
Conditions:
-- Issue so far only seen with non-cisco X2-10GB-ER SFP's plugged in M108 Module
-- Issue NOT seen in 5.1.5. Only after an ISSU upgrade to 6.1.4a
Workaround:
-- Reseating the SFP will temporarily bring the ports back up, until the next reload of LC.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.1(4a)E1 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo15015 |
Title: | urib process crash on N7k |
|
Description: | Symptom:
A N7k running 6.2(2a) crashed on the urib process
Conditions:
This is a corner case. With frequent binding and unbinding of dynamic saps during lots of parallel CLI command processing, q handle management may cause the system subject to this bug.
Workaround:
None. But reducing the number of parallel CLI commands being processed by an application may reduce the chance of this bug.
Further Problem Description:
Impact: Process can crash and will be re-started by HA.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(2a), 7.1(0)D1(0.179) |
|
Known Fixed Releases: | 6.0(2)A6(0.78), 6.0(2)A6(1), 6.0(2)U6(0.78), 6.0(2)U6(1), 6.1(2)I3(2.19), 6.1(2)I3(3), 6.2(10), 6.2(10)CM(0.10), 6.2(10)CM(0.9), 6.2(8)KR(0.8) |
|
|
| |
| |
Bug Id: | CSCuq34116 |
Title: | N7K-F248XT-25E interfaces fail PortLoopback test and fail to initialize |
|
Description: | Symptom:
Interfaces on an N7K-F248-XT-25E fail to initialize.
- Gaurdian is in stuck state.
- Shut / no shut of the interface does not help.
- Not easily reproducible.
- Once we reload the LC, issue goes away.
- So this is very rare and intermittent case.
Conditions:
N7K-F248-XT-25E running 6.2(x)
Workaround:
Reload the impacted line card
Further Problem Description:
The interface in question will fail the port loopback diagnostic test. However, if you were to check the exception log for the module you will see the following exception being raised for the interface:
n7k# sh module internal exceptionlog module 5
********* Exception info for module 5 ********
exception information --- exception instance 1 ----
Module Slot Number: 5
Device Id : 143
Device Name : Port-Client
Device Errorcode : 0xc8f0c269
Device ID : 143 (0x8f)
Device Instance : 12 (0x0c)
Dev Type (HW/SW) : 02 (0x02)
ErrNum (devInfo) : 105 (0x69)
System Errorcode : 0x42370069 GD link down
Error Type : Minor error
PhyPortLayer : Ethernet
Port(s) Affected : Ethernet5/13
Error Description : send_exp_info: Operational param config failed in port client linkup handler port: 12 error 0x42370069
DSAP : 0 (0x0)
UUID : 323 (0x143)
Time : Wed Jul 9 09:43:16 2014
(Ticks: 53BD5504 jiffies)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(2), 6.2(6), 6.2(6a), 6.2(6b), 6.2(8a) |
|
Known Fixed Releases: | 6.2(12)E6, 6.2(13.3)S0, 6.2(14)FB(0.28), 7.1(0)AV(0.74), 7.2(0)D1(0.469), 7.2(0)D1(1), 7.2(0)PDB(0.394), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCut72641 |
Title: | L2BFD: some L2BFD links are not coming up after ascii replay |
|
Description: | Symptom:
After write erase, reload and applying ascii configuration containing per-link port-channels with 2 members, only the 1st member will be added to the port-channel session. The second member will not get bootstrapped onto the port-channel session. This will seen randomly in some port-channels. On the peer, the same port-channel will have 2 members - the first in UP state and the second in DOWN state.
Conditions:
Problem is seen only when you do write-erase, reload and apply ascii config. The problem is timing dependent and is random.
Workaround:
Doing a shut and no-shut of the port-channel will recover it from the problematic state.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.456) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtb02431 |
Title: | tacacs crash on receiving malformed packets from tacacs server |
|
Description: | Symptom:
Switch crashes when receiving malformed TACACS packets.
Conditions:
This has been observed on versions PRIOR to 4.2(1).
Workaround:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: | 4.2(1), 4.2(1.44), 4.2(2) |
|
|
| |
| |
Bug Id: | CSCus68473 |
Title: | urib crash after running "clear ip route vrf xxx *" |
|
Description: | Symptom:
N7K running 6.2(8E10) crash on the urib process after clearing all routes in the VRF rib.
Conditions:
Clearing all routes in the RIB when there is high route count
Workaround:
Clear individual routes, instead of the entire table using *
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(8)E10 |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.1(0)SIB(99.109), 7.2(0)AB(9), 7.2(0)D1(0.451), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)N1(0.146), 7.2(0)N1(1), 7.2(0)PDB(0.387), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCus68892 |
Title: | N7K: assess GHOST vulnerability in glibc (CVE-2015-0235) |
|
Description: | Symptom:
On January 27, 2015, a buffer overflow vulnerability in the GNU C library (glibc) was publicly announced. This vulnerability is related to the various gethostbyname functions included in glibc and affect applications that call these functions. This vulnerability may allow an attacker to obtain sensitive information from an exploited system or, in some instances, perform remote code execution with the privileges of the application being exploited. This vulnerability is documented in CVE-2015-0235.
A Cisco Security Advisory has been published to document this vulnerability at:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150128-ghost
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent.
Workaround:
Not available.
Further Problem Description:
A heap-based buffer overflow in glibc's __nss_hostname_digits_dots() function, which is used by the gethostbyname* glibc function calls.
All previously released versionsand NX-OS software are affected. The fix will be delivered for currently supported releases as follows:
NX-OS 7.0 release - is scheduled to be available in May 2015
NX-OS 6.2 release - first fixed release is 6.2(12) which is available on CCO
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: 10/7.8
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C/CDP:ND/TD:ND/CR:ND/IR:ND/AR:ND
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.2(8), 5.2(9), 6.1(5), 6.2(10) |
|
Known Fixed Releases: | 6.2(12), 6.2(12)S32, 6.2(12.3)S0, 6.2(12.4)S0, 6.2(13.1)S0, 7.2(0)D1(0.410), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.347) |
|
|
| |
| |
Bug Id: | CSCup13175 |
Title: | SSTE: LDP core while doing SSO and LC reload |
|
Description: | Symptom:
LDP process crashes during cleanup. This mostly happens during the clean-up stage, when user unconfigures LDP or interfaces used by LDP go down.
Conditions:
During cleanup, if two threads access/modify the same resource, LDP may crash.
Workaround:
There is no workaround for this fix.
Further Problem Description:
LDP uses cross-OS radix tree API which is not thread safe. Issue happens when one thread modifies the tree, while another is reading it, resulting in memory corruption and crash of LDP process.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(10)S82, 7.1(0)D1(0.151), 7.1(0)D1(0.188), 7.1(0)D1(0.196), 7.1(0)D1(0.228), 7.1(0)D1(0.240) |
|
Known Fixed Releases: | 6.2(10)E5, 6.2(13.3)S0, 6.2(14)FB(0.65), 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.251), 7.1(0)D1(0.262), 7.1(0)N1(0.313), 7.1(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCui58446 |
Title: | M1/M2 module with F2E in same VDC suspends VLAN above 4040 reserved vlan |
|
Description: | Symptom:
In a mixed chassis setup - M cards with F2E card in same VDC, on using any VLAN > 4040 , vPC will not come up.
SVI will remain down
Conditions:
M module with F2E in same VDC
Workaround:
remove any vlans above 4040
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(2)S30, 7.0(0)ZD(0.85) |
|
Known Fixed Releases: | 6.2(2a), 6.2(2a)S2, 6.2(5.45)S0, 6.2(5.7)S0, 7.0(0.51)S0, 7.1(0)D1(0.14), 7.2(0)D1(1) |
|
|
| |
| |
Bug Id: | CSCuu87267 |
Title: | N7K:aclmgr crash seeen with logevity testing |
|
Description: | Symptom:
Crash in the aclmgr process.
Conditions:
Only in 6.2.12.E5. ACLs applied on a tunnel interface that is a member of a port-channel.
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(12)E5 |
|
Known Fixed Releases: | 6.2(12)E5 |
|
|
| |
| |
Bug Id: | CSCuu83574 |
Title: | Error in syslog of interface flap event after reload in remote server |
|
Description: | Symptom:
This can occur when logging source interface loopback is configured with ipv6 address and logging server is configured.
Conditions:
This issue occurs in certain conditions when ipv6 address configured on loopback being used as logging source interface is in compact form:
ex:
1::1/64
Workaround:
Reconfigure the logging source interface with the loopback interface after reload.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.2(1)D1(0.5), 7.2(1)N1(0.239), 7.2(1)N1(1), 7.2(1)ZD(0.5), 7.2(1)ZN(0.5) |
|
|
| |
| |
Bug Id: | CSCte90369 |
Title: | File System Access |
|
Description: | Symptoms:
A vulnerability exists in NX-OS which allows an authenticated, local attacker to read or write arbitrary files in volatile storage. A successful exploit could
allow the attacker to gain unauthorized access to sensitive files on the device, or to overwrite arbitrary files in volatile storage.
Conditions:
Devices running affected versions of NX-OS are vulnerable.
Workaround:
None
Further Problem Description:
This issue was discovered in internal security testing and has been resolved in all current versions of affected software.
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
5.2/4.3:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:C/I:P/A:N/E:F/RL:OF/RC:C
CVE ID CVE-2011-4490 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: | 4.2(3) |
|
|
| |
| |
Bug Id: | CSCuu84449 |
Title: | IGMP snooping entries ageout in AA FEX topologies |
|
Description: | Symptom:
IGMP snooping entries are expiring after 5 seconds on one of the two vPC switches, while the entries are stable on the other vPC switch, which might cause traffic loss for 15-16 seconds (depending on the port-channel hashing result).
Conditions:
Issue can be seen in a vPC topology with AA FEX without having configured the IGMP snooping switch-querier (under "vlan configuration XYZ"), but when having PIM enabled SVI interfaces.
Workaround:
Configure IGMP snooping querier under the "vlan configuration XYZ" configuration mode.
or
Configure "ip igmp query-interval 30" under the SVI configuration mode.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 7.1(0)N1 |
|
Known Fixed Releases: | 7.3(0)RTG(0.27) |
|
|
| |
| |
Bug Id: | CSCus88425 |
Title: | pvlan configured ports error disabled iftmc: invalid argument |
|
Description: | Symptom:
<>
india-29(config-vlan)# sh int bri | i error
india-29(config-vlan)# sh int bri | i dis
Eth1/10 1 eth access down Error disabled auto(D) --
Eth1/16 1 eth access down Error disabled auto(D) --
Eth1/30 1 eth access down Error disabled auto(D) --
Eth1/34 1 eth access down Error disabled auto(D) --
Eth1/36 1 eth access down Error disabled auto(D) --
Eth1/38 1 eth access down Error disabled auto(D) --
india-29(config-vlan)#
india-29(config-vlan)#
india-29(config-vlan)# sh int eth1/10
Ethernet1/10 is down (Error disabled, iftmc: invalid argument to function call)
admin state is up, Dedicated Interface
Hardware: 10/100/1000 Ethernet, address: 0024.986f.20e5 (bia 0024.986f.20e5)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, medium is broadcast
Port mode is access
auto-duplex, 1000 Mb/s
Conditions:
<>
india-29(config-vlan)# sh int bri | i error
india-29(config-vlan)# sh int bri | i dis
Eth1/10 1 eth access down Error disabled auto(D) --
Eth1/16 1 eth access down Error disabled auto(D) --
Eth1/30 1 eth access down Error disabled auto(D) --
Eth1/34 1 eth access down Error disabled auto(D) --
Eth1/36 1 eth access down Error disabled auto(D) --
Eth1/38 1 eth access down Error disabled auto(D) --
india-29(config-vlan)#
india-29(config-vlan)#
india-29(config-vlan)# sh int eth1/10
Ethernet1/10 is down (Error disabled, iftmc: invalid argument to function call)
admin state is up, Dedicated Interface
Hardware: 10/100/1000 Ethernet, address: 0024.986f.20e5 (bia 0024.986f.20e5)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, medium is broadcast
Port mode is access
auto-duplex, 1000 Mb/s
Workaround:
<>
india-29(config-vlan)# sh int bri | i error
india-29(config-vlan)# sh int bri | i dis
Eth1/10 1 eth access down Error disabled auto(D) --
Eth1/16 1 eth access down Error disabled auto(D) --
Eth1/30 1 eth access down Error disabled auto(D) --
Eth1/34 1 eth access down Error disabled auto(D) --
Eth1/36 1 eth access down Error disabled auto(D) --
Eth1/38 1 eth access down Error disabled auto(D) --
india-29(config-vlan)#
india-29(config-vlan)#
india-29(config-vlan)# sh int eth1/10
Ethernet1/10 is down (Error disabled, iftmc: invalid argument to function call)
admin state is up, Dedicated Interface
Hardware: 10/100/1000 Ethernet, address: 0024.986f.20e5 (bia 0024.986f.20e5)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, medium is broadcast
Port mode is access
auto-duplex, 1000 Mb/s
Further Problem Description:
<>
india-29(config-vlan)# sh int bri | i error
india-29(config-vlan)# sh int bri | i dis
Eth1/10 1 eth access down Err
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(0.2), 7.2(0.4) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.65), 7.1(0)AV(0.74), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.2(0)BA(0.12), 7.2(0)D1(0.454), 7.2(0)D1(1), 7.2(0)RTG(0.143), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCur00057 |
Title: | vdc-admin on N7K VDC can read other VDCs (and Admin VDC) config files |
|
Description: | Symptoms:
Cisco Nexus devices running Cisco NX-OS software contain an information disclosure vulnerability within the command line interpreter that could allow an authenticated, local attacker to disclose the configuration
of a Virtual Device Context (VDC) to which they are not assigned.
The vulnerability exists due to a lack of path sanitization on a certain show command. An attacker assigned to the administrative role of a VDC could leverage this vulnerability to display the configuration of a VDC
to which they are not assigned.
Conditions:
Cisco Nexus devices running an affected version of Cisco 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:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:P/I:N/A:N/E:F/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S90, 6.2(10.16)S0, 7.1(0)AV(0.38), 7.1(0)D1(0.298), 7.1(0)EV(0.116), 7.1(0)OTT(0.41), 7.1(0)PDB(0.245), 7.1(0)RTG(0.62), 7.1(0)ZD(0.342) |
|
|
| |
| |
Bug Id: | CSCus57051 |
Title: | Hsrp_Engine crash during ISSU from 6.2(8a) to 6.2.10 |
|
Description: | Symptom:
Failure recovery action::
"Standby will be rebooted to force netboot and image download".
Install has failed. Return code 0x4093005E (system switchover failed).
Please identify the cause of the failure, and try 'install all' again.
Conditions:
ISSU from 6.2(8a) to 6.2.10
Workaround:
Upgrade without ISSU
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a) |
|
Known Fixed Releases: | 6.2(12)S27, 6.2(12.4)S0, 7.1(0)AV(0.38), 7.1(0)SIB(99.92), 7.1(2)N1(0.543), 7.2(0)AB(2), 7.2(0)BA(0.12), 7.2(0)D1(0.398), 7.2(0)D1(1), 7.2(0)N1(0.87) |
|
|
| |
| |
Bug Id: | CSCup05444 |
Title: | Peer switch causes STP dispute through ASA |
|
Description: | Symptom:
On a Nexus 7000 running peer-switch if you bridge two vlans with an ASA in transparant bridge mode the Nexus puts one of the vlans into spanning-tree dispute incorrectly
Conditions:
Nexus 7000 running peer-switch through an ASA.
Workaround:
Disable peer-switch or Spanning-tree on the port
Further Problem Description:
When peer-switch is enabled:
BPDUs go out on both N7K peers
ASA would retransmit the bpdus to the other peer.
So the port on one of the N7K would go into dispute.
This is the expected behavior on N7K
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.1(5), 6.2(8) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua77416 |
Title: | Sup reload or Switchover may occur due to Leap second update |
|
Description: | Symptom:
There are periodic leap second events which can add or delete a second to global time.
When the leap second update occurs a N7K SUP1 could have the kernel hit what is known a "livelock" condition under the following circumstances:
a. When the NTP server pushes the update to the N7K NTPd client, which in turn schedules the update to
the Kernel. This push should have happened 24 hours before June 30th, by most NTP servers.
b. When the NTP server actually updates the clock
Conditions:
The leap second update will be propagated via Network Time Protocol (NTP) or via manually setting the clock.
Workaround:
Please note this is an issue for the SUP1 only and the SUP2 is not susceptible to leap second.
On switches configured for NTP and running affected code, following workaround can be used.
1) Remove NTP/PTP configuration on the switch at least two days prior to June 30, 2015 Leap second event date. Note the entire NTP configuration does not need to be removed and the user can do "no feature ntp" so the NTP feature will be disabled but the NTP configuration will remain in place.
2) Add NTP/PTP configuration back on the switch after the Leap second event date(July 1, 2015). Note if just the feature was disabled the user can now do "feature ntp".
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.1(1), 5.1(5)E2, 5.2(5), 6.0(4) |
|
Known Fixed Releases: | 5.2(6.16)S0, 5.2(7), 6.1(1)S28, 6.1(1.30)S0, 6.1(1.69), 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCus22805 |
Title: | N7K-SUP2/E: Compact Flash Failure or Unable to Save Configuration |
|
Description: | Symptom:The following symptoms have been seen:
- Compact flash diagnostic failure
- Unable to perform a 'copy run start'
To display the current status of the RAID devices, please run the following commands:
switch# show system internal raid | grep -A 1 "Current RAID status info"
Current RAID status info:
RAID data from CMOS = 0xa5 0xf0
Where x is the standby supervisor slot number:
switch# slot x show system internal raid | grep -A 1 "Current RAID status info"
Current RAID status info:
RAID data from CMOS = 0xa5 0xd2
Last number in the RAID data indicate the number of disks failed:
0xf0 ==>> No failures reported
0xe1 ==>> Primary flash failed
0xd2 ==>> Alternate (or mirror) flash failed
0xc3 ==>> Both primary and alternate failed
Conditions:- N7K-SUP2 or N7K-SUP2E
- N77k-SUP2 and N77K-SUP2E are NOT effected
- Several months or years of uptime
Workaround:While system can operate with only one flash device, its highly recommended to recover and add the removed flash back into RAID configuration. Second flash device can also get into this condition over time triggering the read-only mode.
Flash Recovery Tool:
n7000-s2-flash-recovery-tool.10.0.2.tar.gz is available to be downloaded from Cisco support site. This works as a custom plug-in that can be run using the 'load' CLI.
- To run the tool, download and copy it to bootflash/volatile/slot0.
extract it
#tar extract bootflash:n7000-s2-flash-recovery-tool.10.0.2.tar.gz
run with the load command
#load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
- Tool automatically fixes any single flash errors when present.
- If a standby available, it will copy itself to standby and run there.
- No side effects if there are no errors reported at the time.
- Tool will not attempt dual flash recovery either on active or standby.
Single flash failure on active or standby:
Systems running with single flash failure can be repaired while in service using the flash recovery tool.
Dual flash failure on the standby:
This is a recoverable situation by reloading the standby and making sure that the flashes are healthy once it comes back online. Flash recovery tool should be run after reload to put both flashes back into service.
Dual flash failures on Active:
This is not a recoverable situation, unless there is at least one working flash on the standby. Otherwise, switch need to be reloaded during next maintenance window. If the standby is healthy a switchover can be attempted and then recover the old active. Latest running configurations need to be saved external to the switch to be restored after reload. Flash recovery tool should be run after reload to make sure flashes back into service.
Additional verification steps and further information can be found in the Read Me file with the recovery tool.
More Info:Fix is available in 6.2(14), 7.2(x), and later.
Each Nexus 7000 Supervisor board are equipped with 2 identical eUSB flash devices in a RAID1 mirror configuration. Called primary and mirror, they together provide for non-volatile repositories for storing boot images, startup configuration and other persistent application data.
Over years in service, one of these devices may get disconnected from the USB bus. This causes the RAID software to drop the affected device to be removed from its configuration. System still can function normally with the remaining working device.
However, if the second device also experiences similar issue and drops out of the RAID array, boot flash devices will re-mounted as read-only preventing configuration copying. Even though there is no operational impact on systems running in this state, a reload of the affected supervisor is needed to recover f
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.1(5a), 6.2(12) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.26), 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)IB(122), 7.2(0)AB(9), 7.2(0)BA(0.12), 7.2(0)D1(0.456), 7.2(0)D1(1), 7.2(0)N1(0.152) |
|
|
| |
| |
Bug Id: | CSCuu95464 |
Title: | N7K cannot ping own ip L3 port-channel |
|
Description: | Symptom:
After an upgrade to 6.2(12) certain layer 3 port-channels are not pingable from N7K itself
Affects all control plane traffic on the interface. CPU does not send any packet egress for that interface
Conditions:
N7K upgraded from 6.2(10) to 6.2(12)
Workaround:
shut/no shut of port-channel interface fixes the issue
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut29799 |
Title: | Privilege escalation with o+w files and directories |
|
Description: | Symptoms:
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:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:N/I:P/A:N/E:F/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 7.0(0)HSK(0.392) |
|
|
| |
| |
Bug Id: | CSCus42713 |
Title: | 2014 and 2015 OpenSSL Vulnerabilities |
|
Description: | Symptom:Cisco NX-OS (Covering Nexus 5K, N6K and N7K and Cisco MDS) includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE)
IDs:
CVE-2014-3569, CVE-2014-3570, CVE-2014-3571, CVE-2014-3572, CVE-2014-8275,
CVE-2015-0204, CVE-2015-0205, CVE-2015-0206
This bug has been opened to address the potential impact on this product.
Conditions:This device has a vulnerable version of OpenSSL, this bug is being used to update the OpenSSL package used on the product.
Product doesn't support DTLS so is not affected by either:
CVE-2014-3571
CVE-2015-0206
The LDAP SSL authentication feature may be configured to use OpenSSL. This feature is disabled by default. Hence, this vulnerability only exists if the LDAP SSL Authentication feature is enabled.
Workaround:1. Nexus 5000 (N5K) : The following features can use SSL and would need to
be disabled.
a) Avoid any "fabric database" configuration with keyword "enable-ssl".
For example:
fabric database type network
server protocol ldap ip 172.29.21.2 enable-ssl
b) Make sure the 'secure LDAP' option is unchecked when defining POAP
template on DCNM.
c) Do not use Cisco's One Platform Kit (OnePK) with the transport type tls
..." open.
d) Remove the VM Tracker Configuration.
2. Nexus 7000 (N7K) : The LDAP feature uses Open SSL. To disable the LDAP
SSL Authentication feature. LDAP can be disabled or used without SSL
Authentication.
More Info:PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score.
The Base and Temporal CVSS scores as of the time of evaluation are: 4.3/3.6
http://tools.cisco.com/security/center/cvssCalculator.x?version=2.0&vector=AV:N/AC:M/Au:N/C:P/I:N/A:N/E:F/RL:OF/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 Ciscos security vulnerability policy can be
found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.2(8f), 6.2(10), 6.2(11), 6.2(7), 6.2(8)S3, 6.2(8a), 7.2(0)VX(0.9), 7.2(0.1)PR(0.1), 7.3(0.9), 9.9(0)XS(0.1) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.52), 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.1(0)AV(0.81), 7.2(0)D1(0.504), 7.2(0)D1(1), 7.2(0)VZD(0.26), 7.2(0)ZD(0.184), 7.2(1)PIB(0.14) |
|
|
| |
| |
Bug Id: | CSCur00089 |
Title: | vdc-admin on N7K can break out of vsh-"chroot" using symbolic links |
|
Description: | Symptom:
Cisco Nexus devices running Cisco NX-OS software contain a symbolic link vulnerability that could allow a local, authenticated attacker to break out of the chroot environment that their Virtual Device Context (VDC)
has been assigned. This could result in the attacker gaining the ability to write files to locations that should be restricted to the context to which they belong. This could also have an extended impact of allowing the
attacker to read data that should be restricted.
Conditions:
Cisco Nexus devices running an affected version of Cisco NX-OS Software
Workaround:
None.
Further Problem Description:
Credit:
Cisco would like to thank Jens Krabbenhoeft for 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 3.2/2.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:P/I:P/A:N/E:F/RL:OF/RC:C
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.74), 7.3(0)IB(0.17) |
|
|
| |
| |
Bug Id: | CSCtf19827 |
Title: | VSH parsing of backquotes allows linux cli access |
|
Description: |
Symptom:
An authenticated, local attacker could leverage an input handling flaw to execute arbitrary commands on the underlying operating system with elevated
privileges.
Conditions:
Cisco devices running an affected version of NXOS software.
This issue affects:
Nexus 7000
Nexus 5000
Workaround:
Restrict local console access to trusted users only.
Further Problem Description:
This issue was identified during an internal security audit of the Cisco UCS and relate 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 6.8/5.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:C/I:C/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2012-4075 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-4075
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv00717 |
Title: | LSA3 is not generating |
|
Description: | Symptom:
If connected interface that is excluded from OSPF for the same prefix like LSA is present on ABR, LSA3 will not be generated
Conditions:
NX-OS 6.0(2)N2(3). For NX-OS 7 that behavior is not observed.
Workaround:
enable ospf on connected interface
Further Problem Description:
.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul24462 |
Title: | FabricPath interface incorrectly programmed by PIXM after nbr reload |
|
Description: | Symptom:
In certain cases Fabricpath flood BD LTL could be incorrectly programmed on N7k device, resulting in multicast and broadcast traffic loss. This is seen on N7K-F248XP-25E line card when the N7k device is running NX-OS 6.1(4a) and 6.1(4).
Issuing "shut" / "no shut" for the affected interface on either side (N7k or N5k) recovers the interface from the issue.
Conditions:
In the current case the issue is seen if there is a directly attached N5k VPC+ system, and one of the VPC peers is being reloaded.
This issue is not specific to 6.2.6 although was observed in this release. This could occur in a fabricpath deployment when there exists multiple path to a fabricpath switch and one such switch is reloaded. The issue is not easily reproduced, and occurs in certain cases where cumulative route change triggers are simulated. In this particular case switch reload resulted in router port entry modification as well as switch routes being changed. The issue should most likely be observed only when router port entries are configured on the impacted vlan or per-vdc.
Workaround:
1. Set LSP-gen interval on the N5k devices to 1000 or greater:
config command:
fabricpath domain default
lsp-gen-interval 1000 1000 1000
2. Increase the link debounce timer on the VPC peer-link of the N5ks to 500ms:
config command:
interface ethX/Y
link debounce time 500
Further Problem Description:
The root cause of the issue has been identified as the fact that local link failures are seen by ISIS on N7k slower than remote LSPs from VPC peer of the reloaded N5k (indicating reachability change). This could cause ISIS not to factor in the local link failure in the first SPF run but include the remote LSP data in the SPF run. The local link failure would then be included in a later SPF run. This would in turn cause route deletes to go to M2RIB later than route changes. M2RIB seems to have issues when it tries to handle such cumulative updates and attempts to send a single update to PIXM. Hence we see the issue. This issue will addressed in a future release.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.1(4), 6.1(4a), 6.2(2)S42 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.12), 6.2(10)FM(0.35), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.12)S0, 6.2(9)FM(0.75) |
|
|
| |
| |
Bug Id: | CSCtt41698 |
Title: | NXOS subinf MTU inconsistency |
|
Description: | Symptom:
When changing MTU on main interface, subinterface inherits this MTU as per the
"show interface ethernet x/y.z" command. Although, internally, MTU for subinterface
is still set to default.
Conditions:
Subinterface configuration.
Workaround:
Explicitly configure the non-default MTU on both main and subinterface.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 5.2(1), 6.0(1) |
|
Known Fixed Releases: | 6.1(0.184)S10, 6.1(0.197)S0, 6.2(0.228)S0, 7.2(0)VZN(0.30) |
|
|
| |
| |
Bug Id: | CSCtf25457 |
Title: | VSH parsing of SED parameters allows linux cli access |
|
Description: |
Symptom:
An authenticated, local attacker could leverage an input handling flaw to execute arbitrary commands on the underlying operating system with elevated
privileges.
Conditions:
Cisco devices running an affected version of NXOS software.
This issue affects:
Nexus 7000
Nexus 5000
Workaround:
Restrict local console access to trusted users only.
Further Problem Description:
This issue was identified during an internal security audit of the Cisco UCS and relate 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 6.8/5.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:C/I:C/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2012-4077 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-4077
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | 4.2(5.13), 4.2(5.14), 7.0(1)ZD(0.3) |
|
|
| |
| |
Bug Id: | CSCtf81850 |
Title: | OpenSSL Record of Death Issue |
|
Description: | Symptom:
The device may be affected by an OpenSSL vulnerability.
This vulnerability is tracked as CVE-2010-0740
In TLS connections, certain incorrectly formatted records can cause an OpenSSL
client or server to crash due to a read attempt at NULL.
Conditions:
Device configured with any feature that uses SSL.
Workaround:
Not available
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCsy98980 |
Title: | Nexus N7k does not support required password complexity |
|
Description: | Symptom:
Nexus 7000 does not allow the '$' dollar sign character to be used in a password per the documentation:
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/sec_rbac.html#wp1258879
Conditions:
Affects all versions.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.1(4) |
|
Known Fixed Releases: | 4.2(1.17), 4.2(2) |
|
|
| |
| |
Bug Id: | CSCtf40008 |
Title: | LESS allows bash access |
|
Description: | Symptom:
Cisco Nexus OS contains a vulnerability that could allow an authenticated,
local attacker to execute arbitrary commands on a targeted device. The
vulnerability is due to improper sanitization of user-supplied values to
command line interface commands.
An authenticated, local attacker could exploit the vulnerability by issuing
commands that contain malicious options on the device command line interface.
If successful, the attacker could gain elevated privileges on the targeted device.
Conditions:
Injection can be done via either the less or the section sub command. Full
details below:
----------------------------------------------------------------------
NX-OS - "less" sub-command - Command injection / sanitization issues.
----------------------------------------------------------------------
Affected Products:
==================
The following products are affected by this vulnerability:
+-----------------------------------------------------------------+
| Affected Product | Cisco Bug | First Fixed |
| | ID | Release |
|-----------------------------------+------------+----------------|
| Cisco Nexus 7000 Series Switches | CSCtf40008 | 4.2(6) |
| | | 5.1(1) |
|-----------------------------------+------------+----------------|
| Cisco Nexus 5000 Series Switches | CSCtf40008 | 4.2(1)N2(1) |
|-----------------------------------+------------+----------------|
| Cisco Nexus 2000 Series Switches | CSCtf40008 | 4.1(1)N2(1) |
|-----------------------------------+------------+----------------|
| Cisco Nexus 1000V Series Switches | CSCtf40008 | 4.2(1)SV1(5.1) |
|-----------------------------------+------------+----------------|
| Cisco MDS 9000 Software | CSCtf40008 | 4.2(6) |
| | | 5.1(1) |
|-----------------------------------+------------+----------------|
| Cisco Unified Computing System | CSCtg18363 | 1.3(1c) |
| | | 1.4(1i) |
+-----------------------------------------------------------------+
The following are not affecfed by the "less" sub-command - command injection
vulnerability.
* Cisco Nexus 3000 Series Switches
* Cisco Nexus 4000 Series Switches
-------------------------------------------------------------------------
NX-OS - "section" sub-command - Command injection / sanitization issues.
-------------------------------------------------------------------------
Affected Products:
==================
The following products are affected by this vulnerability:
+--------------------------------------------------------------+
| Affected Product | Cisco Bug | First Fixed |
| | ID | Release |
|-----------------------------------+------------+-------------|
| Cisco Nexus 7000 Series Switches | CSCtr44645 | 5.2(1) |
|-----------------------------------+------------+-------------|
| Cisco Nexus 5000 Series Switches | CSCtr44645 | 5.1(3)N1(1) |
|-----------------------------------+------------+-------------|
| Cisco Nexus 3000 Se
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 4.2(4), 4.2(6), 5.1(1a), 5.1(2) |
|
Known Fixed Releases: | 4.2(1)N2(1), 4.2(5.10), 5.1(0.76), 5.1(1), 7.0(1)ZD(0.3) |
|
|
| |
| |
Bug Id: | CSCui04729 |
Title: | Memory leak on eureka_usd while polling cshcMacUsageEntry |
|
Description: | Symptom:
M1/M2 module might be reloaded due to memory leak after SNMP walk against cshcMacUsageTable in CISCO-SWITCH-HARDWARE-CAPACITY-MIB.
A core file with eureka_usd_log in the name will be generated.
A syslog similar to Service "eureka_usd" (PID 1234) hasn't caught signal 6 (core will be saved) will be generated.
Conditions:
Problem only exists on M1 or M2 modules while SNMP walk against cshcMacUsageTable in CISCO-SWITCH-HARDWARE-CAPACITY-MIB.
Workaround:
Restrict access to the following:
cshcMacUsageEntry in CISCO-SWITCH-HARDWARE-CAPACITY-MIB (1.3.6.1.4.1.9.9.663.1.1.1.1.1)
Further Problem Description:
Problem exists only in 6.1(4).
Fixes had been integrated into 6.1(4a), 6.2(2) and later releases.
Memory usage can be monitored with the following command:
switch# slot slot show processes memory | grep eureka_usd
2182 3051520 0 CurrentMemoryUsage 7fe3aa80/7fe3a460 eureka_usd
Example configuration for blocking only cshcMacUsageEntry in CISCO-SWITCH-HARDWARE-CAPACITY-MIB:
snmp-server community communityString group name
role name name
rule 1 permit read
rule 2 deny read oid 1.3.6.1.4.1.9.9.663.1.1.1.1.1
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUN-2015 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(4a), 6.1(4a)S2, 6.1(5.32)S0, 6.2(2), 6.2(2)S6, 6.2(5.2)S0, 7.0(0)ZD(0.84) |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论