| |
Bug Id: | CSCul53679 |
Title: | DEV_CLP_FWD: L2LU IG_SA result merge fifo full Port Internal Err-Dis |
|
Description: | Symptom:
Port set goes into error disabled state with the following error seen in the default VDC:
%MODULE-2-MOD_SOMEPORTS_FAILED: Module x (Serial number: xxxxxxxx) reported failure on ports Ethernet x/y-z (Ethernet) due to error in device DEV_CLP_FWD (device error 0xca802600)
The port group VDC reports the following:
2013 Dec 3 09:20:21.611 7K-VDC2 %ETHPORT-3-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/11 is down (Error disabled. Reason:Internal Error)
2013 Dec 3 09:20:21.623 7K-VDC2 %ETHPORT-3-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/10 is down (Error disabled. Reason:Internal Error)
2013 Dec 3 09:20:21.630 7K-VDC2 %ETHPORT-3-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/12 is down (Error disabled. Reason:Internal Error)
2013 Dec 3 09:20:21.643 7K-VDC2 %ETHPORT-3-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/9 is down (Error disabled. Reason:Internal Error)
Conditions:
Default VDC accounting log reports a 'L2LU IG_SA result merge fifo full' interrupt
Workaround:
Flap the Interface
Further Problem Description:
This is considered a non-fatal interrupt. The interrupt manifests when a MAC table look up result FIFO is deemed to be full and might cause packet drops.
The interrupt is informational only. Behavior is changed in 6.2(6) and later to report these as a log message rather than disabling the port.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-MAY-2015 |
|
Known Affected Releases: | 6.2(5.55)S3 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5.65)S8, 6.2(5.66)S0, 6.2(6) |
|
|
| |
| |
Bug Id: | CSCuq41441 |
Title: | FCoE: HDS: Performance issue in 7K/6K topology at the customer site |
|
Description: | Symptom:
In the AT&T storage network the performance of SCSI over FCoE is extremely low compared to equivalent EMC array which was later found to be an issue with HDS storage and not N7K FCoE stack.
Conditions:
Please refer to AT&T topology for kings mountain data centre
Workaround:
None
Further Problem Description:
The problem was identified to be an issue with the HDS storage box and fixed by the Hitachi Team in the AT&T network. The problem has nothing to do with the N7K FCoE implementation.
|
|
Status: | Terminated |
|
Severity: | 1 Catastrophic |
Last Modified: | 02-MAY-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 04-MAY-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(14)FB(0.25), 7.0(3)I1(1.211), 7.0(3)I1(2) |
|
|
| |
| |
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: | 04-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(14)FB(0.41) |
|
|
| |
| |
Bug Id: | CSCtc83165 |
Title: | SNMP crash due to mutex lock assert fail in 4.2(2a) |
|
Description: |
Problem/Description:
Both Nexus 7000 and Nexus 5000 boxes will crash on snmpd pid.
Workaround:
Software upgrade
Further Actions:
gather show tech details and engage Cisco TAC.
Other:
`show cores`
Module-num Instance-num Process-name PID Core-create-time
---------- ------------ ------------ --- ----------------
1 1 snmpd 3870 Oct 2 10:30
Look for this in the output of
show logging nvram:
%SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 3870) hasn't caught signal 11
(core will be saved).
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 04-MAY-2015 |
|
Known Affected Releases: | 4.2(2a) |
|
Known Fixed Releases: | 4.2(1)N2(1), 4.2(3), 4.2(3.19), 4.2(4), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuu07787 |
Title: | iscm cores after LC reloads with 2 node ITD cofigs . |
|
Description: | Symptom:
iscm cores after LC reloads with 2 node ITD cofigs .
Conditions:
iscm cores after LC reloads with 2 node ITD cofigs .
Workaround:
iscm cores after LC reloads with 2 node ITD cofigs .
Further Problem Description:
iscm cores after LC reloads with 2 node ITD cofigs .
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 04-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.484) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 04-MAY-2015 |
|
Known Affected Releases: | 6.2(1.136) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtu30632 |
Title: | L2FM crash @ cmd_rx_handle_validate |
|
Description: | Symptom:
SUP crash due to l2fm crash
Conditions:
5.2.x & 5.1.3
Workaround:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-MAY-2015 |
|
Known Affected Releases: | 5.2(0) |
|
Known Fixed Releases: | 5.2(3)S9, 5.2(3.8)S0, 6.0(2)S12, 6.1(0.151)S0 |
|
|
| |
| |
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: | 04-MAY-2015 |
|
Known Affected Releases: | 6.2(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj67507 |
Title: | ipqosmgr process crash after applying a policy-map to vlan configuration |
|
Description: | Symptom:
Multiple ipqosmgr process crashes occur leading to a sup reload. The reset-reason is due to a hap reset:
----- reset reason for Supervisor-module 2 (from Supervisor in slot 2) ---
1) At 526111 usecs after Thu Oct 3 16:46:43 2013
Reason: Reset triggered due to HA policy of Reset
Service: ipqosmgr hap reset
Version: 6.1(2)
Conditions:
This issue first occurred while applying a policy-map to vlan configuration 254. The last known configuration that was crashing looked like this:
policy-map type qos Crashes
class crash
police cir 56 kbps bc 200 ms conform transmit violate drop
Workaround:
None known
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 04-MAY-2015 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus76640 |
Title: | VXLAN:NVE crash on IPLUS 444 image with different triggers |
|
Description: | Symptom:
NVE HAP Reset
Conditions:
NVE interface flap or during reloads on VPC pairs
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-MAY-2015 |
|
Known Affected Releases: | 7.1(0)ZN(91.444) |
|
Known Fixed Releases: | 7.1(1)N1(0.466), 7.1(1)N1(1), 7.1(1)ZD(0.11), 7.1(1)ZN(0.18) |
|
|
| |
| |
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: | 05-MAY-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq77904 |
Title: | After ISSU to 6.2.10, Ethernet Interface suspended -in FCOE scenarios |
|
Description: | Symptom:
ISSU is done to 6.2.10 S67 image after doing write erase on the switch.Once ISSU is done then replaying the ascii config which has config for the ethernet interfae,the ethernet interfaces are not coming up.
Conditions:
The conditions are
1> Copy the running config to a file
2> Do write erase
3> Then do ISSU to 6.2.10 S67 image
4> Replay the config
Workaround:
The work around is to do ISSU to 6.2.10 S67 with the running config intact. Or if not doing ISSU then do a fresh reload with the new image and then acii config replay.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 05-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S67 |
|
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: | 05-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 05-MAY-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) |
|
|
| |
| |
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: | 06-MAY-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: | CSCut53389 |
Title: | IPv6 access-list permit ipv6 any any does not match object correctly |
|
Description: | Symptom:
We are experiencing an issue with IPv6 access-list. I am redistributing direct networks (connected subnets) into OSPFv3 using the following the route-map & ipv6 access-list. But it does not match & redistribute the loopback 781. Main purpose is to generate OSPFv3 external type-2 LSA for loopback 781. Looks like permit ipv6 any any rule apparently is not matching any-source or any-destination.
This issue is only experienced with ipv6 access-list & not with ipv4. Similar route-map & ipv4 access-list works just fine & OSPF advertised type-2 external LSA for the connected loopback.
Conditions:
We are experiencing an issue with IPv6 access-list. I am redistributing direct networks (connected subnets) into OSPFv3 using the following the route-map & ipv6 access-list. But it does not match & redistribute the loopback 781. Main purpose is to generate OSPFv3 external type-2 LSA for loopback 781. Looks like permit ipv6 any any rule apparently is not matching any-source or any-destination.
This issue is only experienced with ipv6 access-list & not with ipv4. Similar route-map & ipv4 access-list works just fine & OSPF advertised type-2 external LSA for the connected loopback.
interface loopback781
vrf member EDN
ipv6 address 2001:123:1:2:1::1/128
ipv6 access-list IPV6-DIRECT-NETS
10 permit ipv6 2001:123:1:2:1::1/128 any
20 permit ipv6 any any
route-map IPV6-DIRECT-NETS permit 10
match ipv6 address IPV6-DIRECT-NETS
AQ3-PT-7010-04# show runn ospfv3
!Command: show running-config ospfv3
!Time: Fri Mar 20 15:12:17 2015
version 6.2(10)
feature ospfv3
router ospfv3 EDN
bfd
router-id 44.44.44.44
log-adjacency-changes
address-family ipv6 unicast
redistribute direct route-map IPV6-DIRECT-NETS
interface loopback100
ipv6 router ospfv3 EDN area 0.0.0.1
interface port-channel1000.10
ospfv3 network point-to-point
no ospfv3 passive-interface
ipv6 router ospfv3 EDN area 0.0.0.1
ospfv3 bfd
interface port-channel1001.10
ospfv3 network point-to-point
no ospfv3 passive-interface
ipv6 router ospfv3 EDN area 0.0.0.1
ospfv3 bfd
interface port-channel1002.10
ospfv3 network point-to-point
no ospfv3 passive-interface
ipv6 router ospfv3 EDN area 0.0.0.1
ospfv3 bfd
AQ3-PT-7010-04#
AQ3-PT-7010-04# show ipv6 ospf route vrf EDN <--- IPv6 OSPF routing table is missing the Loopback 781 subnet locally & on other routers.
OSPFv3 Process ID EDN VRF EDN, Routing Table
(D) denotes route is directly attached (R) denotes route is in IPv6 RIB
(NHR) denotes next-hop is in IPv6 RIB
2001:11:11:11::11/128 (inter)(R) area 0.0.0.1
via fe80::66a0:e7ff:fe44:cfc1/Po1002.10 , cost 2 distance 110 (NHR)
2001:22:22:22::22/128 (inter)(R) area 0.0.0.1
via fe80::da67:d9ff:fe08:c441/Po1001.10 , cost 2 distance 110 (NHR)
2001:33:33:33::33/128 (intra)(R) area 0.0.0.1
via fe80::4255:39ff:fe0c:8dc1/Po1000.10 , cost 2 distance 110 (NHR)
2001:44:44:44::44/128 (intra)(D) area 0.0.0.1
via fe80::da67:d9ff:fe0d:c2/Lo100* , cost 0 distance 110 (NHR)
2001:1131:193::/64 (inter)(R) area 0.0.0.1
via fe80::66a0:e7ff:fe44:cfc1/Po1002.10 , cost 4 distance 110 (NHR)
via fe80::da67:d9ff:fe08:c441/Po1001.10 , cost 4 distance 110 (NHR)
2001:1131:193:1::/64 (intra)(R) area 0.0.0.1
via fe80::4255:39ff:fe0c:8dc1/Po1000.10 , cost 4 distance 110 (NHR)
via fe80::66a0:e7ff:fe44:cfc1/Po1002.10 , cost 4 distance 110 (NHR)
2001:1131:193:2::/64 (intra)(D) area 0.0.0.1
via fe80::da67:d9ff:fe06:641/Po1001.10* ,
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 06-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus42535 |
Title: | Anycast-HSRP bundle Active/Active - after pulling out Active SUP N7k |
|
Description: | Symptom:
After pulling out the Active supervisor from the N7k, Some of the Anycast-HSRP bundles are in Active/Active state.
This is causing the Anycast-HSRP state to be in Active/Active and their standby state to be unknown on both sides.
Conditions:
Physically pull out the Active supervisor from the N7k
Workaround:
Reinsert the pulled supervisor.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 06-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 07-MAY-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: | 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: | 07-MAY-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)PDB(0.373), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCtq57444 |
Title: | N7K: MPPM Parity Error in Naxos ASIC |
|
Description: | Symptom:
STP shows vlan in PVID_Inc state on trunk port between two N7K-C7010 w/N7K-M132XP-12 module
Conditions:
N7K-C7010 (E1/9, E2/9) === (E1/9,E2/9) N7K-C7010
PVID-Inc state seen after one port in Etherchannel(E1/9) was bounced to recover from UDLD err-disabled state.
Workaround:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-MAY-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | 4.2(8)S28, 4.2(8)S30, 4.2(8)S32, 4.2(8)S33, 4.2(8.102)S0, 4.2(8.103)S0, 4.2(8.104)S0, 5.1(10.37)S0, 5.1(10.38)S0, 5.1(5)S1 |
|
|
| |
| |
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: | 07-MAY-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)PDB(0.382) |
|
|
| |
| |
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"
Trigger for issue is ISSU or restart of IFTMC process on line card (for example after crash of process)
Workaround:
Reload affected module
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-MAY-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(14)FB(0.20), 7.1(0)AV(0.74), 7.2(0)D1(0.459), 7.2(0)PDB(0.382) |
|
|
| |
| |
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: | 07-MAY-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)RTG(0.129), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6), 7.2(0)ZD(0.127) |
|
|
| |
| |
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: | 07-MAY-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) |
|
|
| |
| |
Bug Id: | CSCur28450 |
Title: | [6210-S100] Rollback to a checkpoint fails verification at FEX SAT PO |
|
Description: | Symptom:
Rollback fails the verification phase, saying "flowcontrol send on" is present in the running-config on the port-channel.
switch# rollback running-config checkpoint checkpoint_name
Verification patch contains the following commands:
---------------------------------------------------
!!
interface port-channel###
no flowcontrol send on
exit
Conditions:
When trying to rollback to a checkpoint where a current HifPC (a port-channel with FEX host interfaces as its members) becomes a simple port-channel (no FEX host interfaces as its members), rollback will fail the verification phase.
Workaround:
Rollback running checkpoint checkpoint_name best-effort
So that it wont do verification and won't revert back to original running config.
And then do "no flowcontrol send on" on the affected interfaces
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S100 |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.2(0)D1(0.439), 7.2(0)PDB(0.360), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCtg34081 |
Title: | ISSU failed due to VPC config lock |
|
Description: | Symptom:
ISSU fails at the very end.
Conditions:
A switch that contains 2 x VDC's running as a VPC pair.
Workaround:
Don't use VPC across 2 x VDC in the same switch.
This configuration is an unsupported topology.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 07-MAY-2015 |
|
Known Affected Releases: | 4.2(4), 5.1(0.126) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu20517 |
Title: | itd scaling up, we see rate-limiter getting hit |
|
Description: | Symptom:
itd scaling up, we will see rate-limiter getting hit. For F3 the rate-limiter was about 30,000 pps
refer to attached mail for more details.
Conditions:
itd scaling up, we will see rate-limiter getting hit. For F3 the rate-limiter was about 30,000 pps
refer to attached mail for more details.
Workaround:
itd scaling up, we will see rate-limiter getting hit. For F3 the rate-limiter was about 30,000 pps
refer to attached mail for more details.
Further Problem Description:
itd scaling up, we will see rate-limiter getting hit. For F3 the rate-limiter was about 30,000 pps
refer to attached mail for more details.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 08-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.459) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtr79909 |
Title: | N7K-M132XP-12 linecard reload, eobc errors reported on supervisor |
|
Description: | Symptoms:
N7K-M132XP-12 linecard might reload with the following messages:
%MODULE-4-MOD_WARNING: Module 1 (serial: XXXXXXXXXX ) reported warning due to
EOBC heartbeat failure in device 10 (device error 0xc000604f)
%MODULE-4-MOD_WARNING: Module 1 (serial: XXXXXXXXXX ) reported warning due to
EOBC heartbeat failure in device 10 (device error 0xc000604d)
%MODULE-2-MOD_NOT_ALIVE: Module 1 not responding... resetting (serial: XXXXXXXXXX)
Conditions:
This issue is seen with N7K-M132XP-12 on Nexus7000 running 5.x release.
Workaround:
None.
Linecard comes back up and resumes operation after reload.
Further Problem Description:
If the above issue is seen, please contact Cisco TAC.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-MAY-2015 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: | 5.2(6), 6.1(2) |
|
|
| |
| |
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: | 08-MAY-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)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), 7.1(0)PDB(0.141) |
|
|
| |
| |
Bug Id: | CSCup11149 |
Title: | isis_build_p2p_iih: Error ckt type when passive configured on interface |
|
Description: | Symptom:
adj is not up
Conditions:
with passive interface configured
Workaround:
restart isis
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-MAY-2015 |
|
Known Affected Releases: | 7.1(0.1) |
|
Known Fixed Releases: | 7.0(0)HSK(0.317), 7.1(0)D1(0.207), 7.1(0)FC(0.2), 7.1(0)GSD(99.0), 7.1(0)N1(0.258), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.18), 7.1(0)PDB(0.155), 7.1(0)RTG(0.12) |
|
|
| |
| |
Bug Id: | CSCun54357 |
Title: | SSTE: URIB crashed at urib_chlist_elem_delink_free |
|
Description: | Symptom:
The process urib might crash due to urib_chlist_elem_delink_free.
Conditions:
The symptoms is observed with RFC5549/MEv6/BGP-PIC with scale setup and during churns.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-MAY-2015 |
|
Known Affected Releases: | 6.2(7.12)S0, 6.2(7.19)S0, 6.2(7.21)S0, 6.2(8)IAS(0.15) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.30)S0, 6.2(8), 6.2(8)E1, 6.2(8)IAS(0.17), 6.2(9)FM(0.37), 7.0(0)BNZ(0.23), 7.1(0)D1(0.113), 7.1(0)FC(0.2), 7.1(0)NF(0.28) |
|
|
| |
| |
Bug Id: | CSCur57579 |
Title: | N7K: MTS queue (pers_q) buffer is getting full and LACP stops working |
|
Description: | Symptom:
%LACP-5-LACP_SUSPEND_INDIVIDUAL: LACP port Ethernet7/18(0x1a311000) of port-channel Ethernet7/18(0x1a311000) not receiving any LACP BPDUs suspending (individual) port
show inter eth152/1/10
Ethernet152/1/10 is down (Internal-Fail errDisable, port-channel: required service is not responding)
MTS messages destined to LACP (SAP 347) are stuck in the persistent
N7K#show system internal mts buffers summary
node sapno recv_q pers_q npers_q log_q
sup 347 0 128281 0 0
SAP 347 is LACP.
"sup" refers to default VDC, "sup-1" to 2nd VDC and so on.
This issue can happen in any VDC.
Conditions:
Currently the known condition is when the command "show lacp interface " is executed, and that interface using LACP.
this issue is seen when the Nexus is using either fast-rate or normal rate LACP PDU's.
Workaround:
Do not issue the "sh lacp int " command CLI, SNMP or through any automated scripts.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a) |
|
Known Fixed Releases: | 6.0(2)A5(1), 6.0(2)U5(1), 6.1(2)I3(2.16), 6.1(2)I3(2.21), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.8) |
|
|
| |
| |
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: | 08-MAY-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: | CSCuu22098 |
Title: | IFTMC miss-programmed on promiscuous port when secondary PVLAN deleted |
|
Description: | Symptom:
All ingress traffic on promiscuous is dropped.
Conditions:
When secondary PVLAN is deleted that is being mapped on a promiscuous port.
This has also been triggered when creating a VLAN that is already being mapped on promsicious port.
Workaround:
Shut/no shut the promiscuous port.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 08-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul76436 |
Title: | 6.2.5.70.S0: xbow: show commands not working - "Cannot allocate memory" |
|
Description: | Symptom:
cli interface is not working due to memory issue
Conditions:
none
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-MAY-2015 |
|
Known Affected Releases: | 6.2(5.67)S0, 6.2(5.70)S0, 7.1(0)D1(0.22), 7.1(0)D1(0.43), 7.1(0)D1(0.58), 7.1(0)D1(0.64), 7.1(0)VG(0.2) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(6), 6.2(6)S1, 6.2(6.1)S0, 6.2(6.13)S0, 7.0(0)FVX(0.87), 7.1(0)D1(0.117) |
|
|
| |
| |
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: | 08-MAY-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.2(0)AB(2), 7.2(0)BA(0.12), 7.2(0)D1(0.398), 7.2(0)N1(0.87), 7.2(0)N1(1), 7.2(0)OTT(0.5) |
|
|
| |
| |
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: | 08-MAY-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: | 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: | 08-MAY-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S3, 6.2(10.5), 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), 7.1(0)NF(0.28) |
|
|
| |
| |
Bug Id: | CSCut39102 |
Title: | stp disputes are seen during vdc reload in vPC + setup |
|
Description: | Symptom:In a VPC+ setup running MST and with a large scale logical port count , on reloading the primary peer, stp disputes may sometimes be seen on the secondary switch.
Conditions:*VPC+ scenario.
*Primary Peer reload
Workaround:More Info:If disputes occur, they will clear as soon as the secondary switches to Operational primary.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 08-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.441), 7.2(0)D1(0.451) |
|
Known Fixed Releases: | 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.2(0)BA(0.12), 7.2(0)D1(0.451), 7.2(0)D1(0.455), 7.2(0)D1(0.470), 7.2(0)RTG(0.143), 7.2(0)RTG(0.150), 7.2(0)VOF(0.2), 7.2(0)ZD(0.136) |
|
|
| |
| |
Bug Id: | CSCus57881 |
Title: | VPC PO continuously flapping when untagged frame statement exist |
|
Description: | Symptom:
When a profile containing a "untagged frame VNI" configuration is mapped to a vPC port channel the port channel will be unstable and continuously flap.
Conditions:
The issue will be seen with link level protocols like LACP etc. Due to the 'untagged VNI frame' configuration applied to the port, the following behavior is seen: the LACP untagged packet coming in hits the port profile and gets the VNI encapsulation. Then the VSI if index is determined when the packet reaches the SUP. The packet is then forwarded to the client (LACP in this case )with the physical if index value replaced by the VSI ifindex. The client expects the packet to contain the physical if index and not the VSI if index, this causes the port lookup to fail and the packet gets dropped at the client.
Workaround:
NONE
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 09-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.386) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 09-MAY-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: | 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: | 09-MAY-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: | 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: | 10-MAY-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: | CSCtz53329 |
Title: | Standby sup stuck in powered-up: syslogd failed to store its snapshot |
|
Description: | Symptom:
This bug affects both Nexus 7000 and MDS platforms.
Standby supervisor reloads continuously. show logging nvram
contains the following messages:
%SYSMGR-2-GSYNC_SNAPSHOT_SRVFAILED: Service "syslogd" on active supervisor
failed to store its snapshot (error-id 0x80480018).
%SYSMGR-2-STANDBY_BOOT_FAILED: Standby supervisor failed to boot up.
Conditions:
This issue only occurs if the standby supervisor reloads many times.
Workaround:
None. Contact Cisco TAC to recover from this issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-MAY-2015 |
|
Known Affected Releases: | 5.2(2d), 5.2(4) |
|
Known Fixed Releases: | 5.2(4.80)S0, 7.0(1)ZD(0.3) |
|
|
| |
| |
Bug Id: | CSCtk36830 |
Title: | Snmpd doesn't respond after KERNEL-2-SYS-MSG started appearing. |
|
Description: | Symptoms:
In Nexus7000, SNMP process stop responding after reporting KERNEL-2-SYS-MSG messages.
Conditions:
This issue is seen in Nexus7000 running 5.x releases.
Workaround:
None.
This issue should be fixed in 5.2(1) or later releases.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 5.2(0.137), 5.2(0.154), 5.2(0.154)S11, 5.2(0.41), 5.2(0.84) |
|
Known Fixed Releases: | 5.2(0.176)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCtn64672 |
Title: | l2fm crash if too many MAC address move over vpc peer link |
|
Description: | Symptom:
If there are too many mac address moves over vpc peer link.
Somtimes, only the process l2fm crash. Sometimes the chassis may
reload. Show system reset-reason shows that the reload reason is
caused by l2fm hap reset.
Conditions:
The exact condition is unknown. Issue has been seen in 5.1(x), 5.2(3a), 6.0(2) and below.
Workaround:
None. Upgrading to 5.2(4), 6.0(3), or later will resolve issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 5.1(2), 5.2(3.38), 5.2(3a) |
|
Known Fixed Releases: | 5.2(4)S1, 5.2(4.1)S0, 6.0(2)E1, 6.0(3)S1, 6.1(1) |
|
|
| |
| |
Bug Id: | CSCuo24939 |
Title: | Memory leak when modifying ACLs |
|
Description: | Symptom:
A memory leak in the aclmgr process is seen. After checking the memory we see the following is leaking:
Lib ID: 0x1
Mem stats for UUID : Non mtrack users(0) Max types: 177
--------------------------------------------------------------------------------
TYPE NAME ALLOCS BYTES
CURR MAX CURR MAX
2 [r-xp]/isan/plugin/0/isan/bin/aclmgr 5285752 5285756 363171903 363181841
The leak will eventually lead to a process crash and could result in a system reload due to a HAP Reset.
Conditions:
This issue is seen while a script dynamically modifies ACLs. We are still looking into the exact conditions of this issue.
This leak happens when user is using "configure session" to configure ACLs.
It is also seen if user configures time-ranges.
Workaround:
Do not use configure session to configure ACLs dynamically.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S73, 6.2(2a) |
|
Known Fixed Releases: | 6.1(2)I3(2.10), 6.1(2)I3(3), 6.2(10), 6.2(10)FM(0.28), 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.0(3)I1(0.138) |
|
|
| |
| |
Bug Id: | CSCus14797 |
Title: | Unexpected VDC reset and aclmgr core created |
|
Description: | Symptom:
A Nexus 7000 running 6.2(8a) has faced an unexpected reset of one of its VDCs. After the reset, that VDC was not booting up properly and its interfaces were listed in state 'unknown'. A few minutes later, an aclmgr core file was written:
`show cores`
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
3 5 1 aclmgr 22993 2014-12-08 15:27:29
Conditions:
ACL changes were made prior to the issue.From the crash decode, it seems like crash has happened while issuing "show startup config"
Workaround:
Unknown
Further Problem Description:
We tried really hard to repro from dev side but could not able to repro it.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 11-MAY-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) |
|
|
| |
| |
Bug Id: | CSCuc37616 |
Title: | SNMPd crashed on ACSII replay of config file |
|
Description: | Symptom:
Nexus 7000 may experience a crash at the snmpd process.
Conditions:
MTS buffers may leak and after a few minutes, triggers snmpd to crash.
KERN-2-SYSTEM_MSG [ 7920.428773] mts_is_q_space_available_new(): NO SPACE
Workaround(s):
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 5.2(8)S1, 6.1(0.198)S3, 6.1(0.237)S7, 6.1(2), 6.1(3)S4, 6.2(0.283)S0, 6.2(0.284)S19, 6.2(0.284)S5, 6.2(0.285)S1, 6.2(0.294)S2 |
|
Known Fixed Releases: | 6.1(3.25)S0, 6.1(3.32)S0, 6.1(4.1)S0, 6.1(5), 6.2(0.282)S0, 6.2(0.286)S0, 6.2(1.93), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCui33374 |
Title: | 622.S19:: vsh core see in fex_xbow_f2e |
|
Description: | Symptom:
VSH Crashed when show accounting log is triggered.
Conditions:
When we execute show accounting log / show tech support which will trigger show accounting log
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 6.2(2)S19 |
|
Known Fixed Releases: | 6.0(2)U3(0.646), 6.0(2)U3(1), 6.0(2)U4(0.60), 6.0(2)U4(1), 6.1(2)I3(2.26), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 6.2(2), 6.2(2)S24 |
|
|
| |
| |
Bug Id: | CSCua39287 |
Title: | System reloads due to TACACS+ process crash |
|
Description: | Symptom:
NX-OS system running 5.2.5 may reload due to TACACS+ process crash.
Conditions:
This issue may occur when TACACS+ is configured for remote accounting. It is caused by a high rate of invalid accounting packets (2 to 3 every second) which create "invalid_ip@" records in the accounting log. This may be confirmed with the following command:
show accounting log | i invalid_ip@
Workaround:
Disable the remote accounting for tacacs.
This can done by removing the aaa accounting config statement for tacacs.
ex:
switch(config)# no aaa accounting default xxxx
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 5.2(5)S8 |
|
Known Fixed Releases: | 5.2(1)N1(5), 5.2(6)S14, 5.2(6.16)S0, 5.2(7), 6.1(1)S39, 6.1(1.41)S0, 6.1(1.69), 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCul35819 |
Title: | BPDUGuard not Activated on Disallowed Edge Trunk VLANs |
|
Description: | Symptom:
BPDUs from a remote device do not activate BPDUGuard on an edge trunk port.
Conditions:
- Remote device misconfigured as an access port
- VLAN on access port is not in the allowed VLAN list of the edge trunk
Workaround:
Configure both sides of the link correctly as either trunks or access interfaces.
Further Problem Description:
A loop can occur on redundant connections when the untagged access side traffic loops into the native VLAN on the trunk side of the link. The loop can be prevented by not allowing the native VLAN on the link.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | 6.0(2)A4(0.810), 6.0(2)A4(1), 6.0(2)U4(0.810), 6.0(2)U4(1), 6.1(2)I3(1.26), 6.1(2)I3(2), 6.2(10), 6.2(10)EC(0.10), 6.2(10)FM(0.18), 6.2(10)NO(0.19) |
|
|
| |
| |
Bug Id: | CSCtw84257 |
Title: | nexus 7010 crash on CoPP during manual switchover after ISSU |
|
Description: | Symptom:
nexus 7010 crash on CoPP and All LED of LC turned RED expect supervisor engine
network outage happened at this moment
cores has generated
`show cores`
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
1 5 1 copp 7013 2011-11-30 18:00:44
1 5 1 copp 4511 2011-11-30 18:00:48
Conditions:
upgraded from 5.1.3 to 5.1.4 using ISSU and then manual swichover
Workaround:
reload chassis
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 5.1(3), 5.1(4) |
|
Known Fixed Releases: | 5.2(4)S7, 5.2(4.8)S0 |
|
|
| |
| |
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: | 11-MAY-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) |
|
|
| |
| |
Bug Id: | CSCug81339 |
Title: | Service "Security Daemon" crashes with heartbeat failure |
|
Description: | Symptom:
Security Daemon crashes with heardbeat failure with the following output in logs
%SYSMGR-3-HEARTBEAT_FAILURE: Service "Security Daemon" sent SIGABRT for not setting heartbeat for last 6 periods. Last heartbeat 3
88.97 secs ago.
%SYSMGR-2-SERVICE_CRASHED: Service "Security Daemon" (PID 6144) hasn't caught signal 6 (core will be saved).?
Note, this bug applies to Nexus 1000V switch also for 5.2(1)SM1, and 4.2(1)SV2
Conditions:
No specific conditions, can occurr randomly
Workaround:
Unknown
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-MAY-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | 6.2(3), 6.2(8) |
|
|
| |
| |
Bug Id: | CSCua21616 |
Title: | tacacs process crashed while running codenomicon authentication suite |
|
Description: | Symptom:
tacacs servcie crash on sup on Nexus 7k
Conditions:
When running authentication suite attack from Codenomicon test tool the "tacacs" service is crashing.
Workaround:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-MAY-2015 |
|
Known Affected Releases: | 6.1(0.293)S0 |
|
Known Fixed Releases: | 6.0(2)A1(1b), 6.0(2)U1(2), 6.1(1)S14, 6.1(1.13)S0, 6.2(0.217), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCtn97658 |
Title: | statsclient mts buffer leak |
|
Description: |
Clear mts buffer anytime this happens, using the following hidden debug command:
debug mts drop node [node] sap [sap] from [Queue] opcode [opcode] age [seconds]
The values for the command, can be found out from the output of "show sys
internal mts buffers detail"
Example:
show sys internal mts buffers detail:
Node/Sap/queue Age(ms) SrcNode SrcSAP DstNode DstSAP OPC MsgId MsgSize
sup/2582/recv 2400964154 0xE02 980 0x901 2582 26 100560 840
debug mts drop node sup sap 2582 from recv opcode 26 age 2400964154
Symptom:
Processes can not communicate with statsclient process on that module
(affecting statistics collection on a module). slow switch response when
entering commands , portchannel malfunction or the KERN-2-SYSTEM_MSG logging
messages.
KERN-2-SYSTEM_MSG mts_print_longest_queue_state: opcode counts for first and
last 50 messages in recv_q of sap 2582: - kernel
KERN-2-SYSTEM_MSG mts_print_msg_opcode_in_queue: opcode 26 - 100 messages -
kernel
KERN-2-SYSTEM_MSG mts_do_msg_input() failing since no space available in 2582
(src_sap = 2582, opc = 26) - kernel
Conditions:
When the linecard CPU is busy. (cpu being busy is the cause of the mts buffers
leak. Not viceversa).
Under rare conditions when processor is busy, there can be mts buffer leak when
the statsclient process is unable to respond to requests within specified time
limit. If this rare condition persists for months, then processes cant
communicate with statsclient process on that module (affecting statistics
collection on a module).
Workaround:
Clear mts buffer anytime this happens, using the following hidden debug command:
debug mts drop node [node] sap [sap] from [Queue] opcode [opcode] age [seconds]
The values for the command, can be found out from the output of "show sys
internal mts buffers detail"
Example:
show sys internal mts buffers detail:
Node/Sap/queue Age(ms) SrcNode SrcSAP DstNode DstSAP OPC MsgId MsgSize
sup/2582/recv 2400964154 0xE02 980 0x901 2582 26 100560 840
debug mts drop node sup sap 2582 from recv opcode 26 age X
X (Age value) has to be be a small value in the range that the command accepts, like 10.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-MAY-2015 |
|
Known Affected Releases: | 5.0(5), 5.3(0.112), 6.0(0.1) |
|
Known Fixed Releases: | 5.2(1)S40, 5.2(1.46)S0, 5.3(0.185)S0, 6.0(0.2)S0 |
|
|
| |
| |
Bug Id: | CSCud76710 |
Title: | SNMPD crashes when writing invalid OID |
|
Description: | Symptom:
snmpd crashes when performing set operation for OID 1.3.6.1.4.1.9.9.367.1.3.1.1.8
Conditions:
When a set operation is performed for OID 1.3.6.1.4.1.9.9.367.1.3.1.1.8 (cAAAServerProtoDirectedReq).
the valid writable OID for cAAAServerProtoDirectedReq are 1.3.6.1.4.1.9.9.367.1.3.1.1.8.1 and 1.3.6.1.4.1.9.9.367.1.3.1.1.8.2
Workaround:
N/A
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-MAY-2015 |
|
Known Affected Releases: | 6.2(0.287)S8 |
|
Known Fixed Releases: | 6.2(1)S6, 6.2(1.11)S0, 6.2(2), 7.0(0.5) |
|
|
| |
| |
Bug Id: | CSCuj75984 |
Title: | Polling of cbqos-mib will cause the device to crash, frequently |
|
Description: | Symptom:
Sup experiences crashes causing service interruption.
Conditions:
Frequent polling of the cbqos-mib.
This problem is also observed when issuing show policy-map interface command.
Workaround:
If disabling SNMP is an option, please consider disabling it.
Further Problem Description:
Will be provided soon
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-MAY-2015 |
|
Known Affected Releases: | 6.1(3), 6.2(5)BF(0.51), 6.2(5.45)S2, 6.2(5.62)S0 |
|
Known Fixed Releases: | 6.1(2)I3(1), 6.1(4.94)S0, 6.1(5), 6.2(0)HS(0.10), 6.2(5)BF(0.52), 6.2(5.71)S0, 6.2(6) |
|
|
| |
| |
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: | 12-MAY-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)ZN(0.174) |
|
|
| |
| |
Bug Id: | CSCuq22841 |
Title: | M1 Module: Invalid COS (0x41040021) after ISSU from 5.2(x) to 6.2(x) |
|
Description: | Symptom:
Ports are not allocated to a secondary VDC with the following logs:
2014 Jul 24 16:14:26.864 N7K %IM-3-IM_RESP_ERROR: Component MTS_SAP_VMM opcode:MTS_OPC_IM_IF_VDC_BIND in vdc:2 returned error:Invalid COS value.
2014 Jul 24 16:14:35.568 N7K last message repeated 1 time
2014 Jul 24 16:14:35.568 N7K %VDC_MGR-3-VDC_ERROR: vdc_mgr: Error for port Ethernet . Port is currently in vdc N7K-VDC2 [2]. GIM returned 41040021 [Invalid COS value.]. Please run the command "allocate interface Ethernet force" to try again
In 'show vdc membership status' we see the following as the reason for the ports not being allocated: 'ERROR:Invalid COS value. (0x41040021)'.
Conditions:
- ISSU from 5.2(x) to 6.2(x)
- M1 Module
Workaround:
Reload affected module.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 12-MAY-2015 |
|
Known Affected Releases: | 6.2(8a), 6.2(8a)S3 |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 12-MAY-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: | 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: | 13-MAY-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: | 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: | 13-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu01306 |
Title: | L3vpn::Post HA, CE2 vrf has incorrect routing info |
|
Description: | SYMPTOM
After a switchover, routes in the unicast RIB are incorrect. Routes which
were in one VRF before the switchover are in a different VRF afterwards.
CONDITION
WORKAROUND
None
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 13-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut67131 |
Title: | ACL_Deny misprogrammed on F1 when creating a new VDC |
|
Description: | Symptom:
When creating a new VDC,
Broadcast packets may loop from one VPC member, across the peer link, and out the other VPC member.
Conditions:
Only seen on a Nexus 7000 switch using F1 Linecards running 6.2
Workaround:
To recover from this state after shut/no shut the VPC member on the F1 modules which is looping the broadcast.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 13-MAY-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur67753 |
Title: | Module reload due to (null) reason |
|
Description: | Symptom:
Linecard reload during the switchover
Conditions:
not known
Workaround:
not known
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 13-MAY-2015 |
|
Known Affected Releases: | 5.2(9) |
|
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: | 13-MAY-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: | 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: | 14-MAY-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: | CSCuh56328 |
Title: | netstack panic when closing the socket with sbuff lock acquired |
|
Description: | Symptom:
The Netstack process will panic and crash with syslogs similar to the following:
NETSTACK-2-PANIC netstack [pid] sbflush: locked: PANIC: (null)
%$ VDC-1 %$ SYSMGR-2-SERVICE_CRASHED Service "netstack" (PID pid) hasn't caught signal 6 (core will be saved).
Conditions:
This issue is seen when Netstack attempts to close a TCP or UDP socket and is unable to due to an internal data structure being in an unexpected state
Workaround:
None
More Info:
N/A
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 14-MAY-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | 5.2(1)N1(7.120), 5.2(1)N1(8), 5.2(9.189)S0, 6.0(2)N2(5.90), 6.0(2)N2(6), 6.0(2)U3(0.642), 6.0(2)U3(1), 6.1(4.97)S0, 6.1(5), 6.1(5.32)S0 |
|
|
| |
| |
Bug Id: | CSCun86405 |
Title: | Orphan Ports on FEX have the MAC learnt on ES ID instead of local SWID |
|
Description: | Symptom:
Orphan ports connected over FEX HIF may observe traffic getting black holed due to incorrect learning of MAC address in a VPC+ domain.
The MAC is learned from Emulated SWID (ESID) instead of Local SWID as observed on other switches in FabricPath Domain.
On the problem switch:
Software MAC learning would pick on the right physical port, though hardware MAC tables would shows MAC learned from ESID instead of Local SWID.
Conditions:
Problem may trigger if ports which were part of VPC+ complex (VPC port-channel) and were then moved to FEX-Fabric mode using channel-group force option.
This does not clear the register setting properly and MAC learning still picks on ESID as is treated to be coming across a VPC+ Port-channel.
This is the only known and analyzed trigger though may not be the only one.
Workaround:
- Shutdown the affected Ports.
- Move them out of FEX Fabric PO.
- Make them regular Access or Trunk ports (not VPC)
- Unshut them. >>>>>>>>> If FET's (Fabric Extender Transceiver) are used then once these ports are taken out from FEX Fabric mode FET SFP's would fail validation hence software state machine would not be complete to unset the corresponding registers. "service unsupported-transceiver" will help bypass validation checks.
- Move ports back to FEX-Fabric mode. This should clear the problem.
Further Problem Description:
N7k-switch# sh mac address-table address 0000.0000.0001
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False
VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+------------------
* 106 0000.0000.0001 dynamic 0 F F Eth150/1/2 >>>>> Here it looks correct
Module-X# show hardware mac address-table address 0000.0000.0001
FE | Valid| PI| BD | MAC | Index| Stat| SW | Modi| Age| Tmr| GM| Sec| TR| NT| RM| RMA| Cap| Fld|Always| PV | RD| NN| UC|PI_E8| VIF | SWID| SSWID| LID
1 1 1 32 0000.0000.0001 0x012d1 0 0x089 1 35 1 0 0 0 0 0 0 0 0 0 0x00 0 0 1 0 0x004 0x2de 0x001 0x012d1
SWID is picked as ESID and not as local SWID. Hardware MAC table will reflect the problem.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-MAY-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.17), 6.2(8)TS(0.28), 6.2(9.1)S0, 7.1(0)D1(0.162), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)OTT(0.4), 7.1(0)PDB(0.92), 7.1(1)SP(0.4) |
|
|
| |
| |
Bug Id: | CSCtw77593 |
Title: | ERROR: Entry not found in copp database while apllying custom copp polic |
|
Description: | Symptom:
Modifying the CoPP profile or CoPP policy throws error "ERROR: Entry not found in copp database"
Conditions:
The issue happens when a reload based upgrade is performed.
Workaround(s):
Please follow the below steps:
1) Reload the switch with NX-OS version where the CoPP profile was last changed/applied
2) Removing the current CoPP profile
3) Upgrade the switch to the newer version and apply the new CoPP profile or CoPP policy
Description:
CoPP uses shadow database to delete the current CoPP profile if the current software version and CoPP profile version are different. Shadow database is created only when the install all based upgrade is performed. It is not created for reload based upgrade.
The issue is fixed by creating shadow database when the running-config is stored as startup-config. So that the shadow database can also be used to delete the CoPP profile when the reload based upgrade is performed. In case if the shadow database is not present, CoPP will delete the current CoPP profile by using the running CoPP database.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-MAY-2015 |
|
Known Affected Releases: | 5.2(3), 5.2(3)S24 |
|
Known Fixed Releases: | 5.2(3.44)S0, 6.1(1) |
|
|
| |
| |
Bug Id: | CSCun74286 |
Title: | MCQ of VEQ block returns dummy data when the queue is not empty |
|
Description: | Symptom:
The tests sends a lot of enqueue to reach a condition of full queue, however before the queue is completely full the rtl uncorrectly returns dummy data in response to dequeue even though the queue is not empty.
on 03/13/2014 the run at
==========
/auto/nvbu-asic20/users/icozzani/voq/2014_02_21/ip_waverider/sim/linked_list/veq/runs
test_basic_random_Nenq_Ndeq_full_930432259_p0_FAIL_RTL_DUMMY
there is a dummy returned on port 0 queue5 when there are 121 entries in that queue.
@ 3154.243 ns: [MSG] num_entries[port_sel=0][pri=0] = 84
@ 3154.243 ns: [MSG] num_entries[port_sel=0][pri=1] = 102
@ 3154.243 ns: [MSG] num_entries[port_sel=0][pri=2] = 111
@ 3154.243 ns: [MSG] num_entries[port_sel=0][pri=3] = 105
@ 3154.243 ns: [MSG] num_entries[port_sel=0][pri=4] = 117
@ 3154.243 ns: [MSG] num_entries[port_sel=0][pri=5] = 121
@ 3154.243 ns: [MSG] num_entries[port_sel=0][pri=6] = 102
@ 3154.243 ns: [MSG] num_entries[port_sel=0][pri=7] = 112
@ 3154.243 ns: [MSG] Generating DEQ = 146 - DEQ pid(0) qid(6) ipg(0x1)
@ 3154.243 ns: [MSG] [mcq_ref_t::process_deq_cmd] Received DEQ pid(0) qid(3)
@ 3154.243 ns: [MSG] [mcq_ref_t::process_deq_cmd] Popped list entry DEQ RSP portid(0) qid(3) pkt_ptr(0x5a) pkt_len(5595) err_drop(1) is_mr(0)
@ 3154.243 ns: [ERROR] [mcq_ref_t::check] Data mismatch RTL: (DEQ RSP portid(0) qid(5) DUMMY) REF EXP: (DEQ RSP portid(0) qid(5) pkt_ptr(0x3c) pkt_len(9398) err_drop(1) is_mr(0))
On 03/13/2014 From PD:
=================
I think I know what is causing this.
Can you please rerun the test by skipping the dummy descriptor and proceeding without halting the test?
Thanks
-PD
[icozzani] On 03/14/2014
==========
I have removed the test ending when the checker compares a dummy from rtl with a correct data from ref.
The run is at
/auto/nvbu-asic20/users/icozzani/voq/2014_02_21/ip_waverider/sim/linked_list/veq/runs/
test_basic_random_Nenq_Ndeq_full_930432259_p0_disable_dummy_check_fail
There is first DUMMY at time 3154 from p0 q5
@ 3154.243 ns: [MSG] [mcq_deq_mon_t::run] Received DEQ RSP portid(0) qid(5) DUMMY
the test does not stop, just prints a warning and continues:
@ 3154.243 ns: [WARN] [mcq_ref_t::check] WARN RTL DUMMY Data mismatch (DEQ RSP portid(0) qid(5) DUMMY) EXP (DEQ RSP portid(0) qid(5) pkt_ptr(0x3c) pkt_len(9398) err_drop(1) is_mr(0))
===> There are no more data coming from port0 queue5 after that: why the correct data does not come back?
Then there is a second DUMMY at time 3164 from port0 queue 6
@ 3162.247 ns: [MSG] [mcq_ref_t::process_deq_cmd] Received DEQ pid(0) qid(6)
@ 3162.247 ns: [MSG] [mcq_ref_t::process_deq_cmd] Popped list entry DEQ RSP portid(0) qid(6) pkt_ptr(0x4a) pkt_len(14706) err_drop(1) is_mr(0)
@ 3164.915 ns: [MSG] [mcq_deq_mon_t::run] Received DEQ RSP portid(0) qid(6) DUMMY
with the following warn printed
@ 3164.915 ns: [WARN] [mcq_ref_t::check] WARN RTL DUMMY Data mismatch
(DEQ RSP portid(0) qid(6) DUMMY)
EXP (DEQ RSP portid(0) qid(6) pkt_ptr(0x4a) pkt_len(14706) err_drop(1)
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 14-MAY-2015 |
|
Known Affected Releases: | 1 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu13792 |
Title: | VPC doesn't come up after HMM is enabled |
|
Description: | Symptom:
VPC peer-link comes up
Conditions:
two sides of port-channel mismatch
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 14-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj81916 |
Title: | pim core when rp-candidate configured with tunnel |
|
Description: | Symptom:
PIM crashes when an RP-candidate is configured with a group-list and some \
previous RP candidate configuration already exists
Conditions:
Multicast Bootstrap Router is configured
Workaround:
Remove all previous RP-candidate configurations prior to applying any new Randezvous Point candidates.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-MAY-2015 |
|
Known Affected Releases: | 6.2(5.20)S1 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(5)BF(0.38), 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.127), 7.0(0)ZN(0.25), 7.0(1)N1(0.47), 7.0(1)N1(1) |
|
|
| |
| |
Bug Id: | CSCup90140 |
Title: | eth_port_sec cores and hap reset on violation after ISSU to 6.2.8a |
|
Description: | Symptom:
service-eth_port_sec crashes
Conditions:
N7k|SUP1|F1|6.2(8a) with ports enabled with port security
Workaround:
none
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 15-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 15-MAY-2015 |
|
Known Affected Releases: | 6.1(2), 6.2(1.121)S1, 6.2(1.121)S2 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj64557 |
Title: | N77-F3 : Module failed - not responding due to eUSB access failure |
|
Description: | Symptom:
The eUSB (Embedded USB) module installed internally on the N77 F3 linecard may fail to respond to accesses from the local processor. Any of the following symptoms may be experienced when this occurs. (For Log examples please see the More-Info section).
(1) Line card gets kernel panic during runtime and is reloaded. "show logging onboard stack-trace" can be used to confirm this.
(2) Line card is not reloaded but experiences eUSB failure during runtime.
The following command can be used to check for eUSB failure : "show system internal kernel messages".
(3) Line card had PLOG failure and ISSU is performed on the failed module. ISSU will fail and line card will be reloaded with Upgrade Failure.
Conditions:
The access failure to the eUSB module on F3 linecard is related to a USB component marginality. It may occur with low probability of occurrence, on a limited set of hardware which uses the marginal component.
The list of serial numbers potentially susceptible to this failure mode is as below , a total of 113 units.
However it may be noted that only a subset of this list will actually experience any symptoms during operation.
N77-F312CK-26 [34 units]
JAE18050366 JAE18050365 JAE1805035Y JAE1805035U JAE1805035Z JAE18050360 JAE18050361 JAE18050367 JAE18050362 JAE18050363 JAE18050364 JAE1805035X JAE1805035W JAE1805035T JAE1805035S JAE18050368 JAE1805035J JAE1805035H JAE1805035L JAE1805035R JAE1805035Q JAE1805035P JAE1805035N JAE18050359 JAE18050358 JAE18050356 JAE18050357 JAE1805035D JAE1805035C JAE1805035A JAE1805035B JAE1805035E JAE1805034W JAE1805034X
N77-F324FQ-25 [30 units]
JAE17500CM3 JAE17500CME JAE17500CM6 JAE17500CM5 JAE17500CSB JAE17500CM1 JAE17500CLW JAE17500CLX JAE17500CSC JAE17500CLV JAE17500CLB JAE17500CM4 JAE17500CLZ JAE17500CLC JAE17500CLD JAE17500CLE JAE17500CLF JAE17500CLG JAE17500CLH JAE17500CLJ JAE17500CLM JAE17500CLN JAE17500CLP JAE17500CLQ JAE17500CLS JAE17500CLU JAE17500CLY JAE17500CM0 JAE17500CSD JAE17500CSE
N77-F348XP-23 [49 units]
JAE18040172 JAE18040173 JAE18040174 JAE18040175 JAE18040176 JAE18040177 JAE18040178 JAE18040179 JAE1804017A JAE1804017B JAE1804017C JAE1804017D JAE1804017F JAE1804017G JAE1804017H JAE1804017J JAE1804017K JAE1804017L JAE1804017M JAE1804017N JAE1804017R JAE1804017S JAE1804017T JAE1804017U JAE1804017V JAE1804017W JAE1804017X JAE1804017Y JAE18040180 JAE18040181 JAE18040182 JAE18040183 JAE18040184 JAE18040185 JAE18040186 JAE18040187 JAE18040188 JAE1804018A JAE1804018B JAE1804018C JAE1804018D JAE1804018E JAE1804018F JAE1804018G JAE1804018H JAE1804018J JAE1804018K JAE1804018L JAE180708R4
Other F3 PIDs and Serial Numbers which do not belong to this list are NOT affected.
Workaround:
None . If a unit in the susceptible serial number list experiences a listed symptom , please replace the unit by RMA.
Further Problem Description:
Log Examples
-------------------
==================================================================
(Case 1) Kernel panic and linecard reload : "show logging onboard stack-trace".
==================================================================
#0 0xc04ed4a8 in mark_buffer_dirty (bh=0xef63aab8) at
/auto/andfreetown14/LUP/tree/third-party/src/linux/kernel/wrl3/linux-2.6.27
_wrl30/fs/buffer.c:1191
#1 0xc0527dd8 in ext3_commit_super (sb=0xeef97400, es=0xeffcb400, sync=1) at
/auto/andfreetown14/LUP/tree/third-party/src/linux/kernel/wrl3/linux-2.6.27
_wrl30/fs/ext3/super.c:2266
#2 0xc05296e0 in ext3_handle_error (sb=0xeef97400) at
/auto/andfreetown14/LUP/tree/third-party/src/linux/kernel/wrl3/linux-2.6.27
_wrl30/fs/ext3/super.c:175
#3 0xc05297a0 in __ext3_std_error (sb=0xeef97400, function=0xc06b6338 "ext3_ordered_writep
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-MAY-2015 |
|
Known Affected Releases: | 6.2(10)FM(0.35), 6.2(10)S67, 6.2(12)S29, 6.2(5.20)S1, 6.2(5.52)S0, 6.2(6)S23, 6.2(6a)S13, 7.1(0)D1(0.136), 7.1(0)D1(0.196) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCub50434 |
Title: | VTP packets looping on vpc |
|
Description: | Symptom:
After an issu upgrade or a supervisor switchover, a nexus 7000 series switch may send back a vtp packet on the same vpc it ingressed from. In DCI topology this can cause a storm of VTP packets between the nexus 7000 switches.
Conditions:
- Nexus 7000 switches are configured in vtp transparent mode
Workaround:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-MAY-2015 |
|
Known Affected Releases: | 5.2(5) |
|
Known Fixed Releases: | 5.2(1)N1(6), 5.2(6.28)S0, 5.2(7), 6.0(2)N2(1), 6.1(2.27), 7.2(0)D1(0.506) |
|
|
| |
| |
Bug Id: | CSCtf36357 |
Title: | n7k: Need ability to configure ingress netflow sampling with dhcp relay |
|
Description: | A Nexus 7000 switch does not currently support having ingress netflow sampling and DHCP relay configured on the same interface. We need this restriction removed.
Symptom:
When trying to configure the two features together you might see error message similar to:
%$ VDC-1 %$ %NFM-2-VERIFY_FAIL: Verify failed - Client 0x87000146, Reason: feature combination is not supported in tcam, Interface: Vlan601
Verify failed - Client 0x83000146, Reason: feature combination is not supported in tcam, Interface: Vlan601
Conditions:
none
Workaround:
When you remove the ip monitor netflow input, you need to bounce the l3 interface to take a effect.
Fix is available in 6.2(2)
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-MAY-2015 |
|
Known Affected Releases: | 4.2(2a), 4.2(3), 5.2(0.266) |
|
Known Fixed Releases: | 6.2(0.279)S0, 6.2(0.287)S0, 6.2(2), 7.0(1)ZD(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: | 15-MAY-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: | CSCuh20873 |
Title: | IPV6 default route URIB and UFIB inconsistency cause traffic drop |
|
Description: | Symptom:
In the customer testing setup, there are eBGP ECMP for IPv6 default route, which works fine at stable mode, but upon any path fail, the URIB and UFIB shows inconsistent, and UFIB point to th epath which is already down which cause traffic blackholed.
Conditions:
NONE
Workaround:
"clear ipv6 route 0::0/0" will cause default route reprogrammed, and can clear the issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-MAY-2015 |
|
Known Affected Releases: | 5.0(3)U5(1f) |
|
Known Fixed Releases: | 5.0(3)U5(1f), 5.2(1)N1(6), 6.0(2)N2(1), 6.0(2)U1(1a), 6.0(2)U1(2), 6.2(1.137)S0, 6.2(2), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCun60587 |
Title: | l3vm core while running config in vinci sanity |
|
Description: | Symptom:
l3vm core while running config in vinci sanity
Conditions:
A race condition when l3vm is terminated and restarted.
Workaround:
No.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.58) |
|
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)PDB(0.65), 7.1(0)SDN(0.6) |
|
|
| |
| |
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: | 16-MAY-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)OTT(0.5) |
|
|
| |
| |
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: | 16-MAY-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: | 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: | 16-MAY-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) |
|
|
| |
| |
Bug Id: | CSCuq27709 |
Title: | NX-OS:Peer router reload causes netstack core @ pc_fib_ip_loadshare_hash |
|
Description: | Symptom:
When a router connected to N7k is reloaded, N7k prints the message %SYSMGR-2-SERVICE_CRASHED: Service "netstack" and netstack crashes causing service disruption.
Conditions:
Directly connected router which is sending routing updates to Nx7K MUST be reloaded and a netstack crash is seen soon after the reload of peer router.
Workaround:
None
The fix for this bug has been committed to 6.2.10 and 6.2.8E9
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 16-MAY-2015 |
|
Known Affected Releases: | 6.2(8)E9 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S49, 6.2(8)E9, 7.1(0)D1(0.238), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.179) |
|
|
| |
| |
Bug Id: | CSCub21497 |
Title: | fails programing accesslist mts_msg Req_id 1956261 failed:aclqos failure |
|
Description: | Symptom:
%WCCP-1-SBADDFAIL: Unable to add WCCP subblock on
interface Vlan200: Error string: Verify failed in LC
with programming faulire on the port-channel
Conditions:
while redirect-list attached to wccp groups ,
when policy attached to port-channel interface
or
vlan having wccp policy attached to port-channel interface
Workaround(s):
feature restart by "no feature wccp" and "feature wccp"
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 5.2(9)S35, 6.1(1), 6.1(2), 6.2(1.150)S0, 6.2(2)S20, 6.2(5.38), 6.2(7.23) |
|
Known Fixed Releases: | 7.0(0)BNZ(0.23), 7.0(0)KM(0.64), 7.1(0)D1(0.131), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.55) |
|
|
| |
| |
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: | 18-MAY-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) |
|
|
| |
| |
Bug Id: | CSCuq81826 |
Title: | F3 Module: High Latency through Fabric |
|
Description: | Symptom:
High latency on traffic going through and F3 module.
Conditions:
- F3/F2 Module in f-series only chassis
- ISSU
- Incorrect COS-to-Queue Mapping
Workaround:
Reload module that shows incorrect queuing structure.
Further Problem Description:
Example of broken QoS Mapping:
'show system internal qos queuing config'
Egress Queuing for Ethernet3/2 [System]
-------------------------------------------
Template: 8Q8E
-----------------------------------------------------------------------------------
Queue Group Bandwidth% PrioLevel Shape% CoSMap BW(G/R/RR)
------------------------------------------------------------------------------------
8e-4q8q-out-q4 3 14 - - 5 (0/14/14)
8e-4q8q-out-q5 4 14 - - 0 (0/14/14)
8e-4q8q-out-q6 5 14 - - 7 (0/14/14)
8e-4q8q-out-q7 6 14 - - 6 (0/14/14)
8e-4q8q-out-q1 0 - 1 - 4 (-/-/-)
8e-4q8q-out-q2 1 14 - - 3 (0/14/14)
8e-4q8q-out-q3 2 14 - - 2 (0/14/14)
8e-4q8q-out-q-default 7 14 - - 1 (0/14/14)
Ingress Queuing for Ethernet3/2 [System]
-------------------------------------------
Trust: Trusted
Num Shared Descriptors: 3585
DSCP to Ingress Queue : Disabled
------------------------------------------------------------------------
Queue Group Qlimit% IVL CoSMap #Pgs #descr
------------------------------------------------------------------------
8e-4q8q-in-q-default 1 88 0 0-4,6-7 3516 128
8e-4q8q-in-q1 0 10 5 5 399 102
8e-4q8q-in-q4 3 1 - - 39 10
8e-4q8q-in-q3 2 1 - - 39 10
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S85, 6.2(10)S86, 6.2(10)S87, 6.2(10)S93, 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S84, 6.2(10)S90, 6.2(10)S95, 6.2(10)S96, 6.2(10.16)S0, 7.1(0)D1(0.318), 7.1(0)EV(0.116), 7.1(0)OTT(0.47), 7.1(0)PDB(0.256) |
|
|
| |
| |
Bug Id: | CSCur99677 |
Title: | EMC-ENTRANCE:Statsclient crash on ISSU from 629a to 6211 S6 |
|
Description: | Symptom:
Symptoms: When you do ISSU from older version like 629a to 6211S6 memory is leaking and stats client process will crash.
Conditions:
Issue happened in basic config setup during ISSU from 629a to 6211 S6 on MDS setup.
Its not easily reproducible.
Its a corner scenario where the counter which keeps track of how many memory blocks are assigned is getting corrupted.
Workaround:
Workaround fix is added to the ddts to reset the counter value to 0 after clearing the memory.
Actual fix will be added as a part of 6213.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 6.2(11)S6 |
|
Known Fixed Releases: | 6.2(13)FM(0.43), 6.2(13)GS(0.13), 6.2(13.1)S0, 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)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCud01394 |
Title: | N7K - F1 / F2 line card: Mac addresses out of sync across FEs |
|
Description: | Symptom:
Following a MAC Flap, the hardware MAC address table on a F1 or F2 modules will not have the same consistent entry across all the forwarding engines (FEs) when the vlan mode is CE and learning mode is non-conversational.
Conditions:
Issue is seen on F1 modules on 5.2(5).
Rapid mac move that happen between two FEs and there is a Flood to bd / flood to fabric miss in hardware
Workaround:
Clear the specific mac address
Fix is present from 5.2(9) onwards for F series cards.
Will this issue impact Nexus7009 running 6.1.3?
Yes. As Integrated-release says its fixed from 6.1.5 onwards for 6.1.x train and all future releases.
Is this issue F1 module specific??
No
Will N7K-F248XP-25E be impacted??
Yes. Fix is present from 6.1.5 onwards.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 5.2(4), 5.2(5) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S64, 5.2(9.113)S0, 5.2(9.114)S0, 6.1(4.3)S0, 6.1(5), 6.2(1.93), 6.2(2), 7.1(0)D1(0.14), 7.1(0)D1(0.15) |
|
|
| |
| |
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: | 18-MAY-2015 |
|
Known Affected Releases: | 5.2(4.72) |
|
Known Fixed Releases: | 5.2(4.85)S0, 5.2(7) |
|
|
| |
| |
Bug Id: | CSCuj16682 |
Title: | acl applied on mgmt interface only works when remove/apply after reload. |
|
Description: | Symptom:
acl applied on mgmt interfaces fail to act, after realod
Conditions:
Once the n7k is reloaded, acl applied on mgmt interface wont work,
checked for acl that blocks telnet to mgmt ip,
telnet seens to be sucessfull after realod, though acl was there to block tcp connections
Workaround:
remove and apply the acl on the mgmt interface after relaod.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 6.2(3), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S56, 6.2(10.16)S0, 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.228), 7.1(0)EB(99.2), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.179) |
|
|
| |
| |
Bug Id: | CSCuc41076 |
Title: | vPC: MST with Peer-Switch Blocking on non-vPC Link between Peers |
|
Description: | Symptom:
The MST instance going across the non-vPC link is being blocked
Conditions:
- MST
- Peer-Switch
- vPC Peer-Link and non-vPC link between Nexus 7000s
Workaround:
None.
Further Problem Description:
This is a design limitation with respect to how MST works with peer-switch.
With the vPC peer-switch feature, all the STP instances on the both peers uses the vPC MAC address as the bridge MAC address. Any MST instance irrespective of the type of VLANs it carries has this behavior. If we have any link (other than the Peer link), STP will put it in BLK state, even it carries non vPC VLANs.
There are three options to avoid hitting this issue:
- Disable peer-switch
- Use RPVST+ instead of MST
- Remove the non-vPC link and use the vPC peer-link for all VLANs
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 6.0(4), 6.1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo81673 |
Title: | F3: fln_em Process Causing High CPU on Module |
|
Description: | Symptom:
High CPU on F3 module due to fln_em process:
module-1# show processes cpu sort | ex 0.0
CPU utilization for five seconds: 72%/0%; one minute: 72%; five minutes: 72%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
----- ----------- -------- ----- ------ ------ ------ --- -----------
1171 1384294340 528081 2621 49.86% 49.98% 49.99% - fln_em
...
Conditions:
- Mix of 1G and 10G/40G/100G ports
- 6.2(8), 6.2(8a), or 6.2(8b)
Workaround:
None. Issue causes no functional impact.
Further Problem Description:
The reason for the high CPU usage is due to parallel link polling routines (run every 20 ms) checking the port link status for 1G and other port speeds.
In 6.2(10) and later only one polling routine will be run at a time.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 6.2(8), 6.2(8)S35 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S2, 6.2(10.5), 6.2(8)E5 |
|
|
| |
| |
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: | 19-MAY-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.2(0)D1(0.504), 7.2(0)ZD(0.184) |
|
|
| |
| |
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
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 19-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 19-MAY-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, 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), 7.2(0)D1(0.463) |
|
|
| |
| |
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: | 19-MAY-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)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), 7.2(1)N1(0.1) |
|
|
| |
| |
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: | 19-MAY-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)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), 7.2(1)N1(1) |
|
|
| |
| |
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: | 19-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8a)S2 |
|
Known Fixed Releases: | 6.2(14)FB(0.28), 7.0(0)HSK(0.433), 7.2(0)D1(0.479), 7.2(0)ZD(0.159) |
|
|
| |
| |
Bug Id: | CSCuu15436 |
Title: | Service "ipqosmgr" in vdc x hap reset |
|
Description: | Symptom:
Multiple ipqosmgr process crashes occur leading to a sup reload. The reset-reason shows:
Reason: Reset triggered due to HA policy of Reset
Service: Service "ipqosmgr" in vdc X hap reset
Version: 6.2(10)
Conditions:
The crashes occurred after making changes to the QoS config.
Workaround:
Not known
Further Problem Description:
The following symptoms may be observed as well:
- VDC in failed state
- Standby SUP in powered-up state
- Redundancy status shows "HA synchronization in progress".
In order to bring up the VDC and the standby SUP - reboot the switch or delete the VDC and re-configure it.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 19-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 19-MAY-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: | CSCuu35748 |
Title: | Post ISSU L2VPN pseudowires don't come UP after reload Peer |
|
Description: | Symptom:
MPLS / L2VPN / L3VPN service updates not processed in F3 card after ISSU. Updates after ISSU might also cause loss of existing MPLS / L2VPN / L3VPN connections. This happens when F3 is a part of a VDC that already has MPLS configured in it.
Conditions:
ISSU from 6.2.x to 7.2 with MPLS / L2VPN / L3VPN enabled on M2-F3 vdc.
Workaround:
Reload the F3 module after ISSU before any further updates on MPLS / L2VPN / L3VPN
Further Problem Description:
n/a
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 19-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.508) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc32563 |
Title: | Linecard reload may trigger multicast packet loss |
|
Description: | Symptom:
Following a linecard reload, silent multicast loss (no syslog) might occur. The impacted multicast traffic will experience complete or near complete packet loss. The issue is related to the multicast distribution (MD) destination index (DI) not programmed correctly for the affected groups.
Conditions:
Issue is seen following linecard(s) reload(s).
Workaround:
Clear ip mroute *
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-MAY-2015 |
|
Known Affected Releases: | 6.1(2)S5, 6.2(1.23), 6.2(1.23)S3, 6.2(2)S40, 6.2(5.38), 6.2(5.52)S3, 6.2(6)S11, 6.2(6)S3, 6.2(8)S0 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S5, 6.2(10.5) |
|
|
| |
| |
Bug Id: | CSCuo22348 |
Title: | port-state request triggers burst of bpdu's from VPC primary switch. |
|
Description: | Symptom:
Nexus 7000 switch may exhibit excessive TX inband traffic rates affecting control-plane services after attempting to collect show interface trunk command output.
Bug is not specific to show int trunk command. It can happen anytime port state info request event is processed.
Request may come via SNMP request or another show command.
Check output of "sh hardware internal cpu-mac inband stats" for TX packet rate. With this bug, TX rate shoots up very high.
N7K1# sh hardware internal cpu-mac inband stats | in rate
Packet rate limit ........... 64000 pps
Rx packet rate (current/max) 1 / 16 pps
Tx packet rate (current/max) 15215 / 18753 pps <<====
AND
Check for below logs in the output of "show spanning-tree internal interactions".
+++++++++++++++++++++
1080) Event:(null), length:87, at 988005 usecs after Wed Oct 29 10:26:46 2014
stp_send_bpdu_now(4995): Start: reason During handling of port state info request
1081) Event:(null), length:85, at 980152 usecs after Wed Oct 29 10:26:46 2014
stp_send_bpdu_now(5017): End: reason During handling of port state info request
++++++++++++++++++++++
Conditions:
Nexus 7000 running 6.2(2) or later release with a high VLAN count. Whenever a port-state request is sent to STP, there are additional BPDUs sent out for each STP logical port in the system.
Workaround:
Do not use the command.
If using AAA with command authorization, the commands may be blocked in the ACS profile.
Further Problem Description:
To monitor CPU-Mac inband stats during an event use show hardware internal cp-mac statistics. The Tx rate increases drastically.
Rx packet rate (current/max) 632 / 3372 pps
Tx packet rate (current/max) 3174 / 31054 pps <<<<<
To verify when the MAX rate was triggered use "sh hardware internal cpu-mac inband events"
Note: The command will only record the MAX rate event if it surpasses the previously recorded max rate event.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 19-MAY-2015 |
|
Known Affected Releases: | 6.2(6), 6.2(6a), 6.2(8), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)EC(0.22), 6.2(10)FM(0.26), 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: | 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: | 20-MAY-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: | CSCuq48411 |
Title: | iplus-291:vinci-FE:IPv6 host move failure- new leaf does not learn neigh |
|
Description: | Symptom:
IPv6 VM host move across leafs in TF mode may lead to traffic black-hole
Conditions:
During V6 host moves, RARP packet is generated by the hypervisor of the moved host towards the old leaf. On processing the RARP packet, old leaf must generate a L2 unicast but L3 multicast NS for the moved host towards the fabric destined for the moved host. This packet was not being sent out of the fabric facing port because of this bug. As a result, the new host may not be detected at the new leaf.
Workaround:
After VM moves, the new host IPV6 neighbor entry may have to be manually cleared so that upon next NS from the moved host, the moved host gets detected at the new leaf.
Further Problem Description:
In Vinci TF mode, when host is moved across leafs, then it may lead to IPv6 traffic black-hole for some time till the moved host is learnt in the IPv6 Neighbor table of the new leaf.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.291) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(1)ZD(0.256), 7.0(1)ZN(0.536), 7.0(4)N1(0.151), 7.0(4)N1(1), 7.1(0)D1(0.257), 7.1(0)OTT(0.34), 7.1(0)PDB(0.205), 7.1(0)ZD(0.305) |
|
|
| |
| |
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: | 20-MAY-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: | CSCur29527 |
Title: | IPv6 Packets with Link-local as Source Address are forwarded |
|
Description: | Symptom:
N7K forwards IPv6 packets with link-local as source IPv6 address.
Conditions:
N7K learns the default route from its BGP peer over MPLS link. The packet with link-local as source-address is seen to be forwarding.
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.21), 6.2(12)FT(0.8), 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.1(0)AV(0.38), 7.1(0)PDB(0.301), 7.2(0)D1(0.387), 7.2(0)OTT(0.5) |
|
|
| |
| |
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: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 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: | CSCuq81249 |
Title: | CoPP segmentation fault upon init |
|
Description: | Symptom:
The Control Plane Policing (CoPP) process on a Nexus 7000 switch could unexpectedly crash and restart during initialization.
Conditions:
When PPF sends two responses for a single statistics request sent by the CoPP manager
Workaround:
No known workarounds.
Further Problem Description:
CoPP has timer to collect statistics from Line card every 5 minutes. CoPP expects only one consolidated statistics response for a single statistics request. But PPF library sent two responses for the same statistics request. This unexpected behavior caused CoPP to crash.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(2)S42 |
|
Known Fixed Releases: | 6.0(2)A5(1), 6.0(2)U5(1), 6.1(2)I3(2.10), 6.1(2)I3(3), 6.2(10), 6.2(10)S78, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(3)I1(0.138) |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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: | CSCuq36827 |
Title: | N5k/N6k - Routing unknown u/c and link local b/c packets |
|
Description: | Symptom:
Symptom:Nexus 5000 & 6000 series switches may route packets with an unicast IP destination address and a broadcast destination mac address. The same is also observed for Unknown Unicast flooded packets hitting the CPU and getting routed, i.e. source MAC being rewritten to the Router MAC of the switch which is routing the packet.
Conditions:
Switches running in L2 mode or without L3 license. SVI exists for the VLAN in which such an issue is observed.
Workaround:
For unicast flooding one of the ways to minimize is to synchronize MAC aging with ARP refresh, such that MAC aging on switches is higher than ARP refresh on devices performing routing in the network.
More Info:
Conditions:
Switches running in L2 mode or without L3 license. SVI exists for the VLAN in which such an issue is observed.
Workaround:
Workaround:For unicast flooding one of the ways to minimize is to synchronize MAC aging with ARP refresh, such that MAC aging on switches is higher than ARP refresh on devices performing routing in the network.
shutdown or remove the svi in the vlan in question.
I.e. move management ip address from inband vlan to out of band management interface mgmt0.
B>More Info:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)ZN(0.4) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(1)ZD(0.252), 7.0(1)ZN(0.517), 7.0(4)N1(0.143), 7.0(4)N1(1), 7.1(0)D1(0.257), 7.1(0)OTT(0.34), 7.1(0)PDB(0.205), 7.1(0)ZD(0.305) |
|
|
| |
| |
Bug Id: | CSCur34065 |
Title: | u6rib cored @u6rib_process_clt_stale while deleting vdc |
|
Description: | Symptom:
the crash seems to occur because of a client clean up issue
Conditions:
Crash is seen when vdc is reloaded
Workaround:
No workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.303), 7.1(0)D1(0.308), 7.1(0)ZD(0.348), 7.1(0)ZD(0.355), 7.2(0)ZD(0.5) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.315), 7.1(0)OTT(0.45), 7.1(0)PDB(0.269), 7.1(0)SIB(99.52), 7.2(0)N1(0.3), 7.2(0)N1(0.7), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCur19960 |
Title: | IPv6 mcast transient traffic drop during ISSU on non-default vdc |
|
Description: | Symptom:
IPv6 mcast transient traffic drop during ISSU
Conditions:
During ISSU [ LC upgrade time frame] PIM6 may age out S,G entries, since packet stats wont be available during that time. This would result transient loss.
Workaround:
workaround is not available. [ Transient loss will get recovered ]
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S94 |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.299), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.372), 7.1(0)N1(1), 7.1(0)OTT(0.41) |
|
|
| |
| |
Bug Id: | CSCuq54742 |
Title: | PVAN-vPC+:Allowed vlan in vpc+ does not work if re-configured after ISSU |
|
Description: | Symptom:
Port with switchport trunk allowed vlan xx configuration and in mode other than trunk we will see vlan not in allowed list going down on those ports.
Conditions:
interface port-channel3
switchport
switchport mode private-vlan trunk promiscuous
switchport trunk allowed vlan 1-7,9-4094 <<<<----- This is the issue, this will remove vlan 8 from the notification
switchport private-vlan trunk allowed vlan 8
switchport private-vlan association trunk 10 50
switchport private-vlan mapping trunk 10 30,40,50
vpc 3
Workaround:
interface port-channel3
switchport
switchport mode private-vlan trunk promiscuous
switchport trunk allowed vlan 1-7,9-4094 <<<<----- Remove this config or add vlan 8 to it as well.
switchport private-vlan trunk allowed vlan 8
switchport private-vlan association trunk 10 50
switchport private-vlan mapping trunk 10 30,40,50
vpc 3
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S58 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S62, 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.263), 7.1(0)OTT(0.36), 7.1(0)PDB(0.200) |
|
|
| |
| |
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: | 20-MAY-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: | CSCur24427 |
Title: | 6210 : VLAN_MGR Event Seq. Timed Out on deleting vlans |
|
Description: | Symptom:
VLAN MGR sequence timed out syslog seen on doing a delete for a range of PVLANS. This is seen only when the number of PVLANS is around 40 in the system
Conditions:
happens when there are 40 or more PVLANS configured and range delete operation on VLANS is attempted
Workaround:
Customer is advised to not delete VLAN in the range of >30 PVLANs at a time.
Even though the event seq for PVLAN times out, VLAN delete operation is successful and the vlans do get deleted from the system.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S100 |
|
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.357), 7.1(0)AV(0.38), 7.1(0)PDB(0.303), 7.2(0)D1(0.387), 7.2(0)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCur28449 |
Title: | vPC crashed on switch on Soft switchover |
|
Description: | Symptom:
Core generated by vpc component
Conditions:
This core can be generated under scenarios when the vpc ports are coming up and failure happens in other parts of the system such as a linecard reload.
It is triggered by a failure to respond in time by the sdb component
Workaround:
No functional impact. The vpc process will restart and continue the processing it was doing.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S100 |
|
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.357), 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.301), 7.2(0)D1(0.387) |
|
|
| |
| |
Bug Id: | CSCup94137 |
Title: | API bd_mgr_is_sw_bd_in_vlan_range() is failing in rtm_get_vni_l2_tpg(). |
|
Description: | Symptom:
the api returns error if there is no system bridge-domain configured in the switch. Need to return success and set bd_di that it is a vlan.
Conditions:
Do not configure system bridge-domain and call the api.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 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.227), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.157) |
|
|
| |
| |
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: | 20-MAY-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: | CSCur03059 |
Title: | VPC+ peer link not part of a topology |
|
Description: | Symptom:
While configuring VPC+ with 8 topologies, we observe that the peer link is not included as part of one of the topologies.
Conditions:
Configure topologies while the switch is in transient busy state.
Workaround:
Repeat the same topology config
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S68 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S91, 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.332), 7.1(0)OTT(0.47), 7.1(0)PDB(0.283), 7.1(0)SIB(99.68) |
|
|
| |
| |
Bug Id: | CSCuq68379 |
Title: | 6210:S64:: res_mgr crash @return res_mgr_data_pss |
|
Description: | Symptom:
A N7K running NX-OS 6.2.x prior to 6.2.10 may crash and produce core files in the Resource Manager Daemon.
show system reset-reason may show
----- reset reason for module 10 (from Supervisor in slot 10) ---
1) At 193686 usecs after Wed Aug 13 15:05:21 2014
Reason: Reset triggered due to HA policy of Reset
Service: res_mgr hap reset
Version: 6.2(2a)
Conditions:
With a relatively low likelihood, a crash/core file may occur when res_mgr handling duplicated HA msg
Workaround:
n/a
Further Problem Description:
n/a
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(2), 6.2(2a), 6.2(6), 6.2(6a), 6.2(6b), 6.2(8), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S66, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.263), 7.1(0)OTT(0.36), 7.1(0)PDB(0.205) |
|
|
| |
| |
Bug Id: | CSCuq27662 |
Title: | Clear install log-history all do not clear the install logs |
|
Description: | Symptom:
Clear install log-history all do not clear the install logs
Conditions:
On Nexus5000 platform, prior install id's are not cleared when issuing the command clear install log-history all
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1 |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.280), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.350), 7.1(0)N1(1), 7.1(0)OTT(0.39), 7.1(0)PDB(0.228) |
|
|
| |
| |
Bug Id: | CSCur25124 |
Title: | SSTE: L2VPN traffic loss is observed after ISSU followed by LC reload |
|
Description: | Symptom:
Route updates from L2VPN are not processed and there might be traffic loss. No further updates will be processed.
Conditions:
This problem might occur on an ISSU to a 6.2.10 version or earlier.
Workaround:
A SUP switchover will correct the problem.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S100, 6.2(12)FT(0.26), 7.2(0)D1(0.386) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.8), 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)PDB(0.301), 7.2(0)D1(0.387) |
|
|
| |
| |
Bug Id: | CSCur20430 |
Title: | Memory leaks are detected from process core dump after testing ACL |
|
Description: | Symptom:
when we issue no sequence number under acl configuration, we observed 152 bytes leak in aclmgr side.
Conditions:
delete sequence number of ACE
Workaround:
workaround is not available.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S86 |
|
Known Fixed Releases: | 6.2(12), 6.2(12)S21, 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.125), 7.1(0)PDB(0.317), 7.1(0)RTG(0.53), 7.2(0)D1(0.355) |
|
|
| |
| |
Bug Id: | CSCuq06354 |
Title: | connection issue between WS-C3750X-48T-S and N7K-F248XT-25E |
|
Description: | Symptom:
when connect WS-C3750X-48T-S and N7K-F248XT-25E, and when disconnect F2 module,
the ports of both catlyst and nexus side remain down .
Conditions:
connect WS-C3750X-48T-S and N7K-F248XT-25E and then disconnect / reconnect F2 port /
Workaround:
shut/ no shut the port or
hard code speed or
duplex on port
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(2), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S62, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.258), 7.1(0)OTT(0.34), 7.1(0)PDB(0.198) |
|
|
| |
| |
Bug Id: | CSCuq03603 |
Title: | N7K:6210:potential aclmgr mem leak |
|
Description: | Symptom:
when we issue show command in the standby supervisor, aclmgr has a leak in command library.
the size of leak is 196 bytes per show command
(show system internal aclmgr log)
Conditions:
we issue show command in the standby supervisor
Workaround:
avoid issuing show command in the standby supervisor
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 7.1(0)D1(0.308) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.233), 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.288) |
|
|
| |
| |
Bug Id: | CSCur10877 |
Title: | VinciPE:ipv6 default route does not have the segid |
|
Description: | Symptom:
In VinciPE setup , the ipv6 default route does not have the segid.
Conditions:
When the default route is generated using "default-information originate" command.
Workaround:
Generate default route using "redistribute" or "network" commands.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.349) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.290), 7.1(0)N1(0.363), 7.1(0)N1(1), 7.1(0)OTT(0.40), 7.1(0)PDB(0.235), 7.1(0)SIB(99.52), 7.1(0)ZD(0.336) |
|
|
| |
| |
Bug Id: | CSCur03111 |
Title: | MACSEC N7K: Link drop with High Traffic on F2E |
|
Description: | Symptom:
Without MACSEC traffic passes fine and the customer can push roughly 8.6 gig of traffic on the link. However, When MACSEC is configured initially the connection is established as long as there is roughly 5 gigs of traffic or less the link stays established.
At about 6.5 gigs of traffic, CRC errors may start being seen on the peer port. After that SAP rekey may fail and the macsec link go down. Link will stay down in SAP AUTHEN INCOMPLETE state.
shut/no shut of the interface or remove/reapply of cts config may not resolve the issue. The port would operate in non-cts mode but not in cts encryption mode. Module needs to be reloaded to recover to cts encryption operation.
Conditions:
1. MACSEC is enabled.
2. egress traffic rate exceeds the effective line rate for encrypted traffic.
Workaround:
Limit the traffic egressing out of Macsec ports to less than effective 10G linerate (including Macsec header overhead). This may be roughly 6.5G for 64B packets.
Further Problem Description:
Macsec encryption has an overhead of 32-40B which goes on to the the wire as part of the packet. This causes the effective packet size on the wire to increase. For 64B packets, this is an overhead of ~33%, resulting in support for only 65% line rate. This percentage is a function of packet size and varies between 0.1%-33%. The device was configured to error out the extra packets causing drop in traffic and Bad CRCs. This resulted in link going down since EAPOL packets were also getting dropped.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(6), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S91, 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.306), 7.1(0)EV(0.116), 7.1(0)OTT(0.45), 7.1(0)PDB(0.245) |
|
|
| |
| |
Bug Id: | CSCur07911 |
Title: | OTV - ISIS does not advertise mac address to any peers |
|
Description: | Symptom:
OTV fails to send mac updates to peers in unicast mode from local site to remote, causing connectivity issues
Conditions:
No trigger known at present
Workaround:
Workaround is to flap the affected overlay interface by shut/no shut.
Further Problem Description:
Problem may only be present in 6.2-based code.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.9), 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), 7.1(0)SIB(99.68) |
|
|
| |
| |
Bug Id: | CSCur23435 |
Title: | with multiple simultaneous terminals private VLAN gets locked |
|
Description: | Symptom:
VLAN configuration could get locked and not able to process any vlan configuration changes anymore.
Conditions:
While configuring private vlan associations from one terminal, if the user simultaneously deletes primary vlans from another terminal PVLAN (Private-Vlan) get locked and cause lock of complete vlan database.
Issue can happen only when configuration are done over multiple terminal session where one session configure private vlan association and second deleting private vlans before first session exit vlan configuration.
Workaround:
Do not simultaneously delete private-vlans from another terminal while configuring the same private-vlans from one terminal. However If you run into this issue, then reload vdc or switch would be required to recover from this problem.
Further Problem Description:
Example of problem configuration. 2 Sessions are open:
Session 1 and Session 2 - numbers represent order in what CLI are added on device on above sessions:
Numbers are order how to execute cli in those 2 sessions.
Session1:
1. vlan 231
2. enter
Session2:
3. no vlan 231 + enter
Session 1
4. private-vlan association 1300,1302-1303 + enter
5. end + enter
At this point vlan database will get lock
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S100 |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.9), 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.144), 7.1(0)PDB(0.320), 7.2(0)D1(0.387) |
|
|
| |
| |
Bug Id: | CSCuq55039 |
Title: | SSTE: Nexus7k ORIB core while polling OTV mib & restart otv-isis default |
|
Description: | Symptom:
Crash seen in orib_show_internal_snmp_route if otv-isis process is killed and restarted by command line interface while the OTV mib (1.3.6.1.4.1.9.9.810) is being polled.
Conditions:
Seen if the otv-isis process is killed and restarted by the command line interface while the OTV mib (1.3.6.1.4.1.9.9.810) is being polled.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S58 |
|
Known Fixed Releases: | 6.2(10), 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.271), 7.1(0)OTT(0.36), 7.1(0)PDB(0.219), 7.1(0)RTG(0.33) |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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: | CSCup77035 |
Title: | [GBR performance] ospf process command execution takes huge time |
|
Description: | Symptom:
With GBR release 179, 193 and within vdc scale
Conditions:
scaled vdc
Workaround:
Unknown still
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.179), 7.1(0)D1(0.188), 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.232), 7.1(0)N1(0.287), 7.1(0)N1(0.288), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.179), 7.1(0)RTG(0.22) |
|
|
| |
| |
Bug Id: | CSCuq67047 |
Title: | N7K: PIM6-3-M6RIB_ADD_ROUTE failure on LC reload with 200 PIM neighbors |
|
Description: | Symptom:
When a module is the only one with PIM6 enabled on it interfaces and it connects to a large number of PIM6 neighbors with a large number of groups per neighbor, then reloading the module can cause subsequent PIM6 interactions with M6RIB to fail permanently, causing traffic loss.
Conditions:
The problem was only seen with 200 PIM6 neighbors on the module and 40 groups per neighbor. It was not seen with 30 groups per neighbor.
Workaround:
None
Further Problem Description:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.246) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.288), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.361), 7.1(0)N1(1), 7.1(0)OTT(0.39) |
|
|
| |
| |
Bug Id: | CSCuq31720 |
Title: | ES common LID is 0x0 after switchover or ISSU |
|
Description: | Symptom:
Prior to switchover or upgrade using ISSU
rt55cn01an# sh sys internal pktmgr internal vdc inband | i 11a
In VDC 6 0x11a1 6 24
In VDC 2 0x11a2 2 0
In VDC 3 0x11a3 3 0
You might also see an error message in syslog
%VPC-2-VPC_ES_FAILED_LID_ALLOC: Failed to negotiate common LID between vPC peers.
After Switchover or upgrade using ISSU
show system internal vpc info glob | i ES
ES common LID:0x0 Bitset of Reserved resources: 2
ES lid in SDB: 0x11a3
show system int pktmgr internal vdc inb | i 0x11a
In VDC 6 0x11a1 6 548
In VDC 2 0x11a2 2 0
<<<< VDC 3 not present
The packets ingressing vpc+ port-channels going to CPU for the affected VDC will be dropped
Conditions:
M1/F1vpc+. in multiple VDCs
This happens only to vpc secondary
Workaround:
To avoid getting into this state, while configuring vpc+ in multiple VDCs, give atleast 5 mins for each vpc+ peer-link to come up.
If a VDC is problematic state after the upgrade/sup failover, bounce the peer-link of only the affected VDC. If multiple VDCs are affected, give atleast 5 mins between bouncing peer-link from each VDC
Further Problem Description:
Known Triggers:
Chassis Reload
Bringing up vpc+ peer-link up in multiple VDCs at the same time
Multiple VDC reloads at the same time
Module with all peer-links from multiple VDCs is reloaded or replaced
Note: The impact of this bug will only be seen after supervisor failover including ISSU
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(6b), 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S53, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.255), 7.1(0)OTT(0.34), 7.1(0)PDB(0.194) |
|
|
| |
| |
Bug Id: | CSCuq90761 |
Title: | N7K: 30 - 60 sec traffic loss when restart pim process on ingress PE |
|
Description: | Symptom:
30 - 60 sec traffic loss when pim is restarted/after switchover for groups which falls under SSM config range.
Conditions:
When SSM config command is replayed, PIM request MRIB to clear all routes for that range.But this should be done during command config time not during restart/switchover.( That is the issue here)
Workaround:
No workaround is available. [ Traffic will resume after routes are learnt ]
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.254) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.281), 7.1(0)N1(0.353), 7.1(0)N1(1), 7.1(0)OTT(0.39), 7.1(0)PDB(0.228), 7.1(0)SIB(99.52) |
|
|
| |
| |
Bug Id: | CSCuq55557 |
Title: | VxLAN: vPC fails to send triggered PIM hello |
|
Description: | Symptom:
Temporary Traffic loss
Conditions:
A newly come up L3 interface A. has DR-delay timer configured, B. Provides better route to a multicast source or Rendezvous Point (in case of shared tree forwarding). The multicast tree gets changed and thus if a stream is already flowing, gets affected temporarily.
Workaround:
Remove DR-delay timer for this interface.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.221) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.261), 7.1(0)D1(0.262), 7.1(0)N1(0.326), 7.1(0)N1(1), 7.1(0)OTT(0.34), 7.1(0)PDB(0.208), 7.1(0)RTG(0.40) |
|
|
| |
| |
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: | 20-MAY-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)OTT(0.5) |
|
|
| |
| |
Bug Id: | CSCuq39832 |
Title: | Crash in Resource Manager Daemon |
|
Description: | Symptom:
A N7K running NX-OS 6.2.x prior to 6.2.10 may crash and produce core files in the Resource Manager Daemon.
show system reset-reason may show
----- reset reason for module 10 (from Supervisor in slot 10) ---
1) At 193686 usecs after Wed Aug 13 15:05:21 2014
Reason: Reset triggered due to HA policy of Reset
Service: res_mgr hap reset
Version: 6.2(2a)
Conditions:
With a relatively low likelihood, a buffer overflow might be triggered when issuing one of the following commands:
show resource
show resource vlan (or another resource name from show resource ?)
show vdc resource detail
show vdc resource vlan (or another resource name) detail
show vdc vdc-name resource
show vdc vdc-name resource vlan (or another resource name)
When the user has frequently created/deleted vlans across multiple VDCs, the user is more susceptible to this issue.
Workaround:
If possible, do not run those listed commands and use alternatives such as "show vdc resource" and "show vdc resource vlan (or another resource name)".
If the user really needs to perform those commands, they can lower the risk of hitting this issue by first doing one of the following (or combining them): (a). reload switch during maintenance window (b). use "limit-resource xxx minimum xxx maximum xxx" to raise the minimum value as much as possible. In particularly, the user might want to raise the minimum value for vlan: limit-resource vlan minimum xxx maximum xxxx.
Further Problem Description:
n/a
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(2), 6.2(2a), 6.2(6), 6.2(6a), 6.2(6b), 6.2(8), 6.2(8a), 7.1(0)D1(0.235) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S52, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)D1(0.244), 7.1(0)NF(0.32), 7.1(0)OTT(0.31), 7.1(0)PDB(0.180) |
|
|
| |
| |
Bug Id: | CSCuq31626 |
Title: | SPM: spm crash after LISP ISSU from 6.2.10.S45->7.1(0)D1(0.229) |
|
Description: | Symptom:
After performing an ISSU from 6.2.10->7.1(0), the SPM service crashes once and then recovers.
Conditions:
LISP policies are installed.
Workaround:
None required. SPM will recover after the crash.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.229) |
|
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.245), 7.1(0)OTT(0.31), 7.1(0)PDB(0.194), 7.1(0)RTG(0.20), 7.1(0)ZD(0.294) |
|
|
| |
| |
Bug Id: | CSCup95423 |
Title: | BFD Initial P packet ignored if the session is still in INIT state |
|
Description: | Symptom:
N7ks running 6.2(6a) running BFD with Arista . BFD flaps for several minutes initially before finally remaining up The issue seems to be with the way BFD is negotiating the timers.
Conditions:
During BFD initialization when both end points send their respective P packets at the same time. NXOS
Workaround:
Increase the bfd timers or slow-timers to trigger a P packet retransmission.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(6a) |
|
Known Fixed Releases: | 6.1(2)I3(2.39), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.10), 6.2(12)FT(0.5), 6.2(6b)E1, 7.0(0)BZ(0.46) |
|
|
| |
| |
Bug Id: | CSCuq79746 |
Title: | N7K: reload line card - mrib crash with 1k PIM neighbors with 255 groups |
|
Description: | Symptom:
MRIB process crashes
Conditions:
While reloading the linecard, PIM process started shutting down as the last PIM interface is getting deleted.
At this time, MRIB is cleaning up the routes and cleaning up resources allocated for the PIM client and at this time, it crashes while trying to destroy the lock. since another thread has obtained the lock.
Workaround:
No Workarounds.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.246) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.320), 7.1(0)OTT(0.47), 7.1(0)PDB(0.269), 7.1(0)SIB(99.68), 7.2(0)N1(0.11), 7.2(0)N1(0.3) |
|
|
| |
| |
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: | 20-MAY-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: | CSCup76505 |
Title: | 6.2.10.S16::N7k F3 Sys Sanity::Seeing ipqosmgr core after reload of UUT |
|
Description: | Symptom:
Apply qos & queuing configs then reload the switch with copy running to start-up. Once switch comes up ipqosmgr core is seen.
Conditions:
Its seen with qos/queuing configs.
Workaround:
No Workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S16 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S23, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.224), 7.1(0)FC(0.2), 7.1(0)N1(0.275), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.20) |
|
|
| |
| |
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: | 20-MAY-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)ZD(0.47), 7.2(0)ZN(0.54) |
|
|
| |
| |
Bug Id: | CSCuq55539 |
Title: | FIB route inconsistencies after ISSU 628-> 6210S58 |
|
Description: | Symptom:
Route inconsistencies from a release to any release prior to 6.2.10
Conditions:
ISSU with a huge route scale (> 500K)
Workaround:
clear ip route * for the inconsistent routes will fix the issues.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S58 |
|
Known Fixed Releases: | 6.2(10), 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.297), 7.1(0)OTT(0.41), 7.1(0)PDB(0.234) |
|
|
| |
| |
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: | 20-MAY-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: | CSCur22743 |
Title: | CB40-brk: FP-reg: Duplicate mcast traffic seen after vdc suspend |
|
Description: | Symptom:
Duplicate traffic for VDC suspend trigger on routers in a LAN. This issue can be hit if a one of the switch has L3 multicast route oifs/oils with multiple owners and when the oif/oil is going away on non-DR.
Ex:
(1.0.99.11/32, 235.0.0.3/32), uptime: 01:01:23, pim mrib ip igmp
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 1)
Vlan101, uptime: 00:03:13, pim, mrib
Conditions:
This can happen on a stand alone IHR or LAN LHR switches which have PIM and IGMP ownership for the same route oif/oil and there is a delete happening for the oif.
Workaround:
clear ip mroute
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S100 |
|
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)RTG(0.55), 7.2(0)D1(0.355) |
|
|
| |
| |
Bug Id: | CSCur11131 |
Title: | In large vlan scale setup SPM is timing out causing issues |
|
Description: | Symptom:
Interfaces are not recognized on switch privilege mode or config terminal prompt or in show interface status.
Sometimes VDC creation can take time too.
Conditions:
Any port bring up activity on a scale testbed of total 400+ vlans and 500 L2 ports or port-channels, allowing most vlans.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S89, 6.2(8)S3, 7.1(0)RTG(0.43) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S91, 6.2(10)S98, 6.2(10.16)S0, 6.2(10.17)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.301), 7.1(0)EV(0.116) |
|
|
| |
| |
Bug Id: | CSCur01307 |
Title: | No triggered PIM register sent on DR during RP change |
|
Description: | Symptom:
After an RP has changed, the first hop router should trigger a NULL register to the new RP to create the S,G state on the new RP. If a new receiver joins after the RP change, it may not receive traffic till the next register is sent to RP. (max 60 seconds)
Conditions:
Occurs when there was a very recent RP change, and the new RP did not have an (S,G) state for the corresponding group.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
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)RTG(0.54), 7.2(0)D1(0.355) |
|
|
| |
| |
Bug Id: | CSCuq92491 |
Title: | SSTE: BGP sessions are down once i do reload after upgrading 6210 to 710 |
|
Description: | Symptom:
When upgrading Cisco NXOS 6.2.10 software to 7.1, after system reloads with new software, all BGP session are down.
Conditions:
When n7000 router is running 6.2.10 software, perform ISSU to upgrade to 7.1 software, and then reload system. After system comes up with 7.1 software, all BGP sessions are down.
Workaround:
There is no workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.253) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.281), 7.1(0)N1(0.353), 7.1(0)N1(1), 7.1(0)OTT(0.39), 7.1(0)PDB(0.228), 7.1(0)SIB(99.52), 7.1(0)ZD(0.330) |
|
|
| |
| |
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: | 20-MAY-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: | CSCur12476 |
Title: | F1 port went into err-disabled state with PIXM error |
|
Description: | Symptom:
port goes into err-disabled state. STP and PIXM sys logs also seen on console
Conditions:
happened when a mode or type change affected for a vlan
Workaround:
reload vdc or switch. delete the vlan and create the vlan again with the required mode or type
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S90, 6.2(10)S93 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S94, 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.312), 7.1(0)EV(0.116), 7.1(0)OTT(0.45), 7.1(0)PDB(0.246) |
|
|
| |
| |
Bug Id: | CSCuq39227 |
Title: | snmpd service crashes when we issue "sh run | i community" |
|
Description: | Symptom:
snmpd service crashes when we issue "sh run | i community" CLI on the device after a new community is created using snmpset. Also, all the snmp configs are cleared in run-config due to this issue.
Conditions:
Create a new community using snmpset & issue CLI "sh run | i community" on the device with "logging console" configured to see crash/cores generated. "show run snmp" shows snmp configs are cleared due to this issue.
Workaround:
NA
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)ZD(0.272) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.257), 7.1(0)OTT(0.34), 7.1(0)PDB(0.205), 7.1(0)ZD(0.305), 7.1(0)ZN(0.405) |
|
|
| |
| |
Bug Id: | CSCur13611 |
Title: | "Service not responding" mess log on console while verifying pbr stats |
|
Description: | Symptom:
"Service not responding" mess log on console while verifying pbr stats
Conditions:
This error is seen if PBRv4 policy is having 1K ACE's.
Workaround:
Reduce the scale.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.360) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.304), 7.1(0)N1(0.378), 7.1(0)N1(1), 7.1(0)OTT(0.41), 7.1(0)PDB(0.249), 7.1(0)RTG(0.62), 7.1(0)SIB(99.52) |
|
|
| |
| |
Bug Id: | CSCuq68578 |
Title: | netstack crashed using devtest program |
|
Description: | Symptom:
Netstack process crash.
Conditions:
On configuring more than 255 global address per interface
Workaround:
Don't configure more than 255 address per interface
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.321), 7.1(0)ZD(0.288) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.303), 7.1(0)OTT(0.41), 7.1(0)PDB(0.249), 7.1(0)ZD(0.348), 7.1(0)ZN(0.451) |
|
|
| |
| |
Bug Id: | CSCuq20222 |
Title: | SMU 7.1: adjust timeout for all services to handshake across all VDCs |
|
Description: | Symptom:
Service isis_l2mp failed to start with binary from a SMU. Then the symlink is reverted back to restart service (using old binary)
Conditions:
when activate a SMU
Workaround:
no Work around
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-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.233), 7.1(0)N1(0.290), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.179), 7.1(0)RTG(0.22), 7.1(0)ZD(0.285) |
|
|
| |
| |
Bug Id: | CSCuq33437 |
Title: | IPv6 TCAM failed to install |
|
Description: | Symptom:
IPv6 TCAM failed to install
Conditions:
Everything looks good after ISSU upgrade. Started first convergence test by reloading a LC and noticed IPv6 TCAM failed to install after the LC reload.
Workaround:
Reload admin vdc
Further Problem Description:
Everything looks good after ISSU upgrade. Started first convergence test by reloading a LC and noticed IPv6 TCAM failed to install after the LC reload.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S41 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S52, 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.263), 7.1(0)OTT(0.36), 7.1(0)PDB(0.201) |
|
|
| |
| |
Bug Id: | CSCuq81871 |
Title: | MVPN/NXOS: MDT Encapsulation information not populated |
|
Description: | Symptom:
Multicast traffic inside VRF is not forwarded over MDT group to remote PE. Control plane exist however traffic is not reaching remote PE.
Conditions:
This could happen only for MVPN traffic in situation where S,G pin Join is send to VPC secondary and there is no local receivers and multicast traffic is received over orphan L3 interface
Workaround:
- Have always local receiver in VPC VLAN
- Change unicast routing to send S,G join always to VPC primary
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S77, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.301), 7.1(0)OTT(0.41), 7.1(0)PDB(0.249) |
|
|
| |
| |
Bug Id: | CSCuq12236 |
Title: | N7K: mrib crash mrib_delete_route_internal on clear ip mroute in scale |
|
Description: | Symptom:
mrib process is crashed and restarted on clear ip mroute *
Conditions:
when there is 15K more mroute state present
Workaround:
wait for mroute to expire by itself
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-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.0(0)KM(0.97), 7.1(0)D1(0.227), 7.1(0)D1(0.235), 7.1(0)D1(0.240), 7.1(0)N1(0.279), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.27) |
|
|
| |
| |
Bug Id: | CSCur49910 |
Title: | show tech failed because no enough space |
|
Description: | Symptom:
Some system configurations might see "No space left on device" message during "tac-pac" collection
Conditions:
18 slot Nexus chassis with all 18 F3 modules and all ports are broken out to be 10G causing max number of ports and max amount of logs to be collected might cause this issue.
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
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.357), 7.1(0)AV(0.38), 7.1(0)EV(0.137), 7.1(0)PDB(0.317), 7.1(0)SIB(99.82), 7.2(0)D1(0.363) |
|
|
| |
| |
Bug Id: | CSCur32203 |
Title: | Pvlan Timeout with Ethpm During ISSU |
|
Description: | Symptom:
In a VPC setup with large number of ports/PCs, ETHPM may time out on PVLAN when peer link is flapped:
2014 Oct 17 14:34:13 F3-xbow1-vpcA %ETHPORT-5-IF_SEQ_ERROR: Error ("sequence timeout") communicating with MTS_SAP_PVLAN for opcode MTS_OPC_ETHPM_PRE_LOGICAL_UP, (RID_PORT: port-channel4096)
Further VPC legs may timeout on PVLAN during MTS_OPC_ETHPM_PORT_LOGICAL_CLEANUP
Conditions:
This may happen when there is a large number of ports or port-channels in the setup
Workaround:
Turn off feature private-vlan in the setup
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S102, 6.2(8a)S2 |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.9), 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.144), 7.1(0)PDB(0.320), 7.2(0)D1(0.387) |
|
|
| |
| |
Bug Id: | CSCuq49866 |
Title: | snmpbulkwalk TIMEOUT Observed for CISCO-VTP-MIB |
|
Description: | Symptom:
SNMP v3 BULK walk on CISCO-VTP-MIB might time out.
Conditions:
Device must be in VTP server or client mode.
Only observed while access with SNMP v3.
Workaround:
1) Increase timeout or 2) use SNMP v2c or v1.
Further Problem Description:
Problem exists in NXOS software releases 6.2(6) and 6.2(8).
Fix had been integrated into 6.2(10) and later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S53 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S57, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.258), 7.1(0)OTT(0.34), 7.1(0)PDB(0.195) |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S77 |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.293), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.367), 7.1(0)N1(1), 7.1(0)OTT(0.40) |
|
|
| |
| |
Bug Id: | CSCuq22831 |
Title: | Crash in snmpd process due to heartbeat failure after netstack hogs CPU |
|
Description: | Symptom:
The snmpd process crashed multiple times triggering a HAP-Reset:
----- reset reason for Supervisor-module 5 (from Supervisor in slot 5) ---
1) At 885418 usecs after Fri Jul 25 08:21:03 2014
Reason: Reset triggered due to HA policy of Reset
Service: Service "snmpd" in vdc 2 hap reset
Version: 6.1(3)
Conditions:
This occurs while polling interface counter statistics via SNMP.
Workaround:
Slowing down the interval of SNMP polling should help reduce the odds of hitting the issue. Disabling SNMP altogether should prevent the issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | 6.1(2)I3(2.39), 6.1(2)I3(3), 6.1(2)I3(3.16), 6.1(2)I3(4), 6.1(5)E1, 6.2(10), 6.2(10)S48, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(3)I1(0.248) |
|
|
| |
| |
Bug Id: | CSCur26119 |
Title: | EIGRP prefixes missing after interface flap |
|
Description: | Symptom:
EIGRP interface/adjacency flap may cause some EIGRP prefixes not to be sent. You should typically be able to see such an occurrence via syslog. One example is below.
%EIGRP-5-NBRCHANGE_DUAL: eigrp-1 [pid x] (default-base) IP-EIGRP(0) 9: Neighbor x.x.x.x (Vlan x) is down: holding time expired.
Once this occurs, EIGRP route's may be missing from the EIGRP table.
Conditions:
- This has been seen with when using route tagging with distribute list, however this is not an absolute cause and effect.
- Occurrence of the issue is unpredictable given it also requires rare internal EIGRP condition when forming route-update packets.
Workaround:
- Clear the EIGRP process on the sending Nexus or clear eigrp neighbors "clear ip eigrp neighbor "
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(8) |
|
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.1(2)I3(3.44), 6.1(2)I3(4), 6.2(10.21)S0, 6.2(12), 6.2(12)FB(0.7), 6.2(12)FT(0.5) |
|
|
| |
| |
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: | 20-MAY-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(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), 7.1(0)OTT(0.27), 7.1(0)PDB(0.199) |
|
|
| |
| |
Bug Id: | CSCuc24792 |
Title: | no response to cli commands after configuring STP on titanium image |
|
Description: | Symptom:
no response to many cli commands after configuring STP on titanium image
Conditions:
After configuring STP
Workaround:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(0.233) |
|
Known Fixed Releases: | 6.2(0.233)S2, 6.2(0.236)S0, 6.2(2), 7.2(0)VZN(0.30) |
|
|
| |
| |
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: | 20-MAY-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: | CSCuo41201 |
Title: | Netstack buffer leaking with IPv6 feature running |
|
Description: | Symptom:
Netstack may run of buffers with certain IPv6 features configured, like OSPFv3, DHCPv6 and HSRPv6.
Conditions:
Following messages are observed when Netstack runs out of buffer:
NETSTACK-3-MBUF_FAILED netstack [xxxx] m_copyin() failed in ipv6_data_main() (80 bytes)
NETSTACK-2-MPULLUP netstack [xxxx] p_ip_output: m_pullup failed for IP, error Operation not permitted
Workaround:
None so far. Reload recovers the leaked memory. Even a forceful crash of Netstack process may help, however requires debug plugin.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N2(3) |
|
Known Fixed Releases: | 5.2(1)N1(7.126), 5.2(1)N1(8), 6.0(2)N2(4.63), 6.0(2)N2(4.64), 6.0(2)N2(5), 6.1(2)I3(1), 6.2(10), 6.2(10)S74, 6.2(10.16)S0, 6.2(8)E10 |
|
|
| |
| |
Bug Id: | CSCur24950 |
Title: | Assert Metric and Metric Pref Value not updated in PIM route structure |
|
Description: | Symptom:
Metric value and metric preferences are update while sending the assert packets but are not updated in the route details after obtaining the metrics from unicast.
Conditions:
The show command - 'show ip pim route' may not have the correct metric values from unicast.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S100 |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.317), 7.1(0)OTT(0.45), 7.1(0)PDB(0.269), 7.1(0)SIB(99.52), 7.2(0)N1(0.3), 7.2(0)N1(0.9) |
|
|
| |
| |
Bug Id: | CSCtt19402 |
Title: | NXOS/VPC: VPC chnnels not init for all ports when one link flaps |
|
Description: | Symptom:
All channels are in the suspended state after reload and when VPC delay restore expire
Conditions:
This happen only when there is fast continuous flapping of some interfaces and only after reload of the VPC or when VPC is configured for the first time.
Workaround:
Shut down interfaces that are flapping to restore all VPC channels.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | 5.2(1)N1(1), 5.2(3.29)S0, 6.1(0.168)S0, 7.2(0)VZN(0.30) |
|
|
| |
| |
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: | 20-MAY-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: | CSCuo38700 |
Title: | PPM : show config-profile does not show include-instance under applied: |
|
Description: | Symptom:
When parameterize profile is applied with include-instance option it is not working fine.
Conditions:
Happens when Profile A includes Profile B, and Profile B has all parameters defined.
Workaround:
Do not use include-instance option. without that general command of apply profile profile_name param-instance instance-name works fine.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.91), 7.1(0)D1(0.99) |
|
Known Fixed Releases: | 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)N1(0.195), 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: | 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: | 20-MAY-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: | CSCuo99830 |
Title: | ISSU: port_client core on F2/F3 handling unsupported port command |
|
Description: | Symptom:
port-client core, ISSU failure, Ports suspended.
Conditions:
ISSU from 6.1(3) to 6.2(8).
Workaround:
Reload
Further Problem Description:
During the ISSU, once the SUP switchover is done, line card is upgraded. At this point, EthPm sends port commands to F2 Line card. Just before this, if there are any process crash (for ex: vpc crash, ungraceful VDC reload), when the port commands from EthPm are processed by port_client, the process crashes. We found that this possibly due to invalid pay load size being sent to port client.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.1(3), 6.1(4), 6.2(10)S26, 6.2(8)S9, 7.1(0)D1(0.148), 7.1(0)D1(0.161) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S32, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.214), 7.1(0)FC(0.2), 7.1(0)NF(0.32), 7.1(0)OTT(0.18), 7.1(0)PDB(0.163), 7.1(0)RTG(0.12) |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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: | 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: | 20-MAY-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: | 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: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 20-MAY-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: | CSCty14876 |
Title: | 5.2.4.S16 UDLD aggressive mode, port: error upon del of port-channel |
|
Description: | Symptom:
UDLD aggressive mode, port: error upon del of port-channel
Conditions:
Just remove port-channel (peer link) on the switch
Workaround:
CoPP in 5.1.5
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 5.2(4)S16 |
|
Known Fixed Releases: | 5.2(4)S28, 5.2(4.27)S0, 6.1(0.228)S0, 7.2(0)VZN(0.30) |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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: | CSCun69580 |
Title: | MPLS TE Tunnel takes too long to go down around 30 - 40 secs |
|
Description: | Symptom:
MPLS Tunnel takes too long to go down. Here is the setup.
N7k1-PE --e1/21--------e1/21--n7k2-p1---e1/25-------------e1/25--n7k1-pe2
Customer is using LSP verbatim and he has a tunnel from pe to pe2, when he shutdown the link e1/25 on n7k2-p1 switch the tunnel remains up for more than 30 secs. Customer wants conversion to be less than 3 secs. This is just with one tunnel.
Conditions:
Tunnel remains up
Workaround:
none
Further Problem Description:
MPLS Tunnel takes too long to go down. Here is the setup.
N7k1-PE --e1/21--------e1/21--n7k2-p1---e1/25-------------e1/25--n7k1-pe2
Customer is using LSP verbatim and he has a tunnel from pe to pe2, when he shutdown the link e1/25 on n7k2-p1 switch the tunnel remains up for more than 30 secs. Customer wants conversion to be less than 3 secs. This is just with one tunnel.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)FM(0.28), 6.2(10)NO(0.17), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.75) |
|
|
| |
| |
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: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)ZD(0.181) |
|
Known Fixed Releases: | 15.4(3)M2.1, 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, 15.5(1.11)S |
|
|
| |
| |
Bug Id: | CSCur35650 |
Title: | Platform Manager crashes during SNMP walk |
|
Description: | Symptom:
Shortly after installing an N7K-F312FQ-25 line card, a Nexus 7009 running 6.2(8a) reboots.
Conditions:
Exact conditions not yet known
Workaround:
None yet
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(12), 6.2(12)S14, 6.2(12.4)S0, 7.1(0)AV(0.38), 7.1(0)EV(0.144), 7.1(0)PDB(0.307), 7.2(0)D1(0.387), 7.2(0)OTT(0.5) |
|
|
| |
| |
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: | 20-MAY-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: | CSCuo43694 |
Title: | snmpd crash upon getnext on vtpInternalVlanTable with negative index |
|
Description: | Symptom:
snmpd might crash when accessing vtpInternalVlanTable with a negative index.
SNMP walk vtpInternalVlanTable does not have issue.
Conditions:
Problem occurred only if accessing vtpInternalVlanTable with a negative index.
Workaround:
Use zero or positive index.
Further Problem Description:
The issue exists in NXOS software releases 5.2(1-9), 6.1(1-5), 6.2(1-8).
The fixes have been integrated into NXOS software release 6.2(9), 6.2(10) and later releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.113) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.5), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.12)S0, 6.2(8.13)S0, 6.2(9)FM(0.68), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.162) |
|
|
| |
| |
Bug Id: | CSCuo47544 |
Title: | Netstack crash at ipv6_add_static_route in ipv6 static route add w/o VRF |
|
Description: | Symptom:
Netstack process crashes
Conditions:
This issue is observed only when adding static route vlan for extranet case with forward reference (where vrf is not created)
Workaround:
Configure the VRF first for extranet case and then add the static route vlan to avoid the crash
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(8)S33 |
|
Known Fixed Releases: | 6.1(2)I3(1), 6.2(10), 6.2(10)FM(0.28), 6.2(10)NO(0.17), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317) |
|
|
| |
| |
Bug Id: | CSCup46560 |
Title: | N7k: AAA daemon core |
|
Description: | Symptom:
AAA daemon process crash
Conditions:
Nexus 7000 switches
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(2a) |
|
Known Fixed Releases: | 6.1(2)I3(2.15), 6.1(2)I3(3), 6.2(10), 6.2(10)S15, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(3)I1(0.145), 7.0(3)I1(1), 7.0(3)I1(1.8), 7.0(3)I1(2) |
|
|
| |
| |
Bug Id: | CSCtz15300 |
Title: | 6.0.3 Introduce Flow Control for PIM |
|
Description: | Symptom:
On a scaled setup with 20k multicast route entries, tracebacks and malloc failed messages seen on doing clear ip mroute * continuously
2012 Sep 10 16:06:21 l3sys2-agg1-A3 %PIM-3-SLAB_LIB_SLAB_ERR: Slab error [double free attempted] in pim_routetype
2012 Sep 10 16:06:21 l3sys2-agg1-A3 %PIM-3-SLAB_ERR: -Traceback: librsw.so+0x9ee8f librsw.so+0x9f173 0x81822ac 0x81c0d5d 0x812f533 librsw.so+0xb76ee librsw.so+0x9bfef librsw.so+0xa6bdf libpthread.so.0+0x6140 libc.so.6+0xca8ce
2012 Sep 10 16:06:21 l3sys2-agg1-A3 %PIM-2-SLAB_LIB_SLAB_ELEM_ERR: Slab element Alloc PC: 0x819cbef, Element index: 1097
Conditions:
Scaled set-up, seen when clear is applied in quick successions.
Workaround:
clear it once, and wait for the convergence before clearing again. flow control feature for PIM which will be introduced through this DDST will fix it.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 5.2(7), 5.2(9)S63, 6.0(3)S3, 6.1(1)S50, 6.1(2)S2, 6.1(3)S11, 6.1(3)S13, 6.1(3)S35, 6.2(2)S2, 6.2(5.7) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)AV(0.38), 7.1(0)D1(0.266), 7.1(0)D1(0.299), 7.1(0)D1(0.310), 7.1(0)D1(0.320), 7.1(0)D1(0.328), 7.1(0)OTT(0.45) |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-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: | CSCuh27257 |
Title: | Port config fails as interface config locked and ethpm queue stuck |
|
Description: | Symptom:
Nexus7000(config-if)# switchport
Please check if command was successful using appropriate show commands
Port config fails as interface config locked and ethpm queue stuck
Conditions:
configuration changes are performed on a port that is locked
Workaround:
No Workaround but to reload the device
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 5.2(3a)S1 |
|
Known Fixed Releases: | 5.2(9.180)S0, 6.1(4.97)S0, 6.1(5), 6.1(5.32)S0, 6.2(1.148)S0, 6.2(2), 7.1(0)D1(0.14), 7.2(0)VZN(0.30) |
|
|
| |
| |
Bug Id: | CSCun32658 |
Title: | BD information not present in vpc during LC reload |
|
Description: | Symptom:
After LC reload, Port-Channels wont have the Data-Structure populated properly
Conditions:
LC Reload
Workaround:
Remove and re-apply the PC config
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.0(1)FVL(0.84) |
|
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.93), 7.0(1)FVL(0.95), 7.0(2)NF(0.17), 7.1(0)D1(0.117), 7.1(0)D1(0.60), 7.1(0)D1(0.64) |
|
|
| |
| |
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: | 20-MAY-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: | CSCub55711 |
Title: | vPC+: MAC flapping when interface goes in indivudial Individual mode |
|
Description: | Symptom:
In case of port-channel (vPC+) configured with "no lacp suspend-individual". If po is down on both vPC+ peers and one interface up as individual on one peer, mac address may flap between the po and the vpc peer-link
Conditions:
Po configured with "no lacp suspend-individual"
vPC+ (fabric path configured on the peer-link)
Po down on both peers
One interface up as individual
Workaround:
Do not use LACP so that interface goes in the po as soon as up
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 5.2(5) |
|
Known Fixed Releases: | 5.2(7.36)S0, 5.2(9), 6.0(2)N1(1), 6.1(1)E1, 6.1(2)E10, 6.1(2)E10.4, 6.1(2)S12, 6.1(2.19)S0, 6.1(4.1)S0, 6.2(0.285) |
|
|
| |
| |
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: | 20-MAY-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)N1(0.14) |
|
|
| |
| |
Bug Id: | CSCuo71613 |
Title: | IPLUS 152: ISSU ND upg -> bin - FEX module preload failed |
|
Description: | Symptom:
ISSU ND from upg to bin FEX image preload is failing
Conditions:
ISSU upgrade
Workaround:
bin to upg worked fine
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1, 7.1(0)N1(0.273), 7.1(0)N1(0.347), 7.1(0)N1(0.348), 7.1(0)N1(0.349), 7.1(0)N1(0.372) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.312), 7.1(0)EV(0.116), 7.1(0)EVN(0.18), 7.1(0)N1(0.1), 7.1(0)N1(0.384), 7.1(0)N1(1), 7.1(0)OTT(0.45) |
|
|
| |
| |
Bug Id: | CSCup58752 |
Title: | ACL entries of FEX ports not deleted after removing member from zoneset |
|
Description: | Symptom:
After the zone member removal, the ACL entries programmed for the removed member will not get removed.
If the zone member is logged in through FEX or the zone member is part of zone where the devices logged in from the FEX are presents.
Conditions:
This issue will occur only with the device logged in through FEX interfaces.
Workaround:
The following is the workaround to delete the entries in the ACL when the zone member is getting removed.
1. Remove the zone member
2. Deactivate the zone set
3. Activate the zone set.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.188), 7.1(0)GF(0.24), 7.1(0)GI(0.2) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.234), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)RTG(0.22), 7.1(0)ZD(0.286) |
|
|
| |
| |
Bug Id: | CSCub48588 |
Title: | L2FM High CPU with SPAN |
|
Description: | Symptom:
CPU spike due to L2fm process
Conditions:
On configuring SPAN on VDC with F1 card.
The way this is triggered is- move a port to VDC and make it SPAN destination while it is admin down
After SPAN commands are applied, bring the port up
Workaround:
1. Keep the span destination up
2. Run the following commands on the span destination
Int eth9/30
No switchport monitor
Switchport mode fabricpath
No switchport mode fabricpath
Switchport monitor
3. Now bring up the monitor session;
conf t
monitor session 1
no shut
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 5.2(5) |
|
Known Fixed Releases: | 5.2(6.26)S0, 5.2(7), 6.1(1.58)S0, 6.1(1.69), 6.1(2), 6.2(0.285), 6.2(2), 7.2(0)VZN(0.30) |
|
|
| |
| |
Bug Id: | CSCup09291 |
Title: | BFD PC per-link member session stuck down after interface flapping |
|
Description: | Symptom:
N7710 / F348 / 6.2(8), bfd port-channel per-link session is configured, after flapping several times of those member links, several member session might stuck at down status.
Conditions:
bfd port-channel per-link session is configured.
interface flapping.
Workaround:
none
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(8) |
|
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)EV(0.137), 7.1(0)PDB(0.317), 7.2(0)D1(0.358), 7.2(0)ZD(0.47), 7.2(0)ZN(0.54) |
|
|
| |
| |
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: | 20-MAY-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: | CSCuo28456 |
Title: | N7K: ospf select wrong next-hop when redistribute route in NSSA area |
|
Description: | Symptom:
External routes in OSPF are installed over a NSSA area (instead of backbone area).
Conditions:
In case, there is reachability of OSPF external prefixes in both NSSA area and the backbone area, OSPF will install routes over those prefixes over the NSSA area.
Example topology:
area 0
N7K-1-----------N7k-2--lo1
(ABR) (ABR/ASBR)
| |
| area 1 |
| nssa |
| |
4948-1----------4948-2
The problem only occurs if one of the links between the ABRs is in the backbone
area and another is in a NSSA area. Only releases 6.2.x/7.0.x are affected by this, and prior releases are unaffected.
Workaround:
There are the following workarounds for this bug:
(1) Configure a lower-cost, normal non-backbone area adjacency between the 2 ABRs.
(2) Configure the link between the 2 ABRs as P2P, and add a multi-area link.
For example, in the topology below, the link between the 2 N7K ABRs is P2P and both in area0, and multi-area 10 at the same time.
Multi-area 10
--------------------
| area 0 |
N7K-1-----------N7k-2--lo1
(ABR) (ABR/ASBR)
| |
| area 1 |
| nssa |
| |
4948-1----------4948-2
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(2a) |
|
Known Fixed Releases: | 6.1(2)I3(1.22), 6.1(2)I3(2), 6.2(10), 6.2(10)CM(0.28), 6.2(8)TS(0.28), 6.2(9.3)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.191), 7.1(0)FC(0.2) |
|
|
| |
| |
Bug Id: | CSCuo12464 |
Title: | Titanium: igmp packets looping within a DFA fabric |
|
Description: | Symptom:
igmp packets looping within a DFA fabric
Conditions:
CPU 100% busy
Workaround:
no
Further Problem Description:
bgp lose connection due to cpu busy.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.43) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(1)ZD(0.184), 7.0(1)ZN(0.304), 7.0(3)N1(0.42), 7.0(3)N1(1), 7.1(0)BF(0.85), 7.1(0)D1(0.171), 7.1(0)FC(0.2) |
|
|
| |
| |
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: | 20-MAY-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: | CSCup57569 |
Title: | oim crash seen with 6.2.10 image during lisp multiple hop regression |
|
Description: | Symptom:
oim crash during configure LISP ESM Multiple feature configure
Conditions:
configure/un-configure LISP ESM Multiple feature
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S10, 6.2(10)S7, 6.2(10)S8 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S15, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.228), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.179), 7.1(0)ZD(0.281) |
|
|
| |
| |
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: | 20-MAY-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: | CSCue14426 |
Title: | High CPU on L2FM and MAC Move Logs |
|
Description: | Symptom:
Nexus 7000 runs high CPU on L2FM (the process manages MAC address in Nexus 7000). If 'logging level l2fm 5' is configured, the following message will be logged:
%L2FM-4-L2FM_MAC_MOVE: Mac in vlan has moved from to
Conditions:
The trigger of the problem is that a physical member of a port channel goes from individual mode to bundled mode. It requires "no lacp suspend individual" configured. This causes a hardware mis-configured on the switch.
Workaround:
shut and no shut the related physical port of the port channel
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.1(2) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S40, 5.2(9.80)S0, 6.1(2)E1, 6.1(4.1)S0, 6.1(4a), 6.1(4a)S2, 6.2(1.10)S0, 6.2(1.93), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCud51292 |
Title: | ifmgr and ethpm crash on Standby Sup during ISSU to Freetown |
|
Description: | Symptom:
ifmgr crash on Standby Sup during ISSU to Freetown
Conditions:
ifmgr crash on Standby Sup during ISSU to Freetown
Workaround:
No workaround
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(0.284)S12 |
|
Known Fixed Releases: | 6.2(0.302)S6, 6.2(1.5)S0, 6.2(2), 7.0(0.5), 7.2(0)VZN(0.30) |
|
|
| |
| |
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: | 20-MAY-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: | CSCul79456 |
Title: | DHCPv6 relay using source-int not working:UDP6 stats showing "NO PORT" |
|
Description: | Symptom:
DHCPv6 relay using source-int not working:UDP6 stats showing "NO PORT" for F3
Conditions:
Need to have global cli "ipv6 dhcp relay source-interface loopback20" configured and client-side SVI should not have ipv6 address
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S23, 6.2(5.69)S0 |
|
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)S81, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.237) |
|
|
| |
| |
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: | 20-MAY-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) |
|
|
| |
| |
Bug Id: | CSCuo76751 |
Title: | Port asic in shared mode does not set Don't_fwd and Don't_learn bit |
|
Description: | Symptom:
Symptom 1: Port-channel member interfaces go into an LACP suspended state b/c because they stop sending LACP PDUs.
Symptom 2: Ports may stop learning mac addresses and stop passing traffic
Symptom 3: Ports may stop learning mac addresses but still flood traffic
Conditions:
Symptom 1 & 2 can be seen when a span destination is configured on a port M132 port in shared mode. Other ports in the port-group will set the DL (Don't Learn) and DF (Don't Forward) bit set to ON.
N7K# slot 1 sho hard int mac port 26 state | egrep -i "dont"
dont_forward: ***On***, dont_learn: ***On***
Symptom 3 is seen when the peer-link is on a shared-mode M132 port. MAC learning is disabled on the peer-link by default. Configuring a peer-link member interface on a shared-mode M132 port will disable MAC learning on the other three ports in the port-group.
N7K# slot 1 sho hard int mac port 26 state | egrep -i "dont"
dont_forward: Off, dont_learn: ***On***
These conditions may be triggered by reloading a VDC or flapping an interface (the VDC reload results in a link flap, the link flap triggers the error condition), though it has been seen when no link flap could be confirmed. When the VDC reload is complete the links in the port channel remain in the suspended state since LACP PDUs are not forwarded.
Workaround:
Symptom 1 & 2:
To restore service:
Remove the SPAN and then shut/no shut ports in the port-group
To configure a SPAN destination on a port in shared-mode, enable ingress learning:
switchport monitor ingress learning
Symptom 3:
Do not put the Peer-link member interfaces on an M132 port in shared mode. This is against best-practice and is documented here:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/interfaces/configuration/guide/if_cli/if_vPC.html#pgfId-1803465
Further Problem Description:
Don't_fwd and Don't_learn bits are set only for SPAN configuration and VPC peer-links to disable mac learning.This is a day one issue in all codes prior to 6210. Only M132 and M132-XL line cards are affected by this bug.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(8), 6.2(8)S25 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S35, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.232), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.169) |
|
|
| |
| |
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: | 20-MAY-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: | CSCuo15363 |
Title: | L3VPN/6VPE : Post BGP restart, BGP NOT Adv VPNv4 & VPNv6 routes to Peer |
|
Description: | Symptom:
After a BGP process restart, VPNv4 and VPNv6 routes are not advertised to a peer.
Conditions:
This occurs after the BGP process is reset in some form. To verify the state of the routes, the following outputs can be checked -
show bgp vpnv4 unicast
show bgp vpnv4 unicast neighbors advertised-routes
show bgp vpnv4 unicast
The prefix should show that it's not advertised to any address-family (AF).
Workaround:
Restarting the BGP process should be tried, although this may not work every time -
restart bgp
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S1, 6.2(10)S3, 7.1(0)D1(0.85) |
|
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)BF(0.84), 7.1(0)D1(0.171), 7.1(0)FC(0.2), 7.1(0)N1(0.138), 7.1(0)N1(1), 7.1(0)NF(0.28) |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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: | 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: | 20-MAY-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)N1(0.14) |
|
|
| |
| |
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: | 20-MAY-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: | CSCuo20496 |
Title: | EIGRP crash with debugs |
|
Description: | Symptom:
eigrp service crash on nexus switch
Conditions:
enabled eigrp debugs
Workaround:
disable eigrp debug
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(2a)S20 |
|
Known Fixed Releases: | 6.0(2)A4(0.761), 6.0(2)A4(1), 6.0(2)U4(0.761), 6.0(2)U4(1), 6.2(10), 6.2(10)FM(0.28), 6.2(10)NO(0.17), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0 |
|
|
| |
| |
Bug Id: | CSCup05138 |
Title: | CPU generated traffic being sent to DEST INDEX:0 and dropped after ISSU |
|
Description: | Symptom:
CPU generated traffic such as HSRP and ARP getting dropped and not making to the forwarding egress line card.
When capturing the HSRP or ARP packets via ethanalyzer, we can see it is has set the NXOS DEST INDEX: 0 as follows.
METMXC2(config)# ethanalyzer local interface inband decode-internal capture-fi "host 10.47.25.4 and host 224.0.0.102" det Capturing on inband NXOS Protocol
NXOS VLAN: 247
NXOS SOURCE INDEX: 1054
NXOS DEST INDEX: 0
Conditions:
HSRP state is Unknown and ARP is incomplete .
Workaround:
In order to resolve the issue, we needed to remove the vlan from the configuration and re-configure it only for the affected vlans.
no vlan X
vlan x
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(6a) |
|
Known Fixed Releases: | 6.2(10)S18, 6.2(10)S94, 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.173) |
|
|
| |
| |
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: | 20-MAY-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) |
|
|
| |
| |
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: | 20-MAY-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: | CSCue14293 |
Title: | F2CR: Copp policy based cos stats mismatch with cpu stats |
|
Description: | Symptom:
For Copp policy based cos stats , we will use l3 length only for F2e linecards.
Conditions:
This is seen only on F2e linecards.
Workaround(s):
No workaround is available.
This is a hardware limitation on F2e linecards.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.1(3)S39 |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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: | CSCts64738 |
Title: | FP: MAC learning on broadcast |
|
Description: | Symptom:
Unicast macs are learnt in FP core switches during broadcast arp on setup having F2.
Condition:
On F2, unicast macs are learnt from broadcast arp resulting in macs being being learnt sub optimally in the mac table. Further uicast re-arp should take care of macs being removed on Fabricpath core switches.
Workaround:
None
This affects only switches having F2 lcs.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.0(0.47)S5 |
|
Known Fixed Releases: | 6.1(0.239)S0, 6.1(0.248)S0, 6.1(0.293)S6, 6.1(0.298)S0, 6.1(1)S31, 6.1(1)S39, 6.1(1.33)S0, 6.1(1.41)S0, 6.1(1.42)S0, 6.1(2)E10 |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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)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, 15.5(1.2.1a)GB |
|
|
| |
| |
Bug Id: | CSCun05808 |
Title: | SSTE: RSVP Core at rsvp_ha_disable after SSO test in 6.2.6a.S11 |
|
Description: | Seeing RSVP Core after SSO test
Symptom:
RSVP Core seen after SSO test following an LC reload when TE/RSVP were on
Conditions:
During RP SSO, when following these steps:
LC Reload
RP SWO
Workaround:
N/A
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(6a)S11, 6.2(8)S24, 7.1(0)D1(0.64) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.10), 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)D1(0.192) |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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: | 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: | 20-MAY-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: | 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: | 20-MAY-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: | CSCul36627 |
Title: | hmm crash by mts_opc_version_get () |
|
Description: | Symptom:
scaled
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-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: | CSCua16339 |
Title: | FEX : FEX interface goes to err disabled state after disabling dot1x |
|
Description: | Symptom:With DOT1X authentication failure, a reinit of port can actually err-disable it.
Conditions:
Workaround: shut and then "no shut" will recover the port
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 5.2(5)S12 |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S55, 5.2(9.103)S0, 6.1(1)S19, 6.1(1.19)S0, 6.2(0.217), 6.2(2), 7.2(0)VZN(0.30) |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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: | CSCuo02670 |
Title: | Fabricpath BFD per-link session stuck in down state after save & reload |
|
Description: | Symptom:
With 6 Fabricpath BFD and 11 L3 BFD sessions up on all supported interface types, We do a save and reload. After reload BFD per-link session on a port channel interface is stuck in Down state.
Conditions:
BFD per-link session stuck in Down state after reload
Workaround:
None
Further Problem Description:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 7.1(0)ZD(0.132) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)BF(0.89), 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: | 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: | 20-MAY-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)OTT(0.5), 7.2(0)PDB(0.345), 7.2(0)RTG(0.91), 7.2(0)ZD(0.88) |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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: | CSCuo82093 |
Title: | Duplicate multicast packets are detected in a mVPN N7k design |
|
Description: | Symptom:
- The Customer Edge (CE) Multicast Receiver would receive duplicate multicast packets for a time of 1 - 10 seconds
- These receivers are physically located behind one or more Provider Edge routers running IOS based code
- The CE Multicast Sources are physically located behind a pair of Nexus 7000 in a VPC domain
Conditions:
- These symptoms occurs in a mVPN design where the N7k are positioned as Provider Edge and the Multicast Sources are part of a VPC domain. The pair of N7ks are also configured for Rendezvous Points for the Customer Edge vrf.
- Order of operations:
1. Remote CE joins a multicast group, Last-Hop-Router (FHR) at the Customer Edge sent a *,G to the RP.
2. A *,G tree is created in the MPLS core from the IOS PE to the remote NX-OS PE-1 (PE-1 = primary RP)
3. When the Last-Hop-Router (LHR) receives the first multicast packet via the *,G tree it will try to join the S,G tree
4. The local PE for LHR will send a S,G towards the Source PE, but the preferred path is now via NX-OS PE-2 (PE-2 - secondary RP)
5. The NX-OS PE-2 will now add the MDT tunnel to the OIL and the multicast traffic will via the S,G tree
6. The Receiver now receives duplicate multicast packets, one via *,G and one via S,G
7. The duration of duplicate packets can range from 1 - 60 seconds
Workaround:
- Ensure the Nexus 7000 Rendezvous Points is local to the source, this will result in the remote *,G and S,G to arrive at only one N7k PE.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.1(2)E10, 6.2(10)S83 |
|
Known Fixed Releases: | 6.1(2)E10, 6.2(10), 6.2(10)CM(0.28), 6.2(8)TS(0.28), 6.2(9.3)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)BF(0.113), 7.1(0)D1(0.171) |
|
|
| |
| |
Bug Id: | CSCuq07308 |
Title: | SYSMGR-2-SERVICE_CRASHED: Service "bgp" |
|
Description: | Symptom:
Error messages such as below could exhibit when BGP is restarted, using command "restart bgp".
Service "bgp" (PID 9158) hasn't caught signal 6 (core will be saved).
Conditions:
When BGP is configured with over 1900 neighbors / peers.
Workaround:
Shutdown the peer sessions before issuing "restart bgp".
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S31 |
|
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.0(3)I1(1.160), 7.0(3)I1(2), 7.1(0)AV(0.38), 7.1(0)D1(0.301), 7.1(0)EV(0.116) |
|
|
| |
| |
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: | 20-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | 7.2(0)D1(0.496), 7.2(0)ZD(0.178) |
|
|
| |
| |
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: | 20-MAY-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: | 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: | 20-MAY-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: | 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: | 21-MAY-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)PDB(0.364), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCur57243 |
Title: | F3: OTV not Encapsulating Unicast Traffic with ARP ND Cache Disabled |
|
Description: | Symptom:
Unicast traffic over OTV is black-holed
Conditions:
- F3 OTV
- 'no otv suppress-arp-nd' configured
Workaround:
Enable the 'otv suppress-arp-nd' feature
Further Problem Description:
Issue is seen after one of the following:
- Switch reload
- VDC reload
- System switchover
- Adding an extended vlan
- Issuing 'clear ip route' in the OTV VDC
- shut/not shut on overlay interface in OTV VDC
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 21-MAY-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.14), 7.1(0)AV(0.38), 7.1(0)D1(0.343), 7.1(0)OTT(0.47), 7.1(0)PDB(0.282) |
|
|
| |
| |
Bug Id: | CSCup59693 |
Title: | N7k:RBH programming missing for flood LTL |
|
Description: | Symptom:
Broadcast traffic may not egress out port channel members(conditions a and b.) and/or physical ports( condition a.)
Conditions:
There are 2 conditions exposing the issue.
a. 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.
b. Batched request to program the affected bd ltls upon a pc membership update causing overwrite
of the port bitmaps and incorrect port bitmap programming in the hardware on F2/F3 modules.
Example: Updation of the affected BD ltl because of membership change in either 1 or both port-channels Po1,Po2 as below as part of a single request.
Po1 -> Eth1/1,Eth2/1
Po2 -> Eth1/2, Eth2/2
Workaround:
Condition a. mentioned above could happen for pc and phy ports associated with the affected BD ltls.
Condition b. above happens only in case of port channels.
Workarounds:
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.
Flap the affected vlan to cause reprogramming of the bd ltl with the right port selects.
Further Problem Description:
The fix for condition a. above will go in 6.2.10, which will be released shortly.
The fix for condition b. above has already gone in 6.2.8 and later releases.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 6.1(2), 6.2(2a), 6.2(6a), 6.2(8) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus98750 |
Title: | PVLAN: Vlan-mgr crash at "in gsdb_op_callback " |
|
Description: | Symptom:
Vlan lock is released if taken by some other event sequence when update sdb timeout has occured.
Conditions:
Lock must be taken by some other sequence.
Workaround:
No workarounds
Further Problem Description:
Thread 1 (process 7286):
#0 0x082a9726 in gsdb_op_callback (ctxt=14425967, err=0, list=0x0, count=0)
at ../infra/vlan_mgr/server/vlan_mgr_bd_sdb.c:769
#1 0xf6549886 in process_gsdb_response (msg=,
call_user_callback=1, errcnt=0x0) at ../infra/pss/shared/sdb_intf.c:3637
#2 0xf655b194 in sdb_dispatch (msg=0xffbc4167)
at ../infra/pss/shared/sdb_intf.c:3703
#3 0xf6526023 in fsrv_sdb_process_msg (mts_q=11, mts_msg=0xffbc4167)
at ../utils/fsmutils/fsrv_client.c:1467
#4 0x081022b6 in vlan_mgr_process_mts_event (q=11, msg_ref=0xffbc4167)
at ../infra/vlan_mgr/server/vlan_mgr_mts.c:4378
#5 0x080a0a3c in vlan_mgr_process_event (q_entry=0xa010d3c)
at ../infra/vlan_mgr/server/vlan_mgr_fu.c:189
#6 0x080a23a7 in vlan_mgr_dispatcher ()
at ../infra/vlan_mgr/server/vlan_mgr_fu.c:316
#7 0x0809c24b in main (argc=, argv=)
at ../infra/vlan_mgr/server/vlan_mgr_main.c:547
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.2(0.7) |
|
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)PDB(0.361), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCus18893 |
Title: | Crash due to a Kernel Panic at mts_sys_my_node_addr_get |
|
Description: | Symptom:
A Nexus device crashed due to a kernel panic. This can be determined by the outputs 'show system reset-reason' command:
----- reset reason for Supervisor-module 5 (from Supervisor in slot 5) ---
1) At 505949 usecs after Fri Dec 12 06:00:59 2014
Reason: Kernel Panic
Service:
Version: 6.2(2a)
The output of the `show logging onboard module 5 stack-trace` command displays functions from several CPUs. Usually the top CPU in the output is the one that had the issue. The following functions saw the issue in this case:
Logging time: Fri Dec 12 06:00:10 2014
1418382010:126475629 process sysinfo (7268), jiffies 0x13c4b55df
Oops
REGISTERS:
CPU: 8 Process: sysinfo (pid 7268) Tainted: P W
RIP: 0010:[] mts_sys_my_node_addr_get+0x36/0xa0 [klm_mts]
RSP: 0000:ffff88042c12dbd8 EFLAGS: 00010286
RAX: 0000000000000501 RBX: ffff880431030000 RCX: 0000000000000001
RDX: 00000000335edb01 RSI: 000000000000431c RDI: ffffffffa2cf93c0
RBP: ffff88042c12dbe8 R08: ffff88042c069b28 R09: 0000000000000002
R10: 000000022c12dc28 R11: 0000000000000000 R12: 00000000e7410020
R13: 0000000080044d1e R14: ffff880431030000 R15: 00000000e7410020
CALL TRACE:
CPU 8 Process: sysinfo (7268)
[] mts_sys_my_node_addr_get+0x36/0xa0 [klm_mts]
[] mts_syscall+0x419/0x8b0 [klm_mts] (64)
[] mts_compat_ioctl+0x7b/0x2890 [klm_mts] (736)
[] compat_sys_ioctl+0xfb/0x28e (112)
[] ia32_syscall_done+0x0/0x5 (131927355826352)
Conditions:
There is no particular events leading to this crash. This is an extremely rare case.
Workaround:
None Known. Will reload on single sup, switchover on dual sup.
Further Problem Description:
The Linux kernel detected the address in R12 (0x00000000e7410020) to be invalid. Instead of handling it gracefully, it caused an crash. Because it was a stack address, the chance of this address being invalid is almost zero.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 6.2(2a), 6.2(8a) |
|
Known Fixed Releases: | 6.1(2)I3(3.81), 6.1(2)I3(4), 6.2(10)E5, 6.2(12), 6.2(12)S14, 6.2(12.4)S0, 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(3)I1(0.209) |
|
|
| |
| |
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: | 21-MAY-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)OTT(0.5), 7.2(0)PDB(0.345), 7.2(0)RTG(0.55), 7.2(0)ZD(0.82), 7.2(0)ZN(0.103) |
|
|
| |
| |
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: | 21-MAY-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)PDB(0.353), 7.2(0)VZD(0.6), 7.2(0)ZD(0.94), 7.2(0)ZN(0.114) |
|
|
| |
| |
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: | 21-MAY-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: | 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: | 21-MAY-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)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: | 21-MAY-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)N1(0.56), 7.2(0)N1(1), 7.2(0)OTT(0.5) |
|
|
| |
| |
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: | 21-MAY-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: | 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: | 21-MAY-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)OTT(0.5) |
|
|
| |
| |
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: | 21-MAY-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)PDB(0.353) |
|
|
| |
| |
Bug Id: | CSCti11629 |
Title: | Cisco NX-OS VDC SSH Privilege Escalation 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/6.2:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:S/C:C/I:C/A:C/E:H/RL:OF/RC:C
CVE ID CVE-2014-2200 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: | 21-MAY-2015 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: | 5.0(3)N1(1), 5.0(5.1)S0 |
|
|
| |
| |
Bug Id: | CSCte62771 |
Title: | Command Injection in admin CLI |
|
Description: | Symptoms:
A vulnerability exists in affected versions of NX-OS which could allow an authenticated local attacker to inject shell commands. A successful exploit
would allow an attacker to gain elevated privileges on the underlying operating system.
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
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-2011-4235 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: | 21-MAY-2015 |
|
Known Affected Releases: | 4.0(4)SV1(2), 4.2(1), 4.2(3) |
|
Known Fixed Releases: | 4.2(1)N2(1), 4.2(4), 4.2(4.14), 4.2(5), 5.0(1), 5.0(1.24) |
|
|
| |
| |
Bug Id: | CSCth76379 |
Title: | OSPF MTS buffer leak |
|
Description: | Problem:
Under certain conditions, OSPF internal message queue could fillup,
and could eventually prevent further messaging into OSPF until the condition
is cleared by a reload or supervisor switchover.
Symptom:
When the internal messaging queue is full, and there is a large amount of
update coming into OSPF, it is possible that OSPF neighborship will not be
formed with this router.
Workaround:
Remove any SNMP context configuration mappings to vRFs
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | 4.2(7.38)S0, 4.2(7.39)S0, 5.0(3)S34, 5.0(3)S36, 5.0(3.43)S0, 5.1(0.193)S0, 5.1(0.194)S0, 5.1(1), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuo79856 |
Title: | N7K Incomplete CTS policies after port-channel coming up |
|
Description: | Symptom:
On a nexus 7000 series switch in a cts enforcement scenario, not all policies for the configured security group tag may be appearing on the device after a port-channel is coming up.
For example, for this interface configuration :
interface Ethernet1/1
cts manual
policy static sgt 0x64 trusted
switchport mode fabricpath
no snmp trap link-status
logging event port link-status
channel-group 11 mode active
If this port-channel flaps, more specifically if we have two member ports of the port-channel coming shortly one after another, not all policies configured on ISE or ACS server with destination group tag 0x64 may be seen in show cts role-based policy
Conditions:
Workaround:
Perform a "cts refresh role-based-policy"
Further Problem Description:
CSCuo65802 addresses this defect for nexus 5000 series switches
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.3), 6.2(8)E3, 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: | CSCti23447 |
Title: | Malformed IP packet causes Netstack crash |
|
Description: | Cisco NX-OS Software is affected by a denial of service (DoS) vulnerability
that could cause Cisco Nexus 1000v, 5000, and 7000 Series Switches that are
running affected versions of Cisco NX-OS Software to reload when the IP stack
processes a malformed IP packet.
Cisco has released free software updates that address this vulnerability.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120215-nxos
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: | 4.2(1)SV1(4), 5.0(2)N1(1), 5.0(5)S3, 5.0(5.1)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCup44514 |
Title: | MACSEC: N7K Port flap on N7K-M148GS-11(opackets dropped for few seconds) |
|
Description: | Symptom:
MACSEC N7K port of module N7K-M148GS-11 with 4500 port
shows port flapping or packet loss (for instance EIGRP flapping).
It happens intermittently (once per day, few times per day, once in few weeks)
Port comes up immediately.
Conditions:
4500 1G interop with Module N7K-M148GS-11 and used with MACSEC configuration
Workaround:
- disable MACSEC
- use different module than N7K-M148GS-11
Further Problem Description:
We have not seen any issues in last 7 years, but this is the first interop issue we got.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.19), 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.302), 7.2(0)D1(0.387), 7.2(0)OTT(0.5) |
|
|
| |
| |
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: | 21-MAY-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)N1(0.143) |
|
|
| |
| |
Bug Id: | CSCsx23179 |
Title: | BGP session resets because AS4_PATH has AS_CONFED_SEQUENCE |
|
Description: |
Symptom:
NX-OS clears the BGP session upon receiving a prefix that has the AS4_PATH attribute
with AS_CONFED_SEQUENCE in it.
Conditions:
A prefix with AS4_PATH attribute with AS_CONFED_SEQUENCE in it is received.
Workaround:
Filter the prefix out further upstream.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 4.1(2) |
|
Known Fixed Releases: | 4.1(4), 4.2(0.147), 4.2(0.156), 4.2(1), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCtf23559 |
Title: | VSH parsing of pipe 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-4076 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-4076
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: | 21-MAY-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | 5.0(2), 5.0(2.35), 5.0(2.37), 5.1(0.70), 5.1(0.76), 5.1(1), 7.2(0)ZN(0.111) |
|
|
| |
| |
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: | 21-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu38313 |
Title: | ETHPORT-2-IF_SEQ_ERROR: Error ("sequence timeout") |
|
Description: | Symptom:
ETHPORT-2-IF_SEQ_ERROR: Error ("sequence timeout") seen on syslog
Conditions:
On Scale Setup - with 384 fabric path bfd sessions & 1616 FP bfd sessions on L3 SVI. While adding/removing the FP members from Vlan
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup18687 |
Title: | CSCup18687SGT mappings not downloaded to HW after module comes online |
|
Description: | Symptom:
On a nexus 7000 series switches, IP to DGT mappings, may not be honoured following a supervisor switchover and a module reload.
Conditions:
Workaround:
The following can be performed to re-install the SGT mappings in the hardware :
- If statically configured, reapply the static SGT mapping configuration
- If learnt via SXP, reapply the SXP configuration.
- clear ip route A.B.C.D will also cause the mapping to be reprogrammed.
This will fix the issue until the next module reload happens as the initial trigger is the supervisor switchover. A reload will permanently clean the issue until a switchover followed by a module reload happens.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 6.1(3), 6.2(2), 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S5, 6.2(10.5) |
|
|
| |
| |
Bug Id: | CSCtq32783 |
Title: | snmpd asserts on length validation check when receiving malformed reques |
|
Description: | Symptoms:.
snmpd process in a system running NX-OS software may crash due to corrupted SNMPv2c set request.
Conditions:
The SNMP process handles a malformed set request.
Workaround:
none
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 4/3.3:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2011-2051 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 5.2(0.907)S4 |
|
Known Fixed Releases: | 5.2(1)S26, 5.2(1.31)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCtw78172 |
Title: | Dont_learn not set on peer link |
|
Description: | Symptom:
Macs learnt on peer_link of M1 linecards.
Conditions:
When the switch has multiple vdc's and on one vdc VPC is configured and another vdc VPC
(emulated vpc) is configured, then DONOT learn on peer_link is not set in port asic for M1
Linecards. This causes packets coming in from peer link to be learnt by hardware.
Workaround(s):
Removing emulated switch config from the switch will restore the correct behavior.
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: | 21-MAY-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | 5.2(3)S24, 5.2(3.25)S0, 6.0(2)S21, 6.1(0.165)S0 |
|
|
| |
| |
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: | 21-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8), 6.2(8a) |
|
Known Fixed Releases: | 6.2(14)FB(0.17), 7.1(0)AV(0.74), 7.2(0)D1(0.453), 7.2(0)PDB(0.375), 7.2(0)VOF(0.2) |
|
|
| |
| |
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: | 21-MAY-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: | 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: | 21-MAY-2015 |
|
Known Affected Releases: | 6.1(3) |
|
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: | 21-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.484) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCub85673 |
Title: | F2 module is present in Admin VDC |
|
Description: | Symptom:
Nexus 7000 allows interfaces to be allocated to the admin VDC
Conditions:
This occurs occurs when the chassis has only F2 modules.
Steps to reproduce:
Boot the Nexus 7000 with only F2 modules
Set the default VDC as the Admin VDC.
Save the config and reload
After reload the admin VDC is set as an F2 VDC and interfaces can be allocated.
Issue does not occur in a mixed chassis.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 6.1(1.69), 6.1(2)S1 |
|
Known Fixed Releases: | 6.1(1.73)S0, 6.1(2), 6.2(0.285), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCts56669 |
Title: | Read-only user can create and overwrite files |
|
Description: |
Symptom:
Cisco Nexus devices contain an input validation vulnerability. This issue could allow a local, authenticated attacker to create or overwrite arbitrary files
on the device. This issue affects all user account types including Read-Only users.
This issue affects Nexus 7000 series and Nexus 5000 series devices.
Conditions:
Devices running an affected version of NX-OS Software.
Workaround:
Restrict access to trusted users only.
Further Problem Description:
This issue was identified during an internal security audit of Cisco Nexus devices.
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.6/3.8:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:L/Au:S/C:N/I:C/A:N/E:F/RL:OF/RC:C
CVE ID CVE-2012-4122 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-4122
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: | 21-MAY-2015 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: | 6.2(0.41)S0, 6.2(2), 7.0(1)ZD(0.3) |
|
|
| |
| |
Bug Id: | CSCuu45561 |
Title: | BFD sending DELETE on F2 module w/o sending an ADD operation |
|
Description: | Symptom:
Acl qos core seen
Conditions:
Have L2 BFd sessions, kill bfdc/aclqos
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.506) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur99327 |
Title: | N7K10G: Rollback is failing on the scale setup |
|
Description: | Symptom:
Rollback to a previously created checkpoint might fail at "no license grace-period" command.
Conditions:
This only happened when performing rollback after "write erase" and on scale setup.
This issue is not always reproducible.
Workaround:
Issue another rollback with "best-effort" option first. And do "no license grace-period" manually if necessary.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 6.2(12)FT(0.26) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtq30759 |
Title: | snmpd might crash due to malformed SNMP packets |
|
Description: | Symptoms:.
snmpd process in a system running NX-OS software may crash due to corrupted SNMPv2c set request.
Conditions:
The SNMP process handles a malformed set request.
Workaround:
none
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:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2011-2047 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: | 21-MAY-2015 |
|
Known Affected Releases: | 5.2(0.907)S4 |
|
Known Fixed Releases: | 5.2(1)S23, 5.2(1.27)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCtu39708 |
Title: | Non-dflt VDC grants access to unauthorized user via SSH |
|
Description: | Symptoms:
A Cisco Nexus switch may allow unauthorized users SSH access under specific
circumstances. However, the user is logged in as a VDC-operator. No escalation is
possible from VDC-operator to VDC-admin.
Conditions:
Device configured with SSHv2 and logging in to a non-default VDC.
Workaround:
Please execute the following command :
"no tacacs-server directed-request"
This would ensure that the unauthorized user would not be able to login.
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:N/AC:M/Au:N/C:P/I:N/A:N/E:F/RL:OF/RC:C
CVE ID CVE-2011-4495 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: | 21-MAY-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | 5.1(6)S2, 5.2(3)S9, 5.2(3.8)S0, 6.0(2)S12, 6.1(0.151)S0 |
|
|
| |
| |
Bug Id: | CSCtx54830 |
Title: | Specific SNMP GET request causes 'snmpd' and 'licmgr' services to crash |
|
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
Conditions:
See published Cisco Security Advisory
Workarounds:
See published Cisco Security Advsiory
Further Problem Description:
See published Cisco Security Advisory
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-1179 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: | 21-MAY-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: | CSCti69207 |
Title: | Security Issue in OpenSSL |
|
Description: | Symptom:
The device may be affected by an OpenSSL vulnerability described in CVE-2010-2939.
Conditions:
Device configured with any feature that uses SSL.
Workaround:
Not available
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:N/AC:M/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2010-2939 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: | Other |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 4.0(1a)N2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup56162 |
Title: | Anycast HSRP custom VMAC not programmed after hsrp restart |
|
Description: | Symptom:
Anycast HSRP with custom VMAC is not programmed at L2FM as gateway after HSRP process stateful restart.
Conditions:
Anycast HSRP is configured with non-default VMAC and HSRP engine process is restarted.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 7.3(0)IB(0.6) |
|
|
| |
| |
Bug Id: | CSCtk34535 |
Title: | Nexus reset due to HA policy on multiple CDP process crash |
|
Description: | Symptoms:
A Cisco Nexus 7000 may reset due to a HA policy if the CDP process crashes multiple times
Conditions:
This has been seen when processing a malformed CDP packet
Workaround:
Disable the CDP process
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:
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:OF/RC:C
CVE ID CVE-2012-2469 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: | 21-MAY-2015 |
|
Known Affected Releases: | 4.2(6) |
|
Known Fixed Releases: | 5.0(5)E1, 5.1(4)E3, 5.1(5)S1, 5.2(0.149)S0 |
|
|
| |
| |
Bug Id: | CSCuu45553 |
Title: | bfd crash seen with bfd_mts_flush_all_bfdc_msgs decodes |
|
Description: | Symptom:
BFD core seen
Conditions:
During copy config to run config
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
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: | 21-MAY-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: | CSCtj42789 |
Title: | SNMP set of SysName does not result in matching configuration change |
|
Description: | SYMPTOM:
Changing system name via SNMP does not result in
a configuration change.
CONDITIONS:
This issue happens when the system name is configured
via SNMP.
WORKAROUND:
Change the system name via non-SNMP method.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-MAY-2015 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: | 5.1(1.37)S0 |
|
|
| |
| |
Bug Id: | CSCtn11475 |
Title: | IPv6 Traffic Causing System Instability |
|
Description: | Symptom:
Cisco Nexus 7000 experiences performance degradation when processing IPv6 packets.
During different tests, when a device/client sends ICMPv6 Neighbor Solicitation messages, not all packets
were rate-limited successfully, thus causing performance degradation.
Note: ICMPv6 Neighbor Advertisement and Neighbor Solicitation are used to facilitate host-router
discovery functions as part of the IPv6 Neighbor Discovery (ND) protocol. IPv4 is not impacted by this issue.
Conditions:
Cisco Nexus 7000 configured for IPv6.
Workaround:
Not available.
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/4.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2011-0368 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: | 21-MAY-2015 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: | 5.1(10.1)S0, 5.1(3)S17, 5.1(3)S22, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuc19553 |
Title: | RADIUS insufficient attribute length check |
|
Description: | Symptoms:
Cisco NXOS contains a vulnerability in the RADIUS authentication code.
Conditions:
Malformed packets are returned from a RADIUS authentication server.
Workaround:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2012-6377 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: | 21-MAY-2015 |
|
Known Affected Releases: | 6.0(3) |
|
Known Fixed Releases: | 6.1(2.45)S0, 6.2(0.273)S0, 6.2(0.285), 6.2(2) |
|
|
| |
| |
Bug Id: | CSCui22543 |
Title: | Corrupted packet causes CFS to crash |
|
Description: | <B>Symptom:</B>
If a Nexus 7000 receives a corrupted GRE packet with protocol type 0x8843 the packet will be
punted to the CPU and cause CFS to crash.
If dual supervidors are present successive corrupted packets will cause a supervisor failover and
possibly a reload of the VDC that received the corrupted packets.
If the switch has only a single supervisor the switch may reload.
<B>Conditions:</B>
The issue occurs when a corrupted packet with protocol type 0x8843 is received
<B>Workaround:</B>
none
<B>More Info:</B>
|
|
Status: | Other |
|
Severity: | 1 Catastrophic |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 5.2(7), 6.0(4), 6.1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 22-MAY-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: | 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: | 22-MAY-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)N1(0.12), 7.2(0)N1(0.3) |
|
|
| |
| |
Bug Id: | CSCuo34849 |
Title: | N7K:Incorrect CBL programming of vlans on members of portchannel |
|
Description: | Symptom:
This is post-ISSU scenario. Due to specific sequence of PVLAN events and ISSU combination, PIXM can undergo memory corruption and this can lead to of the following issues
- PC and its members are error disabled
- Incorrect CBL programming
- PIXM may crash
Conditions:
Pre-conditon to hit defect:- You should have a port-channel carrying private vlan. Regular layer two trunk carrying plan will not be affected from this defect.
1. Primary VLAN should be associated to Secondary VLAN
2. PC should be trunk PC carrying both primary and secondary VLANs
3. STP operating on either primary or secondary on trunk PC.
4. Any PC modify operation (ADD/REMOVE) on the PC will result in above symptoms.
Workaround:
1: First disassociate Secondary VLAN from Primary
2. Delete the Primary and Secondary VLAN
3. Recreate the same Primary and Secondary VLANs and apply the config
4. Wait for some time for protocols to converge on both the VLANs
5. Finally associate Secondary to Primary VLAN
Further Problem Description:
The issue can happen only on 6.2.6 and 6.2.6a image.
This issue is fixed in 6.2.8 and is ONLY green start compliant, which means , if you already ran into this bug in 626 and you simply did ISSU to 628 , issue will still be present in 628. Please try to follow above workaround in 628 before doing ISSU to 628. Or simply upgrade to 628 using traditional reload method.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 6.2(6a), 6.2(8)S17 |
|
Known Fixed Releases: | 6.2(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: | 22-MAY-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(14)FB(0.28), 7.1(0)AV(0.74), 7.2(0)D1(0.469), 7.2(0)PDB(0.394) |
|
|
| |
| |
Bug Id: | CSCul72684 |
Title: | N7k: Default credentials vulnerability on CMP |
|
Description: | Symptoms:
A vulnerability in authentication module of CMP component of Cisco Nexus 7000 could allow an authenticated, remote attacker to log in to CMP using
credentials that were previously deleted from the Supervisor.
The vulnerability is due to the way CMP caches credentials from a Supervisor, if the user ever uses these credentials to log in to the CMP. Once deleted
from a Supervisor, those credentials will still be cached on the CMP. An attacker could exploit this vulnerability by loging into the CMP, using deleted
credentials from a Supervisor.
Conditions:
If the local user exists on the Supervisor, and is used to log into the CMP, CMP will cache those credentials.
All credentials are authenticated by the Supervisor, if the Supervisor is running.
When the local user is deleted from the Supervisor, the CMP still caches those credentials and they may be used to log in directly to CMP.
Workaround:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are
2.1/1.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:S/C:P/I:N/A:N/E:POC/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: | 22-MAY-2015 |
|
Known Affected Releases: | 5.0(0.66) |
|
Known Fixed Releases: | 5.2(9.280)S0, 6.1(5), 6.1(5)S8, 6.2(0)HS(0.10), 6.2(7.7)S0, 6.2(8), 6.2(8)CM(0.7), 6.2(9)FM(0.37), 7.1(0)ZD(0.200) |
|
|
| |
| |
Bug Id: | CSCto47349 |
Title: | N7K: allowed trunk vlans are gone after switchover |
|
Description: | Symptom:
Allowed trunk vlans are removed from configuration after a switchover
Conditions:
trunk vlan is removed by "remove" syntax before executing switchover.
Nexus7000(config-if)# switchport trunk allowed vlan remove
The issue is observed on NX-OS 5.1(3)
Workaround:
When modifying trunk vlans, NOT to use "remove" option can be
a workaround.
For instance, you would like to remove vlan 1,51 from trunk,
you can overwrite the trunk vlan other than vlan 1,51.
Nexus7000-B(config-if)# switchport trunk allowed vlan 2-50,52-100
This will cause VLANS to be overwritten. Continue anyway? [yes]
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: | 5.1(10.1)S0, 5.1(3)E5, 5.1(4)S0 |
|
|
| |
| |
Bug Id: | CSCup10049 |
Title: | ACLQOS crash and %IPQOSMGR-3-QOSMGR_PPF_ERROR: PPF library error: |
|
Description: | Symptom:
A Nexus C7009 running NX-OS version 6.2(2a) may have a crash in aclqos with accompanied core file(s).
%SYSMGR-SLOT3-2-SERVICE_CRASHED: Service "aclqos" (PID ) hasn't caught signal 6 (core
will be saved).
Post crash, the below messages may also be seen:
%IPQOSMGR-3-QOSMGR_PPF_ERROR: PPF library error: MTS
Error 0x801c0010 (Device or resourc e busy) after 1706 retries .
Conditions:
there were too many queries from ipqosmgr and COPP to aclqos
Workaround:
Not known at this time.
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 6.2(2a), 6.2(6) |
|
Known Fixed Releases: | 6.1(2)I3(1.19), 6.1(2)I3(2), 6.2(10), 6.2(10)S92, 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)D1(0.326) |
|
|
| |
| |
Bug Id: | CSCue02901 |
Title: | Logging server shows unreachable, syslog not delivered |
|
Description: | Symptom:
show logging server output shows the following text for a logging server:
'This server is temporarily unreachable'
While ping to the same server IP / hostname is successful.
Conditions:
Workaround:
Run following commands:
DC1-4(config)# no logging server 172.28.92.10 7 use-vrf management facility local6
DC1-4(config)# logging server 172.28.92.10 7 facility local6
DC1-4(config)# logging source-interface loopback 0
Configuring logging source-interface will open UDP/syslog socket(514).
DC1-4(config)# logging server 172.28.92.10 7 use-vrf management facility local6
DC1-4(config)# no logging source-interface loopback 0
UDP/syslog socket(514) is being closed.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 5.2(7), 6.1(2) |
|
Known Fixed Releases: | 6.0(2)U2(2.29), 6.0(2)U2(3), 6.0(2)U3(0.617), 6.0(2)U3(1), 6.0(2)U4(0.60), 6.0(2)U4(1), 6.2(5)BF(0.24), 6.2(5.42)S0, 6.2(6) |
|
|
| |
| |
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: | 22-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.409), 7.2(0)N1(0.111) |
|
Known Fixed Releases: | 7.2(0)D1(1), 7.2(0)N1(0.213), 7.2(0)N1(1), 7.2(0)ZD(0.194), 7.2(0)ZN(0.213) |
|
|
| |
| |
Bug Id: | CSCuj13702 |
Title: | Make 'to' option of lig only available to admin-level users |
|
Description: |
Symptom:
Cisco IOS and Cisco NX-OS contain a vulnerability that could allow an authenticated, local attacker to poison the LISP routing cache on the router
configured as a ITR.
Conditions:
An attacker needs to have a privilege 0 local access to the ITR router and execute ''lig'' commands.
Workaround:
1. configure ''privilege exec level 15 lig'', to prevent privilege level 1 users from executing the lig command.
2. use separate VRFs for the EID and RLOC spaces, assuming the attacker does not have access to the RLOC case.
3. using GETVPN or other crypto in the RLOC space may mitigate against this, but not in the common deployment scenario, where crypto maps are
applied to the LISP0 interface.
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.5/1.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:M/Au:S/C:N/I:P/A:N/E:F/RL:W/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: | 22-MAY-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.2(5)BF(0.23), 6.2(5.42)S0, 6.2(6) |
|
|
| |
| |
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: | 22-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(14)FB(0.58) |
|
|
| |
| |
Bug Id: | CSCun25245 |
Title: | NLB mutlicast mac unicast IP duplicated by the CPU |
|
Description: | Symptom:
Packets with Unicast IP and Multicast MAC are being duplicated on the destination interface. which can cause performance issues to the application.
Conditions:
on using MS NLB Option 2: Static ARP + MAC-based L2 Multicast Lookups + Static Joins + IP Multicast MAC
Workaround:
use unicast mode.
Further Problem Description:
Packets that are copied to the CPU must meet:
- Packet needs to be intervlan Routed
- Multicast L2 lookup is MAC based
- We have either an IGMP Static entry for the "group" or received a "join" entry.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 6.2(2a), 6.2(6) |
|
Known Fixed Releases: | 7.1(0)D1(0.198), 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)PDB(0.155), 7.1(0)RTG(0.12), 7.1(0)SIB(99.6), 7.1(0)VX(0.3), 7.1(0)ZD(0.254) |
|
|
| |
| |
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: | 22-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E5, 6.2(14)FB(0.36), 7.1(0)AV(0.74), 7.2(0)D1(0.485), 7.2(0)ZD(0.167) |
|
|
| |
| |
Bug Id: | CSCut93469 |
Title: | SUP2,F2E ,arp response failing with SI set as GPC LTL |
|
Description: | Symptom:
ARP responses for the HSRP VIP are dropped.
Conditions:
An ARP response from the active HSRP Anycast is dropped on the HSRP Anycast standby when enabling Dynamic ARP Inspection.
This problem only occurs when having the vdc configured for 'limit-resource module-type F2 F2E' and only hosting F2E linecards on the chassis.
Workaround:
Reconfigure the vdc for F2E only support and rebind the interfaces.
vdc xxx id 1
limit-resource module-type f2e
This ensures that the F2E linecard is using the physical source interface instead of using the HSRP anycast GPC as the source interface for incoming ARP responses.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 6.2(10)E8 |
|
Known Fixed Releases: | 6.2(10)E3, 7.2(0)D1(1) |
|
|
| |
| |
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-MAY-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) |
|
|
| |
| |
Bug Id: | CSCus58902 |
Title: | Potential of opening al back door |
|
Description: | Symptom:
If the admin user is able to reach the underlying OS shell, it migh be possible to create a fully functional operating system account that could have unlimited access to the underlying operating system.
Conditions:
Requires full administrative access to the device and the existence of a separate bug that would allow the administrator to access the underlying operating system
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-MAY-2015 |
|
Known Affected Releases: | 7.2(0)ZN(0.36) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 23-MAY-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)PDB(0.347) |
|
|
| |
| |
Bug Id: | CSCuu01321 |
Title: | ipfib crash @ fln_ecmp_alloc_block_inst_bmap |
|
Description: | Symptom:
When there is an ECMP comprised of two traffic engineering tunnels, and one of them is the backup (in this case the backup is also announced for routing which is not supposed to be done), if the process ipfib is restarted, it might crash.
Conditions:
ipfib process can be restarted when there is a crash due to some bug or when ISSU is performed.
Workaround:
Don't use backup tunnel for routing. This way there will be no ECMP and the crash can be avoided. In general avoid having an ECPM with tunnels when performing ISSU.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 24-MAY-2015 |
|
Known Affected Releases: | 6.2(12)S29 |
|
Known Fixed Releases: | |
|
|
| |
| |
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-MAY-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: | 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-MAY-2015 |
|
Known Affected Releases: | 7.0(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 25-MAY-2015 |
|
Known Affected Releases: | 6.2(6)S9 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCub16539 |
Title: | SNMP MTS Buffer Leak on VLAN MIBs - dot1d bridge, vlan membership, smon |
|
Description: | Symptom:
A Nexus 7k or 5k switch may experience crashes in the SNMPd process. Errors leading up to the crash hint at an MTS issue with the SAP used by SNMP. Eg:
KERN-2-SYSTEM_MSG mts_is_q_space_available_old(): NO SPACE - node=4, sap=27, uuid=26, pid=28679, sap_opt = 0x1, hdr_opt = 0x0, rq=1122(322640), lq=0(0), pq=0(0), nq=0(0), sq=0(0), fast: rq=0, lq=0, pq=0, nq=0, sq=0 - kernel
KERN-2-SYSTEM_MSG mts_print_longest_queue_state: opcode counts for first and last 50 messages in recv_q of sap 27: - kernel
KERN-2-SYSTEM_MSG mts_print_msg_opcode_in_queue: opcode 7679 - 100 messages - kernel
KERN-2-SYSTEM_MSG mts_do_msg_input() failing since no space available in 27 (src_sap = 27, opc = 8923) - kernel
Conditions:
The leak occurs when polling a VLAN MIB and performing a walk down the MIB's subtree -- specifically the dot1d bridge MIB, vlan membership MIB, and smon MIB.
Workaround(s):
None known.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 5.2(5), 6.1(1) |
|
Known Fixed Releases: | 5.2(1)N1(5), 5.2(6.23)S0, 5.2(7), 6.0(2)A1(1), 6.0(2)N1(1), 6.0(2)U1(1), 6.1(1)S50, 6.1(1.48)S0, 6.1(1.69) |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtk56774 |
Title: | Some of the telnet sessions do not get cleared with recursive telnet |
|
Description: | Symptom:
Telnet sessions do not get cleared on the Nexus switch.
Checking 'sh proc cpu', a lot of 'dcos-telnet' processes are still running even though these sessions do not exist anymore.
Conditions:
Customer is using a script to telnet into the Nexus, and then telnet to other devices from there.
Workaround(s):
to issue "clear user admin" command
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 5.1(1.77) |
|
Known Fixed Releases: | 5.2(1)N1(1), 5.2(3.1), 6.0(0.13)S0 |
|
|
| |
| |
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: | 25-MAY-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) |
|
|
| |
| |
Bug Id: | CSCuq05409 |
Title: | NXOS/SPM/PPF: MTS buffer full after infinite loop in PPF show |
|
Description: | Symptom:
High number of messages cause low memory in MTS for internal SPM process (SAP 487) and consequent crash of SPM and switchover.
Conditions:
This is rare corner case where issue can happen during execute show cli inside sh tech spm (or as part of tac-pac).
Workaround:
Use an EM script to vlock the following CLI:
sh tech spm
show system internal spm ppf info all
show tech-support netflow
sh tech aclmgr
show system internal aclmgr ppf control
sh tech copp
show system internal copp ppf-database policy all
sh tech ipqos
show system internal ipqos ppf-lib
sh tech pbr
sh tech rpm
show system internal rpm ppf
sh tech aclqos
show system internal aclqos database policy control
show system internal aclqos event-history ppf
sh tech cts
show cts internal ppf
sh tech dhcp
show system internal dhcp database policy all
sh tech npacl
show system internal npacl ppf
sh tech-support ip
show ip internal acl ppf
show ip internal ppf
show tech-support netflow
show system internal flow nf ppf
show flow internal ppf db
Not in sh tech but trigger ppf show:
show system internal ipqos ppf control
show tunnel internal database policy all
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
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S34, 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.224), 7.1(0)FC(0.2), 7.1(0)N1(0.275), 7.1(0)N1(1), 7.1(0)NF(0.32) |
|
|
| |
| |
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: | 25-MAY-2015 |
|
Known Affected Releases: | 5.2(1), 6.1(4) |
|
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: | CSCuq31499 |
Title: | N7K FEX satctrl hap reset |
|
Description: | Symptom:
FEX attaching to N7K may crash:
1) At 659678 usecs after Thu Jul 31 09:03:30 2014
Reset Reason: Reset triggered due to HA policy of Reset (16)
Service (Additional Info): satctrl hap reset
Image Version: 6.2(8)
Conditions:
there is no trigger can be found for now.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 6.2(8)S9 |
|
Known Fixed Releases: | 6.1(2)I3(3.71), 6.1(2)I3(4), 6.2(0)FH(0.167), 6.2(10.19)S0, 6.2(12), 6.2(12)FT(0.27), 7.0(2)FG(0.38), 7.0(3)I1(1.99), 7.0(3)I1(2), 7.0(3)I2(0.140) |
|
|
| |
| |
Bug Id: | CSCtt38629 |
Title: | Emerson 6KW AC supply fails when power restored on input 1 |
|
Description: | Symptom:
Using N7K 6KW AC power supplies that have serial number starting with AZS (manufactured by Emerson) may inadvertently shutdown momentarily when power is restored to input 1 after a power failure of two or more supplies. This is seen when simulating a grid failure. See logs for example:
2011 Oct 13 19:18:00 N7K-7010-2 %PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS1 changed its capacity. possibly due to power cable removal/insertion (Serial number DTM1423007S)
2011 Oct 13 19:18:00 N7K-7010-2 %PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS2 changed its capacity. possibly due to power cable removal/insertion (Serial number AZS1526101E)
2011 Oct 13 19:18:03 N7K-7010-2 %PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS1 changed its capacity. possibly due to power cable removal/insertion (Serial number DTM1423007S)
2011 Oct 13 19:18:05 N7K-7010-2 %PLATFORM-5-PS_STATUS: PowerSupply 2 current-status is PS_FAIL
2011 Oct 13 19:18:05 N7K-7010-2 %PLATFORM-2-PS_FAIL: Power supply 2 failed or shut down (Serial number AZS1526101E)
2011 Oct 13 19:18:05 N7K-7010-2 %PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS2 changed its capacity. possibly due to power cable removal/insertion (Serial number AZS1526101E)
2011 Oct 13 19:18:05 N7K-7010-2 %PLATFORM-2-PS_RED_MODE_RESTORED: Power redundancy operational mode changed to configured mode
2011 Oct 13 19:18:07 N7K-7010-2 %PLATFORM-5-PS_FOUND: Power supply 2 found (Serial number AZS1526101E)
2011 Oct 13 19:18:07 N7K-7010-2 %PLATFORM-2-PS_OK: Power supply 2 ok (Serial number AZS1526101E)
2011 Oct 13 19:18:07 N7K-7010-2 %PLATFORM-5-PS_STATUS: PowerSupply 2 current-status is PS_OK
2011 Oct 13 19:18:07 N7K-7010-2 %PLATFORM-2-PS_FANOK: Fan in Power supply 2 ok
Conditions:
Only occurs on restoring power to input 1. Input 2 does not exhibit this problem.
Only 6.0KW AC power supplies starting with serial number AZS are affected with this issue.
Power supples starting with serial number DTM are NOT affected with this issue.
Workaround:
There is no workaround
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 5.1(5), 5.2(1), 6.0(1)S3 |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 25-MAY-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: | CSCtu10608 |
Title: | CDP with long protocol crashes process |
|
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
7.8/6.4:
https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2013-1181 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: | 25-MAY-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | 5.2(3.30)S0, 5.2(3.39)S0, 6.1(0.137)S0, 6.1(0.145)S0, 6.1(0.173)S0 |
|
|
| |
| |
Bug Id: | CSCuu11331 |
Title: | N7K - SNMP snmpd core os_syscall_ioctl, tcp_api.c, libmts.c running UTE |
|
Description: | Symptom:snmpd crashed. In the background 8 out of 10 times its aclqos mib causing the problem.
Conditions:This happens when CPU utilization is high from the normal.
Workaround:snmpd restart is stateful so it boots up with all the configs intact.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S102, 7.2(0)D1(0.475), 7.2(0)D1(0.484) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtr44645 |
Title: | Command Injection vulnerability with the | section command |
|
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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.0(3)N1(1) |
|
Known Fixed Releases: | 4.2(8.133)S0, 5.0(7.5)S0, 5.1(10.73)S0, 5.1(6)S2, 5.2(1)S72, 5.2(1)S73, 5.2(1.61)S0, 7.0(1)ZD(0.3) |
|
|
| |
| |
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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: | 4.2(1), 4.2(1.44), 4.2(2) |
|
|
| |
| |
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: | 26-MAY-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: | 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: | 26-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun73067 |
Title: | WCCP redirect policy config fails/ Vlan addition fails |
|
Description: | Symptom:
Attempted deletion of WCCP policy fails. Further additions of policy may hit the error "Invalid operation".
Another possible symptom for this bug is the inability to create new vlans.
Conditions:
An aborted WCCP configuration must have occurred in the past.
or
ISSU to 6.2(2) and EPLD upgrade.
Workaround:
Reloading the switch will resolve this.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.2(7.19)S0 |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(8), 6.2(8)S8, 6.2(8.5) |
|
|
| |
| |
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: | 26-MAY-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: | CSCug47098 |
Title: | N7k Internal Loop on M1 Module |
|
Description: | SYMPTOM:
Nexus 7000 with M1 modules only or in mixed chassis may experience
internal loop conditions across VDCs that saturate all interswitch links
and affects all services on the switch causing a network outage.
Symptom:
Conditions:
Nexus 7000 series switch with M1 series linecards.
Workaround:
Prune VLAN 1 from all trunks. This will prevent the internal loop
conditions.
FURTHER INFORMATION:
This issue is caused when the switch receives a non-standard Ethernet
frame. In this case, the non-standard Ethernet frame is replicated over
interswitch links, which then causes the looping condition.
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.5:
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:W/RC:C
CVE ID CVE-2013-1226 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-2013-1226
Information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
Further Problem Description:
The workaround mentioned was for customer where issue was first reported. There is no guaranteed workaround.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.0(1), 6.1(3) |
|
Known Fixed Releases: | 5.2(9.145)S0, 5.2(9.197)S0, 6.1(4.97)S0, 6.1(4a), 6.1(4a)S1, 6.1(4a)S3, 6.1(5.32)S0, 6.2(1.100)S0, 6.2(2), 7.0(0)ZD(0.53) |
|
|
| |
| |
Bug Id: | CSCud69928 |
Title: | N7K: Received Duplicate DBD packets cause 7K to increase sequence number |
|
Description: | Symptom:
N7K may incorrectly increment its DBD sequence number by 2 instead of 1 when it receives
duplicate DBD packets. This will cause the neighboring device to detect a bad sequence number
and reset the neighbor relationship to extart state.
Conditions:
N7K is Master in the Neighbor relationship. N7K sends a DBD with relative sequence number of 1:
Neighbor <--------seq 1------- N7K
Neighbor echos DBD with sequence number of 1 as per RFC but it sends one or more duplicates:
Neighbor ----------seq 1-------> N7K
Neighbor ----------seq 1-------> N7K
N7K should discard the duplicate packets but in some instances it may incorrectly increment the
relative sequence number buy 2 instead of 1:
Neighbor <-------seq 3--------- N7K
This will cause the neighbor to detect a bad sequence number and send a DBD with the I bit set
which will move the state machine from exchange to exstart:
Neighbor ----------seq 2(I bit set)----- N7K
Workaround:
Eliminate the duplicate DBD packets.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 2.9/2.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:M/Au:N/C:N/I:N/A:P/E:ND/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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.1(5) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S26, 5.2(9.50)S0, 6.0(2)A1(1), 6.0(2)N2(1), 6.0(2)U1(1), 6.1(3), 6.1(3)S30, 6.1(3.44)S0, 6.2(1.93) |
|
|
| |
| |
Bug Id: | CSCts72967 |
Title: | Port-Security on M1 card mis-programs F1 card |
|
Description: | Symptoms:
On a Nexus 7000 series switch running 5.1(4) if port-security is configured on an
M1 series module then this will cause a hardware misprogramming on any F1 series
modules on the same port number. Example would be configuring port-security on
Eth12/1 would affect Eth1/1.
Conditions:
When this misprogramming occurs the port will cease to pass any traffic in the
input direction causing a total loss of connectivity to any device connected to
that port.
Workaround:
To recover this perform a shut/no shut on any port on the M1 module which
corresponds to the port number on the F1 module. For example if Eth1/1 is having
the problem, shut/no shut on any port 1 on an M1 module would fix the issue.
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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.1(4) |
|
Known Fixed Releases: | 5.1(10.53)S0, 5.1(10.55)S0, 6.1(1) |
|
|
| |
| |
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: | 26-MAY-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: | 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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtl77076 |
Title: | Applying large egress acl triggers control-plane instability |
|
Description: | Symptom:
Ospf and Lacp flaps when Applying Large Acl's on Egress direction.
Conditions:
Apply Large Acl's in the egress direction.
Workaround:
None
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 5.0(5), 5.0(5)E1, 5.1(3), 5.1(3.17) |
|
Known Fixed Releases: | 5.0(5)E1, 5.1(10.1)S0, 5.1(3)S11, 7.1(0)ZD(0.16), 7.1(0)ZD(0.23), 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCtz01813 |
Title: | N7K-F248XP-25 fex port may hang when in vntag mode |
|
Description: | Symptom:
Any port that connects any Fabric Extender (FEX) device terminated on a N7K-F248XP-25 module of
a Nexus 7000 chassis may go err-disable and possibly take the FEX offline.
Conditions:
Only seen on N7K-F248XP-25 ports in fex mode
Workaround:
Reload the module to recover from the condition.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | 6.0(3)S2, 6.0(3)S5, 6.1(0.252)S0 |
|
|
| |
| |
Bug Id: | CSCtj73415 |
Title: | RIP crash at rip_ipv4_pkt_debug_message during UDP port reconnaisance |
|
Description: |
Symptom:
Cisco NXOS based devices contain a denial of service vulnerability within the Routing Information Protocol (RIP) service engine. An unauthenticated,
remote attacker with the ability to submit a malformed RIPv4 or RIPv6 message to port UDP/520 could cause the RIP service engine to restart. This
may result in a temporary inability for the device to pass traffic to a destination populated in the route table by RIP.
Conditions:
Cisco devices running an affected version of NXOS software and configured to utilize RIP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 5/3.9:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?
dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4091 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-4091
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: | 5.0(0)MP1(0.420), 5.1(1.49)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
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: | 26-MAY-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: | CSCtj90512 |
Title: | ospfv2/v3 memory leak when receiving specific malformed packets |
|
Description: | Symptoms:
OSPFv2/v3 process leaks memory when receiving specially-crafted packet
Conditions:
This issue may occur when the switch processes a malformed packet.
Workaround:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2011-2539 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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.2(6), 5.1(3), 5.2(0.1) |
|
Known Fixed Releases: | 4.2(8)S25, 4.2(8.93)S0, 5.0(0)MP1(0.440), 5.1(4)S5 |
|
|
| |
| |
Bug Id: | CSCum68908 |
Title: | snmpbulkwalk fails with tooBig error |
|
Description: | Symptom:
When snmpbulkwalk using v3 is performed
Conditions:
snmpbulkwalk using v3 having number of repeaters as high as 32/64
Workaround:
If this is seen, reduce the number of repeaters untill the walk succeeds
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.2(6a)S3, 7.1(0)D1(0.148), 7.9(0)ZD(0.3) |
|
Known Fixed Releases: | 6.1(2)I3(1.19), 6.1(2)I3(2), 6.2(10), 6.2(10)S13, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.215), 7.1(0)FC(0.2), 7.1(0)NF(0.32), 7.1(0)OTT(0.18) |
|
|
| |
| |
Bug Id: | CSCtj42748 |
Title: | SNMP crashes when receiving malformed snmp set serial number packet |
|
Description: |
Symptom:
The SNMP service may crash.
Conditions:
This issue happens when the switch processes
a malformed SNMP request
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 5/4.1
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:H/RL:U/RC:C
No CVE ID has been assigned to this issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: | 4.2(7.96)S0, 5.1(1.49)S0, 5.2(0.121)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCut49295 |
Title: | 7.2.0.D1.0.444.S3::UIN-1::Seeing BFD/EIGRP flap after doing 2nd SSO |
|
Description: | Symptom:
EIGRP session flap after SSO
Conditions:
Seen after multiple consecutive SSOs
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.444) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtx54818 |
Title: | Specific SNMP GET request causes 'ipqosmgr' to crash on Nexus 7K |
|
Description: | Symptoms:
Cisco Nexus 7000 devices contain a denial of service vulnerability within the SNMP subsystem. This vulnerability could allow an authenticated,
remote attacker to crash the device by submitting a malformed SNMP request to a specific MIB.
Conditions:
Cisco Nexus 7000 devices running an affected version of Cisco NX-OS 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
6.8/6.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:N/I:N/A:C/E:F/RL:U/RC:C
CVE ID CVE-2012-4126 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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(1), 6.0(1) |
|
Known Fixed Releases: | 5.2(4.9)S0 |
|
|
| |
| |
Bug Id: | CSCtn13055 |
Title: | BGP does not filter updates with incorrect AS-PATH values |
|
Description: |
Symptom:
Cisco NXOS based devices configured for BGP routing do not properly filter invalid AS Path values. This could allow an upstream BGP neighbor to pass
an invalid update to an NXOS based device that would then be propagated down stream of the affected device. This will likely result in a rest of and
resync with the BGP peer that received the invalid update.
Conditions:
Cisco devices running an affected version of NXOS software and configured for BGP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?
dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4098 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-4098
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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(0.180)S14 |
|
Known Fixed Releases: | 5.2(0.218)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuh09675 |
Title: | 6.1.4 or 6.2.1 || BGP Service Crash cause Multiple processes to crash |
|
Description: | Symptom:
BGP service crashes with 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.2(1).
++ Customer tries to execute the command which tears down the BGP session.
Workaround:
None
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-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: | CSCsy31458 |
Title: | can use 'perl' from CLI to bypass security mechanisms |
|
Description: |
Symptoms:
The Perl interpreter can be used as an escape to the underlying operating system bash shell.
Conditions:
Cisco NX-OS prior to 4.1(4)
Workaround:
None.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.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-2011-0361 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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.0(4)SV1(2), 4.1(3) |
|
Known Fixed Releases: | 4.1(4) |
|
|
| |
| |
Bug Id: | CSCti69214 |
Title: | Security Issue in OpenSSL |
|
Description: | Symptom:
The device may be affected by an OpenSSL vulnerability described in CVE-2010-2939.
Conditions:
Device configured with any feature that uses SSL.
Workaround:
Not available
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:N/AC:M/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2010-2939 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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | 5.0(2)N2(1), 5.1(1.10)S0 |
|
|
| |
| |
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: | 26-MAY-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: | CSCtx54797 |
Title: | Specific SNMP GET request causes 'vlan_mgr' to crash on Nexus switches |
|
Description: | Symptoms:
Cisco Nexus 1000v, Nexus 3000, Nexus 5000, and Nexus 7000 devices contain a denial of service vulnerability within the SNMP subsystem. An
authenticated, remote attacker could submit a request to an affected device designed to trigger a null pointer dereference error that results in a crash
and reload of the affected device.
Conditions:
Cisco Nexus 1000v, Nexus 3000, Nexus 5000, and Nexus 7000 devices running an affected version of Cisco NX-OS Software.
Workaround:
None.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are
6.8/6.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:N/I:N/A:C/E:F/RL:U/RC:C
CVE ID CVE-2012-4125 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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(1), 6.0(1) |
|
Known Fixed Releases: | 5.2(4.47)S0 |
|
|
| |
| |
Bug Id: | CSCtn13065 |
Title: | BGP does not filter BGP update with incorrect AS-PATH Segment Length |
|
Description: |
Symptom:
Cisco NXOS based devices configured for BGP routing do not properly filter invalid AS Path Segment Lengths. This could allow an upstream BGP
neighbor to pass an invalid update to an NXOS based device that would then be propagated down stream of the affected device. This will likely result in
a rest of and resync with the BGP peer that received the invalid update.
Conditions:
Cisco devices running an affected version of NXOS software and configured for BGP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?
dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4099 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-4099
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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(0.180)S14 |
|
Known Fixed Releases: | 5.2(0.218)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCuo73774 |
Title: | F3: ACL logic may break for all ACLs while programming an IPv6 ACL |
|
Description: | Symptom:
During testing, it was found that the atomicity of TCAM operations was not guaranteed, during programming ACL
entries for IPv6 on F3-type linecards. Consequently during a very small window of time where the results are
not fully in line with the configuration, and could lead to unexpected results.
Conditions:
While configuring IPv6 access lists, on an F3-type linecard
Workaround:
None
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via
normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.2(10)FM(0.27), 6.2(6), 6.2(6a), 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.30), 6.2(6b), 6.2(6b)S1, 6.2(8)E1, 6.2(8)E5, 6.2(8a), 6.2(8a)S1 |
|
|
| |
| |
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: | 26-MAY-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: | CSCub81080 |
Title: | MTM cores found during l2fm |
|
Description: | Symptoms:
Line card may crash when processing a number of packets with broadcast source MAC address.
Conditions:
receiving multiple packets with source MAC address set to broadcast on a F2 Line Card.
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
3.3/2.7:
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: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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(7), 6.1(1.62)S0, 6.1(2) |
|
Known Fixed Releases: | 5.2(7.23)S0, 5.2(9), 6.1(2.27), 6.1(2.6)S0, 6.2(0.285), 6.2(2) |
|
|
| |
| |
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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.1(4) |
|
Known Fixed Releases: | 4.2(1.17), 4.2(2) |
|
|
| |
| |
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: | 26-MAY-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)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCti03724 |
Title: | GDB in NX-OS images |
|
Description: | Symptoms:
Cisco NX-OS Software images contain the GDB debugger.
Conditions:
Cisco NX-OS Release 4.2(3) and prior
Workaround:
None
Further Problem Description:
GDB will be removed from NX-OS images that integrate the resolution to this bug.
GDB is the GNU Program Debugger, the show version command will indicate that GDB is included in
the image.
switch# show version
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2008, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
Software
BIOS: version 3.17.0
loader: version N/A
kickstart: version 4.0(1a) [gdb]
system: version 4.0(1a) [gdb]
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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.0(4)SV1(2), 4.2(3) |
|
Known Fixed Releases: | 4.2(7.124)S0, 4.2(7.56)S0, 5.1(10.1)S0, 5.2(0.262)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCsw63039 |
Title: | User with vdc-admin role can escalate privileges |
|
Description: | Symptom:
An already logged on user can escalate privileges
Conditions:
Cisco NX OS 4.1(2) and prior
Workaround:
None
Further Problem Description:
Fixed in NX OS starting with 4.1(3) and 4.2(1)
Additional Information:
This vulnerability was reported to Cisco by George Hedfors.
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.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 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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.1(1.64) |
|
Known Fixed Releases: | 4.1(3), 4.2(0.120), 4.2(1) |
|
|
| |
| |
Bug Id: | CSCuc48695 |
Title: | Mac address not learnt on a port security port |
|
Description: | Symptom:
MAC addresses are not learned from a port security enable port.
If a MAC address is learned as dynamically from a non port security port first, then N7K does
not learn the MAC address properly if it receives a frame from a port security port. This
applies to the condition where the N7K put the MAC address as static or drop.
Conditions:
This bug only applies to M1 and M2 modules only. This bug applies to NX OS up to 6.2(6).
<B>
Workaround:
</B>
You can configure the unsecure port as Port-sec/secure port to avoid this issue.
<B>
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:
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:W/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: | 26-MAY-2015 |
|
Known Affected Releases: | 6.1(2)S8, 6.1(3)S30, 6.2(0.269)S8, 6.2(1.52)S1 |
|
Known Fixed Releases: | 6.2(1)AG(0.3), 6.2(1.53)S0, 7.1(0)AV(0.38), 7.1(0)D1(0.14), 7.1(0)D1(0.15), 7.1(0)D1(0.343), 7.1(0)OTT(0.47), 7.1(0)PDB(0.264) |
|
|
| |
| |
Bug Id: | CSCtn13043 |
Title: | BGP does not filter updates with invalid AS Path Segment type |
|
Description: |
Symptom:
Cisco NXOS based devices configured for BGP routing do not properly filter invalid AS Path Segment Types. This could allow an upstream BGP
neighbor to pass an invalid update to an NXOS based device that would then be propagated down stream of the affected device. This will likely result in
a rest of and resync with the BGP peer that received the invalid update.
Conditions:
Cisco devices running an affected version of NXOS software and configured for BGP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?
dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4097 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-4097
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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(0.180)S14 |
|
Known Fixed Releases: | 5.2(0.218)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCtr63091 |
Title: | OSPF Process hogging CPU after receiving certain crafted packets |
|
Description: | Symptoms:
Certain crafted OSPF packets may cause high CPU and OSPF processing to be degraded.
Conditions:
Cisco Nexus 7K configured for OSPF routing.
The attacker must be layer 2 adjacent to the device.
Workaround:
Not available.
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: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(1)S67 |
|
Known Fixed Releases: | 5.2(3.28)S0, 6.0(0.21)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
Bug Id: | CSCum42151 |
Title: | Enable secret hashes improperly calculated |
|
Description: | Symptoms:
The salt of 'enable secrets' is not randomized properly.
Conditions:
'feature privilege' is configured.
Workaround:
None
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: | 26-MAY-2015 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | 6.0(2)A4(0.764), 6.0(2)A4(1), 6.0(2)U4(0.764), 6.0(2)U4(1), 6.2(10), 6.2(8)KR(0.8), 6.2(8.13)S0, 6.2(9)FM(0.67) |
|
|
| |
| |
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: | 26-MAY-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)OTT(0.5) |
|
|
| |
| |
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: | 26-MAY-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: | CSCup96876 |
Title: | N7K FIB Entry Miss-programmed into wrong SPL Bank |
|
Description: | Symptom:
Traffic to a subset of hosts is punted to the CPU and either forwarded in software or dropped.
Conditions:
ISSU from 6.2(8) to 6.2(8a)
ISSU from older releases to 6.2(8) or 6.2(8a)
Problem specific to M1-XL or M2 (Does not apply to F2/F3)
Workaround:
Reload the affected linecard
Further Problem Description:
This occurs when the FIB entry is programmed in the wrong SPL bank. As a result, the longest prefix match is not hit and traffic is punted for an ARP glean.
For example, a host exists in a /24 subnet. Checking 'show ip route' to the host will show a /32 installed in the RIB. However, checking the longest prefix match in hardware will show the /24 route.
N7K-1# show system internal forwarding ipv4 route 172.22.31.173 module 7
Routes for table default/base
----+---------------------+----------+----------+------+-----------
Dev | Prefix | PfxIndex | AdjIndex | LIFB | LIF
----+---------------------+----------+----------+------+-----------
1 172.22.31.0/24 0x423e 0xa2cb 0 0x1ff8b <------hardware only finds the /24 entry
Note, the /32 entry is present in hardware but since it is programmed in the wrong bank it will always hit the /24 entry.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S55, 6.2(10)S56, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.258), 7.1(0)OTT(0.34), 7.1(0)PDB(0.196) |
|
|
| |
| |
Bug Id: | CSCtg79818 |
Title: | aclmgr does not allow hw prgrmming of acls on l3 port-channel sub-ifs |
|
Description: | <B>Symptom:</B>
Under a very strict set of circumstances, acls may not be programmed in hardware on
layer 3 sub-interfaces.
<B>Conditions:</B>
A very strict set of circumstances must be present before this issue is seen:
1. Must have a parent layer 3 interface or port-channel without any acls applied
2. Must have a number of layer 3 sub-interfaces where there is at least one sub-interface with
an acl configured.
3. A switchover must have occurred prior to any configuration change.
4. Now if you try to configure an acl on a previos sub-interface that did not have any
acls configured or any new sub-interfaces created where an acl is configured will fail
to program in hardware. This can be seen with the command:
show access-list <name or number> summary
<B>Workaround:</B>
The workaround is to shut/no shut the main interface or port-channel. An alternate workaround
for port-channel is to remove/re-add a member port from the channel, then remove/reapply the
acls on all the affected sub-interfaces.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | 4.2(6)S12, 4.2(6.52)S0, 5.0(3)S46, 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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud44300 |
Title: | EntitySensor MIB handler should validate if_idx before query port client |
|
Description: | Symptom:
On a Nexus 7000 switch, if an interface index is queried that is higher than the number of
ports on the specific linecard, there is a chance that mts memory may be held indefinitely by
snmpd and eventually will exhaust mts resources. In a dual supervisor environment , snmpd will
core and a HAP reset will be observed. In a single sup, a core should be saved and the system
will crash/reboot.
Conditions:
This problem would typically happen if a higher-density linecard is replaced in the same slot
with a lower-densitiy card, and the management station continues to try and poll the
non-existant higher ports.
Workaround:
Workaround is to rediscover the devices to eliminate the out of bounds polling of the
non-existant interfaces or if the device is statically-configured with the mib, disable polling
for that non-existant object.
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.8/5.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2012-6396 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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(7), 6.1(2) |
|
Known Fixed Releases: | 5.2(9), 5.2(9)S26, 5.2(9.50)S0, 6.0(2)A1(1c), 6.0(2)U1(3), 6.0(2)U2(1), 6.1(3), 6.1(3)S19, 6.1(3.29)S0, 6.2(1.93) |
|
|
| |
| |
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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: | 4.2(3) |
|
|
| |
| |
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: | 26-MAY-2015 |
|
Known Affected Releases: | 6.1(4a)E2, 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtu10595 |
Title: | CDP with long address crashes process |
|
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
7.8/6.4:
https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2013-1181 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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | 5.2(3.30)S0, 5.2(3.39)S0, 6.1(0.137)S0, 6.1(0.173)S0 |
|
|
| |
| |
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: | 26-MAY-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: | CSCtf08873 |
Title: | CDP with long hostname crashes the CDP process on N7k |
|
Description: | Symptom:
A port is connected to other switch with CDP enabled. Once CDP is exchanged, the CDP process crashes.
Conditions:
It happens when the remote switches or routers with CDP enabled has the extraordinary LONG hostname (> 255B)
Workaround:
Disable CDP under the interface of the remote device where the N7k port is connected.
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/2.7:
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:OF/RC:C
CVE ID CVE-2011-0361 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: | 26-MAY-2015 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: | 4.2(5), 5.0(2) |
|
|
| |
| |
Bug Id: | CSCtu10556 |
Title: | CDP with long sysobj crashes process |
|
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
7.8/6.4:
https://intellishield.cisco.com/security/alertmanager/cvss?target=new&version=2.0&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2013-1181 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: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | 5.2(3.39)S0, 6.1(0.145)S0, 6.1(0.153)S0 |
|
|
| |
| |
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: | 26-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(14)FB(0.58), 7.2(0)D1(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: | CSCtz71765 |
Title: | NF configuration is retained when the config is not supported in HW |
|
Description: | Symptom:
Nexus 7000 switches have several restrictions in terms of hardware support for ACL based features being configured on the same L3 interface. For example Netflow and DHCP relay are not supported on the same interface at the same time.
The N7K may accept netflow configuration on the CLI and save it to the start-up configuration even though this configuration is not supported on the interface in question due to a conflict with some other ACL based feature. Upon reloading the N7K the start-up process discovers this problem and will suspend the VLAN interfaces in question. You may see errors like this:
2013 Sep 25 22:04:13 2JUA_SDS-7K-DATA ETHPORT-3-IF_ERROR_VLANS_SUSPENDED VLANs
2-999 on Interface port-channel610 are being suspended. (Reason: Tcam Allocatio
n Failure)
Conditions:
N7K with Netflow and other ACL based feature configured on the same interface. For example DHCP relay and ingress Netflow. Save config and reload the box. the bug has two parts:
1. It should reject the command
2. It should give you an error every time you configure it
r12.7k-VDC2(config-if)# no ip flow monitor standard-monitor input sampler nf-sampler r12.7k-VDC2(config-if)# ip access-group test1 in r12.7k-VDC2(config-if)# ip flow monitor standard-monitor input sampler nf-sampler Verify failed - Client 0x83000146, Reason: Tcam Allocation Failure, : RACL, Netflow Sampler (SVI), Interface: Vlan145 r12.7k-VDC2(config-if)# 2013 Sep 26 16:51:48 r12.7k-VDC2 %$ VDC-2 %$ %NFM-2-VERIFY_FAIL: Verify failed - Client 0x83000146, Reason: Tcam Allocation Failure, : RACL, Netflow Sampler (SVI), Interface: Vlan145
r12.7k-VDC2(config-if)# show run int vlan 145
!Command: show running-config interface Vlan145
!Time: Thu Sep 26 16:51:59 2013
version 6.1(4)
interface Vlan145
ip access-group test1 in
ip flow monitor standard-monitor input sampler nf-sampler
ip address 10.13.169.2/24
no shutdown
r12.7k-VDC2(config-if)# ip flow monitor standard-monitor input sampler nf-sampler r12.7k-VDC2(config-if)#
Workaround:
Remove the conflicting configuration before you save your config and reload the box.
Or you can try to upgrade to 6.2.2 and issue this command:
hardware access-list resource feature bank-mapping
The above command adds more flexibility in how various ACL based features are mapped to the 4 different TCAM banks. It doesn't make every feature combination work but it greatly reduces the amount of combinations that are not supported.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 5.2(7), 5.2(9)S50, 6.1(0.277), 6.1(2), 6.1(4.9), 6.2(10)S12, 6.2(10)S38, 6.2(2)S42, 6.2(2)S6, 6.2(5.38) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq18021 |
Title: | SNMPset to community strings with special characters cause hap reset |
|
Description: | Symptom:
NX-OS SNMPd process crashes with HAP reset.
Conditions:
Community string has leading ''%'' and ends with a number.
(however some other combination of special characters may cause this problem, we haven't seen them yet but can't exclude)
Workaround:
don't use leading % as a character. Better to avoid using special characters in RW communities or at least not as a leading characters
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via
normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 7.1(0)ZD(0.278) |
|
Known Fixed Releases: | 5.2(1)N1(8.156), 5.2(1)N1(9), 6.0(2)N2(5.107), 6.0(2)N2(6), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(1)ZN(0.772), 7.0(6)N1(0.264), 7.0(6)N1(1), 7.1(0)D1(0.241) |
|
|
| |
| |
Bug Id: | CSCuf95718 |
Title: | High CPU for pktmgr seen consistently on VPLS EFP/BD Scale testbed |
|
Description: | Symptom:
High CPU utilization observed on active supervisor.
Conditions:
When VPLS or EFP Ethernet virtual circuits are configured, pktmgr process on active supervisor will register high cpu utilization as it will be busy dropping STP BPDUs entering the virtual circuit from customer edge-side.
Workaround:
Prevent STP BPDUs originating from customer-edge device from entering the provider-edge device where Ethernet virtual circuits/VPLS is configured.
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.2(1.56)S5, 6.2(1.69)S5 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu29219 |
Title: | SSTE: global parameter exchange not happening for some BD/VNI |
|
Description: | Symptom:
-More--2015 May 10 10:52:31 Leaf-Leaf179 %$ VDC-2 %$ %VNSEGMENT_MGR-2-VNSEG_PENDING_RESPONSE_TIMEOUT: Waiting for Pending response for req MTS_OPC_VLAN_MGR_BD_PORT_ADD (msg id:3754673)
Conditions:
POAP
Workaround:
NA
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.499) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur14589 |
Title: | vulnerability related to cmd injection via DHCP offer options |
|
Description: |
Symptom:
Command injection via DHCP offer options used with PowerOn Auto Provisioning (POAP)
Conditions:
NX-OS Switch would have to be in a state where POAP is initiated, and if
an attacker can either:
A) Inject their own DHCP server and respond to the POAP DHCP request with
crafted DHCP options.
B) Compromise an existing DHCP server, and craft the specific DHCP
options.
Then during the POAP process, when the crafted DHCP options are processed
arbitrary commands on the system could be executed in the context of root
user.
Note this issue only occurs during the POAP DHCP boot process.
First Fixed Releases:
6.2(10)
7.1(0)N1(1)
7.1(2)N1(1)
7.2(0)N1(1)
Workaround:
None.
More Info:
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.8/5.3:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dis
patch=1&version=2&vector=AV:A/AC:H/Au:N/C:C/I:C/A:C/E:POC/RL:OF/RC:C
CVE ID CVE-2015-0658 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: | 26-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.226) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S98, 6.2(10.17)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.291), 7.1(0)D1(0.292), 7.1(0)D1(0.293), 7.1(0)EV(0.116) |
|
|
| |
| |
Bug Id: | CSCuu26390 |
Title: | SSTE: multiple ethpm cores noticed on POAP + autoconfig |
|
Description: | Symptom:
ethpm cores
Conditions:
POAP + autconfig
Workaround:
NA
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.490) |
|
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: | 26-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCum52399 |
Title: | Fixing EIGRP to take Interface MTU as default Max-Packet Size |
|
Description: | Symptom:
Symptom:
In 6.2.2, the default EIGRP mtu is 16384 regardless of the interface MTU. If system receives large update packets then they will get fragmented. The CoPP on the nexus can drop these fragments as they get classified under default-class of CoPP. These fragments are not considered as EIGRP packets being fragmented packets.
Conditions:
EIGRP MTU is 16384.
Workaround:
Modify COPP.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 6.0(2)A4(0.814), 6.0(2)A4(1), 6.0(2)U4(0.814), 6.0(2)U4(1), 6.2(10), 6.2(10)EC(0.12), 6.2(10)FM(0.10), 6.2(10)NO(0.6), 6.2(8)KR(0.8), 6.2(8)TS(0.28) |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup02927 |
Title: | ELTM crash upon LC reload |
|
Description: | Symptom:
Nexus 7000 may have crash in "eltm" process
Conditions:
Pre-condition (must-have):- There should be more than total of 8 port-channels in whole system containing regular or pvlan mapping.
Condition#1 Linecard reload
Condition#2 Configuration should have vlan translations, on port-channels, for e.g.:-
>switchport private-vlan mapping trunk 93 94
Condition#3 There is an internal memory allocation done when LC is brought up and depending on that allocation we may or may NOT hit this issue even if condition#1 and 2 matches.
Condition#4 issue may be seen in scale setup.
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.21), 6.2(6b), 6.2(6b)S1, 6.2(8)E5, 6.2(8)TS(0.28), 6.2(8.12)S4, 6.2(8a), 6.2(8a)S2, 6.2(9.1)S0 |
|
|
| |
| |
Bug Id: | CSCut58899 |
Title: | ISIS cored when add 200 vrfs |
|
Description: | Symptom:
isis crashes on a scale setup.
Conditions:
On a scale setup with 1000 sub-interfaces spreading across 201 vrfs
Workaround:
no workaround, isis restarts itself after crash.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.444) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj82684 |
Title: | "fips mode" enable before the All LC s are online leads to LC failure |
|
Description: | Symptom:
"fips mode" enable before the All LC s are online leads to LC failure
Conditions:
"fips mode" enable before the All LC s are online leads to LC failure
Workaround:
enable fips mode only after all the LC s are up .
Further Problem Description:
for more details refer to test plan ,
NEXUS_FIPS_140-2_Detailed_Test_Plan
http://wwwin-eng.cisco.com/Workgroup/Eng/DC_OS/QA/NEXUS_FIPS_140-2_Detailed_Test_Plan.doc
Status: AP EDCS Rev: 5 Date: 27-AUG-2010 Size: 2 M
Doc No: EDCS-664107 Format: WORD PDF
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut85350 |
Title: | SSTE: m2rib CPU hog after auto config |
|
Description: | Symptom:
m2rib CPU hog
Conditions:
auto config
Workaround:
NA
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 27-MAY-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | 6.2(10)E7, 6.2(10)E8, 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) |
|
|
| |
| |
Bug Id: | CSCut29918 |
Title: | UIN-1::Seeing IPV6 eigrp auth failure during system switchover |
|
Description: | Symptom:
IPV6 eigrp auth failure during system switchover
Conditions:
Authentication is enabled for IPv4 EIGRP on the same interface
Workaround:
Unconfigure/Reconfigure ipv6 eigrp on the interface
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.437) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 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.444), 7.2(0)D1(0.456), 7.2(0)D1(0.457), 7.2(0)N1(0.152), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuq93334 |
Title: | [Performance impact] M2 reload stuck in power cycle for 17-18 minutes |
|
Description: | Symptom:
Module power cycle takes 17-18 mins to complete.
Conditions:
we observed this issue with the reload module scenario with more than about 100+ BFD session in the system.
as module goes off, PPF session can't reach the destination which cause ppf server do a retry internally and it takes approximately 10 sec for each session. we got over 100 session (1000 sec =16 mins) that's the reason why power-cycle took 17~18 mins
Workaround:
before reloading the module, I recommend doing a no feature bfd, and then do a module reload, finally add bfd feature back to the system.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 6.2(10)E1, 7.2(0)ZD(0.106) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.2(0)D1(0.476), 7.2(0)PDB(0.408), 7.2(0)VZD(0.26), 7.2(0)ZD(0.156) |
|
|
| |
| |
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: | 27-MAY-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: | 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: | 27-MAY-2015 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 27-MAY-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(14)FB(0.52), 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.2(0)D1(0.504), 7.2(0)VZD(0.26), 7.2(0)ZD(0.184) |
|
|
| |
| |
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: | 27-MAY-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: | 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: | 27-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 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)VZD(0.26), 7.2(0)ZD(0.175) |
|
|
| |
| |
Bug Id: | CSCts64383 |
Title: | N7K: FEX goes offline when more than 4 fabric ports went down |
|
Description: | Symptom:
Nexus2000 series (FEX) goes when more than 4 fabric ports went down at once even if there are some fabric ports available.
Conditions:
This issue happens when both of the following was meet.
+ more than 4 fabric ports went down by something like module reload
+ those disabled/flapped fabric ports include a fabric port for control traffic
example)
think about FEX with 4 fabric ports for module 1, 4 fabric ports for module2.
a fabric ports for control traffic is located on module 1.
the issue happens when module 1 reloaded.
Workaround:
reduce the number of fabric ports.
If the FEX has 3 fports for one module and other 3 ports for another module, then the issue won't happen with module reload.
Further Problem Description:
You can check which fabric port is for control traffic.
n7004# sh fex 101 | grep control
Fabric port for control traffic: Eth3/1
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 5.2(1), 5.2(3.35)S0, 6.0(0.36)S13 |
|
Known Fixed Releases: | 5.2(3.52)S0, 6.0(0.60)S0 |
|
|
| |
| |
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: | 27-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 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)VZD(0.26), 7.2(0)ZD(0.176) |
|
|
| |
| |
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: | 27-MAY-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)PDB(0.390), 7.2(0)VZD(0.26) |
|
|
| |
| |
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: | 27-MAY-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(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), 7.2(0)N1(0.157) |
|
|
| |
| |
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: | 27-MAY-2015 |
|
Known Affected Releases: | 5.2(1)S84 |
|
Known Fixed Releases: | 6.0(0.14)S0 |
|
|
| |
| |
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: | 27-MAY-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.1(0)AV(0.81), 7.2(0)D1(0.503), 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), 7.2(0)ZN(0.199) |
|
|
| |
| |
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: | 27-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 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)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: | 27-MAY-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)N1(0.134), 7.2(0)N1(0.183), 7.2(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuu12299 |
Title: | eg lif 0x0, when reload AC module after change AC port from VPWS to VPLS |
|
Description: | Symptom:
With the trigger stated in the bug headline, packet forwarding does not happen in for that VFI.
Conditions:
When a port that was a part of a VPWS connection is removed from it and then configured to be in a VLAN that is extended via VPLS, then the egress LIF for that port becomes 0x0 and disrupts packet forwarding.
Workaround:
None
Further Problem Description:
None
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.490) |
|
Known Fixed Releases: | |
|
|
| |
| |
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-MAY-2015 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.1(1)N1(0.8) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtx90551 |
Title: | 6.2.0.78:S0::ISSU::Return code 0x4093001e(Standby failed to come online) |
|
Description: | Symptom:
6.2.0.78:S0::core at syslogd
Conditions:
Seen this issue while doing ISSU
Workaround:
Do not configure "debug logfile " on active before doing ISSU.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 6.2(0.147)S0, 6.2(0.78)S0 |
|
Known Fixed Releases: | 6.2(0.217)S3, 6.2(0.218)S0, 6.2(2), 7.0(1)ZD(0.3) |
|
|
| |
| |
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: | 27-MAY-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)ZD(0.199), 7.2(0)ZN(0.218) |
|
|
| |
| |
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: | 27-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E2, 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)VZD(0.26), 7.2(0)ZD(0.175) |
|
|
| |
| |
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: | 27-MAY-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)VZD(0.26) |
|
|
| |
| |
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: | 27-MAY-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.1(0)AV(0.74), 7.2(0)D1(0.479), 7.2(0)N1(0.173), 7.2(0)N1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
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: | 27-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.444) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.2(0)D1(0.468), 7.2(0)PDB(0.401), 7.2(0)VZD(0.26), 7.2(0)VZN(0.34), 7.2(0)ZD(0.147), 7.2(0)ZN(0.164), 7.2(1)N1(0.1), 7.2(1)N1(1) |
|
|
| |
| |
Bug Id: | CSCuf61304 |
Title: | NX-OS : RPF on mroute incorrectly pointing to the RP for (S,G) |
|
Description: | Symptom:
On the Turn around router running NX-OS, RPF on mroute incorrectly pointing to the RP for (S,G)
Conditions:
RP on a stick set-up. mostly seen in cases that have slow sources. on the turn around router running NX-OS, the incoming interface on the (S,G) points towards the RP instead of towards the Source, packet flow stops in this state. Clearing the mroute fixes
the issue. But the Mroute randomly goes back to this state.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 5.0(3)N2(2a), 5.2(1)N1(3), 6.0(2)N1(2) |
|
Known Fixed Releases: | 5.0(3)U5(1f), 5.2(1)N1(5), 6.0(2)N1(2a), 6.0(2)N2(1), 6.0(2)U1(1), 6.2(1.83)S0, 6.2(2), 7.0(1)N1(1), 7.2(0)ZN(0.111) |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 27-MAY-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)ZD(0.190) |
|
|
| |
| |
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: | 27-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.499) |
|
Known Fixed Releases: | 7.1(0)AV(0.81), 7.2(0)D1(0.511), 7.2(0)N1(0.209), 7.2(0)N1(1), 7.2(0)ZD(0.191), 7.2(0)ZN(0.209) |
|
|
| |
| |
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: | 27-MAY-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.1(0)AV(0.81), 7.2(0)D1(0.504), 7.2(0)VZD(0.26), 7.2(0)VZN(0.34), 7.2(0)ZD(0.184), 7.2(0)ZN(0.200) |
|
|
| |
| |
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:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-MAY-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) |
|
|
| |
| |
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: | 27-MAY-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)VZD(0.26) |
|
|
| |
| |
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: | 27-MAY-2015 |
|
Known Affected Releases: | 6.0(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 27-MAY-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.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), 7.2(0)D1(0.408) |
|
|
| |
| |
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-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 28-MAY-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: | 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-MAY-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: | CSCuf20035 |
Title: | FEX : MTU changes not taking effect on fex queues |
|
Description: | Symptom:
When the user changes the interface MTU on a fabric port, the configured MTU on the FEX ports are not configured to the same value.
Conditions:
This will occur anytime the user changes the interface MTU on a fabric-port.
Workaround(s):
The configured MTU for the FEX ports is controlled by the network-qos policy. The user should modify the network-qos policy to change as well to change the MTU configured on the FEX ports when they change the fabric-port MTU.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 28-MAY-2015 |
|
Known Affected Releases: | 6.2(1.42) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 28-MAY-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: | CSCut63393 |
Title: | Vinci FE - 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: | 28-MAY-2015 |
|
Known Affected Releases: | 7.2(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 28-MAY-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: | CSCum10704 |
Title: | 465 byte leak with epld during show run can cause copy r s to abort |
|
Description: | Symptom:
It is not possible to save the configuration anymore and the memory shows up as full :
%SYSMGR-2-NON_VOLATILE_DB_FULL: System non-volatile storage usage is unexpectedly high at 100%.
N7K# copy run start
[########################################] 100%
Configuration update aborted: request was aborted
N7K#
Conditions:
Each time "copy run start" or "show run" is issued, the size of the epld_auto_log file in /mnt/pss/epld_log is growing.
This fills up /mnt/pss space. When the /mnt/pss gets full, "copy run start would fail. This can be seen with
N7K# show system internal dir /mnt/pss/epld_log
Workaround:
Prevent such commands from being run by scripts and call TAC to delete the file.
Further Problem Description:
Affected releases are from 6.2(1) to 6.2(6a).
It has been fixed in 6.2(8).
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-MAY-2015 |
|
Known Affected Releases: | 6.2(6)S10 |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 28-MAY-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)VZD(0.26), 7.2(0)ZD(0.174) |
|
|
| |
| |
Bug Id: | CSCud63152 |
Title: | F2/F2E/F3 improper programming gateway mac on some instances |
|
Description: | Symptom:
Traffic destined to CPU is flooded instead of being punted.
This causes symptoms such as ARP being incomplete, L3 routed traffic not getting routed correctly
Conditions:
We have determined this is a result of the Interface VLAN MAC address not programmed in the hardware
Workaround:
shut/no shut of the interface vlan
This will force the switch to reprogram the router mac address
Further Problem Description:
Additional information regarding this fix:
After ISSU to a fixed release (ie., 6.1(5) and above), reload of F2/F2E/F3 modules are required to get the fix applicable. If the F2/F2E/F3 modules are not reloaded, this problem may continue to happen.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-MAY-2015 |
|
Known Affected Releases: | 6.0(3) |
|
Known Fixed Releases: | 6.1(5), 6.1(5)S11, 6.1(5.10)S0, 6.2(0)HS(0.10), 6.2(8), 6.2(8)S1, 6.2(8.5) |
|
|
| |
| |
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: | 28-MAY-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(9), 5.2(9)S53, 5.2(9.98)S0, 6.0(2)N1(2a), 6.0(2)U1(1) |
|
|
| |
| |
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: | 28-MAY-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(0.2), 7.2(0.4) |
|
Known Fixed Releases: | 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)RTG(0.143), 7.2(0)VOF(0.2), 7.2(0)ZD(0.135) |
|
|
| |
| |
Bug Id: | CSCut17599 |
Title: | N7K-F248XT-25E: Periodic PortLoopback Failures for Unknown Reason |
|
Description: | Symptom:
PortLoopback test failure with failure reason 'Loopback test failed. Unable to analyze the reason for failure'
Conditions:
- Unused port
- N7K-F248XT-25E
Workaround:
1. If diagnostic test is error-disabled (DIAG TEST ERR DISABLE) due to this reason, you can reset the diagnostic by doing the following:
# diagnostic clear result module all
(config)# no diagnostic monitor module test 6
(config)# diagnostic monitor module test 6
# diagnostic start module test 6
2. If the Port loopback test is failing (DIAG TEST FAIL) even after resetting the condition, then see if you are hitting CSCuq34116. If yes, please the attachment - Workaround
3. If the fix of CSCuq34116 in step 2 is not helping recover, it is most likely a hw issue.
4. Reloading the module might recover the ports (Secure a maintenance window and reload the module)
Further Problem Description:
If this is not a CSCuq34116, then its very likely a hw issue. Recommend an RMA.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 28-MAY-2015 |
|
Known Affected Releases: | 6.1(5), 6.2(10) |
|
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: | 28-MAY-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) |
|
|
| |
| |
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: | 28-MAY-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: | 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-MAY-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(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)PDB(0.364), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
Bug Id: | CSCut23978 |
Title: | soft-voq detects congestion and taildrops inband tx traffic on sup2 |
|
Description: | Symptom:
On high scale setups (large RSTP scale for instance) we may notice some BPDUs missing in Tx direction from SUP in-band toward network.
Conditions:
Supervisor kernel is queuing packets for egress toward network and may tail-drop control-plane traffic.
Workaround:
None
Further Problem Description:
This issue may impact Tx traffic from in-band toward network for any protocol at high packet rates.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 28-MAY-2015 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: | |
|
|
| |
| |
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-MAY-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(14)FB(0.21), 7.1(0)AV(0.74), 7.2(0)D1(0.453), 7.2(0)PDB(0.378), 7.2(0)VOF(0.2), 7.2(0)VZD(0.26) |
|
|
| |
| |
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: | 28-MAY-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)ZD(0.177) |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-MAY-2015 |
|
Known Affected Releases: | 6.2(8.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj17755 |
Title: | SNMPd process crash |
|
Description: | Symptom:
the SNMPd process may restart unexpectedly
Conditions:
SNMP active on the switch. The specific conditions are not known at this time. Aggressive snmp polling of the switch and periodically high cpu is observed. The debug info collected is not sufficient to root cause the problem, but it shows several thousand mts messages which were not getting freed.
Workaround:
None at this time.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 29-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.444) |
|
Known Fixed Releases: | 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) |
|
|
| |
| |
Bug Id: | CSCui36490 |
Title: | BGP outbound messages can get stuck in certain conditions. |
|
Description: | Symptom:
BGP outbound messages can get stuck in certain conditions
Conditions:
If BGP has caught up with updating its peers with all route updates, the sender thread may inadvertently go to sleep because of this bug. In such a case, residual outbound messages to the peers will be stuck until another message (keepalive, update, etc.) gets queued to wake the sender thread
Workaround:
"clear ip bgp" or "restart bgp" may resolve the issue but it may end up in the same situation later.
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 2.6/2.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:N/I:N/A:P/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: | 29-MAY-2015 |
|
Known Affected Releases: | 6.2(0)PF(0.296), 6.2(2)S31, 6.2(8) |
|
Known Fixed Releases: | 6.0(2)N3(1), 6.2(10), 6.2(10)CM(0.34), 6.2(11)FM(0.7), 6.2(8)E1, 6.2(8)IAS(0.18), 6.2(9.4)S0, 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)ZD(0.122) |
|
|
| |
| |
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: | 29-MAY-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: | 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(6)N1(0.202), 7.0(6)N1(1), 7.1(0)D1(0.253), 7.1(0)N1(0.314), 7.1(0)N1(1), 7.1(0)OTT(0.32) |
|
|
| |
| |
Bug Id: | CSCus36521 |
Title: | ISIS Neighbor with network type p2p not coming up between NXOS and IOS |
|
Description: | Symptom:
ISIS Neighbor with network type p2p not coming up between NXOS and IOS
Conditions:
With network type p2p the adjacency is not coming up.
It shows INIT State on IOS Device and does not list the adjacency on NXOS end.
Workaround:
Remove p2p network type command from the interfaces on both ends.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu54461 |
Title: | Traffic loss seen after BGP Autodiscovery triggers |
|
Description: | Symptom:
In VPLS BGP auto-discovery, if L2VPN changes the route-target configs for a VFI, the config changes may not be reflected in outgoing routes until a route refresh is done in BGP.
Conditions:
Changing route-target configs like in the following condition.
l2vpn vfi context test7
vpn id 7
autodiscovery bgp signaling ldp
route-target import 1.2.3.4:7 <<<<<<
route-target export 1.2.3.4:7 <<<<<<
no auto-route-target <<<<<<
Workaround:
Route-target changes are typically done across the network, not just limited to one router. So, it is cautious to do a "clear bgp l2vpn vpls * soft" in routers that will see its effect percolate across the whole network, after all config changes are completed.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 29-MAY-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: | 29-MAY-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(0)D1(0.490) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCti40402 |
Title: | N7K-M132XP: Some frames truncated by 4 bytes when TXing shared-mode int |
|
Description: | Problem Description:
A small percentage of packets (0.0001%) transmitted (tx) on a N7K-M132XP-12 shared-mode interface may be truncated by 4 bytes.
Symptom:
Customers may see the following messages that could indicate malformed packets have been received:
1. %EEM_ACTION-6-INFORM: Packets dropped due to IDS check length consistent on module
Cisco NX-OS supports Intrusion Detection System (IDS) checks that validate IP packets to ensure proper formatting. The length consistent check will drops IP packets where the Ethernet frame size is greater than or equal to the IP packet length (contained in packet header) plus the length of a standard Ethernet header.
2. %STP-2-RECV_BAD_TLV: Received SSTP BPDU with bad TLV on
Cisco NX-OS PVST BPDUs contain a PVID field identifying the vlan instance of the BPDU (located in the last 4 bytes of the PVST BPDU). This message can be reported if there is a native vlan mismatch on a trunk interface, or the error could be reported because the PVID field is missing.
If either message is logged, you should check if the upstream interface is a N7K-M132XP-12 shared-mode interface. Ingress packet captures on the interface/module logging the above messages will allow you to verify the condition of the packet and confirm if you are affected by this bug.
Conditions:
Traffic egressing a N7K-M132XP-12 shared-mode interface may be affected. At high traffic rates >300MB a tiny percentage of frames 0.0001% have 4 bytes removed.
Workaround:
Configure N7K-M132XP-12 ports to 'rate-mode dedicated'.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: | 5.0(5)S6, 5.0(5.1)S0 |
|
|
| |
| |
Bug Id: | CSCus77706 |
Title: | Phy vpc: Can't bring up 2 orphan ports in I mode |
|
Description: | Symptom:
PXE boot servers won't work with phy. port vPC.
Conditions:
PXE boot servers won't work with phy. port vPC.
Workaround:
There is no workaround.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.390) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 29-MAY-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(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.1(0)AV(0.74), 7.1(0)ES(0.7) |
|
|
| |
| |
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: | 29-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(14)FB(0.22), 7.0(3)I1(1.226), 7.0(3)I1(2), 7.1(0)AV(0.74), 7.2(0)D1(0.459), 7.2(0)PDB(0.381), 7.2(0)VZD(0.26) |
|
|
| |
| |
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-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(14)FB(0.62) |
|
|
| |
| |
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: | 29-MAY-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) |
|
|
| |
| |
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: | 29-MAY-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: | CSCun34812 |
Title: | BGP OSH: URIB not triggering notification of next-hop registration |
|
Description: | Symptom:
Next hop for random routes could point to wrong destination interface in hardware forwarding engine
Conditions:
This can happen after BGP restart/crash.
Workaround:
Switchover to standby supervisor
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 6.1(4a), 7.2(0)MV(0.1) |
|
Known Fixed Releases: | 6.2(10), 6.2(10)S9, 6.2(10.5) |
|
|
| |
| |
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.
2) Add NTP/PTP configuration back on the switch after the Leap second event date(July 1, 2015).
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 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: | 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: | 29-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E6, 6.2(14)FB(0.57) |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 29-MAY-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)VZD(0.26), 7.2(0)ZD(0.184) |
|
|
| |
| |
Bug Id: | CSCur12364 |
Title: | N5K: ISSU fails 5.1(3)Nx(x)/5.2(1)N1(x) -> 6.0(2)Nx(x) -> 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)
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) (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: | 29-MAY-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.1(0)AV(0.81), 7.2(0)D1(0.505), 7.2(0)N1(0.199), 7.2(0)N1(1), 7.2(0)VZD(0.26), 7.2(0)VZN(0.34), 7.2(0)ZD(0.185), 7.2(0)ZN(0.200) |
|
|
| |
| |
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: | 29-MAY-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) |
|
|
| |
| |
Bug Id: | CSCut72659 |
Title: | can not attach rise nam from sup, need to update ssh client version |
|
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.
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,rijndael-cbc@lysator.liu.se server \
aes128-ctr,aes192-ctr,aes256-ctr
N7K-6#
Symptom:
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,rijndael-cbc@lysator.liu.se server \
aes128-ctr,aes192-ctr,aes256-ctr
N7K-6#
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-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: | 6.2(13)S15, 7.0(0)HSK(0.433), 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), 7.2(0)N1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
Bug Id: | CSCtz13307 |
Title: | kgdb on udld process while peer-link shut no shut continuously |
|
Description: | Symptom:
A Nexus 5500 switch running NX-OS 5.1(3)N1(1) might reload with kernel
panic.
`show system reset-reason`
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 543702 usecs after Wed Feb 1 03:27:24 2012
Reason: Kernel Panic
Service:
Version: 5.1(3)N1(1)
Conditions:
Observed on Nexus5K and Nexus7k as well.
Workaround(s):
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: | 5.1(3)N2(1a), 5.2(4.83)S0, 6.0(4)S1, 6.1(0.280)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 29-MAY-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: | 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: | 29-MAY-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) |
|
|
| |
| |
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: | 29-MAY-2015 |
|
Known Affected Releases: | 6.2(8a), 6.2(8b) |
|
Known Fixed Releases: | |
|
|
| |
| |
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 and run the load command.
- 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 from this situation. Moreover, the latest running configuration may be lost in the event of a power outage.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 6.1(5a), 6.2(12) |
|
Known Fixed Releases: | 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)N1(0.152), 7.2(0)N1(1), 7.2(0)PDB(0.395) |
|
|
| |
| |
Bug Id: | CSCug47483 |
Title: | 'bgp' process crashes due to missing heartbeats |
|
Description: | Symptom:
Both core file and syslog show that BGP was killed by sysmgr due to missing heartbeats. . A very rare situation was hit and messed up the linked-list, and it's difficult to find out why BGP got into it based on the current information. Instrumented image is needed to debug the root cause and/or verify some treatment.
Conditions:
core file
Workaround:
none
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 6.2(1.83)S4 |
|
Known Fixed Releases: | 6.1(4.97)S0, 6.1(5), 6.1(5.29)S0, 6.2(1.118)S0, 6.2(2) |
|
|
| |
| |
Bug Id: | CSCug90667 |
Title: | Traffic Blackhole after "wccp redirect exclude-in" configuration |
|
Description: | Symptom:
After updating configuration of "wccp redirect exclude-in" traffic from WCCP device passing through Nexus 7000 maybe black-holed.
Conditions:
This happens when using redirect exclude-in feature to enable WCCP bypass.
Workaround:
Reload the linecards handling the reconfigured interface or vlan.
Further Problem Description:
The failing HW programming remains in effect also after the relevant configuration command is removed.
Please also note that if Customer is running a fix version and upgrade was done via ISSU and line card was not related, we are still impacted, so verify the upgrade process and see if ISSU was done, and if yes, then use the same workaround.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 5.1(4), 5.2(9) |
|
Known Fixed Releases: | 5.2(3a)E2, 5.2(9.195)S0, 6.1(4.97)S0, 6.1(4a), 6.1(4a)S4, 6.1(5.32)S0, 6.2(6) |
|
|
| |
| |
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: | 29-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.456) |
|
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: | 29-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtx46109 |
Title: | Clipper KLM Interrupt Throttling trigger MTM FE timer expired. |
|
Description: | Kernel Loadable Module may permanently mask interrupts for F2 modules which are consider as spurious interrupt event.
Symptom:
Certain commands like "show mac address-table" will time out without displaying any output.
The message "service not responding" will be displayed.
The following errors may also be seen in the logs:
%MTM-SLOT-0-FE_TIMER_EXPIRED: FE timer expired for fe !
Conditions:
Seen on N7k with F2 modules
Workaround(s):
Reload the module which are effected. After that upgrade the code to 6.0.3 to overcome this issue.
Do not perform an ISSU to a fixed release without reloading the affected modules first.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-MAY-2015 |
|
Known Affected Releases: | 6.0(1), 6.0(1)E1, 6.0(2) |
|
Known Fixed Releases: | 6.0(3)S1, 6.1(0.193)S0, 6.1(0.205)S4, 6.1(0.208)S0 |
|
|
| |
| |
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: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 30-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.514) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu59433 |
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: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 30-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu59466 |
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: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 30-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut08818 |
Title: | SNMPD crash 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: | 30-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(8a) |
|
Known Fixed Releases: | 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.2(0)D1(0.492), 7.2(0)N1(0.187), 7.2(0)N1(1), 7.2(0)VZD(0.26), 7.2(0)VZN(0.34), 7.2(0)ZD(0.174), 7.2(0)ZN(0.189), 7.2(1)N1(0.1) |
|
|
| |
| |
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: | 30-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.506) |
|
Known Fixed Releases: | 7.2(0)D1(1), 7.2(0)ZD(0.202) |
|
|
| |
| |
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: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | 6.2(12)E4, 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)FM(0.3), 7.2(0)PDB(0.379), 7.2(0)RTG(0.96), 7.2(0)VOF(0.2) |
|
|
| |
| |
Bug Id: | CSCus16438 |
Title: | sh ip/ipv6 eigrp neigh cmd takes time to execute on router eigrp shutdow |
|
Description: | Symptom:
CLI do not take affect when EIGRP shutdown command is executed
Conditions:
Seen in scaled setup where there are >50000 routes
Workaround:
After a few minutes, EIGRP processing is complete and CLIs can be executed.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 31-MAY-2015 |
|
Known Affected Releases: | 7.2(0)ZD(0.6) |
|
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)FM(0.3), 7.2(0)PDB(0.353), 7.2(0)VZD(0.6), 7.2(0)ZD(0.94), 7.2(0)ZN(0.114) |
|
|
| |
| |
Bug Id: | CSCur33396 |
Title: | OTV cannot match extended vlan range |
|
Description: | Symptom:
OTV extended vlan range cannot go above 3967 in NX-OS 6.2 releases even when the reserved vlan range is re-allocated from 3968-4095
Conditions:
NX-OS 6.2 release software running on Nexus 7000.
Workaround:
Potentially vlan translation on Layer2 link can be used as a workaround but it may or may not work depending on RSTP or MST.
Further Problem Description:
OTV works fine with the extended vlan range in NX-OS releases 6.0 and 6.1.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: | 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)PDB(0.359), 7.2(0)RTG(0.65), 7.2(0)VZD(0.6), 7.2(0)ZD(0.103), 7.2(0)ZN(0.122) |
|
|
| |
| |
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: | 31-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.456), 7.2(0)D1(0.490) |
|
Known Fixed Releases: | 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)ZD(0.188) |
|
|
| |
| |
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: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(12)E2 |
|
Known Fixed Releases: | 6.2(12)E2, 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)FM(0.3), 7.2(0)PDB(0.368), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
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: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: | 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)FM(0.3), 7.2(0)PDB(0.352), 7.2(0)VZD(0.6) |
|
|
| |
| |
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.
Workaround:
1. Restart pim on the RP router
2. Remove and reconfigure "ip pim rp-address <>" in global configuration on the RP.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 31-MAY-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.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.422), 7.2(0)FM(0.3) |
|
|
| |
| |
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: | 31-MAY-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)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), 7.2(0)VZD(0.6) |
|
|
| |
| |
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: | 31-MAY-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)FM(0.3), 7.2(0)PDB(0.350), 7.2(0)VZD(0.6) |
|
|
| |
| |
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: | 31-MAY-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)FM(0.3), 7.2(0)N1(0.143) |
|
|
| |
| |
Bug Id: | CSCur54182 |
Title: | NX-OS Tacacs Daemon hap reset |
|
Description: | <B>
Symptom:</B>
Device configured for TACACS may face crash due to "Tacacs
Daemon hap reset"
Reason: Reset triggered due to HA policy of Reset
Service: Tacacs Daemon hap reset
<B>
Conditions:</B>
On a switch running NX-OS 6.2(8a) or later, if a very long command is
given with remote authorization using TACACS enabled, a crash is seen in TACACS. Because
TACACS expects the strings to be of size 255, it is unable to handle strings greater than 255.
<B>
Workaround:</B>
None.
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.4/3.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:M/Au:S/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2014-8013 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: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.0(2)A6(0.41), 6.0(2)A6(1), 6.0(2)U6(0.41), 6.0(2)U6(1), 6.1(2)I3(2.15), 6.1(2)I3(3), 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.12), 7.0(0)BZ(0.46) |
|
|
| |
| |
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: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S98, 6.2(10)S99, 7.1(0)ZD(0.95) |
|
Known Fixed Releases: | 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), 7.2(0)D1(0.397) |
|
|
| |
| |
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: | 31-MAY-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)FM(0.3), 7.2(0)PDB(0.379), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6), 7.2(0)ZD(0.126), 7.2(0)ZN(0.144) |
|
|
| |
| |
Bug Id: | CSCur22182 |
Title: | SNMP walk aborts as BGP MIB OID does not increase with BGP VPNv4 |
|
Description: | Symptom:
snmpwalk aborts when performing a snmpwalk on CISCO-BGP4-MIB, when any bgp peer is configured with both VPNv4 Unicast AF(afi=1, safi=128), IPv6 Unicast AF (afi=2, safi=1) and/or IPv6 Multicast AF(afi=2, safi=2). Snmpwalk on the following tables are affected and will not be queried completely and aborts when querying VPNv4 unicast AF of any peer with above mentioned configuration:
- cbgpPeerAddrFamilyTable
- cbgpPeerAddrFamilyPrefixTable
- cbgpPeer2AddrFamilyTable
- cbgpPeer2AddrFamilyPrefixTable
This issue will abort snmpwalk on cbgpPeer (1.3.6.1.4.1.9.9.187.1.2) or any oid tree that includes these tables.
Example:
.1.3.6.1.4.1.9.9.187.1.2.7.1.3.1.4.19.0.101.6.2.1 = IPv6 Unicast
.1.3.6.1.4.1.9.9.187.1.2.7.1.3.1.4.19.0.101.6.1.128 = VPNv4 Unicast
Conditions:
Occurs when any bgp peer is configured with both VPNv4 Unicast AF(afi=1, safi=128), IPv6 Unicast AF (afi=2, safi=1) and/or IPv6 Multicast AF(afi=2, safi=2)
Workaround:
Since this issue breaks the snmpwalk to cbgpPeer and the other oid trees which queries the tables in CISCO-BGP4-MIB, snmpwalks can work only with oid trees which do not include CISCO-BGP4-MIB, under this configuration/scenario without aborting. The CISCO-BGP4-MIB tables can be queried separately to get the information from the unaffected tables. Further, snmpget is not affected by this issue and will provide the correct outputs but can only be used to query specific oids.
Further Problem Description:
Snmpwalk oids have to be queried incrementally, but in this case, IPv6 unicast and IPv6 multicast AFs are sent queries before VPNv4 unicast AF which has a lower oid value, this aborts the snmpwalk query.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S97 |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.12), 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)PDB(0.359) |
|
|
| |
| |
Bug Id: | CSCus67594 |
Title: | 7.2.0.D1.0.386.S2::UIN-1::Seeing eigrp-3 core after LC reload trigger |
|
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: | 31-MAY-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: | 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: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 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)FM(0.3), 7.2(0)PDB(0.365), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
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: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(8b) |
|
Known Fixed Releases: | 6.2(12)E4, 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), 7.2(0)FM(0.3) |
|
|
| |
| |
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: | 31-MAY-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.2(0)D1(0.451), 7.2(0)FM(0.3), 7.2(0)N1(1), 7.2(0)PDB(0.387), 7.2(0)RTG(0.119), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
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: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(10), 7.2(0)D1(0.430) |
|
Known Fixed Releases: | 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)FM(0.3), 7.2(0)PDB(0.379), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
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: | 31-MAY-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)FM(0.3), 7.2(0)PDB(0.353) |
|
|
| |
| |
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: | 31-MAY-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)PDB(0.359) |
|
|
| |
| |
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: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(8a), 7.1(0)D1(0.328) |
|
Known Fixed Releases: | 7.1(0)AV(0.38), 7.2(0)D1(0.402), 7.2(0)OTT(0.5), 7.2(0)PDB(0.332) |
|
|
| |
| |
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: | 31-MAY-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)FM(0.3), 7.2(0)PDB(0.368), 7.2(0)VOF(0.2), 7.2(0)VZD(0.6) |
|
|
| |
| |
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: | 31-MAY-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.1(0)AV(0.74), 7.1(0)ES(0.7) |
|
|
| |
| |
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: | 31-MAY-2015 |
|
Known Affected Releases: | 7.1(0)ZD(0.341) |
|
Known Fixed Releases: | 6.2(10)E5, 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)ES(0.7), 7.1(0)EV(0.125), 7.1(0)OTT(0.41), 7.1(0)PDB(0.317), 7.2(0)D1(0.356) |
|
|
| |
| |
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: | 31-MAY-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)FM(0.3), 7.2(0)RTG(0.129) |
|
|
| |
| |
Bug Id: | CSCum04858 |
Title: | Mem Leak observed on running Routing APP |
|
Description: | Symptom:
Memory leak is observed when adding routes on NXOS routers using onePK route add apis
Conditions:
Memory leak is seen when programming routes using onePK api when an application connects & disconnects several times and does route add during each session. Memory leak does not seem to increase depending on the number of routes programmed during one application session.
Workaround:
Minimize application connection flaps to reduce memory leak.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 31-MAY-2015 |
|
Known Affected Releases: | 6.0(2)N3(1), 7.0(0.9)CA |
|
Known Fixed Releases: | 6.0(2)N3(0.89), 6.0(2)N3(1), 6.0(2)U2(0.10), 6.0(2)U2(1a), 6.0(2)U2(2), 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)KM(0.37), 7.0(0)N1(0.438), 7.0(0)N1(1) |
|
|
| |
| |
Bug Id: | CSCuq96822 |
Title: | After ISSU 6.1.4 to 6.2.8 crash due to heartbeat failure on scale |
|
Description: | This is a scale config on an interface
Symptom:
When 4k vlans are assigned to an interface, the heartbeat fails as it is looping and it will crash due to timeout
Conditions:
Same as above
Workaround:
Assign about 1000 vlans at a time
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(10)S77 |
|
Known Fixed Releases: | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.8), 7.1(0)ES(0.7), 7.2(0)D1(0.422), 7.2(0)FM(0.3), 7.2(0)PDB(0.359), 7.2(0)RTG(0.70), 7.2(0)VZD(0.6), 7.2(0)ZD(0.103) |
|
|
| |
| |
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: | 31-MAY-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)S2, 6.2(12), 6.2(12)S24, 6.2(12.4)S0, 6.2(13)FM(0.65), 6.2(9b) |
|
|
| |
| |
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: | 31-MAY-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E2, 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)FM(0.3), 7.2(0)PDB(0.358), 7.2(0)VOF(0.2), 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: | 31-MAY-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)FM(0.3), 7.2(0)PDB(0.353), 7.2(0)RTG(0.113) |
|
|
| |
| |
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: | 31-MAY-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: | 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: | 31-MAY-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.232) |
|
Known Fixed Releases: | 6.2(10)E5, 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), 7.2(0)FM(0.3), 7.2(0)OTT(0.4) |
|
|
| |
| |
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: | Open |
|
Severity: | 2 Severe |
Last Modified: | 31-MAY-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 31-MAY-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) |
|
|
| |
:
没有评论:
发表评论