| |
|
Alert Type: | Updated * |
Bug Id: | CSCud96571 | Title: | pf_dev1 UIT: hmm cpu busy when launch 8 spines+96 leafs with 132 image |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: * | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 14-SEP-2015 |
|
Known Affected Releases: | 6.2(0.99) |
|
Known Fixed Releases: * | 6.2(0)PF(0.144), 7.0(0)BNZ(0.23), 7.0(0)KM(0.37), 8.3(0)CV(0.142) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus66218 | Title: | Deleted vlans are still showing in show fabricpath output |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
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:
|
|
Last Modified: | 16-SEP-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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh04650 | Title: | N7K aclqos service crash causing linecards to stay in powered down state |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
The N7K was operating normally when it unexpectedly wrote out an ACLQOS core which also caused the line cards to go into power down state.
Conditions:
This has been seen on N7K running 5.2(5) code which was previously operating normally.
Workaround:
Not known at this time.
More Info:
To Be Determined (TBD).
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.2(5) |
|
Known Fixed Releases: * | 5.2(9.192)S0, 6.2(1.156)S0, 6.2(2), 8.3(0)CV(0.134) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw13529 | Title: | Runts, short packet errors etc not reported by F2e port with CTS config |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Line errors for small packets, runts, align/symbol errors etc are not displayed when a F2e module port is configured with CTS.
Conditions:
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 6.2(14)S25 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo02430 | Title: | SSTE: hsrp process crashed with SSO trigger |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
HSRP process on the standby sup becomes unresponsive and eventually crashes with heartbeat timeout when system switchover is performed. HSRP process is then restarted by sysmgr.
Conditions:
HSRP groups are configured on interfaces with invalid VRFs (i.e. where the VRF is shutdown or not defined). Switch is booted up with saved startup config. System switchover is performed.
Workaround:
Ensure VRFs are valid before system switchover, i.e. if the VRF is shutdown then "no shut" the VRF, and if VRF is not defined then define it.
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 6.2(8)S11, 6.2(8)S19, 6.2(8)S9, 7.0(3)I2(0.375) |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)FM(0.28), 6.2(10)NO(0.18), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(3)I2(0.390), 7.0(3)I2(1), 7.0(3)ITI2(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub27429 | Title: | N7K snmpwalk OID not increasing for ifTable on some Tunnel interfaces |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
look:~$ snmpwalk -v2c -c public 10.86.206.103 ifName
ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.402718720 = Tunnel0
ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.402719232 = Tunnel512
ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.402718723 = Tunnel3
Error: OID not increasing: ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.402719232 >= ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.402718723
Conditions:
Config a small tunnel number, big tunnel number interface, then small tunnel number.
e.g. tunnel0, tunnel512, tunnel3
Workaround:
Add -Cc to avoid the warnings
look:~$ snmpwalk -v2c -Cc -c public 10.86.206.103 ifName -Cc
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.2(6.16), 6.1(1)S42, 6.2(0.217) |
|
Known Fixed Releases: * | 5.2(6.23)S0, 5.2(7), 6.1(1.52)S0, 6.1(1.69), 6.1(2), 6.2(0.226)S0, 6.2(0.285), 6.2(2), 7.1(0)RTG(0.50), 7.1(0)SIB(99.52) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsq66001 | Title: | SNMP:mibwalk not detecting tunnel interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | In SNMP mibwalk tunnel interface is not detected.
Under all conditions
There is no work around for this issue. Issue doesn't have any functional impact.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.0(2) |
|
Known Fixed Releases: * | 4.2(0.158), 4.2(1), 5.0(0.129), 5.0(1), 7.1(0)RTG(0.50), 7.1(0)SIB(99.52), 7.1(0)ZD(0.331), 8.3(0)CV(0.134) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj17755 | Title: | SNMPd process crash |
|
Status: * | Other |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut34478 | Title: | unicast route for the NVE peer loopback IP is missing on some ASIC inst |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
This issue is specific to Vxlan - Flood and Learn. When the peer LC goes down and it is the only core facing LC on the peer switch, the peer route is not programmed properly on all the instances and hence the traffic fails.
Conditions:
This issue is specific to Vxlan - Flood and Learn.
The peer route must be programmed on the VDC instances. This is achieved through the following two updates -
a. URIB route update for programming the route on core vrf instances.
b. NVE Manager peer add updates for programming the route on the VDC instances.
This issue is observed when the peer LC goes down and it is the only core facing LC on the peer switch. In such a scenario, when OSPF timeouts, URIB triggers an unlearn for the peer route.
However, the MAC Table timeout is longer than the OSPF timeout. Hence, the MAC table still has the Remote host MAC entry - thus the NVE peer is still seen in NVE Manager.
When the peer LC is up again, OSPF sends an update for the peer route. However, NVE manager doesn't resend the peer route update since it already has the peer update. As a result, we end up with the peer route programmed only on the URIB notified VRF instances and not the other instances in the VDC.
Workaround:
clear ip route vrf all
shut / no shut on the nve interface.
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.424) |
|
Known Fixed Releases: * | 7.2(1)D1(0.75), 7.2(1)ZD(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug81339 | Title: | Service "Security Daemon" crashes with heartbeat failure |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: * | 6.2(3), 6.2(8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv40883 | Title: | F3 unexpected reload after span session config |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After enable a span session for a Port-channel source in vPC with N77-F348XP-23 physical port in module 1 and destination port in module 6 (both modules N77-F348XP-23) a core crash is created for both modules. they are restored after reload crash reload.
Conditions:
I saw this problem by the very first time during a customer network troubleshooting.
I reproduced problem on CALO with the next conditions:
HW:
1 x N77-SUP2E
2 x N77-F348XP-23
1 x N77-C7706-FAB-2
1 x N77-C7709
2 VDCs were created , 1 for SPINE Fabric Path VDC 1 for LEAF Fabric Path VDC
Problem occurs on LEAF VDC just after we do 'no shut' under the monitor session config mode
problem was reproduced on 6.2(8a) and 6.2(10)
Workaround:
Further Problem Description:
Cores from 6.2(10)
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437208662_0x102_fln_fwd_usd_log.1178.tar.gz
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437208661_0x802_fln_fwd_usd_log.1178.tar.gz
Cores from 6.2(8a)
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437203676_0x102_fln_fwd_usd_log.1160.tar.gz
http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=635507347&fileName=1437203675_0x802_fln_fwd_usd_log.1160.tar.gz
|
| Severity: error
| lcfln_n77 - Nexus 7700 platform running 6.2(10)S102 experienced a crash
| at 2015-07-18 08:37:42.
| The decoded stack traces are:
| 0x0ff4a4b0 usd_sse_process_msg
| 0x0ff4a4b0 usd_sse_process_msg ---> usd_sse.c:826
| 0x100673e8 fln_fwd_sse_hdlr ---> fln_fwd_services.c:9067
| 0x0ff5bf48 usd_handle_event ---> usdw_main.c:344
| 0x0ff5c4cc usd_loop ---> usdw_main.c:466
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: * | 6.2(10), 6.2(12), 6.2(8a) |
|
Known Fixed Releases: | 6.2(14)S1, 7.2(1)D1(0.41), 7.2(1)ZD(0.36) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv99892 | Title: | nvt: Mcast traffic loss on vpc primary on reloading secondary vdc |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
Transient traffic lose experienced
Conditions:
With disruptive network configuration changes, large amount of l2 route will be sent to H/W in very short time. If the same route is sent back-to-back repeatedly with different information, h/w state might not be able to keep up the change,
Workaround(s): None.
Workaround:
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 7.2(1)D1(0.49) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc23279 | Title: | SYSTEST:FCoE:core detected due to hwclock crash on standby sup |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Core detected due to hwclock crash on standby sup.
Conditions:
None
Workaround(s):
No impact reported.
Workaround:
Further Problem Description:
|
|
Last Modified: | 14-SEP-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) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw23407 | Title: | iftmc cores at at iftmc_pd_verify while reapply of pvlan communityconf |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
iftmc cores at at iftmc_pd_verify while reapply of pvlan communityconf
Conditions:
iftmc cores at at iftmc_pd_verify while reapply of pvlan communityconf
Workaround:
iftmc cores at at iftmc_pd_verify while reapply of pvlan communityconf
Further Problem Description:
iftmc cores at at iftmc_pd_verify while reapply of pvlan communityconf
|
|
Last Modified: | 14-SEP-2015 |
|
Known Affected Releases: | 7.2(1)D1(0.57) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud14484 | Title: | BGP crash with 1K EBGP , with multi dimensional scale |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 6.2(0.257) |
|
Known Fixed Releases: * | 6.2(0.287)S0, 6.2(2), 8.3(0)CV(0.144) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug88160 | Title: | Vinci MT-FULL: topo/vni notification not sent to ISIS |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
DATA-UP is not sent to ISSI by RTM.
Conditions:
Workaround:
Use "fabricpath isis data-up"
More Info:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 6.2(0)PF(0.210) |
|
Known Fixed Releases: * | 6.0(2)N3(1), 7.0(0)BNZ(0.23), 7.0(0)ZD(0.7), 7.0(1)N1(0.47), 7.0(1)N1(1), 8.3(0)CV(0.144) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur03059 | Title: | VPC+ peer link not part of a topology |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 16-SEP-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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum13338 | Title: | SSTE: L3VM Hap-Reset on Leaf |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
.
Conditions:
.
Workaround:
.
Further Problem Description:
.
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N3(1), 7.0(1)ZN(0.35) |
|
Known Fixed Releases: * | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.109), 7.0(0)N1(0.452), 7.0(0)N1(1), 7.0(0)ZD(0.190), 7.0(0)ZN(0.165), 7.1(0)D1(0.104), 7.1(0)FC(0.2), 7.1(0)NF(0.28), 7.1(0)PDB(0.60) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue28836 | Title: | Interface down (VRF Unusable) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
interface become vrf-unusable.
Conditions:
Do switchover immediately after module reload.
Workaround:
Do not do switchover immediately after module reload.
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 6.1(3)S41 |
|
Known Fixed Releases: * | 6.2(1.69)S0, 6.2(2), 7.0(0.7), 8.3(0)CV(0.144) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud45447 | Title: | Freetown:Service"ldp" is cored |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Service "ldp"is cored .
Conditions:
LDP service is cored.
Workaround:
NA
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: * | 6.2(0.284)S8, 6.2(0.304), 6.2(0.304)S12, 6.2(0.304)S16, 6.2(1.5)S2 |
|
Known Fixed Releases: * | 6.2(1.7)S0, 6.2(2), 7.0(0.5), 8.3(0)CV(0.144) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul87609 | Title: | I:392:FP non-default topo doesn't works after ISSU downgrade I to H+ |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
I:392:FP non-default topo doesn't works after ISSU downgrade I to H+
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N3(1) |
|
Known Fixed Releases: * | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)N1(0.433), 7.0(0)N1(1), 7.0(0)ZD(0.183), 7.0(0)ZN(0.150), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.2(0)D1(1), 8.3(0)CV(0.144) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul78703 | Title: | i-379: l3vm hap reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
i-379: l3vm hap reset
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N3(1) |
|
Known Fixed Releases: * | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)N1(0.399), 7.0(0)N1(1), 7.0(0)ZD(0.172), 7.0(0)ZN(0.124), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.2(0)D1(1), 8.3(0)CV(0.144) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup77035 | Title: | [GBR performance] ospf process command execution takes huge time |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
With GBR release 179, 193 and within vdc scale
Conditions:
scaled vdc
Workaround:
Unknown still
Further Problem Description:
|
|
Last Modified: | 16-SEP-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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv50831 | Title: | BGP is installing route with AD 255 in URIB |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Routes with an AD of 255 are permitted for redistribution.
Conditions:
When using the [distance # # #] command for BGP to set summarized/local routes to an administrative distance of 255. The summary routes remain in the routing table, but marked with an AD of 255 from its default of 220 and also permitted to be redistributed into other protocols.
10.10.0.0/16, ubest/mbest: 1/0
*via Null0, [255/0], 00:00:11, bgp-65545, discard, tag 65012 ---------------->Route remained in routing table but AD did adjust to 255.
r12.7k-VDC3(config-router-af)#
############Redistributing BGP into OSPF############################
##Route shouldn't be redistributed as it is within the RIB with an AD of 255.
version 6.2(12)
feature ospf
router ospf 1
router-id 172.16.0.1
redistribute bgp 65545 route-map test ----------------------->Sending route to OSPF
ip prefix-list bgp seq 5 permit 0.0.0.0/0 le 32
route-map test permit 10
match ip address prefix-list bgp
r12.7k(config)# sho ip ospf database | b Ex
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 172.16.0.1 14 0x80000002 0xea3c 65005
10.10.0.0 172.16.0.1 14 0x80000002 0x50cd 65012 ---------->Summary is installed within OSPF database and advertised to OSPF peers. Which shouldn't happen as AD is 255
Workaround:
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 5.1(4), 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)PDB(0.57), 7.3(0)RTG(0.66) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus97380 | Title: | plcmgr crash during OpenFlow extended sanity |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Crash in plcmgr.
Conditions:
Occurs sometimes during addition of OpenFlow matches to end of policy.
Workaround:
None known.
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.402) |
|
Known Fixed Releases: * | 7.1(0)ES(0.5), 7.3(0)D1(0.86), 7.3(0)DHB(0.32), 7.3(0)EG(0.3), 7.3(0)OTT(0.37), 7.3(0)PDB(0.57) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo86388 | Title: | NXOS-VPC-VPLS Scale-after Core LC OIR,subset of PW Remain in Down state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 7.1(0)ZD(0.181) |
|
Known Fixed Releases: * | 15.4(3)M2.1, 15.4(3)M3, 15.4(3)M3.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 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv37216 | Title: | Callhome messages via HTTP transport is not sent due to L3VM error |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Callhome messages vis HTTP transport not sent due to l3vm_get_context_id failing.
Conditions:
Try sending any call home message thru http transport.
Workaround(s):
None.
Workaround:
None.
Further Problem Description:
None.
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 7.3(0)SLN(0.28) |
|
Known Fixed Releases: * | 7.3(0)D1(0.98), 7.3(0)PDB(0.57), 7.3(0)SL(0.109), 7.3(0)SL(0.85) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu09287 | Title: | SSTE: pixm critical message on 'no feature-set fabric' |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.484) |
|
Known Fixed Releases: * | 7.2(1)D1(0.51), 7.2(1)N1(0.283), 7.2(1)N1(1), 7.2(1)ZD(0.45), 7.2(1)ZN(0.47), 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)PDB(0.57), 7.3(0)RTG(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus96272 | Title: | pvlan Channel-group members add/remove fails . |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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 .
|
|
Last Modified: | 23-SEP-2015 |
|
Known Affected Releases: | 7.2(0.8) |
|
Known Fixed Releases: * | 6.2(13.6)S0, 6.2(14), 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)D1(0.469), 7.2(0)D1(1), 7.2(0)PDB(0.390), 7.2(0)VZD(0.26) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut08818 | Title: | SNMPD crashes with role with only deny OIDs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 23-SEP-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(8a), 6.2(9a) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.63), 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.1(2)N1(0.548), 7.1(2)N1(1), 7.1(2)ZD(0.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup22563 | Title: | Vulnerabilities in OpenSSL: LDAP over SSL |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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
|
|
Last Modified: | 24-SEP-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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus42713 | Title: | 2014 and 2015 OpenSSL Vulnerabilities |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 5.2(8f), 6.2(10), 6.2(11), 6.2(7), 6.2(8)S3, 6.2(8a), 7.2(0)VX(0.9), 7.2(0.1)PR(0.1), 7.3(0.9), 9.9(0)XS(0.1) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.52), 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.0(0)KMS(0.11), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui61230 | Title: | after reloading box when new pw is added under vfi it stays down |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When a new PW is added under vfi context, it does not come UP
Conditions:
Seen for manual PWs (i.e config of the type "member 1.2.3.4 encapsulation mpls" under the vpls context)
Workaround:
"clear l2vpn service vfi name ", or deleting and reconfiguring the PW fixes the issue.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 6.2(2)S33 |
|
Known Fixed Releases: * | 15.3(3)M1.5, 15.3(3)M2, 15.3(3)S0.4, 15.3(3)S1, 15.3(3)S2, 15.4(0.12.6)PIH23, 15.4(0.19)S, 15.4(0.20)PI24d, 15.4(0.22)T, 15.4(0.22.1)PIH23 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu63346 | Title: | vPC leg no BD after multiple link flaps |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
vPC leg (on one side) ended up without BD after a particular sequence of link flap. The other side, vPC leg is in STP BLK state.
vPC status
---------------------------------------------------------------------
id Port Status Consistency Active VLANs Active BDs
----- ------------ ------ ----------- ---------------- --------------
100 Po100 up success - - <<< No BD
200 Po200 up success - 100-107
A#
Conditions:
Happens with below particular sequence:
vPC Peerlink down -> A vPC leg(100) down -> vPc peerlink up -> A vPC leg(100)up
Workaround:
The sequence of recovery steps that will avoid the system coming into this unrecoverable bad state is to bring up the primary vpc leg up first followed by the peer link. This will ensure consistency and correctness in the final state.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.44), 7.2(1)ZD(0.38), 7.3(0)D1(0.45), 7.3(0)D1(0.64), 7.3(0)D1(0.73), 7.3(0)D1(1A), 7.3(0)EG(0.3), 7.3(0)IB(0.67), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus93974 | Title: | NVE peer is not learned later, if the NVE peer delete happens LC ISSU |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | This defect is not applicable to current GBR release since vxlan configs were not a part of the previous release which is freetown. Hence there is no issue on issu.
Symptom:
There exists an issue with vxlan peer learning on ISSU from gbr to gbr upgrade. When a line card upgrade is in progress and the SUP is already up and ready to learn peers, line card components reject a peer-add and we end up having inconsistent peer information in PI components and line card which causes an issue when the peer needs to be re-learned.
This issue is not currently applicable to gbr since freetown -> gbr ISSU will not suffer from this because vxlan wil be first introduced in gbr.
Conditions:
Occurs only during ISSU.
Workaround:
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.392) |
|
Known Fixed Releases: * | 7.3(0)D1(0.99), 7.3(0)IB(0.72), 7.3(0)N1(0.136), 7.3(0)N1(1), 7.3(0)ZD(0.113), 7.3(0)ZN(0.124) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut84904 | Title: | Process "mtm" Cores on F3 Cards Shortly After Boot |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Repeated "mtm" cores on an F3 linecard
Conditions:
The issue is not specific to any line card type.
The issue happens in a vpc complex, when one Peer has a version >= 6.2.10 and the other peer has a version < 6.2.10
If port-security with aging time is configured on a vpc leg, then the issue could be seen.
The issue is also seen if port-security with aging time is configured on an orphan port
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 27-SEP-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S1 |
|
Known Fixed Releases: * | 6.2(14), 6.2(14)S2, 7.2(1)D1(0.66), 7.2(1)ZD(0.58) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw39946 | Title: * | MAC learnt on non existent F2e port |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
MAC address learnt on a non existent port
Conditions:
Seen when a loop occurs and multiple mac flaps were seen. While this happens, if the port-channel is deleted, the process responsible for mac learning still believes the interface exist
Workaround:
create the port-channel again and issue clear mac address-table and then delete the port-channel
Further Problem Description:
|
|
Last Modified: | 27-SEP-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur57124 | Title: | can not ping OTV extended VLAN SVI although OTV adjcancy is UP |
|
Status: * | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
OTV Adjacency is up but can not ping between extended VLAN SVI
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
N/A
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 6.2(10)VIK(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw18366 | Title: | OTV core while bringing up 42+ OTV adjacency |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
OTV process crash.
Conditions:
While add more than 42 OTV adjacency are added for on N7k.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: * | 7.3(0)RTG(0.80) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv90456 | Title: | pimxc timeout happening on removing VSI channel-group |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
pixm timeout syslog when the VSI channel group is removed in an auto config setup
Conditions:
this doesn't happen always. has been seen rarely only in scale scenarios when close to 500 profiles are deleted at the same time
Workaround:
VSI port channel deletion can be re-attempted
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 7.3(0)D1(1A) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)PDB(0.43) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup05138 | Title: | CPU generated traffic being sent to DEST INDEX:0 and dropped after ISSU |
|
Status: | Terminated |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 29-SEP-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), 7.2(1)D1(0.95) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw16411 | Title: | HSRP state Active/Active after removing Anycast |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Nexus 5600 VPC+ peers will show Active/unknown for HSRP Active/standby states on both peers
N5k-1# sh hsrp br
*:IPv6 group #:group belongs to a bundle
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
# Vlan10 10 100 Active local 10.10.10.67 10.10.10.1 (conf)
Vlan20 2 100 Active local unknown 20.20.20.1 (conf) <<<<<<<<<<
Conditions:
Rolling back from HSRP Anycast to legacy HSRP on VPC+ peers. Seen only under following conditions
1)Bug is only seen if hsrp anycast <> ipv4 is configured and subsequently removed.
2)In addition ,one SVI on one vPC peer has to be shut after removing anycast configuration
2)Bug is not seen with same steps if "hsrp anycast <> both? is configured
3)Even if bug is seen, configuration for the group/vlan can be changed to "hsrp anycast <> both? and migrated to legacy HSRP without hitting the problem.
4)Problem not seen after migrating to legacy HSRP
Workaround:
Change HSRP anycast configuration to include both IPv6 and IPv4 using command hsrp anycast <> both and then remove the anycast configuration.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 7.0(7)ZN(0.215) |
|
Known Fixed Releases: * | 7.3(0)D1(0.112), 7.3(0)N1(0.150), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu84449 | Title: | IGMP snooping entries ageout in AA FEX topologies |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IGMP snooping entries are expiring after 5 seconds on one of the two vPC switches, while the entries are stable on the other vPC switch, which might cause traffic loss for 15-16 seconds (depending on the port-channel hashing result).
Conditions:
Issue can be seen in a vPC topology with AA FEX without having configured the IGMP snooping switch-querier (under "vlan configuration XYZ"), but when having PIM enabled SVI interfaces.
Workaround:
Configure IGMP snooping querier under the "vlan configuration XYZ" configuration mode.
or
Configure "ip igmp query-interval 30" under the SVI configuration mode.
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1 |
|
Known Fixed Releases: * | 7.2(1)D1(0.7), 7.2(1)N1(0.240), 7.2(1)N1(1), 7.2(1)ZD(0.6), 7.2(1)ZN(0.6), 7.3(0)D1(0.72), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.27) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03410 | Title: | Nexus 6.2.x OSPF taking long time in LSA generation |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
- Customer reported that there was a delay in LSA generation.
- The cost was increased at 03:42:36 but the LSA was generated at 03:43:20 which caused an impact for the customer as all the traffic moved to this router and cause congestion on the port-channel causing an impact for nearly 45 seconds.
- The first LSA was generated at the same time for the first port-channel but for the next 3 port-channels it throttled and took over 40+ seconds
Conditions:
> Info:
1. OSPF maintains a wheel with 600 slots in which LSAs will be inserted if they are to be generated and also tracks the current slot which is being processed. Lets say an LSA is to be generated after 100 msec, then it will be inserted in (current + 2) slot (1 slot equals 50 msec).
2. There is a common throttle timer which fires every 50 msec and increments the current slot. This is done by timer thread.
3. The flooding thread picks the LSA's from the current slot and generates the LSA's. Both these happen independently.
> Sequence of steps leading to problem:
In the customer's case, an LSA was to be generated after 5000 msec and hence was inserted at (current + 100) slot. Looks like the timer thread incremented the current slot before the flooding thread could process the LSA's in current slot.
This could happen if the order of thread execution is:
Lets say that the current slot is 199 and there is an LSA at 200.
Timer thread executes and increments current slot to 200.
Scheduler schedules some other OSPF thread for the next 50 msec or more. This means the throttle timer would have fired.
Scheduler schedules timer thread which will increment the current slot to 201.
Now, OSPF will have to wait for the current slot to reach 600, then cycle back, and then from 1 to 200 again. This will take 50 * 600 = 30000 msec or 30 sec.
Workaround:
Though the issue is timing related, using interface range command seems to not lead to the problem.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(12)E6, 6.2(14.3)S0, 7.0(3)I2(1.19), 7.0(3)I2(2), 7.2(1)D1(0.79), 7.2(1)N1(0.307), 7.2(1)N1(1), 7.2(1)ZD(0.71), 7.2(1)ZN(0.70), 7.3(0)D1(0.96) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtu28085 | Title: * | M1 Line Card: MAC Moves Cause Out-of-Sync Forwarding Engine |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Following a MAC Flap, the hardware MAC address table may not have the same consistent entry across all the forwarding engines (FEs)
Conditions:
Issue is seen on M1 modules
Rapid mac move that happen between two FEs and there is a Flood to bd / flood to fabric miss in hardware
Workaround:
Clearing the affected mac address from the L2 table will restore connectivity (address will be learned on the correct interface).
clear mac address-table dynamic [address ]
Further Problem Description:
Fix is present in 5.2(4), 6.1(1), and later.
Refer to CSCud01394 for fix to F modules for the same issue.
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: * | 5.2(3a), 6.0(4) |
|
Known Fixed Releases: * | 5.2(3.59)S0, 5.2(4) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw10951 | Title: | NXOS/F3: Multicast convergence improvement |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Slow multicast convergence on F3 cards during RPF/OIF changes in high scale scenario
Conditions:
It happen only in high scale 20+ S,G routes
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuj54486 | Title: | multicast packets drop for certain flows after fex reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
multicast packets drop for certain flows after fex reload
Current set of m2rib logs seem to be indicating that IGMP did not clean up Ethernet107/1/42 OIF, when IGMP received IM delete for Ethernet107/1/42 . Later that IOD was assigned to Eth101/1/42. Since IGMP already had iod 1366, it would have considered that it had already sent update to m2rib. That would have resulted the OIF mismatch in this case.
Conditions:
I am running fex reload 8 hr script and after fexes are reloaded certain flow groups are dropped.
Workaround:
no
Further Problem Description:
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(2) |
|
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.257), 7.1(0)N1(0.319), 7.1(0)N1(1), 7.1(0)OTT(0.34), 7.1(0)PDB(0.205), 7.1(0)SIB(99.24), 7.1(0)ZD(0.305) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv34380 | Title: | vPC switch keeps sending (S, G) joins even after (*, G) entry gone. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PIM (S, G) joins are sent upstream even when corrosponding (*, G) entry has expired.
Conditions:
vpc-peers with "ip pim pre-built spt" configured. Active source but receivers are expired.
Workaround:
clear ip mroute will remove the unwanted (S, G) entry.
Further Problem Description:
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 7.2(0)ZD(0.99) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)DHB(0.31), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.43), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCur59789 | Title: | while configuring vrf Unrecognized IP message minor type 33 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
while configuring vrf Unrecognized IP message minor type 33
Conditions:
This failure message is seen by every DFA customer when they deploy a new VRF via auto-config.
Workaround:
Further Problem Description:
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.299), 7.1(0)N1 |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)IB(122), 7.1(0)SIB(99.109), 7.1(1)N1(0.500), 7.1(1)N1(1), 7.1(1)ZD(0.31), 7.1(1)ZN(0.54), 7.2(0)AB(9), 7.2(0)BA(0.12) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv69813 | Title: | En/Dis LLDP cause "Error in sending MTS message to dcx: (Broken pipe)" |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
with a few back to back changes on
1) "no feature lldp"
2) "feature lldp"
3) "no feature lldp"
4) "feature lldp"
5) "no feature lldp"
6) "feature lldp"
and large number of active ports (tried with 768) following message can be seen
VDC-1 %$ %IPQOSMGR-2-QOSMGR_MTS_FAILURE: Failed to do MTS operation: Error in sending MTS message to dcx: (Broken pipe)
Conditions:
Large number of active ports
back to back change of LLDP feature
Workaround:
Further Problem Description:
Message is harmless
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 6.2(14)S4 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum10680 | Title: | BUG0438791:Wrong next hop for APBR entry, next hop is NSIP instead SNIP |
|
Status: * | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Some APBR entries next hop is NSIP instead SNIP in show rise output
Conditions:
This happens when default route is define is NS IP sub net. When specific route to realer server subnet is removed, NetScaler use default route to reach realer server and install APBR entry with NS IP address as next hop. This is an issue when NetScaler is configured in HA pair, since NS IP is unique to each NetScaler
Workaround:
Not to configure default gateway address in NS IP subnet , In future NS release APBR entry with next hop as NS IP address will be prevented
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 6.2(6)S4 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu99291 | Title: | Cisco Nexus 7000 VDC Authenticated Privilege Escalation Vulnerability |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A vulnerability in Command Line Interface (CLI) parser of the Cisco Nexus Operating
System (NX-OS) devices could allow an authenticated, local attacker to perform a
privilege escalation at the CLI.
The vulnerability is due to improper input validation of special characters within
filenames. An attacker could exploit this vulnerability by authenticating at the local
shell and writing a file to disk with certain special characters. The attacker could then
use that file with other CLI commands to obtain an shell prompt at their current
privilege level. An exploit could allowthe attacker to read/write files and perform
other privileged commands.
Conditions:
Device running with default configuration running an affected version of
software.
Workaround:
The user has to be authenticated so use care when distributing ''admin''
credentials to only trusted sources.
Further Problem Description:
Credit:
Cisco would like to thank Jens Krabbenhoeft for discovering and reporting this vulnerability.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are
4.3/4.1:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:P/I:P/A:P/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2015-4237 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(13.4)S0, 7.2(1)D1(0.51), 7.2(1)ZD(0.45) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCur86210 | Title: | Iplus: motd banner not displayed upon login.. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
MOTD banner is not printed upon login
Conditions:
After the reload banner is not working.
Workaround:
No
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 7.1(0)N1(0.413) |
|
Known Fixed Releases: | 7.1(0)N1(0.415), 7.1(0)N1(1), 7.1(0)ZN(0.490), 7.1(1)N1(0.34), 7.1(1)N1(1), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu76369 | Title: | Random characters in show ip igmp policy statistics reports vlan |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Random characters are observed in the output of 'show ip igmp policy statistics vlan <>
Nexus9k# show ip igmp policy statistics reports vlan 100
Interface \6?? doesn't exist
Nexus 9k# show ip igmp policy statistics reports vlan 100
Interface tN?? doesn't exist
Conditions:
If a SVI is not deployed on Nexus 9k and , show ip igmp policy statistics reports vlan <> is executed for the VLAN ,
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.20), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu11282 | Title: | N7k: ITD probe with frequency config less than 5s seconds reverts to 60s |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ITD probes are only sent every 60 seconds when probe frequency is configured less than 5 seconds
Conditions:
ITD probe configured on Nexus 7000 running 6.2(10)
Workaround:
Configure probe frequency with at least 5 seconds frequency
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14)FB(0.52), 7.2(0)D1(1), 7.2(0)D1(1.8), 7.2(0)ZD(0.216), 7.2(1)PIB(0.14), 7.3(0)D1(0.69), 7.3(0)DHB(0.31), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu66267 | Title: | LISP: implicit iid 0 does not get assigned with proxy-itr configuration |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LISP traffic encapsulated with no Instance-ID may fail to be forwarded on the eTR/PeTR
Conditions:
The problem depends on configuration sequence and timing, i.e. is a race condition.
Workaround:
Configure explicitly "lisp instance-id 0" in the VRF that receives LISP-encapsulated packet with no Instance-ID
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 7.2(0.70), 7.3(0)ZD(0.10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)DHB(0.31), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.21), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu36071 | Title: | Packets encaped with wrong VNI after addition of new link to Peerlink PC |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Receivers at remote vxlan L2 gateway may experience traffic lose. This is because the packets at vPC L3 gateway is encapped with wrong VNI value. This can be confirmed by examine the VNI field of the vxlan encapped packet received at remote L2 gateway.
Conditions:
The condition to hit the issue is to configure new vPC peer-link in a new hardware instance. This may cause timing issue when program the encap route in the new peer-link instance.
Workaround:
unconfig, then reconfig the multicast encap for this bridge-domain under nve interface will clear the wrong encap route and reprogram with correct information.
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.490), 7.2(0)VZD(0.33) |
|
Known Fixed Releases: * | 7.1(0)ES(0.24), 7.2(1)D1(0.36), 7.2(1)ZD(0.31), 7.3(0)D1(0.34), 7.3(0)D1(0.45), 7.3(0)D1(0.52), 7.3(0)D1(0.53), 7.3(0)DHB(0.14), 7.3(0)HM(0.47), 7.3(0)IB(0.35) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu39555 | Title: | Sometimes few HSRPVIP removed ISSU 6.0.2.N2(7)>7.0.6.N1(1)>7.2.0.N1(1) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
IP address with be removed after we do ISSU from "H+MR6 [6.0(2)N2(7)] to IMR5[7.0(6)N1(1)] then to JJ[7.2(0)N1(1)]"
Conditions:
Need to perform 2step ISSU from H+MR6 [6.0(2)N2(7)] to IMR5[7.0(6)N1(1)] then to JJ[7.2(0)N1(1)] with virtual ip configured in HSRP.
After doing ISSU from H+MR6 to IMR5 ISSU will succeed, then when we do ISSU from IMR5 to JJ, will get below error
<<<%NETSTACK-2-CRIT_FAILURE: netstack [4007] Failed to configure IP address on Vlan834. IP address overlaps with one of the address configured on Vlan833. Vlan834 has been shutdown.Please change the IP address to avoid overlap and perform a "no shutdown">>>
and ip address will be removed on the vlan or vlan interface will be shutdown.
Workaround:
Need to reconfigure the ip address after correcting the network mask of HSRP ip in the vlan.
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.206) |
|
Known Fixed Releases: * | 7.0(0)FHS(0.23), 7.3(0)D1(0.45), 7.3(0)DHB(0.14), 7.3(0)HM(0.47), 7.3(0)IB(0.35), 7.3(0)MMD(0.9), 7.3(0)N1(0.61), 7.3(0)N1(1), 7.3(0)OTT(0.14), 7.3(0)PDB(0.15) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu06829 | Title: | SUP switchover causes duplicate connection on switchover device |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On sup switchover or BGP process restart, duplicate connection request error is seen on switchover device.
Conditions:
1. Multiple sessions between switchover peer and helper peer.
2. High route scale
Workaround(s):
Workaround:
If multiple sessions are to be run between two boxes, configure one peer to be a passive listener always.
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 5.2(5), 7.0(3)I1(1.206), 7.0(3)I1(1.233) |
|
Known Fixed Releases: * | 7.0(3)I2(0.365), 7.0(3)I2(0.367), 7.0(3)I2(0.381), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.72) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu22255 | Title: | LL shouldn't be installed in u6rib by ospfv3 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
from "show routing ipv6 internal event-history general" we see there were some link local prefixes been advertised by ospfv3
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 6.2(0.304)S10, 6.2(12) |
|
Known Fixed Releases: * | 7.0(3)I2(0.469), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.15), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.3(0)IB(0.12), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut98635 | Title: | Eigrp Traceback @ dual_unstick_dndb on Sochi Tor on bootup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
EIGRP internal errors seen
Conditions:
Workaround:
No functionality impact, just a warning message
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I1(1.205) |
|
Known Fixed Releases: * | 7.0(3)I2(0.406), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.72) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv56604 | Title: | N7K:ospf pushing BFD into admin down state |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
All BFD/OSPF sessions flap on the local chassis.
Conditions:
This happens when sup switchover through physical removal or through CLI "system switchover" command with OSPF having passive-interface default in SR mode and no ip ospf passive-interface in certain interfaces.
Workaround:
The following workaround solved the issue
- no bfd echo
- bfd timers 150 min-rx 150 interval 3
Further Problem Description:
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | 7.1(3)N1(0.611), 7.1(3)N1(1), 7.1(3)ZD(0.9), 7.1(3)ZN(0.16), 7.3(0)IB(0.41) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut22695 | Title: | "mts_drop:2265 proc(/isan/bin/acllog) errno(22)" msg seen in 7.2.0.D1 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"show logging ip access-list internal event-history errors throws errors"
Conditions:
Configure access list (RACL/VACL/PACL) on any interface. Pump traffic through that interface so that there is a hit on the packet because of configured access-list. Then run "show logging ip access-list internal event-history errors throws errors"
Workaround:
This is not breaking any functionality. Its just reported in event-history debug message
Further Problem Description:
|
|
Last Modified: | 08-SEP-2015 |
|
Known Affected Releases: * | 7.2(0)D1(0.409), 7.2(0)D1(0.437), 7.2(1)D1(0.54), 7.3(0)ZD(0.23), 7.3(0)ZD(0.49) |
|
Known Fixed Releases: | 7.3(0)IB(0.8) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuo93802 | Title: | RISE service in vPC direct mode showing as admin down |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
There are two vPC peers directly connected to an MPX. One peer has an active RISE service, while the other has a RISE service showing as "admin down". The MPX itself lists only one RISE connection.
Conditions:
1. Configure vPC between two switches
2. Create active RISE service on both
3. Delete configuration and reload MPX with -warm flag
Workaround:
Reboot MPX and peer with "admin down" service.
Further Problem Description:
|
|
Last Modified: | 08-SEP-2015 |
|
Known Affected Releases: | 6.2(8)E1 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuq48097 | Title: | vsh errors due to bootvar after switch reload and NAM online |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Port-channels 4091 and 4092 are created and have "unknown enum" as their status in "show port-channel summary" after the agni-NAM module comes online.
The error "eth_pcm: unknown enum:0, tid(hex):2c00004, comp:191, cid(hex):0" appears after the "show port-channel summary" is issued.
Conditions:
The switch is reloaded under the following conditions:
1. There is only one supervisor module inserted
2. The configuration specifies a kickstart boot string for sup-2. e.g:
sup-1: kickstart
sup-1: system
sup-2: kickstart
Workaround:
Clear the sup-2 kickstart boot variable and reload.
Further Problem Description:
|
|
Last Modified: | 08-SEP-2015 |
|
Known Affected Releases: | 7.1(1)SP(0.15) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCus26803 | Title: | RISE up after removing vPC configuration from port-channel. |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
RISE is up for an indirect mode service, even though vPC configuration is missing from one of the two vPC peers.
Conditions:
vPC configuration is missing from one of the two vPC peers for a RISE indirect mode service.
Workaround:
Disable the non-desired vPC peer connection directly.
Further Problem Description:
|
|
Last Modified: | 08-SEP-2015 |
|
Known Affected Releases: | 6.2(12)S13 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue28131 | Title: | NXOS/OTV: OTV adj down due to tunnel creation failure |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | B>Symptom:
Continuous overlay flap could result in OTV adjacency down.
Conditions:
Continuous overlay flap for more than 2.5k times could result in tunnel hardware programming failure.
Workaround:
Reload vdc
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 5.2(9), 5.2(9)S49, 5.2(9.95)S0, 6.1(4.23)S0, 6.1(5), 6.2(1.72)S0, 6.2(1.93), 6.2(2), 7.0(0)ZD(0.53), 7.0(0)ZD(0.55) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCso22558 | Title: | SYSTEST:mts_sys_drop(): invalid input q_entry 0xc8ad2920 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
"2008 Mar 14 19:32:05 qadc3-ind06 %$ VDC-1 %$ %KERN-2-SYSTEM_MSG: mts_sys_drop(): invalid input q_entry 0xc8ad2920 for PID 6435 (tm). - kernel" error message gets printed on screen.
This message gets printed ocationally during tunnel interface bringup or when linecard is coming online.
This issue does not have any functional impact. There is no work around
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.0(1) |
|
Known Fixed Releases: * | 4.0(1.39), 8.3(0)CV(0.134) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup44154 | Title: | OTV Unicast : TM_MEM_fu_gwrap_t Memory Leak 6.2.6.S23 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
%SYSMGR-2-SERVICE_CRASHED syslog error message may be triggered by the 'tunnel' process in OTV unicast transport configuration. The core file generated by the 'tunnel' process should be visible under 'show core' command output.
Conditions:
OTV unicast transport configuration is configured on Nexus 7000 running 6.2(6) release.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 6.2(6)S23 |
|
Known Fixed Releases: * | 6.2(10), 6.2(10)S39, 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.303), 7.1(0)EV(0.116), 7.1(0)NF(0.32), 7.1(0)OTT(0.27) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw13014 | Title: | MTS buffer exhaustion in mcecm/vpc |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
MTS buffer exhaustion in ethpm and vpc, "vlan not responding" errors, or log messages indicating MTS buffer exhaustion.
Conditions:
A bulk delete of vlans is conducted without using the range command
Workaround:
reload the switch or use a vlan range statement to delete multiple vlans at once.
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui15592 | Title: | Nexus 7k unable to add spanning-tree commands to current interface |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Cannot add spanning-tree commands to current interface
Conditions:
any previously configured interface
Workaround:
default interface
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.1(5) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu73084 | Title: | HSRP Bundle in INIT state after reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
HSRP Anycast bundle goes to INIT state after reload.
Conditions:
HSRP Anycast bundle may go to INIT state after reload. This can happen if some interfaces come up later in the initialisation sequence after reload and makes the bundle in down state.
Workaround:
Shut and no shut the hsrp Anycast bundle to recover.
Further Problem Description:
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: * | 6.2(10), 7.2(0)D1(0.484) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14)FB(0.75), 7.1(2)N1(0.558), 7.1(2)N1(1), 7.1(2)ZD(0.14), 7.1(2)ZN(0.17), 7.2(0)D1(1), 7.2(1)D1(0.1), 7.2(1)PIB(0.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw09891 | Title: | BGP peers flap continuously |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
BGP peers will flap continuously and not stabilize even after several hours have passed.
Conditions:
Outbound policy with multiple AS Path regex matches that deny the route, coupled with non-default holdtimers (4/12, 10/30).
Workaround:
Change holdtimer to default values. Simplify the regex is possible and match the access-list *after* the prefix list in the route-map sequence.
Further Problem Description:
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 6.2(10)S102 |
|
Known Fixed Releases: * | 7.3(0)RTG(0.71) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur68883 | Title: | RISE: APBR adds on single SVI very slow at large scale |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Adding APBR's belonging to a single SVI takes a long time.
Conditions:
Configuring many APBR's ( > 1,000)
Workaround:
Follow RISE scale guidelines for the release in question. Ensure TCAM usage is within acceptable boundaries.
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 6.2(10)S102 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut94161 | Title: | EEM: Configuration failed with: 0x412c000d validation timed out |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Configuring EEM with syslog as trigger is not accepted in a Nexus 5500/5600/6000
esc-5648-left(config)# event manager applet ntp
esc-5648-left(config-applet)# event syslog pattern "%PFMA-5-MOD_STATUS: Module 1 current-status is MOD_STATUS_ONLINE"
Configuration failed with: 0x412c000d validation timed out
Conditions:
Configuring EEM
Workaround:
Restart of evmc process can be done. Please open a TAC case for this since it needs to be done from the linux prompt.
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.0(3)I2(0.528), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.1(2)N1(0.556), 7.1(2)N1(1), 7.1(2)ZD(0.11), 7.1(2)ZN(0.15) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup39948 | Title: | maximum routes X warning-only starts dropping routes after reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After reload with maximum routes X warning-only devices stops installing routes into routing table saying it has reached the limit configured.
Even after the command stays the same in running config. after reload device ignores warning-only and set the number as actual limit for the routing table.
And you will see following msg says configured limit reached even though the running config will say warning only.
URIB-4-ROUTELIMIT_EXCEEDED urib [5997] (test-base) Number of routes (4) reached or exceeds configured limit (4); dropped (1)
vrf context test
address-family ipv4 unicast
maximum routes 4 warning-only >>>>>>>>>>> warning only
after reload
show routing vrf test internal
SUP state: ACTIVE
Clean Restart: YES
Ksink: PSS URI: volatile:/dev/shm/urib_runtime_pss
Servers ; CLIS: Up ; L3VM: Up ; RPM: Up ; LISP: Down; UFDM: Up ;
Registered; CLIS: Yes ; L3VM: Yes ; RPM: Yes ; LISP: No ; UFDM: Yes ;
SHM Min: 96; Size: 96
MPLS VPN MIB Trap Threshold: disabled by default
debug-filter vrf: default (0x1)
client: all (index 0x0) (mask 0x1)
prefix-list: none
VRF "test" (0x00000003) State: UP (Up) UFDM Enabled: Yes
TIB converged: Yes
Route limit 4, warning limit 100% (4)>>>>>>>>>>>>> set the number as an actual limit
Reinstall at 0% (4), pending: Yes
Last MIB trap 00:05:49 ago; Max reset: No; Warn reset: Yes
Current count 4, added 4, deleted 0, dropped 5
Conditions:
When maximum routes X command configured for a routing table with warning-only option.
Workaround:
putting the same command ?maximum routes X warning-only? again fixes the issue.
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 6.2(2a), 6.2(6a), 7.0(3)I2(0.562) |
|
Known Fixed Releases: * | 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.11), 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(3)I2(0.572), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.1(0)D1(0.189) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv44967 | Title: | Unable to modify access-list using config session |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Unable to modify ACL using config session
Following error is shown
N7K# conf session impulse
Config Session started, Session ID is 1
Enter configuration commands, one per line. End with CNTL/Z.
N7K(config-s)# ip access-list test
N7K(config-s-acl)# permit ip host 1.1.1.1 any
N7K(config-s-acl)# commit
Failed to start Verification: Checkpoint Name already exists
N7K(config-s)#
N7K# conf session test
Config Session started, Session ID is 1
Enter configuration commands, one per line. End with CNTL/Z.
N7K(config-s)# ip access-list test
Maximum number of commands reached
N7K(config-s)#
Conditions:
This problem was observed on 6.2.10 code after using config session for couple of days.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 6.2(10)S92 |
|
Known Fixed Releases: * | 7.3(0)D1(0.87), 7.3(0)OTT(0.37), 7.3(0)SL(0.115), 7.3(0)ZD(0.102) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu78729 | Title: | EIGRP can install non-successor to RIB in case of ECMP paths |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In N7K1 , N7K2 is being installed as a successor for 2001:420:1411::/48 even though it doesn't meet the Dual FC condition.
fe80::224:f7ff:fe19:2e41 metric 19968/19456
fe80::226:98ff:fe0c:6bc1 metric 19968/19712
Conditions:
If there's another path with same metric which passes Dual FC condition and during installation to RIB, the 2 paths are considered to be ECMP
Workaround:
Increase the total metric of the path which fails the FC condition using "ip delay eigrp" or distribute-list command
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 5.2(7) |
|
Known Fixed Releases: * | 6.2(13.11)S0, 7.0(3)I2(0.542), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.2(1)D1(0.51), 7.2(1)N1(0.283), 7.2(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus59622 | Title: | N5K - NS stuck on "ISSU : InProgress" after ISSU completed |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
APBR's from the HA secondary are missing. "Show rise profile" CLI on the MPX shows "ISSU : InProgress", though ISSU has completed.
Conditions:
A RISE vPC direct service is configured with MPX in an HA cluster. "NS mode RISE_APBR" and/or "NS mode RISE_RHI" is disabled on the NetScaler HA primary. One of the two switches in the vPC undergoes ISSU. NS mode RISE_APBR and/or RISE_RHI are then re-enabled on the NetScaler HA primary.
Workaround:
Disable the affected RISE service on N5K, and confirm that the service is torn down on the NetScaler. Then, re-enable the RISE service.
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 7.1(1)N1(0.71) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu35062 | Title: | n7k hsrp error with more than 255 secondary ip on an interface |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
an interface with more than 255 secondary addresses configured will not allow you to configure hsrp ip address. the following error is seen
(config-if-hsrp)# ip x.x.x.x
ERROR: Invalid IP address((Mismatch with IP subnet))
Conditions:
when more than 255 secondary addresses are configured on the interface
Workaround:
use less than 255 secondary addresses per interface
Further Problem Description:
|
|
Last Modified: | 14-SEP-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(12)E1, 6.2(13.3)S0, 6.2(14)FB(0.56), 7.0(3)I2(0.461), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.2(1)D1(0.26), 7.2(1)N1(0.261), 7.2(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud51189 | Title: | HMM support to get all AM adjacencies for the given SVI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 14-SEP-2015 |
|
Known Affected Releases: | 6.2(0)PF(0.82) |
|
Known Fixed Releases: * | 6.2(0)PF(0.105), 7.0(0)BNZ(0.23), 7.0(0)KM(0.37), 8.3(0)CV(0.142) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq23138 | Title: | first collapse of pi71-sjc-l2o-bnb |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
B&B collapse, not applicable
Conditions:
B&B collapse, not applicable
Workaround:
B&B collapse, not applicable
Further Problem Description:
|
|
Last Modified: | 14-SEP-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.228), 7.1(0)N1(0.281), 7.1(0)N1(0.321), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.179), 7.1(0)ZD(0.281) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud31278 | Title: | Wrong o/p for "show vrf vpn detail" on freetown |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Wrong o/p for "show vrf vpn detail"
Conditions:
router configured with vrf vpn
Workaround:
none
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 6.2(0.265)S4, 6.2(0.269)S11, 6.2(0.278)S6 |
|
Known Fixed Releases: * | 6.2(0.293)S0, 6.2(2), 8.3(0)CV(0.144) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum49090 | Title: | vrf_tenant_profile is not being applied |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
vrf_tenant_profile is not being applied
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 7.0(1)FVL(0.25) |
|
Known Fixed Releases: * | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)GI(0.5), 7.0(1)FVL(0.61), 7.1(0)D1(0.55), 7.1(0)PDB(0.13), 7.2(0)D1(1), 8.3(0)CV(0.144) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul67163 | Title: | L3VM core file is truncated |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
L3VM core file is truncated
Conditions:
When L3VM Crashes.
Workaround:
Not known
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 6.0(2)N3(1) |
|
Known Fixed Releases: * | 7.0(0)BNZ(0.23), 7.0(0)FVX(0.66), 7.0(0)N1(0.399), 7.0(0)N1(1), 7.0(0)ZD(0.172), 7.0(0)ZN(0.124), 7.1(0)ARP(0.2), 7.1(0)D1(0.43), 7.2(0)D1(1), 8.3(0)CV(0.144) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu53397 | Title: | [VxLAN EVPN] clear bgp * results in assert failed msgs with Traceback |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Traceback seen-
%BGP-3-ASSERT: bgp-65001 [6952] ../routing-sw/routing/bgp/bgp_util.c:3338: Assertion `def_tbl_ctx->first_bestpath_done' failed.
Conditions:
Shut one of the VRFs and do - clear bgp all * vrf all
No functional impact seen with the traceback.
Workaround:
Issue not seen without vrf shut.
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.484), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(3)I2(0.513), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)PDB(0.57), 7.3(0)RTG(0.66), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut71442 | Title: | "PIM Data Register" debug message missing after receiving data packets |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When the FHR receives the data packets, a data register is sent to the RP. As part of the conformance test, the script expects following debug msg -
2014 Dec 2 00:58:13.070567 mcastfwd: libpim [6339] Sent PIM Data Register for (10.10.2.201, 239.23.23.23) to RP 10.10.10.1, ttl 254 (1 registers in last sec)
But the above debug is not observed on the console
Conditions:
There is no functionality impact here. Only when we enable mcastfwd debugs, we expect the debugs to show up on the console but for some reason the debugs are not showing up on the console.
Workaround:
No workaround. The bug is purely for development purpose.
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475), 7.2(0)D1(0.499), 7.2(1)D1(0.54) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)PDB(0.57), 7.3(0)RTG(0.54) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus87414 | Title: | N7K: ascii replay loses IP SLA / obj tracking config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When applying an existing config to a device via 'copy run', routing statements used in object tracking are not created. The same behavior is seen when the file is copied to either startup, or scheduled-config, and the device is reloaded. 'copy start' , or 'copy schedule' will trigger this on reload.
In the same way we may also lose the vrf membership for the 'ip sla' configuration.
Conditions:
The device has a blank configuration - ie, has just been issued a 'write erase' or minimal configuration
Workaround:
The routes will need to be added manually once the configuration is loaded entirely. If a 'copy run start' is performed the issue will not occur again on the next reload.
Further Problem Description:
|
|
Last Modified: | 23-SEP-2015 |
|
Known Affected Releases: | 6.1(5a), 6.2(10), 6.2(2a), 6.2(8a) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.21), 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.0(0)KMS(0.11), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)SIB(99.109) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup86423 | Title: | MIB: MPLS-LSR-STD-MIB issues found by MPLS xOS automation |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The MPLS-LSR-STD-MIB (mplsLsrStdMIB) content may be erroneous or incomplete
Conditions:
none
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 23-SEP-2015 |
|
Known Affected Releases: | 7.1(0)D1(0.113) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.0(0)KMS(0.11), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)D1(0.487), 7.2(0)D1(1), 7.2(0)N1(0.183) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus40095 | Title: | Memory leak at dual_sia_active |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Memory leak when gone into SIA state.
Conditions:
Under certain topology conditions at high scale when gone into SIA state.
Workaround:
no work around
Further Problem Description:
|
|
Last Modified: | 23-SEP-2015 |
|
Known Affected Releases: | 7.2(0)ZD(0.6) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)IB(120), 7.2(0)D1(0.481), 7.2(0)D1(1), 7.2(0)VZD(0.26) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus45517 | Title: | BGP MED not used with LOCAL AS Neighbors. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
BGP MED not used in path selection for paths with LOCAL AS Neighbors.
Conditions:
Device running NX-OS
Workaround:
configure :
bestpath always-compare-med
Further Problem Description:
Example :
ON NXOS:
--------
sh bgp vpnv4 un 10.4.50.4/30
BGP routing table information for VRF default, address family VPNv4 Unicast
Route Distinguisher: 42961:300
BGP routing table entry for 10.4.50.4/30, version 1223249
Paths: (2 available, best #1)
Flags: (0x000002) on xmit-list, is not in urib
Advertised path-id 1
Path type: internal, path is valid, is best path
AS-Path: NONE, path sourced internal to AS
10.75.39.1 (metric 83) from 10.75.40.1 (10.75.40.1)
Origin incomplete, MED 103, localpref 100, weight 0
Received label 34354
Extcommunity:
RT:42961:42
RT:42961:301
Originator: 10.75.39.180 Cluster list: 0.0.0.100 10.75.39.1
Path type: internal, path is valid, not best reason: NH metric
AS-Path: NONE, path sourced internal to AS
10.75.39.2 (metric 93) from 10.75.40.2 (10.75.40.2)
Origin incomplete, MED 203, localpref 100, weight 0
Received label 156518
Extcommunity:
RT:42961:42
RT:42961:301
Originator: 10.75.39.180 Cluster list: 0.0.0.100 10.75.39.2
Path-id 1 not advertised to any peer
ON IOS:
--------
R1#sh bgp vpnv4 un all 10.10.10.10
BGP routing table entry for 1:1:10.10.10.10/32, version 4
Paths: (2 available, best #2, table A)
Not advertised to any peer
Refresh Epoch 1
Local
2.2.2.2 (metric 156160) from 2.2.2.2 (2.2.2.2)
Origin incomplete, metric 21, localpref 100, valid, internal
Extended Community: RT:1:1
mpls labels in/out nolabel/19
Refresh Epoch 1
Local
3.3.3.3 (metric 15388160) from 3.3.3.3 (3.3.3.3)
Origin incomplete, metric 20, localpref 100, valid, internal, best
Extended Community: RT:1:1
mpls labels in/out nolabel/18
|
|
Last Modified: | 23-SEP-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.0(3)I1(1.211), 7.0(3)I1(2), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)D1(0.473), 7.2(0)D1(1), 7.2(0)N1(1), 7.2(0)PDB(0.408) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo80764 | Title: | N5K - ISSU upgrade to 7.0.1.N1.1 changing config vrf name to unknown |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
upgrade to 7.0.1.N1.1 using ISSU can result in change in config where vrf name would show as unknown.
Conditions:
ISSU upgrade
Workaround:
reload the switch
Further Problem Description:
|
|
Last Modified: | 23-SEP-2015 |
|
Known Affected Releases: | 7.0(1)N1(1), 7.0(3)I2(0.529) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(2)N1(0.552), 7.1(2)N1(1), 7.1(2)ZD(0.8), 7.1(2)ZN(0.11) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut77072 | Title: | N7K-F248XP-25E 6.1(5) link flaps with no cable |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When interface with SFP inserted without any connection or with connection (but the link partner is in disabled state) is now enabled (no shutdown), interface flaps too many times and goes into Error Disabled state or Port goes into False Link up state for a brief period.
F2 interface + SFP <== No cable
F2 interface + SFP <========cable=======> Peer Port disabled
Conditions:
In a very rare case where the link is very noisy.
Workaround:
1. If the port is not physically connected through a cable or the Link partner is disabled, then shutdown the local port also.
2. With the fix of this DDTS, apply a large debounce timer (for ex: 1000ms).
Note that this fix takes effect only when the link debounce timer of port is > 300 ms,
conf t
interface Ethernet4/46
link debounce time 1000 <===
Further Problem Description:
Please note that this fix will help reduce the number of occurrences of this to a great extent along with large debounce timer.
Here is the example log below
=======================
N01CRSRV-3-TEST(config-if)# no sh
2015 Mar 6 12:12:39 N01CRSRV-3-TEST %ETHPORT-5-IF_ADMIN_UP: Interface Ethernet3/14 is admin up .
N01CRSRV-3-TEST(config-if)# 2015 Mar 6 12:12:40 N01CRSRV-3-TEST %ETHPORT-5-SPEED: Interface Ethernet3/14, operational speed changed to 10 Gbps
2015 Mar 6 12:12:40 N01CRSRV-3-TEST %ETHPORT-5-IF_DUPLEX: Interface Ethernet3/14, operational duplex mode changed to Full
2015 Mar 6 12:12:40 N01CRSRV-3-TEST %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface Ethernet3/14, operational Receive Flow Control state changed to off
2015 Mar 6 12:12:40 N01CRSRV-3-TEST %ETHPORT-5-IF_UP: Interface Ethernet3/14 (description:) is up in Layer3
2015 Mar 6 12:12:40 N01CRSRV-3-TEST %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet3/14 (description:) is down (Link failure)
2015 Mar 6 12:12:50 N01CRSRV-3-TEST %ETHPORT-5-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/14 (description:) is down (Error disabled. Reason:Too many link flaps)
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 6.1(5) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.75), 7.2(1)D1(0.13), 7.2(1)ZD(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv51488 | Title: | N77-F348 Linecard misreports reset reason |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
An N77-F348 linecard could unexpectedly reload due to a high-CPU condition. Following the reload, the reset reason may be misreported as a disruptive upgrade:
1) At 709401 usecs after Mon May 18 20:42:50 2015
Reason: Disruptive upgrade
Service: SAP:37185
Version: 6.2(10)
2) At 670422 usecs after Mon May 18 20:42:40 2015
Reason: Unknown
Service:
Version: 6.2(10)
Conditions:
High CPU affecting the System Manager (sysmgr) process, followed by a reload of the linecard
Workaround:
Not known
Further Problem Description:
None known
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.2(1)D1(0.90), 7.2(1)ZD(0.81) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun80488 | Title: * | Ingress CRC/Runts on FEX HIF (N2K-C2232TM-10GE) |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
There are increasing ingress CRC/Runts on FEX disabled Host Interfaces On N2K-C2232TM-10GE
Conditions:
6.1(30 s50, N2K-C2232TM-10GE
Workaround:
NA
Further Problem Description:
NA
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu20867 | Title: | F3 does not check control plane flag to skip RPF check |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:Multicast control traffic is subject to RPF rate-limiters on F2/F3 cards.
Conditions:There is no trigger for this issue. Multicast control packets will be dropped due to RPF check. But should only affect LISP deployments.
Workaround:No workaround
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.484) |
|
Known Fixed Releases: * | 6.2(12)E6, 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.79), 7.1(0)AV(0.81), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)CF(0.11), 7.2(0)D1(0.506), 7.2(0)D1(0.508) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03144 | Title: | OpenSSH: Evaluation of Multiple OpenSSH CVEs for NX-OS |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Cisco Nexus Operation System (NX-OS) includes a version of Open Secure Shell (OpenSSH)
software that is affected by the vulnerabilities identified by the following Common
Vulnerability and Exposures (CVE) IDs:
CVE-2015-5600, CVE-2015-6563, CVE-2015-6564, CVE-2015-5352 and CVE-2015-6565
This bug was opened to address the potential impact on this product.
Conditions:
Device with default configuration.
Workaround:
Not currently available.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at
http://cve.mitre.org/cve/cve.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5600
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6563
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6564
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6565
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5352
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.9/6.9:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:M/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C&version=2.0
CVE ID CVE-2015-5600, CVE-2015-6563, CVE-2015-6564, CVE-2015-6565, CVE-2015-5352 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 6.2(12), 7.3(0)ZN(0.89) |
|
Known Fixed Releases: * | 7.3(0)D1(0.90), 7.3(0)EG(0.3), 7.3(0)IB(0.72), 7.3(0)N1(0.125), 7.3(0)N1(1), 7.3(0)PDB(0.57), 7.3(0)RTG(0.78), 7.3(0)SL(0.115), 7.3(0)ZD(0.105), 7.3(0)ZN(0.114) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtw81451 | Title: | Changing member priority is not reflected properly in PWRED mbackup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
1. set up PWRED with multiple backup.
l2vpn xconnect context foo
member e1/1.1
member pseudowire 100 group blue priority 1
member pseudowire 101 group blue priority 3
member pseudowire 102 group blue priority 5
member pseudowire 103 group blue priority 7
where the pseudowire 100 is the highest priority PW and currently active,
change the configuration such that member pseudowire 102 has priority 0, and it should become the active PW, but it is not.
Conditions:
When set up is PWRED with multiple backup, and trying to change the priority of the PW in the configuration to change the active PW.
Workaround:
There is no work around
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 5.2(0)LV1(0.150) |
|
Known Fixed Releases: * | 15.2(2.9)S, 15.2(4)S, 15.3(0.15)PI21b, 15.3(1.1)T, 7.3(0)IB(0.72), 7.3(0)RTG(0.78), 7.3(0)ZD(0.114), 7.3(0)ZN(0.125) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv61896 | Title: | show mac address-table should not fill up mtm debug logs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
mtm debugs are filled up with mtm_get_pi_entry_from_pd_entry logs for each mac
Conditions:
when show hardware mac address-table X CLI is executed
OR
sh mac address-table hardware-age
Workaround:
none
Further Problem Description:
To RCA mac inconsistency issues like the ones documented in CSCut03392, we need this logging improvement in l2fm.
|
|
Last Modified: | 27-SEP-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(14), 6.2(14)S4, 7.2(1)D1(0.45), 7.2(1)ZD(0.39) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv57578 | Title: | L2FM-M3-IT:VPC Peer link is blocked due to Bridge asurance inconsistency |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | $$IGNORE
Symptom:
PFA the config
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 7.0(0)HSK(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu22117 | Title: | N7k F3 IPv4 FIB misprogramming |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:Route installed by both AM and LISP is in the RIB but not the FIB
Conditions:Route was installed by both AM and LISP, and AM installed before LISP.
Workaround:Clear the host route from the RIB "clear ip route"
More Info:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: * | 6.2(10), 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E1, 6.2(12)E6, 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.59), 7.2(1)D1(0.48), 7.2(1)N1(0.280), 7.2(1)N1(1), 7.2(1)ZD(0.42), 7.2(1)ZN(0.44) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul13180 | Title: | Nexus 7K Crashes in PIM Process Due to mdt_route->refererQ->head |
|
Status: * | Other |
|
Severity: | 4 Minor |
Description: | Symptom:
Nexus 7k may experience a crash in the "PIM" process when trying to access an invalid memory address in software while trying to delete an MVPN route that has an expired timer.
SYSMGR-2-SERVICE_CRASHED Service "pim" (PID 5860) hasn't caught signal 11 (core will be saved).
Conditions:
MVPN is being used, and a route is being deleted in software due to an expired aging timer.
Workaround:
None known.
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 6.1(4a)S20 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtu60214 | Title: | Release-note for traffic loss on restart bgp w/ route-import among vrfs |
|
Status: | Terminated |
|
Severity: | 4 Minor |
Description: * | Symptom:
Traffic loss occurs during BGP restart
Conditions:
When there is mutual route import amongst VRFs, traffic loss can occur when BGP is restarted. This happens because the import in the target VRF happens only after the source VRF's bestpath has run. When there is mutual import between 2 or more VRFs, some VRFs will end up running their bestpath before importing routes from the target VRFs. As a result, imported routes will get
prematurely flushed leading to traffic loss.
Workaround:
None, unless the mutual import can be resolved be reconfiguration.
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 6.0(1), 6.2(1.139)S0 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum77376 | Title: | Need to Supress Pim Message PIM-6-ROUTE_LOOKUP |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
2014 Jan 13 15:08:35 nexus2 PIM-6-ROUTE_LOOKUP pim [5984] Couldn't find PIM route (*, 224.0.0.0/4) in pim_process_mfdm_stats_msg()
2014 Jan 13 15:08:45 nexus2 PIM-4-SYSLOG_SL_MSG_WARNING PIM-6-ROUTE_LOOKUP: message repeated 3 times in last 78 sec
2014 Jan 13 15:09:26 nexus2 PIM-6-ROUTE_LOOKUP pim [5984] Couldn't find PIM route (*, 224.0.0.0/4) in pim_process_mfdm_stats_msg()
Conditions:
When upgraded to 6.2(x) code
Workaround:
reduce the pim logging severity to 4 or 5.
Further Problem Description:
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)DHB(0.31), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.43), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua73297 | Title: | L2MCAST_HW_INSTALL_FAIL with Private VLAN Feature |
|
Status: * | Terminated |
|
Severity: | 4 Minor |
Description: | Symptom:
A Nexus switch may fail to install layer 2 multicast entries into hardware following a reload/module bring up. The following errors are observed:
%L2MCAST-SLOT1-3-L2MCAST_HW_INSTALL_FAIL: Hw install failed for vlan 802 (74, *, *) entry!
%L2MCAST-SLOT9-3-L2MCAST_HW_INSTALL_FAIL: Hw install failed for vlan 806 (74, *, *) entry!
Conditions:
When private-vlan is in use.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 6.1(1), 6.2(1.136)S5, 6.2(10)S89 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut80582 | Title: | logging level spm6 missing after non-ISSU from 6.0.4 to 6.2.10 |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
After upgrade from 6.0(4) to 6.2(10), customer lost the config: 'logging level spm6'
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 13-SEP-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)RTG(0.72) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut12411 | Title: | transceiver power read incorrectly on FEX from 6.1.3 to 6.2.8a |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The "Detail Diagnostics Information" section in CLI "show inter transceiver details" contains incorrectly scaled information.
Conditions:
Transceiver with diagnostic information
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14)FB(0.9), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)CF(0.11), 7.2(0)D1(0.439), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.362), 7.2(0)VOF(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr47838 | Title: | idle-timeout in tacacs-server test has different range |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
idle-timeout in "tacacs-server test" has the range as 0 to 1440, while "tacacs-server host test" has the range as 1 to 1440.
Conditions:
Always.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 7.3(0)IB(0.54) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtu33370 | Title: | Need "show snmp" command in "show tech snmp" in NX-OS |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Need to include the output of "show snmp" command in "show tech snmp" in NX-OS
Symptom:
"sh tech snmp" doesnt include new show commands.
Conditions:
"sh tech snmp" doesnt include new show commands.
Workaround:
Execute different CLIs one by one.
Further Problem Description:
Need to include the output of "show snmp" command in "show tech snmp" in NX-OS
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 4.2(8), 5.2(1) |
|
Known Fixed Releases: * | 7.3(0)IB(0.54) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue35705 | Title: | Getting password prompt even when entering password in copy ftp command |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
When specifying the user password in the copy ftp command, the password prompt is still popped:
nexus# copy ftp://test:test@ftpserver/file bootflash:
Enter vrf (If no input, current vrf 'default' is considered): management
Password: <<<<<<<<<<<
Conditions:
Nexus switch
Workaround:
- Use the "terminal password" command to set the password to be used for the password prompts on this terminal session:
nexus# terminal password test
nexus# copy ftp://test@ftpserver/file bootflash:
Enter vrf (If no input, current vrf 'default' is considered): management
***** Transfer of file Completed Successfully *****
Copy complete, now saving to disk (please wait)...
nexus#
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 5.2(3a), 6.1(2), 6.2(10)S53 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj28897 | Title: | N7k logging level all # does not change logging facility pim or pim6 |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The bug I see is that pim/pim6 do not go to ?6? but stay at their previous values when the ?logging level all 6? command is issued. This is a minor bug.
B16u1-DC1-Agg1-vdc1(config)# logging level all 6
Then via ?show logging?:
Facility Default Severity Current Session Severity
-------- ---------------- ------------------------
pim 5 7
pim6 5 5
Conditions:
B16u1-DC1-Agg1-vdc1(config)# no logging logfile
B16u1-DC1-Agg1-vdc1(config)# clear logging logfile
B16u1-DC1-Agg1-vdc1(config)# logging logfile log 7 size 2000000
B16u1-DC1-Agg1-vdc1(config)# logging level all 6
B16u1-DC1-Agg1-vdc1(config)# logging level sysmgr 1
B16u1-DC1-Agg1-vdc1(config)# clear logging logfile
Workaround:
User can try changing the pim and pim6 levels individually by logging level ip pim <> " and "logging level ipv6 pim "
Further Problem Description:
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)RTG(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo02299 | Title: | Overlay1 Last link flapped timer is flushed after 24 hours |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
In "show interface Overlay1" output , counter "Last link flapped" never goes above 24 hours. It is reseted to 00:00:00 every 24 hours , so it can't be used to access how long interface was UP.
sh int o1
Overlay1 is up
Last link flapped 23:59:59
Last clearing of "show interface" counters 07:45:30
zixu-PE2# sh int o1
Overlay1 is up
Last link flapped 00:00:00
Last clearing of "show interface" counters 07:45:31
Conditions:
Normal operations
Workaround:
None. It' just a cosmetic issue it doesn't affect OTV communications. To check liveliness of OTV connections please use "show otv isis adjacency detail" and check for how long ISIS sessions has been stable.
show otv isis adjacency detail
OTV-IS-IS process: default VPN: Overlay1
OTV-IS-IS adjacency database:
System ID SNPA Level State Hold Time Interface Site-ID
nexus-OTV1 001b.54c2.4242 1 UP 00:00:12 Overlay1 0000.0000.0001
Up/Down transitions: 1, Last transition: 20:23:22 ago <---------------- last transition 20 hours ago
...
nexus-OTV2 001b.54c2.4244 1 UP 00:00:12 Overlay1 0000.0000.0002
Up/Down transitions: 1, Last transition: 20:19:26 ago <---------------- last transition 20 hours ago
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)PDB(0.57), 7.3(0)RTG(0.57) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo45167 | Title: | Multicast v6 Vinci: src type is still named "ngmvpn" not "fabric_mcast" |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
OIF name is listed as ngmvpn instead of fabric_mcast in the show ipv6 mroute output when fabric_mcast process has added the OIF.
Conditions:
All conditions
Workaround:
no workaround
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 7.0(0)FVX(0.114) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)PDB(0.57), 7.3(0)RTG(0.66) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum22663 | Title: | Missing description for parameter under show lisp internal event-history |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
miss description for parameter under show lisp internal event-history
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)PDB(0.57), 7.3(0)RTG(0.66) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCus06608 | Title: | N7K: NETSTACK-3-LOCK_STACK_FULL messages in log |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Nexus 7000 platform running 6.2(10) which is configured with IPv6 addressing might print following messages in the log.
%NETSTACK-3-TSP_LOCK_STACK_FULL: Lock stack full
%NETSTACK-3-LOCK_RELEASE_ORDER: -Traceback: l
ibrsw.so+0xe6d4d librsw.so+0xe6f4e liburib.so+0x1070a liburib.so+0x15ec8 liburib.so+0x1
5f8c liburib.so+0xb021 libu6rib.so+0x8aab libu6rib.so+0x973a 0x8277115 0x8406e2f 0x840a
cbc 0x83f5e28 0x83f9fb4 0x8390*
Conditions:
%NETSTACK-3-LOCK_RELEASE_ORDER: -Traceback: l
ibrsw.so+0xe6d4d librsw.so+0xe6f4e liburib.so+0x1070a liburib.so+0x15ec8 liburib.so+0x1
5f8c liburib.so+0xb021 libu6rib.so+0x8aab libu6rib.so+0x973a 0x8277115 0x8406e2f 0x840a
cbc 0x83f5e28 0x83f9fb4 0x8390*
Workaround:
no operational impact. Messages can be suppressed by changing logging level for netstack temporarily to 2 which would avoid logs from getting filled up with these messages by issuing following command.
logging level netstack 2
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv45421 | Title: | Multicast source address inverted in igmpv3 event-history log message |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Incorrect SRC address in log IGMP event-history message:
#show ip igmp snooping event-history vlan
2015 Jul 15 15:00:48.128938 igmp [1663]: [1676]: SN: <405> Received v3 Group-source-specific query for 239.195.1.3 from 10.21.25.252 on Vlan405 (mrt 1 sec)
2015 Jul 15 15:00:48.128928 igmp [1663]: [1676]: SN: <405> Received a v3 GSS-Query for group 239.195.1.3 (source-count 1) on Vlan405 (mrt 1 sec) src0:225.253.203.91, srcN:225.253.203.91
Conditions:
N7k + IGMPv3 + IGMP snooping
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.50), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto33777 | Title: | No check in vPC for STP pathcost method |
|
Status: | Terminated |
|
Severity: | 5 Cosmetic |
Description: * | Symptom:
The STP cost on vPC peers may differs. This might be result in inconsistency of STP topology
Conditions:
The STP pathcost method (long or short) is currently not checked in vPC global consistency check. If
this parameter is configured in different way on two vPC peers, it could result in different STP path cost
values.
Workaround:
Avoid different configuration of STP pathcost method on vPC peers.
Further Problem Description:
It is recommend to have the same STP pathcost method in the STP domain. Currently the
recommended STP pathcost method is long for environments which using 10GE links in the STP
domain.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.2(6), 5.1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq49889 | Title: | OTV - Interface overlay counters incorrect. |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
counters for the overlay interface shows incorrect values
Stos-OTV1# show int ov 1 | i bits
24224647 bytes 15653205936 bits/sec 2468907 packets/sec <---
Conditions:
noticed running 6.2.8
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: * | 7.3(0)RTG(0.80) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup34431 | Title: | Build breakage for CSCui89702 |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Doing XML code changes for "show routing-context" ,"show privilege" clis
Conditions:
No conditions
Workaround:
no
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 7.0(99.1)ZD |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.228), 7.1(0)N1(0.280), 7.1(0)N1(0.286), 7.1(0)N1(1), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.179), 7.1(0)ZD(0.281) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug64700 | Title: | NX-OS parser: auto-complete functionality for certain QoS commands |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Ability to auto-complete for certain commands
class-map
Symptom:
auto complete of acl names was not happening.
Conditions:
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 5.2(3a) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)PDB(0.57), 7.3(0)RTG(0.64) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo63753 | Title: | "system fabric forwarding vni" command - follow-up fix |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
"system fabric forwarding vni" command - follow-up fix
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 9.9(9.9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum52148 | Title: | Distributed reflective denial-of-service vulnerability on NTP server |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
A vulnerability in Network Time Protocol (NTP) package of Cisco NX-OS Software and Cisco Multilayer Director Switch (MDS) could allow an unauthenticated, remote attacker to cause a Denial of Service (DoS) condition on an affected device.
The vulnerability is due to processing of MODE_PRIVATE (Mode 7) NTP control messages which have a large amplification vector. An attacker could exploit this vulnerability by sending Mode 7 control requests to NTP servers and observing responses amplified up to 5500 times in size. An exploit could allow the attacker to cause a Denial of Service (DoS) condition where the affected NTP server is forced to process and respond with large response data.
Conditions:
This is a day 1 issue and all versions of NX-OS and MDS with support for NTP are vulnerable.
Fixed Software:
This bug will apply to the Cisco Nexus 7000 (N7K), Cisco Nexus 6000 (N6K), Cisco Nexus 5000 (N5K)
and Cisco Multilayer Director Switch (MDS) and the fix is currently targeted for a release towards the end of
CY2015.
Cisco NX-OS Software and Cisco MDS switches are vulnerable to attacks utilizing Mode 7 NTP requests. Mode 7 requests can have amplification vector up to 5500.
To see if a device is configured with NTP, log into the device and issue the CLI command
"show running-config | include ntp". If the output returnseither of the following commands
listed then the device is vulnerable:
ntp master
ntp peer
ntp server
ntp broadcast client
ntp multicast client
The following example identifies a Cisco device that is configured with NTP:
router#show running-config | include ntp
ntp peer 192.168.0.12
The following example identifies a Cisco device that is not configured with NTP:
router#show running-config | include ntp
router#
Information about Cisco NX-OS and MDS Software release naming conventions is available in
''White Paper: Cisco IOS and NX-OS Software Reference Guide'' at the following link:
http://www.cisco.com/web/about/security/intelligence/ios-ref.html
Workaround:
There are no solid workarounds other than disabling NTP on the device via the "no feature ntp" command. The following mitigations have been identified for this vulnerability; only packets destined for any configured IP address on the device can exploit this vulnerability. Transit traffic will not exploit this vulnerability.
Note: NTP peer authentication is not a workaround and is still a vulnerable configuration.
* NTP Access Group
Warning: Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the
sender's IP address, which may defeat access control lists (ACLs) that permit communication to these ports
from trusted IP addresses. Unicast Reverse Path Forwarding (Unicast RPF) should be considered to be used in conjunction to offer a better mitigation solution.
Additionally, "serve-only" keyword added to the NTP access-group will limit the exposure of the server to
only respond to valid queries.
Note: NTP Access Group groups are not supported by the Cisco MDS switch.
For additional information on NTP access control groups, consult the document titled ''Cisco Nexus 7000 Series NX-OS System Management Configuration Guide, Release 4.x'' at the following link:
http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_2/nx-os/system_management/configuration/guide/sm_3ntp.html
* Infrastructure Access Control Lists
Warning: Because the
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 6.0(2), 6.2(9a), 7.2(1)ZN(0.30) |
|
Known Fixed Releases: * | 6.2(13.12)S0, 6.2(14), 7.2(1)D1(0.51), 7.2(1)N1(0.283), 7.2(1)N1(1), 7.2(1)ZD(0.45), 7.2(1)ZN(0.47), 7.2(1)ZN(0.48), 7.3(0)D1(0.107), 7.3(0)D1(0.96) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus92802 | Title: | VPC role election and auto-recovery : sticky bit |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Impact of sticky bit and auto-recovery feature in vpc role decision should be documented for NX-OS platforms.
Conditions:
VPC secondary switch isolated during upgrade or for any other reason, when attached back into vPC domain and after auto-recovery timer expires may cause outage.
Outage occurs as VPC roles change and vPC secondary switch takes over as Operational Primary due to sticky bit set, this leads to vPC legs to go down on Primary switch which changes to vPC operational secondary.
Workaround:
Disable auto-recovery prior upgrade/isolation on both vPC peers. Please note auto-recovery is by default enabled since NX-OS 6.2.x for N7k and 7.x for N5k/6k switches. Please use this command to check for sticky bit and auto-recovery status:
show system internal vpcm info global | i Sticky|Reload
If sticky bit is set (True) on the isolated switch, re-configuring same VPC role priority on this switch under vPC domain potentially unsets (False) the sticky bit.
Only once sticky bit is false attach the isolated switch back in vPC.
Further Problem Description:
NX-OS(config)# show system internal vpcm info global | i Sticky|Reload
Sticky Master: TRUE >>>>> Sticky bit is set
Reload timer started: FALSE
Reload restore configured: TRUE, timer :240 >>> Auto-recovery enabled
NX-OS(config)# show vpc role
vPC Role status
----------------------------------------------------
vPC role : secondary, operational primary
Dual Active Detection Status : 0
vPC system-mac :
vPC system-priority : 32667
vPC local system-mac :
vPC local role-priority : 200
NX-OS(config)# vpc domain 1
NX-OS(config-vpc-domain)# role priority 200
Warning:
!!:: vPCs will be flapped on current primary vPC switch while attempting role change ::!!
Note:
--------:: Change will take effect after user has re-initd the vPC peer-link ::--------
NX-OS(config-vpc-domain)# exit
NX-OS(config)# show system internal vpcm info global | i Sticky|Reload
Sticky Master: FALSE >>>>>>>>>>>>>>>>> Set to False, good now to attach in vPC
Reload timer started: FALSE
Reload restore configured: TRUE, timer :240
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtu21704 | Title: | Config time push |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
%IPQOSMGR-4-QOSMGR_PPF_WARNING log message is seen.
Conditions:
- High VLAN scale
- Configuration push caused by either a port bring up or large scale modification (i.e., ACL programming on multiple ports)
Workaround:
Upgrade to 6.2(x)
Further Problem Description:
This is an enhancement to decrease the amount of time it takes to push changes in configuration. Part of it includes removing PPF from the process.
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 5.0(3.1), 6.1(1)S11, 6.1(3) |
|
Known Fixed Releases: * | 6.2(0.138)S0, 6.2(0.142)S0, 6.2(0.269c)S1, 6.2(0.269c)S2, 6.2(0.29)S0, 6.2(0.298)S0, 6.2(0.82)S0, 6.2(2), 7.0(1)ZD(0.3), 7.0(3)I1(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu96175 | Title: | L2FM/MCEM/CFS need more robust registration & retry infra |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
This is to address possible timeouts between L2FM and CFS under failure condition (CFS crash, control plane congestion) that could cause registration issues between applications.
Conditions:
This may occur under high control plane load.
Workaround:
Perform Supervisor Switchover or reload device
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 6.2(6b) |
|
Known Fixed Releases: | 6.2(13.7)S0, 7.2(1)D1(0.20), 7.2(1)ZD(0.16) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj20960 | Title: | Improve serviceability of show tech xml |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
This bug requests to add these commands in show tech xml:
show xml server internal exec-info all
show xml server internal history errors
show xml server internal history commands
Conditions:
this bug affects software up to 6.2(2)
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 6.2(2) |
|
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.9)S0, 6.2(9)FM(0.73), 7.0(3)I2(0.524), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth56943 | Title: | elam remains armed even after trigger causing packets to hit acl log rl |
|
Status: * | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
When using elam on M! series linecards on Nexus 7000 with the 'rbi-corelate' keyword, after the trigger subsequent packets that match the email will leak to software through the access-list-log hardware rate-limiter.
Conditions:
Workaround:
After troubleshooting is complete be sure to type 'release' before exiting elam applet.
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: * | 4.2(4), 5.0(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut63393 | Title: | Border Leaf needs to advertise hash-len for BSR |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
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:
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 7.2(0.1) |
|
Known Fixed Releases: * | 7.0(0)HSK(0.433), 7.0(0)KM(0.119), 7.0(0)KMS(0.11), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)CF(0.11), 7.2(0)D1(0.473), 7.2(0)N1(0.166), 7.2(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum21014 | Title: | LISP should notify when unsupported hardware in use |
|
Status: * | Terminated |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When using modules on the Nexus 7000 that are not M132 or using M132 modules running EPLD versions less than 186.008 LISP does not work.
Conditions:
Nexus 7000 LISP without M132 or with EPLD version less than 186.008
Workaround:
LISP is only supported on the Nexus 7000 on M132 modules running EPLD versions 186.008 or higher.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 6.2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCup74957 | Title: | Enhancement to Support Type 8 and Type 9 Encoding for Enable Secret NXOS |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:NA
Conditions:Enable secrete is used to temporarily escalate the privilege level of user using enable secret password.
if admin use the CLI command "enable secrete" then he has configure the enable secrete password.
Workaround:
Dont use this enable secret CLI command.
it is not enabled by default also.
More Info:Attacker should have valid user name and password and they should be able login to the box then only this issue can be exploited.
They should get access to the encrypted enable secret password and if they can decrypt this then only this issue can happen.
if admin has enabled the ENABLE SECRET option in the NXOS box and he has configured the password for enable secret, we store then encrypted enable secret password.
Encryption method used here is MD5 which is considered to be week encryption. Hence plan is to support TYPE 8 and TYPE 9 encryption methods.
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: | 7.1(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug55348 | Title: | Enable ability to change syslog destination port |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Needs changes for logging port for syslog.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 06-SEP-2015 |
|
Known Affected Releases: | 5.2(2a), 6.1(2), 6.1(3) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.0(3)I2(0.496), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.15), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.1(0)BF(0.99) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCum47496 | Title: | Invalid Hostname or address for mailhost - SCH message |
|
Status: | Other |
|
Severity: | 6 Enhancement |
Description: | Symptom:
observed that N7K displaying "Invalid hostname or address for mailhost" message when SMTP server sends timeout message.
Conditions:
We were performing callhome test using smtp method.
Workaround:
None.
Further Problem Description:
clear error message has to be displayed for each of the error cases
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq63391 | Title: | clear ip mroute for NXOS routers. |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
No single CLI to clear multicast state information from all multicast components.
Conditions:
The problem that exists with the current implementation may remove the state from MRIB but not essentially from other components which are MRIB clients.
Workaround:
Currently, we may be need to issue all the following CLIs to completely remove the multicast state entries:
1. clear ip igmp group vrf [do this only if you don't need traffic from any sources for this group]
2. clear ip pim route vrf
3. clear ip mroute data-created vrf
4. clear ip mroute vrf
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 4.2(6), 6.2(0.278)S10, 6.2(8) |
|
Known Fixed Releases: * | 7.3(0)BZN(0.47), 7.3(0)D1(0.76), 7.3(0)MMD(0.9), 7.3(0)N1(0.103), 7.3(0)N1(1), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)ZD(0.89), 7.3(0)ZN(0.96) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtu54802 | Title: | Syslog server cannot see origin-id from Nexus 5000 |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
This is an enhancement bug to add a configurable option to make the Nexus 5k to send origin-id to syslog server similar to IOS's command "logging origin-id ?". For example, having this option would allow the Nexus 5K to send syslogs messages with the hostname of the Nexus 5K at the beginning so it would be easy for the network administrator to identify which device the syslog came from.
Conditions:
n/a
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 7.2(0.9) |
|
Known Fixed Releases: * | 7.2(1)N1(0.293), 7.2(1)N1(1), 7.2(1)ZN(0.57), 7.3(0)BZN(0.47), 7.3(0)N1(0.108), 7.3(0)N1(1), 7.3(0)ZN(0.101) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh34065 | Title: | F2E: BFD flap on M/F2E VDC in vpc setup with peer-gateway configured |
|
Status: * | Other |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
BFD neighbor relationship fails to come up when BFD packets need to traverse peer-link. Typically this would be FHRPs as well as any routing protocols that have L3 peering over the peer-link.
Conditions:
All of these have to be present:
1) VPC peer-gateway is enabled
2) BFD echo is enabled
Workaround:
1) Remove VPC peer-gateway
AND/OR
2) Disable BFD echo
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 6.2(1.125)S4 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui15096 | Title: * | MDS :NX-OS does not allow special characters for username |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Unable to use spaces on username for nexus authentication accounts
Conditions:
When using spaces on the usersname like "Cisco user"
Workaround:
Use usernames with no spaces.
More Info:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuh94514 | Title: | N7K FIPS: Integrity test feature |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
FIPS requires a integrity test feature which ensure that the switch is not tampered with. This feature will be designed around the FIPS CLI configs. A hash of the CLI config will be stored and verified with a new generated hash to ensure that the switch's integrity is not tampered.
Conditions:
Workaround:
FIPS requires a integrity test feature which ensure that the switch is not tampered with. This feature will be designed around the FIPS CLI configs. A hash of the CLI config will be stored and verified with a new generated hash to ensure that the switch's integrity is not tampered.
Further Problem Description:
|
|
Last Modified: | 04-SEP-2015 |
|
Known Affected Releases: | 6.2(1.148), 6.2(5) |
|
Known Fixed Releases: | 6.2(0)FPS(0.2), 6.2(0)FPS(0.4), 6.2(0)FPS(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx81322 | Title: | NXOS: "show ip interface" Enhancement To Add Applied ACLs |
|
Status: * | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
The "show ip interface" and "show ipv6 interface" commands do not include applied inbound and outbound ACL's for IPV4 and IPv6 in the CLI or XML tags.
Conditions:
This only occurs when a user expects to see applied ACL inbound and outbound ACL's when using the "show ip interface" or "show ipv6 interface" CLI commands like in Cisco IOS Software.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 6.0(1) |
|
Known Fixed Releases: | 6.2(0.178)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta17153 | Title: | Max password lenhgt should allow 80 characters string |
|
Status: * | Other |
|
Severity: * | 6 Enhancement |
Description: | Symptoms:
User or Administrator can not set a password that is greater than 64 characters.
Conditions:
Systems running an affected version of Cisco Unified Computing System software.
Workaround:
None.
Further Problem Description:
Cisco policy states that Cisco devices should accept passwords from 0 to 80 characters in length.
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via
normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 1.0(0.176a), 1.2(0.88) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun18186 | Title: | ISSU to detect NX-OS compatability during upgrade |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
An impact check or pre-upgrade check between non supported images comes with no warning.
Conditions:
ISSU between non-supported images not meeting compatibility requirements
Workaround:
Release notes should be read carefully before upgrade. Compatibility matrix for ISSU should be followed.
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCsq95595 | Title: | NxOS: clear counters not clearing tunnel interface counters |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: |
"clear counters" command doesn't clears up tunnel interface counters.
switch# show int tunnel 0
Tunnel0 is up
Internet address is 10.0.0.2/24
MTU 1476 bytes
Transport protocol is in VRF "default"
Tunnel protocol/transport GRE/IP
Tunnel source 10.0.0.2, destination 10.0.0.1
Tx
0 packets output, 5 minute output rate 0 packets/sec
Rx
7 packets input, 5 minute input rate 0 packets/sec
switch# clear counters
switch# show int tunnel 0
Tunnel0 is up
Internet address is 10.0.0.2/24
MTU 1476 bytes
Transport protocol is in VRF "default"
Tunnel protocol/transport GRE/IP
Tunnel source 10.0.0.2, destination 10.0.0.1
Tx
0 packets output, 5 minute output rate 0 packets/sec
Rx
7 packets input, 5 minute input rate 0 packets/sec
Under all conditions
There is no workaround.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.0(2.44) |
|
Known Fixed Releases: * | 4.1(1.61), 7.0(0)KM(0.97), 7.1(0)D1(0.283), 7.1(0)OTT(0.39), 7.1(0)PDB(0.235), 8.3(0)CV(0.134) |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论