| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv42949 | Title: | Nexus 7k Crashes due to "isis_otv-default" Process |
|
Status: | Terminated |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
Nexus 7k crashed due to the "isis_otv-default" process multiple times in quick succession. If redundant supervisor engines are installed, both may crash within a short timeframe of one another, leading to a full chassis reset if the switch briefly has no ready active supervisor.
Conditions:
None known. May be caused by OTV depolarization feature, but uncertain at this point.
Workaround:
None known.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.56), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw86978 | Title: | F2E 6.2.(14) upgrade fail %VMM-2-VMM_SERVICE_ERR: VDC1: Service SAP |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
upgrade fail with error message
%$ VDC-1 %$ %VMM-2-VMM_SERVICE_ERR: VDC1: Service SAP Aclmgr SAP
for slot 3 returned error 0x41040069 (Sufficient free entries are
not available in TCAM bank) in if_bind sequence
and interfeces are removed , not shown in show interface though show module status is ok state.
`show module`
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 0 Supervisor Module-2 N7K-SUP2 active *
3 48 1/10 Gbps Ethernet Module N7K-F248XP-25E ok
* this terminal session
`show vdc membership`
Flags : b - breakout port
---------------------------------
vdc_id: 0 vdc_name: XXXXXXXXX interfaces:
vdc_id: 1 vdc_name: XXXXXXXXX interfaces:
*Ethernet3/1 *Ethernet3/2 *Ethernet3/3
*Ethernet3/4 *Ethernet3/5 *Ethernet3/6
*Ethernet3/7 *Ethernet3/8 *Ethernet3/9
*Ethernet3/10 *Ethernet3/11 *Ethernet3/12
*Ethernet3/13 *Ethernet3/14 *Ethernet3/15
*Ethernet3/16 *Ethernet3/17 *Ethernet3/18
*Ethernet3/19 *Ethernet3/20 *Ethernet3/21
*Ethernet3/22 *Ethernet3/23 *Ethernet3/24
*Ethernet3/25 *Ethernet3/26 *Ethernet3/27
*Ethernet3/28 *Ethernet3/29 *Ethernet3/30
*Ethernet3/31 *Ethernet3/32 *Ethernet3/33
*Ethernet3/34 *Ethernet3/35 *Ethernet3/36
*Ethernet3/37 *Ethernet3/38 *Ethernet3/39
*Ethernet3/40 *Ethernet3/41 *Ethernet3/42
*Ethernet3/43 *Ethernet3/44 *Ethernet3/45
*Ethernet3/46 *Ethernet3/47 *Ethernet3/48
Conditions:
F2E module
6.2.(14)
Workaround:
reduce the number of SVI
Further Problem Description:
|
|
Last Modified: | 22-DEC-2015 |
|
Known Affected Releases: | 6.2(8.13), 7.3(0)D1(0.165) |
|
Known Fixed Releases: * | 7.3(0)D1(0.190), 7.3(0)ZD(0.208) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw84708 | Title: | Evaluation of n9k, n3k, mds, n7k and n5k infra for NTP_October_2015 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The following Cisco products:
NEXUS 9000
NEXUS 7000
NEXUS 6000
NEXUS 5000
NEXUS 3000
Cisco MDS
includes a version of ntpd that is affected by the vulnerabilities identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-7691; CVE-2015-7692; CVE-2015-7701; CVE-2015-7702; CVE-2015-7703; CVE-2015-7704; CVE-2015-7705; CVE-2015-7848; CVE-2015-7849; CVE-2015-7850; CVE-2015-7851; CVE-2015-7852; CVE-2015-7853; CVE-2015-7854; CVE-2015-7855; CVE-2015-7871
This product is affected by one of more of the listed CVE ids.
Conditions:
This issue is configuration dependant and applies only when the following command is configured (some platforms enabled by default):
feature ntp
Cisco NX-OS devices are NOT affected by the following vulnerabilities:
* NX-OS does not allows remote configuration via Mode 6/7 commands:
CVE-2015-7848 - Network Time Protocol ntpd multiple integer overflow read access violations
CVE-2015-7849 - Network Time Protocol Trusted Keys Memory Corruption Vulnerability
CVE-2015-7850 - Network Time Protocol Remote Configuration Denial of Service Vulnerability
CVE-2015-7851 - Network Time Protocol ntpd saveconfig Directory Traversal Vulnerability
CVE-2015-7852 - Network Time Protocol ntpq atoascii Memory Corruption Vulnerability
CVE-2015-7854 - Network Time Protocol Password Length Memory Corruption Vulnerability
CVE-2015-7855 - Denial of Service Long Control Packet Message
CVE-2015-7703 - Configuration Directive File Overwrite Vulnerability
* Cisco NX-OS does not support Autokey:
CVE-2015-7691 - Denial of Service AutoKey Malicious Message
CVE-2015-7692 - Denial of Service AutoKey Malicious Message
CVE-2015-7701 - Denial of Service CRYPTO_ASSOC Memory Leak
CVE-2015-7702 - Denial of Service AutoKey Malicious Message
Cisco NX-OS is affected by the following vulnerabilities:
CVE-2015-7704 - Denial of Service by Spoofed Kiss-o'-Death
CVE-2015-7705 - Denial of Service by Priming the Pump
CVE-2015-7871 - NAK to the Future: NTP Symmetric Association Authentication Bypass Vulnerability
Cisco NX-OS may be affected by:
CVE-2015-7853 - Network Time Protocol Reference Clock Memory Corruption Vulnerability
Details for KoD vulnerabilities:
client poll-based association are affected (IE If the device is configured with ntp server x.x.x.x).
When exploited the poll values to request time updates will be changed to 36hours. This prevents a client from synchronizing to any of its preconfigured NTP servers.
Symmetric active mode poll-based associations are NOT affected (IE ntp peer x.x.x.x).
If your device is configured to serve time as an authoritative NTP Server (configured with "ntp master x) then it is not performing polling.
Devices configured to use "ntp broadcast client or ntp multicast client are not affected as they dont do polling.
Workaround:
The following mitigations will help protect from exploitation:
1. If the upstream mgmt0 device supports uRPF then ensure it is configured.
2. For affected platforms that do not support the ntp access-group command, configure an inbound ACL for trusted NTP server addresses to the NTP port (UDP port 123) on mgmt0.
3. On devices configured with ntp server x.x.x.x ensure ntp access-groups are applied to only allow updates from trusted time sources and/or applying NTP Authentication will help mitigate CVE-2015-7704.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 6.4/5.3
http://tools.cisco.com/security/center/cvss
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 7.3(1)XX(0.1) |
|
Known Fixed Releases: * | 6.2(15)S10, 7.0(3)I3(0.191), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.62), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux41744 | Title: | ITD scale of services would result in malloc failed , |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ITD scale of services would result in malloc failed ,
Conditions:
ITD scale of services would result in malloc failed ,
Workaround:
ITD scale of services would result in malloc failed ,
Further Problem Description:
ITD scale of services would result in malloc failed ,
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.169) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.194), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.62), 7.0(3)IDP3(2), 7.3(0)D1(0.185), 7.3(0)ZD(0.203), command |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv44868 | Title: | L2FMC is not in the card config of M3 VMM bind/unbind |
|
Status: * | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VDC pointer not cleared after vdc reload from mtm db
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 04-DEC-2015 |
|
Known Affected Releases: | 7.0(0)HSK(0.475) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu11602 | Title: | M2 linecard reset due to EOBC heartbeat failure |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: * | Symptom:
A M2 linecard may be reset by the supervisor due to EOBC heartbeat being missed by the linecard
Conditions:
1. There should be NO cpu/eobc hog on LC.
2. Upon LC bring up, post_code should be in range 0x00 and 0xf0 only. (sh mod internal act mod shows PWR_MGMT_POST_CODE_REG(0xb) = 0xab)
Workaround:
None known
Further Problem Description:
This was fixed in 6.2(10) via CSCup20959, but the problem is still seen
|
|
Last Modified: | 08-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03713 | Title: | N7K: Layer 2 (L2) packet not dropped on length mismatch |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * |
Symptom:
The Cisco Nexus 7000 (N7K) Ethernet driver fails to properly drop a Layer 2 (L2) frame that should be evaluated as invalid.
The L2 frame will be flooded to all active ports on the associated VLAN due to a failure to match to a known Media Access
Control (MAC) in the Cisco Access Manager (CAM) table. This could allow the attacker to perform a traffic amplification
attack to consume bandwidth on all ports associated with the VLAN of the receiving port.
Conditions:
The N7K chassis contains a F1, F2, F3, M1 or M2 Linecard.
Workaround:
The CAT6K upstream router was configured with the command:
mac-address-table static 0000.0000.xxx vlan <#> drop
OR you can configure ACL on Nexus 7000 as :-
MAC access list DROP_ETHERYTYE0
10 deny any any 0x0
20 permit any any
More Info:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 3.3/3.1:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:U/RC:C&version=2.0
No CVE ID has been assigned to this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 09-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv26663 | Title: | Static mac missing from M card for L3 BD in HW |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
L3 interfaces can not resolve ARP. Packet may get flooded.
HW mac table on LC will not have static mac for L3 BD.
Conditions:
add , delete , add L3 subifs couple times in quick succession (either via script or copy paste on terminal)
Or
add/delete/add any fhrp
Workaround:
Once issue is hit , only way to recover is to reload LC.
However, to avoid hitting the issue you can introduce a "sleep 8" (when doing copy/paste or using script) between adding deleting sub interfaces , when creating new HSRP group on an interface , and when following master hsrp group.
for eg:-
sleep 8
interface po x.y
sleep 8
SNIP
sleep 8
hsrp 123
follow master_group_number
sleep 8
Further Problem Description:
This is a timing issue and is not HW dependent issue.
|
|
Last Modified: | 09-DEC-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(8b) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut98473 | Title: | PortLoopback test fails following EOBC congestion |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After seeing EOBC congestion in some rare circumstances it is possible to starting seeing false Gold port loopback failures
/* example of EOBC congestion */
2015 Apr 13 18:07:43 iad7-ws-dis-r2 %MODULE-4-MOD_WARNING: Module 18 reported
warning due to EOBC heartbeat failure in device DEV_EOBC_MAC (device error 0xc0a09145)
/* example of the false errors */
2015 Apr 13 18:07:43 iad7-ws-dis-r2 %MODULE-4-MOD_WARNING: Module 18 reported warning due to EOBC heartbeat failure in device DEV_EOBC_MAC (device error 0xc0a09145)
Conditions:
Problem occurs after heavy EOBC congestion and link flapping
Workaround:
To recover from the issue you can reload the affected LC
Further Problem Description:
|
|
Last Modified: | 12-DEC-2015 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.37) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw73046 | Title: | Vinci MT-full L2 extension on Borderleaf requires configuration of BDI |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Flood entry missed in the vinci case if there is NO forwarding mode configured which might cause traffic halt.
Conditions:
Unknown traffic drop.
Workaround:
Need to declare the bd as dfa/vinci-capable. This can be done via creation of a bdi with either in ef/tf mode
interface bdi 3101
fabric forwarding mode anycast-gateway
Once this is done, we should be able to see end-to-end traffic with L2.
Further Problem Description:
|
|
Last Modified: | 13-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.169), 7.3(0)D1(0.181), 7.3(0)ZD(0.199) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua67236 | Title: | N7K: stale routing table may remain in rib in case of bfd down |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
stale static route information may remain in RIB when BFD to the
static route goes into down state
Conditions:
After reloading Nexus 7000 series switch, BFD may does not work
properly
Workaround:
Deleting the bfd session using "no ip route static bfd ..." and re-configuring it with "ip route static bfd .." solves the issue
|
|
Last Modified: | 17-DEC-2015 |
|
Known Affected Releases: * | 5.2(4), 6.0(3) |
|
Known Fixed Releases: | 5.2(6.8)S0, 5.2(7), 6.1(1)S21, 6.1(1.20)S0, 6.1(1.42), 6.2(0.217), 6.2(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub24023 | Title: | NXOS: mem leak in SNMPD when polling nonexisting int index OID |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
A memory leak happens when an snmp query is done on a non existing tunnel interface.
Conditions:
The interface index being queried should be using the tunnel interface space, and the
tunnel should not exist.
Workaround:
Only query valid tunnel interfaces.
Further Problem Description:
|
|
Last Modified: | 17-DEC-2015 |
|
Known Affected Releases: | 4.2(8), 6.0(4) |
|
Known Fixed Releases: | 5.0(3)U5(1e), 5.2(7), 5.2(7)S3, 5.2(7.7)S0, 6.1(1)S59, 6.1(1.49)S0, 6.1(2.27), 6.2(0.285), 6.2(2), 7.1(0)RTG(0.50) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut89882 | Title: | NXOS-MPLS-TE:Traffic loss after SUP Failover |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
TE tunnels flap 2 minutes after the 1st switchover.
Conditions:
The issue is present when RSVP graceful restart is configured and head-end TE tunnels are present. The issue occurs only after the 1st failover occurs after the mpls traffic-eng feature is enabled.
Workaround:
As only the first failover triggers the issue, performing a manual switchover after enabling the mpls traffic-eng feature will prevent this issue from being seen subsequently.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)TE(0.6), 7.3(0)TEC(0.1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)GLF(0.25), 7.3(0)OTT(0.17), 7.3(0)PDB(0.102), 7.3(0)SC(0.14), 7.3(0)ZD(0.114), 7.3(0)ZN(0.125) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.392) |
|
Known Fixed Releases: * | 7.3(0)D1(0.99), 7.3(0)FMD(0.9), 7.3(0)IB(0.72), 7.3(0)N1(0.136), 7.3(0)N1(1), 7.3(0)OTT(0.55), 7.3(0)PDB(0.74), 7.3(0)SC(0.14), 7.3(0)ZD(0.113), 7.3(0)ZN(0.124) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw50467 | Title: | F3 module drops to failure state after ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
After ISSU a LC drops to failure state. "sh system reset-reason module" lists the reason as "elo_io hap reset => [Failures < MAX] : powercycle"
Conditions:
ELOAM must be configured and running on the LC while the ISSU occurs.
Workaround:
Remove all ELOAM config before the ISSU and then reapply afterwards.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.112) |
|
Known Fixed Releases: * | 7.3(0)D1(0.122), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw74438 | Title: | N7k L3vm crash during ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
L3vm crash during ISSU
Conditions:
This has been observed on N7k MPLS PE running MVPN during an ISSU to 7.2(0)D1(1)
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)RTG(0.97), 7.3(0)SC(0.14), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur21785 | Title: | N7K - M1/M2 Egress Queuing behavior post 6.2(x) for control plane packet |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Control plane packet ( marked with DSCP value for Example PIM etc ) received on ACCESS port, and then get bridged into same VLAN do not queued in priority Queue on Egress port. The issue is not seen after doing "no ip igmp snooping"
Conditions:
- Nexus 7000 running 6.2(x), 7.2(x) image; Earlier images like 5.2(x) do not see the same condition.
- Packet is coming in ACCESS port and getting bridged into same VLAN via ACCESS or Trunk port.
- M series Line cards
Workaround:
Not available yet
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(14), 6.2(8a), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.38), 7.2(1)D1(1), 7.2(1)N1(0.272), 7.2(1)N1(1), 7.2(1)ZD(0.33), 7.2(1)ZN(0.36), 7.3(0)D1(0.72), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw27044 | Title: | OSPFv3 takes 30 min to install route when using link-local addresses |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When peering a nexus 7k with an ASR9k using OSPFv3 with link-local addresses only, it takes 30 minutes for the ASR9k to install the routes learned from the Nexus 7k. I have tried peering a nexus 7k with another device (i.e 6500 swith) and the result is the same: the 6500 device takes 30 minutes to install the route learned from the nexus 7k.
Conditions:
Customer using layer 3 port-channels but it can happen for all types of interfaces.
Workaround:
Configure regular IPv6 addresses
Further Problem Description:
When peering a nexus 7k with an ASR9k using OSPFv3 with link-local addresses only, it takes 30 minutes for the ASR9k to install the routes learned from the Nexus 7k. I have tried peering a nexus 7k with another device (i.e 6500 swith) and the result is the same: the 6500 device takes 30 minutes to install the route learned from the nexus 7k.
This is day-1 issue with stub area. The link local lsa is not added to DB entries.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(14a)S4, 7.0(3)I2(1.27), 7.0(3)I2(2), 7.2(1)D1(1), 7.2(1)ZD(0.103), 7.2(1)ZN(0.97), 7.2(2)D1(0.2), 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.69) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut25162 | Title: | VPLS VC's don't come after delete/add VFI's in EFP scale setup |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Few VPLS PW's remain down
Conditions:
With L2VPN VFI's scaled, delete all VFIs and Re-add all VFI's.
Workaround:
clear l2vpn service vfi all
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.422), 7.2(0)D1(0.430) |
|
Known Fixed Releases: * | 15.5(1)S0.17, 15.5(1)S1.1, 15.5(1)S2, 15.5(1)S2.1, 15.5(1)S2.15, 15.6(0.16)S, 15.6(0.17)PI30d, 15.6(0.25)T, 15.6(1.1)T, 15.6(1.3)S |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu13792 | Title: | VPC doesn't come up after HMM is enabled |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VPC peer-link comes up
Conditions:
two sides of port-channel mismatch
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)VZN(0.1) |
|
Known Fixed Releases: * | 7.0(0)FHS(0.23), 7.2(0)VZD(0.40), 7.3(0)D1(0.21), 7.3(0)D1(0.33), 7.3(0)DHB(0.2), 7.3(0)HM(0.36), 7.3(0)IB(0.35), 7.3(0)OTT(0.8), 7.3(0)RTG(0.39), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu66415 | Title: | VINCI UI: ethpm receiving an empty vlan list from vlan_mgr |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
vlan_mgr sends notifications to ethpm with empty interest list
Conditions:
happens during bridge-domain create
Workaround:
this has no operational impact
Further Problem Description:
this is an interaction between vlan_mgr and ethpm. the empty list becomes a NOP for ethpm and this has no impact on operation or functionality
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1), 7.2(1)D1(0.80), 7.3(0)D1(0.24) |
|
Known Fixed Releases: * | 7.2(1)D1(0.2), 7.2(1)D1(1), 7.2(1)ZD(0.2), 7.3(0)D1(0.70), 7.3(0)D1(0.71), 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: | CSCuu10618 | Title: | Traffic loss on some vlans after line card reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
after reload there is 100% packet drop on a few vlans
Conditions:
LC reload on scaled setup
Workaround:
clear l2vpn service all
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471), 7.2(0)D1(0.475) |
|
Known Fixed Releases: * | 15.5(1)S1.5, 15.5(1)S2.15, 15.5(1)S2.7, 15.5(1)S3, 15.5(2.20)T, 15.5(2.21)S0.12, 15.5(2.21)S0.5, 15.5(3)S, 15.5(3)S0a, 15.5(3)S1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw25153 | Title: | Traffic loss during HSRP Recovery |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | HSRP is configured on 2 Nexus 7700, one is active and the other one is standby.
When the link on the active one is down, the standby one will take over the role of the active one. However, after the link is up, when the original active one try to take back the role, there will be a traffic loss of more than 1s. This issue occurs once in 30 trials.
Symptom:
HSRP is configured on 2 Nexus 7700, one is active and the other one is standby.
When the link on the active one is down, the standby one will take over the role of the active one. However, after the link is up, when the original active one try to take back the role, there will be a traffic loss of more than 1s. This issue occurs once in 30 trials.
Conditions:
Hsrp sessions over BFD and we need to keep on doing shut and no shut
Workaround:
No workaround is there for the drop. Its random.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(13)S8, 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.3), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZD(0.8), 7.2(2)ZN(0.7), 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)IB(0.95), 7.3(0)SC(0.14), 7.3(0)ZD(0.194) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.484) |
|
Known Fixed Releases: * | 7.2(1)D1(0.51), 7.2(1)D1(1), 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)FMD(0.9), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu53575 | Title: | sh vlan id 1 shows incorrect ports after doing ASCII replay twice |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Any port which is not in mode trunk should not have config for trunk allowed vlan's under it. For exmaple
int po10
switchport
switchport mode fabricpath
switchport trunk allowed vlan 11-20
no shutdown
Conditions:
Only happens when "switchport trunk allowed vlan " is done after the mode is changed to no trunk mode.
Workaround:
Do no switchport trunk allowed vlan in case of fabricpath/pvlan mode as this config is of no use.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.69), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.21), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu11726 | Title: | LIM flush clears non VxLAN macs on the BD affected |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
For silent orphan hosts, we can see traffic drops if traffic reaches other VPC peer.
We can also experience flooding if it reaches the peer containing the silent host.
Conditions:
PeerLink shut, Dismembering VNI from BD, NVE flap
BD should be common for VxLAN and non VxLAN hosts.
Workaround:
ReARP the silent hosts after the flush
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.475), 7.3(0)D1(0.64) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.47), 7.3(0)SC(0.14) |
|
|
| |
| |
|
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: | 19-DEC-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)DX(0.16), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.37), 7.3(0)PDB(0.57), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw21334 | Title: | F3/OTV:packets flooded into BD 0(DI:0xC000) after decapsulation |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic drop over OTV on F3 modules on decapsulation side.
Conditions:
F3 module used for OTV.
SVI configured for OTV extended vlan(could have occurred prior to ISSU).
Workaround:
remove and readd the vlan to otv extended list.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.171), 7.3(0)GLF(0.44), 7.3(0)PDB(0.131), 7.3(0)RTG(0.80), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu69256 | Title: | SSTE: SNMP user mem is increasing continuously polling from 3 stations |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
High memory usage shown by snmpd process.
Conditions:With higher scale (768 ports, 700+ BGP sessions, 10K multicast approximately), we are doing getBulk from 3 NMS stations.. Over four days and seeing snmpd mem usage
Workaround:As of now no crash has been seen as some of the memory held is freed so there is no need of workaround as of now.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.28), 7.2(1)D1(1), 7.2(1)N1(0.263), 7.2(1)N1(1), 7.2(1)ZD(0.23), 7.2(1)ZN(0.27), 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.24), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw81299 | Title: | OAM session not coming up with F3-M2 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ELOAM sessions do not come up on M2 linecards. Further, sessions may be incorrectly detected as miswired.
Conditions:
ELOAM is configured on interfaces on an M2 linecard.
Workaround:
None, but ELOAM works fine on F3 cards.
Further Problem Description:
The problem occurs because metadata attached to received packets is incorrect, making it look as if ELOAMPDU packets were received on a different interface to that which they actually came in on.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.127), 7.3(0.99) |
|
Known Fixed Releases: * | 7.3(0)D1(0.135), 7.3(0)D1(0.138), 7.3(0)D1(0.142), 7.3(0)D1(0.146), 7.3(0)GLF(0.25), 7.3(0)IB(0.122), 7.3(0)N1(0.195), 7.3(0)N1(1), 7.3(0)OTT(0.73), 7.3(0)PDB(0.102) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.44), 7.2(1)D1(1), 7.2(1)ZD(0.38), 7.3(0)D1(0.126), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu77709 | Title: | LISP: map-caches entries to non-routable RLOCs are installed in fwd |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A LISP map-cache entry on a xTR lists a group of locators as being in state "up" even while the routing table does not have an entry to reach them. They should be listed in state "no-route".
These locators are pushed down to the forwarding table and flows that match this forwarding entry are blackholed.
Conditions:
The main condition to see this problem is that the setup has a "split" RLOC view, i.e. the eTR registering the lisp database entry is able to see the RLOCs while the iTR is not.
From there the following needs to happen simultaneously to face this problem:
(1) Multiple map-cache entries in the xTR have the same locator set
(2) Some of the RLOCs in this locator set are permanently unreachable (no routing entry in RIB) from iTR
Workaround:
Enabling RLOC probing, which will complement the information from the routing table.
"lisp loc-reach-algorithm rloc-probing"
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.17), 7.2(1)D1(1), 7.2(1)N1(0.248), 7.2(1)N1(1), 7.2(1)ZD(0.13), 7.2(1)ZN(0.14), 7.3(0)D1(0.72), 7.3(0)DHB(0.31), 7.3(0)EG(0.3), 7.3(0)MMD(0.9) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 7.1(0)N1 |
|
Known Fixed Releases: * | 7.2(1)D1(0.7), 7.2(1)D1(1), 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)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)N1(1) |
|
|
| |
| |
|
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: | 19-DEC-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: | CSCuw61079 | Title: | Tenant multicast encap route missing in FIB on border leaf |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
vxlan encap is not happening because vxlan encap route is missing from mfdm/mfib, eg.
show forwarding distribution nve multicast route.
Conditions:
With vxlan configured - "feature nv overlay". If config "feature otv" then "no feature otv", vxlan encap routes will be deleted.
Workaround:
We don't support otv and vxlan configured in the same vdc. If by accident someone configured otv then unconfigured it, workaround will be unconfig vxlan - "no feature nv overlay". Then reconfigure it and the corresponding nve interface(s).
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.111) |
|
Known Fixed Releases: * | 7.3(0)D1(0.145), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)SC(0.14), 7.3(0)ZD(0.162) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus98516 | Title: | Rollback should not be disruptive to unrelated FP VLANs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Rollback should not be disruptive to unrelated FP VLANs
Conditions:
FP vlans
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.70), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 7.0(7)ZN(0.215) |
|
Known Fixed Releases: * | 7.1(3)N1(0.647), 7.1(3)N1(1), 7.1(3)ZN(0.55), 7.3(0)D1(0.112), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)IB(0.90), 7.3(0)IZN(0.7), 7.3(0)N1(0.150), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw10915 | Title: | MPLS ldp sync disappears after interface flap |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | MPLS ldp sync disappears after interface flap
Symptom:
MPLS ldp sync disappears after interface flap
Conditions:
MPLS ldp sync is enabled and interface is configured as ISIS level-2-only
Workaround:
Configure interface as ISIS level-1-2 or level-1.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.102), 7.2(1)D1(1), 7.2(1)N1(0.323), 7.2(1)N1(1), 7.2(1)ZD(0.92), 7.2(1)ZN(0.85), 7.3(0)D1(0.171), 7.3(0)GLF(0.44), 7.3(0)N1(1), 7.3(0)PDB(0.131) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw64042 | Title: | EIGRP process crash after LC reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
EIGRP process crash after LC reload
Conditions:
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)ZD(0.133) |
|
Known Fixed Releases: * | 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)IB(0.121), 7.3(0)SC(0.14), 7.3(0)ZD(0.194), 7.3(0)ZN(0.210) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv95316 | Title: | Pixmc core being observed after insert new sup or reload chassis |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
after upgraded code, insert new sup or reload chassis generated PIXMC core
Conditions:
insert new sup or reload chassis
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(14), 6.2(14)S25, 7.3(0)D1(0.79) |
|
Known Fixed Releases: * | 7.3(0)D1(0.126), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.71), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw13282 | Title: | LTL missing FPC pc on removing and adding vsi |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | During deletion of the BD, PIXM will update the FPC CBL/BD state as DISABLE/EXCLUD
So when STP comes for BD 100 to put FWD state PIXM will send request to PIXMC as
part of SET_VLAN_CBL trigger LTL will be programmed correctly
Symptom:
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(1A) |
|
Known Fixed Releases: * | 7.3(0)D1(0.94), 7.3(0)D1(1A), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)IB(0.72), 7.3(0)OTT(0.55), 7.3(0)RTG(0.78), 7.3(0)SC(0.14), 7.3(0)ZD(0.108) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw82347 | Title: | PIM Assert Storm on pair of N6Ks with Egress VPC and ECMP in L3 Core |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
PIM Assert Storm between pair of Nexus 6000s in a VPC Pair with Egress VPC and ECMP on the L3 Core.
Both vPC peer elected as forwarder for a particular source over L3 core.
Conditions:
There was an EIGRP SIA event that caused both Switches to loose the ECMP Next Hop RPF to the RP and the Source of the traffic.
Workaround:
Restart the PIM Process on one of the Nexus 6Ks.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)RTG(0.113), 7.3(0)SC(0.14), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut17793 | Title: | SSTE:Traffic loss observed after flapp mpls interf with 7.2(0)D1(0.422) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Few VPLS PWs are down
Conditions:
Flap MPLS interface used by PWs
Workaround:
clear l2vpn service all
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.422), 7.2(0)D1(0.484) |
|
Known Fixed Releases: * | 15.5(1)S1.5, 15.5(1)S2.15, 15.5(1)S2.7, 15.5(1)S3, 15.6(0.16)S, 15.6(0.17)PI30d, 15.6(0.25)T, 15.6(1.1)T, 15.6(1.3)S, 15.6(1.9)T0.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup56162 | Title: | Anycast HSRP custom VMAC not programmed after hsrp restart |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Anycast HSRP with custom VMAC is not programmed at L2FM as gateway after HSRP process stateful restart.
Conditions:
Anycast HSRP is configured with non-default VMAC and HSRP engine process is restarted.
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.6), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut18721 | Title: | gbr_422: urib core at urib_chlist_segv_handler |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
urib crashes and since it is not restartable, the crash will result in reload of the switch in single SUP scenario or will result in SSO when dual SUP is present.
Conditions:
Inter VRF case where routes in one VRF are pointing to next hops in different VRF.
Workaround:
no workaround
Further Problem Description:
This issue mainly happens when routes are being flapped in large scale by BGP due to multiple restart or some other reasons or repeated execution of "clear ip route *".
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.422), 7.2(0)D1(0.444) |
|
Known Fixed Releases: * | 6.2(10)E8, 6.2(12)E1, 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.28), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)SIB(99.109), 7.1(2)N1(0.571), 7.1(2)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur00089 | Title: | vdc-admin on N7K can break out of vsh-"chroot" using symbolic links |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco Nexus devices running Cisco NX-OS software contain a symbolic link vulnerability that could allow a local, authenticated attacker to break out of the chroot environment that their Virtual Device Context (VDC)
has been assigned. This could result in the attacker gaining the ability to write files to locations that should be restricted to the context to which they belong. This could also have an extended impact of allowing the
attacker to read data that should be restricted.
Conditions:
Cisco Nexus devices running an affected version of Cisco NX-OS Software
Workaround:
None.
Further Problem Description:
Credit:
Cisco would like to thank Jens Krabbenhoeft for reporting this vulnerability.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 3.2/2.6:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:P/I:P/A:N/E:F/RL:OF/RC:C&version=2.0
No CVE ID has been assigned to this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(13.4)S0, 6.2(14), 6.2(14)FB(0.74), 7.2(1)D1(0.30), 7.2(1)D1(1), 7.2(1)ZD(0.25), 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.17) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw90876 | Title: | %ETHPORT-5-IF_SEQ_ERROR: Error ("IFTMC PD commit db search failed"). |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After enabling cts role-based enforcement on a vlan, bounce of any interface in that vlan will cause it to become errdisabled due to "IFTMC PD commit db search failed" error.
Conditions:
cts enabled, role-based policies downloaded, and role-based enforcement enabled on vlan.
Workaround:
disable role-based enforcement on vlan
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.3), 7.2(2)ZD(0.8), 7.3(0)D1(0.162), 7.3(0)GLF(0.44), 7.3(0)PDB(0.105), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw51463 | Title: | HSK: %SYSMGR-2-SERVICE_CRASHED: Service "vpc_config_sync" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
config-sync service crashes
Conditions:
when lacp mode is configured differently on vpc peer switch for the same physical vpc and config-sync is enabled.
Workaround:
Disable config-sync before make lacp mode changes.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.105), 7.3(0)D1(0.111) |
|
Known Fixed Releases: * | 7.3(0)D1(0.173), 7.3(0)D1(0.175), 7.3(0)GLF(0.44), 7.3(0)PDB(0.125), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw92095 | Title: | NXAPI: json "show monitor session" destination interfaces incomplete |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
some destination interfaces are missing from JSON format output of the "show monitor session" command in the NXAPI Sandbox
Conditions:
On Nexus 6004 running version 7.2(0)N1(1) or 7.2(1)N1(1), using the "show monitor session all" command in the NX-API SandBox, with JSON output format, not all the destinations will appear in the output but the last one.
Workaround:
Request the response in XML format.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)N1(1), 7.2(1)N1(0.9) |
|
Known Fixed Releases: * | 7.3(0)D1(0.175), 7.3(0)GLF(0.44), 7.3(0)N1(0.229), 7.3(0)N1(1), 7.3(0)SC(0.14), 7.3(0)ZN(0.206) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw12778 | Title: | TE tun setup issues with ISIS due to incorrect Out I/f on ABR4 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In some ISIS topologies with interarea support, some TE tunnels may fail to be set up and may be stuck waiting for RSVP signalling due to an ABR sending the PATH message over the wrong interface. This can be verified using the "show mpls traffic-eng tunnels internal" command and looking for the OutIf field under RSVP Signalling Info, or by checking the output of "show ip rsvp neighbor". In both cases, the outgoing interface to the expanded next hop will be wrong.
Conditions:
The conditions for this bug to occur are rather arbitrary, but it happens on ISIS ABRs that are a DIS in more than one area.
Workaround(s):
Sometimes restarting the mpls_te process resolves this issue.
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)OTT(0.40), 7.3(0.31) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)GLF(0.25), 7.3(0)OTT(0.43), 7.3(0)PDB(0.102), 7.3(0)SC(0.14), 7.3(0)ZD(0.155), 7.3(0)ZN(0.170) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 5.1(4), 6.2(12) |
|
Known Fixed Releases: * | 7.0(3)I2(1.24), 7.0(3)I2(2), 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.66), 7.3(0)SC(0.14), 8.3(0)CV(0.196) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw65271 | Title: | OAM session goes down after applying trunk allowed vlan |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
ELOAM sessions do not come up on sessions with an allowed VLAN configured.
Also, ELOAM sessions do not come up on ports which are blocked by STP. A side effect of this is that when an interface is first configured as a switchport, it can take around 1 minute before the ELOAM session comes up.
Conditions:
Any switchport interface running Ethernet Link OAM can be affected if STP blocks that port, or if the interface has "switchport trunk allowed vlan " config.
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.96) |
|
Known Fixed Releases: * | 7.3(0)D1(0.135), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.102), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux41397 | Title: | PVLAN crashed for clearing configs using default interface on fex |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
PVLAN crashed for clearing configs using default interface on fex
Conditions:
PVLAN crashed for clearing configs using default interface on fex
Workaround:
PVLAN crashed for clearing configs using default interface on fex
Further Problem Description:
PVLAN crashed for clearing configs using default interface on fex
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.169) |
|
Known Fixed Releases: * | 7.3(0)D1(0.175), 7.3(0)GLF(0.44), 7.3(0)SC(0.14), 7.3(0)ZD(0.191) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux38877 | Title: | "private-vlan mapping" needs tobe blocked at fex interface ports |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
"private-vlan mapping? needs tobe blocked at fex interface ports
Conditions:
"private-vlan mapping? needs tobe blocked at fex interface ports
Workaround:
"private-vlan mapping? needs tobe blocked at fex interface ports
Further Problem Description:
"private-vlan mapping? needs tobe blocked at fex interface ports
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.169) |
|
Known Fixed Releases: * | 7.3(0)D1(0.179), 7.3(0)PDB(0.130), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu45553 | Title: | bfd crash seen with bfd_mts_flush_all_bfdc_msgs decodes |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BFD core seen
Conditions:
During copy config to run config
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: * | 7.3(0)D1(0.89), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.78), 7.3(0)SC(0.14), 7.3(0)SL(0.115), 7.3(0)ZD(0.104) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux02206 | Title: | Underlay mcast route is not programmed on peer-link inst after LC reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In vpc+vxlan F&L configuration, underlay multicast traffic from core may get dropped at forwarder. This is due to that derlay multicast route in core facing vrf is not programmed in peer-link instance.
Conditions:
Multicast route programmed in underlay core facing vpn has multiple instances, including peer-link. The vpn instance is affected by the LC reload - deleted and added back again
Workaround:
clear the affected route by "clear ip mroute x.x.x.x" will fix the issue.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.125) |
|
Known Fixed Releases: * | 7.3(0)D1(0.125), 7.3(0)D1(0.142), 7.3(0)D1(0.149), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)RTG(0.115), 7.3(0)ZD(0.167) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu33340 | Title: | Param-list is not cleaned up when the vrf are gone |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
param-list entries still showing in "show run" even when all profiles have been un-applied
Conditions:
Auto-Configuration has been used to apply profiles and profiles have subsequently been un-applied (either manually or due to host aging).
Workaround:
User can remove param-list entries manually by doing "no param-list ..."
Further Problem Description:
The param-list entries do not cause a problem with subsequent profile applies.
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.484), 7.2(0)VZD(0.33) |
|
Known Fixed Releases: * | 7.3(0)D1(0.179), 7.3(0)SC(0.14), 7.3(0)ZD(0.195) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux62222 | Title: | Line card reloads upon seeing bad index-directed frames |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
All Line card in chassis reloads
Conditions:
when bad frames come in from SUP side due to packet buffer memory corruption on SUP side
Workaround:
TBD
Further Problem Description:
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh10793 | Title: | OTV AS : ARP response from site are installed in local OTV cache |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Mac flap will be seen on the downstream aggregation device for remote macs.
The remote mac incorrectly point to non AED OTV VDC.
Non AED is incorrectly decapsulating the packets.
Conditions:
Unicast OTV setup with 3 OTV sites.
Workaround:
Disable arp nd cache on all 3 OTV sites
Further Problem Description:
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 6.2(1.111)S6 |
|
Known Fixed Releases: | 6.2(1.150)S0, 6.2(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz59354 | Title: | cNTP ACL Does Not Continue Processing After Matching Deny Entry |
|
Status: | Fixed |
|
Severity: * | 2 Severe |
Description: | Symptom:
When an NTP ACL is configured for "peer", "serve", "serve-only", or "query-only" and a deny ACE is matched, the other NTP options are not checked.
For example:
ntp access-list peer 10
ntp access-list serve 11
ip access-list 10 permit host 192.168.1.1 any
ip access-list 10 deny ip any any
ip access-list 11 permit host 172.16.1.1 any
If the host matching ACL 11, 172.16.1.1, sends an NTP message it will be blocked by the "peer" ACL. However, it should be permitted by the "serve" ACL, but it is not.
Conditions:
Multiple NTP ACLs configured.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 5.2(4), 6.1(3)S5, 6.1(3)S6, 6.2(1.121)S0, 7.3(0)ZN(0.161) |
|
Known Fixed Releases: | 6.1(2.30)S0, 6.1(4.97)S0, 6.1(5), 6.1(5.32)S0, 6.2(0.285), 6.2(1.149)S0, 6.2(2), 7.0(0)ZD(0.84), 7.0(1)ZD(0.3), 7.0(3)I2(0.315) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw95078 | Title: | M2 VLAN Translation Missing after Module Reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic loss for VLAN translated flows crossing M2 module after recent module reload or possible link flap on M2 module ports with VLAN mapping configured.
Conditions:
Noticed on M2 module, symptoms do not match other M2 VLAN translation defects, seen after module reload.
Workaround:
Only current know workaround is to rebuild the port-channel configuration (delete port-channel, default member interfaces, reconfigure).
Further Problem Description:
Example of missing translations in hardware:
interface Ethernet3/7
switchport
switchport mode trunk
switchport vlan mapping 499 500
switchport trunk allowed vlan 190-200,500
mtu 9216
channel-group 3 mode active
no shutdown
module-3# show system internal eltmc info interface ethernet 3/7 vdc 4 | no
ELTM Detailed info for Interface Ethernet3/7
vlan_xlt_tlb_en_egress : 1 vlan_xlt_tlb_en_ingress: 1
num_vlan_xlt_entries : 2
num_m2_ingress_vlan_xlt_entries : 0
num_m2_egress_vlan_xlt_entries : 0
Vlan Translation Table
--------------------------------
dir tbl_idx in_vlan xlt_vlan <---- Missing translations
Correct table would show:
Vlan Translation Table
--------------------------------
dir tbl_idx in_vlan xlt_vlan
IG 0 499 500
EG 0 500 499
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 6.2(14), 6.2(8b), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(14)E1, 7.2(2)D1(0.3), 7.2(2)ZD(0.1), 7.3(0)D1(0.162), 7.3(0)GLF(0.44), 7.3(0)PDB(0.103), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq22841 | Title: | M1 Module: Invalid COS (0x41040021) after ISSU from 5.2(x) to 6.2(x) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Ports are not allocated to a secondary VDC with the following logs:
2014 Jul 24 16:14:26.864 N7K %IM-3-IM_RESP_ERROR: Component MTS_SAP_VMM opcode:MTS_OPC_IM_IF_VDC_BIND in vdc:2 returned error:Invalid COS value.
2014 Jul 24 16:14:35.568 N7K last message repeated 1 time
2014 Jul 24 16:14:35.568 N7K %VDC_MGR-3-VDC_ERROR: vdc_mgr: Error for port Ethernet . Port is currently in vdc N7K-VDC2 [2]. GIM returned 41040021 [Invalid COS value.]. Please run the command "allocate interface Ethernet force" to try again
In 'show vdc membership status' we see the following as the reason for the ports not being allocated: 'ERROR:Invalid COS value. (0x41040021)'.
Conditions:
- ISSU from 5.2(x) to 6.2(x)
- M1 Module
- A queuing policy which has a wred configured to the queues. Some of the queues should not have COS mapped to the Q.
Workaround:
Map the COS to all the queues in the queuing config.
Reload the module.
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.2(8a), 6.2(8a)S3 |
|
Known Fixed Releases: * | 6.2(14), 6.2(14)S24, 6.2(14.3)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv71201 | Title: | Evaluation of n7k-infra for OpenSSL June and July 2015 Vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
This product includes a version of OpenSSL that is affected by the vulnerability identified by the
Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-8176
CVE-2015-1788
CVE-2015-1789
CVE-2015-1790
CVE-2015-1792
CVE-2015-1791
CVE-2015-4000
All previous versions of Cisco NX-OS on Multilayer Directory Switch (MDS) includes a version of the OpenSSL protocol which is vulnerable.
Conditions:
For Cisco NX-OS and MDS any feature that leverages SSL/TLS may be affected.
Workaround:
None.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 7.8/6.4
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/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 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: | 23-DEC-2015 |
|
Known Affected Releases: | 5.2(8g), 5.2(9), 6.2(1), 6.2(11), 6.2(12), 6.2(13), 6.2(2), 7.3(0)ZD(0.60) |
|
Known Fixed Releases: * | 6.2(15)S3, 6.2(15)S4, 7.3(0)BZN(0.47), 7.3(0)D1(0.73), 7.3(0)D1(0.74), 7.3(0)EG(0.3), 7.3(0)IB(0.67), 7.3(0)MMD(0.9), 7.3(0)N1(0.101), 7.3(0)N1(0.135) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus18893 | Title: | Crash due to a Kernel Panic at mts_sys_my_node_addr_get |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus device crashed due to a kernel panic. This can be determined by the outputs 'show system reset-reason' command:
----- reset reason for Supervisor-module 5 (from Supervisor in slot 5) ---
1) At 505949 usecs after Fri Dec 12 06:00:59 2014
Reason: Kernel Panic
Service:
Version: 6.2(2a)
The output of the `show logging onboard module 5 stack-trace` command displays functions from several CPUs. Usually the top CPU in the output is the one that had the issue. The following functions saw the issue in this case:
Logging time: Fri Dec 12 06:00:10 2014
1418382010:126475629 process sysinfo (7268), jiffies 0x13c4b55df
Oops
REGISTERS:
CPU: 8 Process: sysinfo (pid 7268) Tainted: P W
RIP: 0010:[] mts_sys_my_node_addr_get+0x36/0xa0 [klm_mts]
RSP: 0000:ffff88042c12dbd8 EFLAGS: 00010286
RAX: 0000000000000501 RBX: ffff880431030000 RCX: 0000000000000001
RDX: 00000000335edb01 RSI: 000000000000431c RDI: ffffffffa2cf93c0
RBP: ffff88042c12dbe8 R08: ffff88042c069b28 R09: 0000000000000002
R10: 000000022c12dc28 R11: 0000000000000000 R12: 00000000e7410020
R13: 0000000080044d1e R14: ffff880431030000 R15: 00000000e7410020
CALL TRACE:
CPU 8 Process: sysinfo (7268)
[] mts_sys_my_node_addr_get+0x36/0xa0 [klm_mts]
[] mts_syscall+0x419/0x8b0 [klm_mts] (64)
[] mts_compat_ioctl+0x7b/0x2890 [klm_mts] (736)
[] compat_sys_ioctl+0xfb/0x28e (112)
[] ia32_syscall_done+0x0/0x5 (131927355826352)
Conditions:
There is no particular events leading to this crash. This is an extremely rare case.
Workaround:
None Known. Will reload on single sup, switchover on dual sup.
Further Problem Description:
The Linux kernel detected the address in R12 (0x00000000e7410020) to be invalid. Instead of handling it gracefully, it caused an crash. Because it was a stack address, the chance of this address being invalid is almost zero.
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.2(2a), 6.2(8a) |
|
Known Fixed Releases: * | 6.1(2)I3(3.81), 6.1(2)I3(4), 6.2(10)E5, 6.2(12), 6.2(12)S14, 6.2(12.4)S0, 6.2(8)E10, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(3)I1(0.209) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw62175 | Title: | F3 - MTM FE Timer Expired after Gross Interrupt Threshold Exceeded |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
F3 card may reload due to an XBAR diagnostic failure
`show system reset-reason module 1`
*************** module reset reason (1) *************
Time stamp : At 109484 usecs after Tue Oct 13 04:18:18 2015
Service name : Xbar manager
Reset reason : Runtime diagnostic failure => [Failures < MAX] : powercycle
Serial number: JAExxxxxxxxx
Error code : NA
Conditions:
F3 card on 6.2(x) code. May be seen after supervisor switchover.
Workaround:
None, card will reload and come back online
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 7.3(0)D1(0.136), 7.3(0)GLF(0.25), 7.3(0)IB(0.122), 7.3(0)OTT(0.73), 7.3(0)RTG(0.115), 7.3(0)SC(0.14), 7.3(0)ZD(0.150) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus74176 | Title: | boot loop w/ 'no logging logfile' in config w/ power outage/reload VDC3 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
core dump generated in boot loop when sudden power outage such as unplug power cord. soft reload worked fine. issue can be recreated with reload VDC 3
Conditions:
suddenly lost power when the command 'no logging logfile' is in the configuration
Workaround:
Remove 'no logging logfile' from the configuration
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.2(10), 7.2(0)D1(0.430) |
|
Known Fixed Releases: * | /bin/sh:, 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.40), 7.0(3)I3(0.177), 7.0(3)I3(1), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), 7.1(0)AV(0.74), 7.1(0)ES(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux50293 | Title: | t2: gre/v6 tunnel in nondefault vrf stuck in source ip not reachable |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Tunnel source configured as interface does not pick up the ipv6 address configured on source interface properly.
Conditions:
1. Tunnel mode gre ipv6
2. Tunnel source interface has to be configured
2. Tunnel use-vrf & tunnel source interface vrf has to be different by the time ipv6 address is being configured on the tunnel source interface
Workaround:
Workaround(s):
Multiple workarounds but Make sure tunnel source interface and tunnel use-vrf are in same vrf.
1. Remove & configure back the ipv6 address on the tunnel source interface.
2. Remove tunnel source & configure back
Further Problem Description:
|
|
Last Modified: | 27-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.178) |
|
Known Fixed Releases: * | 7.0(3)I3(0.183), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux54153 | Title: | Deletion of prefix-list seq doesn't trigger OSPF external LSA deletion |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Deleting a Seq in prefix-list used in Route-map (used in redistribution) doesn't trigger to delete External LSA in OSPF
Initial Config:
router ospf 2
vrf tenant-VJ
redistribute bgp 2 route-map vj
N9372-42# show route-map vj
route-map vj, deny, sequence 5
Match clauses:
ip address prefix-lists: vj
Set clauses:
route-map vj, permit, sequence 10
Match clauses:
route-type: internal
Set clauses:
N9372-42#
N9372-42# sh ip prefix-list vj
ip prefix-list vj: 3 entries
seq 3 deny 10.166.6.13/32
seq 5 permit 164.0.0.0/8 eq 32
seq 15 permit 10.0.0.0/8 eq 32
N9372-42#
N9372-42# sh run | in vj <------------------Prefix-list
ip prefix-list vj seq 3 deny 10.166.6.13/32
ip prefix-list vj seq 5 permit 164.0.0.0/8 eq 32
ip prefix-list vj seq 15 permit 10.0.0.0/8 eq 32
N9372-42# show ip os database external vrf tenant-VJ
OSPF Router with ID (164.1.0.42) (Process ID 2 VRF tenant-VJ)
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.166.6.13 164.1.0.42 1083 0x80000116 0xb222 3489660930 <------------LSA generated based on the route-map filter
Conditions:
Repro:
N9372-42(config)# no ip prefix-list vj seq 3 deny 10.166.6.13/32 <-----------Deleting the seq 3 on the prefix-list
tputs:
N9372-42(config)# show ip os database external vrf tenant-VJ
OSPF Router with ID (164.1.0.42) (Process ID 2 VRF tenant-VJ)
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.166.6.13 164.1.0.42 1206 0x80000116 0xb222 3489660930 <-----------The External LSA still in the DB
N9372-42(config)
N9372-42(config)# show ip prefix-list vj
ip prefix-list vj: 2 entries
seq 5 permit 164.0.0.0/8 eq 32
seq 15 permit 10.0.0.0/8 eq 32
N9372-42(config)#
Workaround:
N9372-42(config)# router ospf 2
N9372-42(config-router)# vrf tenant-VJ
N9372-42(config-router-vrf)# no redistribute bgp 2 route-map vj <-----------Work-around to this issue
Further Problem Description:
The actual problem is the VPN BGP redistribution. When OSPF redistributes the BGP routes. it expects the Extended Community Attributes to be present and from OSPF. In this case, the source route is from connected/local and ECA is added for that routes. When OSPF sees the routes with ECA and not originated by the OSPF, it treats and normal redistribution.
While flushing it treats as VPN redistribution and missed to flush as normal redistribution. Thus the LSA remains in the database.
|
|
Last Modified: | 27-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(2) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.204), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.54), command, convert_version.pl:, found, not |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux38940 | Title: | M132 Vlan Translation in Shared Mode Is Only Supported in Egress |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Ingres VLAN Translation on Nexus 7000 not working
Conditions:
Nexus 7000
M132 Module
Attempting to perform ingress VLAN Translation
ASIC is configured in shared mode
Workaround:
Configure the ASIC In dedicated mode. For more information on this please refer to the following configuration guide:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/nx-os/interfaces/configuration/guide/b-Cisco-Nexus-7000-Series-NX-OS-Interfaces-Configuration-Guide-Book/configuring-basic-interface-parameters.html#concept_18991F83452E437FA897F8559ADD420B
Further Problem Description:
|
|
Last Modified: | 04-DEC-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw74054 | Title: | Traffic outage issue on switch reload - multicast scale testbed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Under scale conditions, when the neighboring router is rebooting, it is possible that PIM and MRIB routes go out of sync and hence possible black holing of traffic for some receivers.
Conditions:
Under scale (like 25k-32k routes) conditions and the neighbor router is coming up after a cold reboot.
Under these conditions, PIM module does not update MRIB module about the correct OIF states.
"show ip pim oif-list" and "show ip mroute" will show different set of outgoing interfaces. This bug is due to incorrect processing of txlist used by PIM to update MRIB module.
Although this bug is rarely under less scale, it is still possible to get into this condition.
Workaround:
Use "clear ip mroute" command to clear out the problematic routes will fix the issue.
Further Problem Description:
|
|
Last Modified: | 04-DEC-2015 |
|
Known Affected Releases: | 7.2(1)D1(1), 7.3(0.149) |
|
Known Fixed Releases: * | 7.3(0)N1(0.228), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux23763 | Title: | EEM_POLICY_DIR: device crash while executing Phyton script |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
EEM configured with multiple polices, for same events results in eem_policy_dir crash during long run(Approx 2-3 days)
Conditions:
Customer had configured two EEM policies with same event and policy was triggered frequently. This issue occurred in long run
Workaround:
No workaround, must be fixed. This is due common resource being freed and added by two different threads.
Further Problem Description:
|
|
Last Modified: | 05-DEC-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.97) |
|
Known Fixed Releases: * | 7.3(0)D1(0.172), 7.3(0)N1(0.226), 7.3(0)N1(1), 7.3(0)PDB(0.131), 7.3(0)ZD(0.187), 7.3(0)ZN(0.203) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul45084 | Title: | netstack crash when do show ip int brief include-secondary |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:Executing 'show ip int brief include-secondary' might crash the Netstack service or make Netstack unstable.
'show ip int brief ' has no issues.
or show ip interface bried include-secondary vrf when 'ip forward' is enabled on an interface.
Conditions:This symptom might been seen when using 'ip unnumbered' interfaces, such as Multicast Tunnel Interfaces.
This is also seen when we have 'ip forward' configuration on the interface.
Workaround:There is no workaround except for avoiding the command when having 'ip unnumbered' interfaces.
More Info:
|
|
Last Modified: | 07-DEC-2015 |
|
Known Affected Releases: | 5.2(3a), 6.2(2), 6.2(5)BF(0.58) |
|
Known Fixed Releases: * | 6.0(2)U3(0.644), 6.0(2)U3(1), 6.2(0)HS(0.10), 6.2(5)BF(0.64), 6.2(5.66)S0, 6.2(6), 7.0(3)I2(2.18), 7.0(3)I2(2a), 7.0(3)I2(3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh81332 | Title: | N7k stays off after shutting down from insufficent power |
|
Status: * | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
N7k is offline after power supply issues and does not power up. Red LED on each module and sup will be flashing, but it will stay powered off and nothing will be on the console.
Conditions:
The supplied power to the switch drops low enough where the switch loses power, but there are still power supplies functioning and supplying power insufficient to run the switch. In this case the N7k will not reboot. It will shutdown and stay off.
Workaround:
Turn off all PSU and then turn on all PSU
Re seat the supervisor
Further Problem Description:
This does not happen until the supplied power drops well below the Actual Draw power.
The Allocated power values have no relation to this bug, and Total allocated power only affects the amount of modules that stay in a pwr-denied state if there is not enough power to turn them on after a reboot.
|
|
Last Modified: | 08-DEC-2015 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux45270 | Title: | n7k:snmp host configuration fails with valid host name on n7k |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
snmp host configuration fails with valid host name on n7k
Conditions:
config
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 08-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.169) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw31706 | Title: | logging server removed upon downgrade from Camden to I3(4b) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Post downgrade from camden to lower versions, logging server config is removed.
Conditions:
Downgrade from camden CCO to lower versions like Bronte/Ashfield
Workaround:
Re-configure logging server
Further Problem Description:
|
|
Last Modified: | 12-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.34), 7.0(3)I2(2), 8.3(0)CV(0.248) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut26394 | Title: | M148 vPC secondly drop packet |
|
Status: * | Other |
|
Severity: * | 3 Moderate |
Description: | Symptom:
when the vPC secondly configure as L2 ports , specific destination IP forwarding fail on M148 module.
Conditions:
when add the vlan information to vPC secondry :see the setting change logs
Workaround:
change the the dest dest IP ;VIP to SVI actual IP
Further Problem Description:
|
|
Last Modified: | 14-DEC-2015 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub49964 | Title: | The default route inject route table when next hop unreachable |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * |
Symptom: Configured Pinned Static Route remains in routing table eventhough the pinned interface is down
Conditions:
i) Let's suppose there is a pinned static route to x.x.x.x/y via a pinned interface and next hop z.z.z.z and let the pinned interface be up. This route will be there in URIB.
ip route x.x.x.x/y z.z.z.z
ii) If the user configures another pinned static route to the same x.x.x.x/y via another pinned interface and next hop a.a.a.a, but with a tag value of 100 and if the pinned interface in this case be down, then the route is not installed in URIB as is the expected behavior.
ip route x.x.x.x/y a.a.a.a tag 100
iii) If the user now configures the same pinned static route in ii) but without a tag value this time, then the route gets added to URIB eventhough the pinned interface is down
ip route x.x.x.x/y a.a.a.a
Workaround: Use clear ip route command
|
|
Last Modified: | 17-DEC-2015 |
|
Known Affected Releases: | 5.2(4.57) |
|
Known Fixed Releases: | 5.2(1)N1(7.121), 5.2(1)N1(8), 5.2(7), 5.2(7)S5, 5.2(7)S8, 5.2(7.12)S0, 5.2(7.8)S0, 6.0(2)A1(1), 6.0(2)N1(1), 6.0(2)U1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus45372 | Title: * | Enable advance debugs root cause DCOS_SSHD/VSH Hung Sessions(CSCuu61774) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The customer sees a build up of DCOS_SSHD/VSH process pairs when using DCNM. TheSSHD process is not terminating due to VSH even with the exec-timeout configured (with and without).
Conditions:
DCNM is used and that does SSH connections to the N7K.
Workaround:
The following is a possible workaround:
Each time the customer opens a remote SSH session to the N7K configure a new timeout value (non-default) on that
terminal using the command "terminal session-timeout ".
Otherwise the command "no feature sshd" has to be issued and SSH reconfigured. This will clear for a period of time. In the case of a customer which continuously hits this condition we can configure a periodic EEM script (chron job) to disable and reconfigure SSH to clear the hung sessions.
Further Problem Description:
This fix is to help troubleshoot the build up of dcos_ssh/vsh processes. This fix does not resolve the root issue.
|
|
Last Modified: | 18-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.17), 6.2(14)FB(0.54) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw37945 | Title: | HSK:UDLD should check FEX HIF and report error |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
udld feature is not supported on fex port
Conditions:
Issue is seen only on fex ports
Workaround:
Further Problem Description:
udld feature is not supported on fex port
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.98) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.80), 7.3(0)SC(0.14) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.20), 7.3(0)SC(0.14), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv42487 | Title: | show tech-support fcoe needs to contain all pertinent FC information |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:Enhance show tech-support fcoe so that it includes all FC pertinent information. This should be similar to the MDS show tech-support details
Conditions:Applicable to the Nexus 7000 switch in the FCoE storage VDC.
Workaround:Use individual show tech-support commands. For example:
show tech-support zone
show tech-support fcns
show tech-support fcdomain
show tech-support port
etc...
More Info:None.
Resolution Summary:
show tech-support fcoe will now contain a large amount of information specifically for troubleshooting FCoE related problems. It will include fcoe-manager and other FC/FCoE related show techs.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.148), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)N1(0.197), 7.3(0)N1(1), 7.3(0)PDB(0.112), 7.3(0)RTG(0.115), 7.3(0)SC(0.14), 7.3(0)ZD(0.165), 7.3(0)ZD(0.174) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut10399 | Title: | MAC address flooding on F3 linecard |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Brief flooding is noticed when vPC leg, on which the mac-address is learnt, is shut.
Conditions:
1. Happens only on F3 modules.
2. The mac-address is learnt only on one leg of vPC due to polarized flow.
Workaround:
No work around- default behavior.
Further Problem Description:
Per original design, when vPC leg is shut, the mac-address aging logic purges the mac-address if it was learnt only on that vPC leg causing a temporary flooding till the mac-address is learnt on the other vPC leg.
This fix provides a configuration knob ?mac address-table aging-mode portchannel-refresh? to prevent the temporary flooding. Rather the MAC would wait for a full age cycle across all the members before it would get purged.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12), 7.3(0)D1(0.64) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.27), 6.2(14)FB(0.29), 6.2(14)FB(0.30), 7.3(0)D1(0.162), 7.3(0)GLF(0.44), 7.3(0)PDB(0.93), 7.3(0)SC(0.14) |
|
|
| |
| |
|
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: | 19-DEC-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: | CSCuw30197 | Title: | ELOAM not registering for changes to port-channel members |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ELOAM will not run on interfaces which are members of port channels.
Conditions:
If ELOAM is configured on an interface which is made a member of a port channel, the sessions will go down and will not come back up.
The ELOAM config CLI does not appear under port-channel members, so ELOAM cannot be configured on such interfaces.
Workaround:
None. EOAM cannot run on members of a port-channel.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.39) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.74), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus66235 | Title: | Match Statements within route-map do not function as AND for table-map |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Match statements in a single sequence of route-map are supposed to behave like AND. It is not happening when 'match ip next-hop' or 'match interface' is present in the sequence. The behaviour is fine with any other combination of match statements.
Conditions:
In a route-map, when 'match ip next-hop' or 'match interface' statement is used in combination with other match statements. This is not behaving as AND. The final result is TRUE if 'match ip next-hop' or 'match interface' turns out to be true and even if the other match statements are evaluated to FALSE.
route-map OSPF-FILTER1 permit 10
match interface Ethernet5/39.321
match metric 20 <-- final result is TRUE even if this match statement is FALSE.
Workaround:
Add another sequence in a 'deny' statements for the other match statements.
route-map OSPF-FILTER1 permit 10
match interface Ethernet5/39.321
match metric 20
route-map OSPF-FILTER1 deny 20
match metric 10 < we can add unwanted attribute values for deny here.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.57), 7.2(1)D1(0.29), 7.2(1)D1(1), 7.2(1)N1(0.264), 7.2(1)N1(1), 7.2(1)ZD(0.24), 7.2(1)ZN(0.28), 7.3(0)D1(0.143) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 5.2(7) |
|
Known Fixed Releases: * | 6.2(13.11)S0, 6.2(14), 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)D1(1) |
|
|
| |
| |
|
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: | 19-DEC-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: | CSCux09020 | Title: | NSSA intern router originate default not ASBR post ISSU 6.2.8a to 6.2.12 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
OSPF ASBR capability of N7K router originating default in NSSA area becomes disabled following ISSU upgrade from 6.2.8a to 6.2.12 or from 6.2.12 to 6.2.14. Default route may not be installed on OSPF neighbour routers in NSSA area.
Conditions:
ISSU upgrade from 6.2.8a to 6.2.12 or from 6.2.12 to 6.2.14.
Workaround:
Restart OSPF process with 'restart ospf ' CLI command
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12), 6.2(14) |
|
Known Fixed Releases: * | 7.0(3)I3(0.162), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)IB(0.120), 7.3(0)SC(0.14), 7.3(0)ZD(0.194), 7.3(0)ZN(0.210) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv04106 | Title: | need "MAINTENANCE" as (special) reset-reason for GIR |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
while in Maintenance Mode, if the switch reloads because of any reason that is not part of handful that are covered under mmode today ,it should come back up in Maintenance mode.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.180), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.33), 7.3(0)D1(0.160), 7.3(0)GLF(0.44), 7.3(0)IB(0.122), 7.3(0)PDB(0.121), 7.3(0)RTG(0.115) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu01234 | Title: | OTV, next hop pointing to wrong AED - OTV Part |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
-> Host in vlan 257 points to wrong AED.
Conditions:
-> This behaviour is observed in Image: n7000-s1-dk9.6.2.10.bin
Workaround:
-> Avoid VLAN-mapping from ODD???> to EVEN vlans (257 -> 534).
EVEN???>ODD mapping works fine, as the ACTIVE AED is N7k2 (100 -> 101).
In the real life, it may not be feasible to implement.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)DHB(0.31), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.37), 7.3(0)SC(0.14), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut46889 | Title: | OV intf stuck at "Cleanup in Progress" when bouncing overlay interface |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
OV intf stuck at "Cleanup in Progress" when bouncing overlay interface.
Conditions:
Bring down and bring up link on overlay interface of secondary/backup adjacency server.
Workaround:
Reload VDC (after the problem occurs).
To prevent this issue we need to make sure no IPv6 addresses are present on the join interfaces of all device connecting the unicast core on that overlay. This will prevent the secondary AS device to be stuck in the "Cleanup In Progress" state.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S28 |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)EG(0.3), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.47), 7.3(0)SC(0.14), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw35258 | Title: | Memory leak observed in elo_io process during LC ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
The elo_io process leaks memory when receiving a packet from an unexpected interface.
Conditions:
Whenever a packet on an unexpected interface is received the elo_io process will leak a small amount of memory.
Workaround:
None, but unless the elo_io process receives a high volume of packets it is not expecting, the actual impact is likely to be low.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.96) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.74), 7.3(0)SC(0.14) |
|
|
| |
| |
|
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: | 19-DEC-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)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.66) |
|
|
| |
| |
|
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: | 19-DEC-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.2(1)D1(1), 7.2(1)ZD(0.103), 7.2(1)ZN(0.97), 7.2(2)D1(0.2), 7.3(0)D1(0.143), 7.3(0)GLF(0.43) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw37373 | Title: | Python: Script with stdin, input, raw_input does not show the message |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
when executing a script that accepts input value from the keyboard, with the message "what is your name" (or any other message) It doesn't give me the message to enter the input.
Conditions:
NA
Workaround:
use "term len 0"
Further Problem Description:
From python mode it works fine
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)N1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.178), 7.3(0)IB(0.97), 7.3(0)SC(0.14), 7.3(0)ZD(0.194), 7.3(0)ZN(0.210) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu70539 | Title: | N5K bgp process crash after configuring default-originate |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N5K BGP process crash caused hap reset.
Conditions:
Configure "default-originate route-map |
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.0(5)N1(1) |
|
Known Fixed Releases: * | 7.0(3)I2(0.470), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.0(7)N1(0.73), 7.0(7)N1(1), 7.0(7)ZN(0.154), 7.1(2)N1(0.576), 7.1(2)N1(1), 7.1(2)ZD(0.27) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu79263 | Title: | ISIS_MTS_SYSMGR: Leaks seen after ND ISSU from IPMR1->JJ226 in5548P |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ISSU on N5k is causing a (small) memory leak
Conditions:
Workaround(s):
Workaround:
No workaround known
Further Problem Description:
This is a small leak, a single message that is left from the image from where the ISSU starts
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)N1(0.226) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.59), 7.3(0)SC(0.14) |
|
|
| |
| |
|
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: | 19-DEC-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)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.21), 7.3(0)SC(0.14), 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: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 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)EG(0.3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv06177 | Title: | copy run to sftp on linux server fails |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
copy run sftp: fails for non-root users as it always uses root directory(/) as target. copy bootflash: sftp: works perfectly as it always uses /var/home/
Conditions:
++SFTP service should be running on Linux/Unix
++Non root credentials should be used.
Workaround:
Specify the complete path
switch# copy bootflash:test sftp:
Enter vrf (If no input, current vrf 'default' is considered): management
Enter hostname for the sftp server: /home/kmuruga2/test^C
switch# copy running-config sftp:
Enter destination filename: [switch-running-config] /home/kmuruga2/test
Enter vrf (If no input, current vrf 'default' is considered): management
Enter hostname for the sftp server: 173.36.137.136
Enter username: kmuruga2
Password:
Connected to 173.36.137.136.
sftp> put /var/tmp/vsh/switch-running-config //home/kmuruga2/test
Uploading /var/tmp/vsh/switch-running-config to //home/kmuruga2/test
/var/tmp/vsh/switch-running-config 100% 3134 3.1KB/s 00:00
sftp> exit
Copy complete.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(13.11)S0, 6.2(14), 7.2(1)D1(0.50), 7.2(1)D1(1), 7.2(1)ZD(0.45), 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.33), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv80499 | Title: | BGP flapping with same AS-PATH ACL matched in two or more route-map seqs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Multiple BGP sessions fail to establish after link flap on route refresh on N7K. The sessions cycle between Idle/Active/Closing
Conditions:
This is seen when N7K have outbound policy route-map matching the same as-path ACL in two or more sequences of the same route-map.
Some of the peers are sending upwards of 50K prefixes and in the same update-group as other peers sending 10 to 100 prefixes.
Link flap to one or some of the peers or route refresh(clear ip bgp * soft) is the trigger. This is mostly seen when aggressive timer is configured for multiple neighbors.
Workaround:
Match the as-path once in the route-map and use other attributes to match the prefixes in other sequences. Relax the bgp timers to accommodate the CPU spike due to the regex processing.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S102, 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.163), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.2(1)D1(0.78), 7.2(1)D1(1), 7.2(1)N1(0.306), 7.2(1)N1(1), 7.2(1)ZD(0.70) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut18591 | Title: | tshark: Segmentation Violation with IP Protocol 89 Capture Filter |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Ethanalyzer crashes with the following reason:
tshark: Child dump cap process died: Segmentation violation
Conditions:
Unknown at this time
Workaround:
None.
Further Problem Description:
Issue was due to overflow issue in memcpy.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)D1(0.144), 7.3(0)D1(0.162), 7.3(0)GLF(0.25), 7.3(0)IB(0.122), 7.3(0)OTT(0.73), 7.3(0)PDB(0.89), 7.3(0)PDB(0.93), 7.3(0)RTG(0.115), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv55905 | Title: | Can configure ntp server <name> use-vrf w/o name server configuration. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Can configure ntp server use-vrf without name server configuration.
Conditions:
- use-vrf traffic should lookup name server of "vrf context"
- can configure ntp server use-vrf without resolve domai name.
when system doesn't have dns configuration, nx-os should decline to configure "ntp server use-vrf "
- and ntp will lookup name server of default vrf when ntp server is configured and sync time.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.86), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur57084 | Title: | FEX Core Fails to Upload in Non-default VDC - No Workaround on NPE Image |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Nexus 2000 may fail to copy the core file to the Nexus 7000 during a crash but continues to try over and over:
N7k-2 SYSMGR-FEX101-3-CORE_OP_FAILED Core operation failed: send_msg_to_ccdmon: Could not send to CORE_DMON return -1 errno 32
N7k-2 SYSMGR-FEX101-5-SUBPROC_TERMINATED "System Manager (core-client)" (PID 1903) has finished with error code SYSMGR_EXITCODE_CORE_CLIENT_ERR (11).
Conditions:
When the Nexus 2000 connected to a non-default VDC crashes.
Workaround:
Contact Cisco TAC.
Further Problem Description:
Fix is present starting in 7.2. Issue exists in all releases prior to 7.2.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)FHS(0.23), 7.0(0)HSK(0.395), 7.0(0)KM(0.119), 7.0(0)KMS(0.11), 7.0(2)FIP(0.19), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.1(0)IB(122), 7.1(0)SIB(99.109) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw61767 | Title: | eloam_bugfix/32 BnB commit into hsk_bundle |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | This DDTS was used to release CSCuw54273 and CSCuw56149. See the release notes for those.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.120) |
|
Known Fixed Releases: * | 7.3(0)D1(0.126), 7.3(0)GLF(0.25), 7.3(0)IB(0.122), 7.3(0)IZN(0.7), 7.3(0)N1(0.166), 7.3(0)N1(1), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)RTG(0.115), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw57347 | Title: | IS reachability TLV not suppressed while extended reachability TLV is |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LSPs do not contain TLV 22 under certain conditions - which is the correct behaviour - but TLV 2 is still advertised. This contradicts the intention of not advertising TLV 22.
Conditions:
IS-IS must be run with "metric-style transition", otherwise no TLV 2 is generated
Workaround:
No workaround known. The advice is to not use "metric-style transition" unless it is really necessary.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.121), 7.3(0.121) |
|
Known Fixed Releases: * | 6.2(14)E1, 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)RTG(0.90), 7.3(0)SC(0.14), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw56149 | Title: | ELOAM should identify interfaces of rx packets based on VQI |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: |
Symptom:
ELOAM does not come up on interfaces which are members of a port-channel. In particular, the sessions on such interfaces will not process any packets sent to them.
Conditions:
Any interface which is configured with both "ethernet oam" and "channel-group will be affected.
Workaround:
None. Either remove ethernet oam or remove the interface from the port-channel.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0.99) |
|
Known Fixed Releases: * | 7.3(0)D1(0.126), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut84064 | Title: | Duplicate traffic on FEXAA HIFPC while ST to AA conversion after ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Duplication of traffic is seen on traffic egressing on FEXAA HIFPC after doing below steps
1. VPC peers were running CCO images which doesnt support FEXAA
2. FEXes were in ST mode in that image
3. Did ISSU to GBR image and then converted it to AA mode
4. Configured the FEX AA HIFPC on both the vpc peers and then the duplication was seen
Root cause looks like the vsl bit was not programmed correctly on the fabric vpc.
Refer the Mailthread enclosure for more details.
Conditions:
ST to AA conversion
Workaround:
deconfig and reconfig the hif-pc
Further Problem Description:
Duplication of traffic is seen on traffic egressing on FEXAA HIFPC after doing below steps
1. VPC peers were running CCO images which doesnt support FEXAA
2. FEXes were in ST mode in that image
3. Did ISSU to GBR image and then converted it to AA mode
4. Configured the FEX AA HIFPC on both the vpc peers and then the duplication was seen
Root cause looks like the vsl bit was not programmed correctly on the fabric vpc.
Refer the Mailthread enclosure for more details.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.471) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.47), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv40977 | Title: | Tunnel flap after applying config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Existing tunnel flaps when applying config
It seems the tunnel is flapping after applying a config to an existing tunnel that is up. Here is some info that might help:
This is the tunnel state before applying config:
14:57:15.638: Name: nxosA_t1000 (tunnel-te1000) Destination: 192.168.0.4^M
14:57:15.638: Status:^M
14:57:15.648: Admin: up Oper: up Path: valid Signalling: connected^M
14:57:15.648: path option 10, type explicit lsp0 (Basis for Setup, path weight 80)^M
14:57:15.648: path option 20, type explicit lsp1^M
14:57:15.648: ^M
14:57:15.648: Config Parameters:^M
14:57:15.648: Bandwidth: 1000 kbps (Global) Priority: 7 7 Affinity: 0x0/0xffff^M
14:57:15.658: Metric Type: TE (interface)^M
14:57:15.658: AutoRoute: enabled LockDown: disabled ^M
14:57:15.658: auto-bw: disabled^M
14:57:15.658: Active Path Option Parameters:^M
14:57:15.658: State: explicit path option 10 is active^M
14:57:15.658: BandwidthOverride: disabled LockDown: disabled Verbatim: disabled^M
14:57:15.669: ^M
14:57:15.669: ^M
14:57:15.669: InLabel : - ^M
14:57:15.669: OutLabel : Ethernet2/1, 20^M
14:57:15.669: RSVP Signalling Info:^M
14:57:15.669: Src 192.168.0.1, Dst 192.168.0.4, Tun_Id 1000, Tun_Instance 5^M
14:57:15.669: RSVP Path Info:^M
14:57:15.669: My Address: 192.168.0.1 ^M
14:57:15.669: Explicit Route: 10.10.10.2 14.14.14.2 14.14.14.4 192.168.0.4 ^M
14:57:15.679: Record Route: NONE^M
14:57:15.679: Tspec: ave rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits^M
14:57:15.679: RSVP Resv Info:^M
14:57:15.679: Record Route: 10.10.10.2 14.14.14.4 ^M
14:57:15.679: Fspec: ave rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits^M
14:57:15.679: Shortest Unconstrained Path Info:^M
14:57:15.679: Path Weight: 80 (TE)^M
14:57:15.679: Explicit Route: 13.13.13.1 13.13.13.3 16.16.16.3 16.16.16.4 ^M
14:57:15.689: 192.168.0.4 ^M
14:57:15.689: History:^M
14:57:15.689: Tunnel:^M
14:57:15.689: Time since created: 1 minutes, 2 seconds^M
14:57:15.689: Time since path change: 11 seconds^M
14:57:15.689: Number of LSP IDs (Tun_Instances) used: 5^M
14:57:15.689: Current LSP:^M
14:57:15.689: Uptime: 14 seconds^M
14:57:15.689: Selection: reoptimization^M
14:57:15.689: Prior LSP:^M
14:57:15.689: ID: path option 20 [3]^M
14:57:15.699: Removal Trigger: reoptimization completed^M
Applying config here (Same as the config that was already applied except added path-option 5):
14:57:16.052: ^MnxosA(config)# <[LF]>mpls traffic-eng configuration^M^M
14:57:16.395: ^MnxosA(config-te)# explicit-path name lsp0<[LF]>^M^M
14:57:16.739: ^MnxosA(config-te-expl-path)# <[LF]>index 10 next-address strict 10.10.10.2^M^M
14:57:17.082: ^MnxosA(config-te-expl-path)# index 20 next-address strict 14.14.14.4<[LF]>^M^M
14:57:17.455: ^MnxosA(config-te-expl-path)# mpls traffic-eng confi<[LF]>guration^M^M
14:57:17.789: ^MnxosA(config-te)# <[LF]>explicit-path name lsp1^M^M
14:57:18.152: ^MnxosA(config-te-expl-path)# index 10 next-address strict 11.11.11.2<[LF]>^M^M
14:57:18.516: ^MnxosA(config-te-exp
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)TE(0.9) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)GLF(0.25), 7.3(0)OTT(0.21), 7.3(0)PDB(0.102), 7.3(0)SC(0.14), 7.3(0)ZD(0.114), 7.3(0)ZN(0.125) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu30252 | Title: | N7K:aclmgr: cmd_dynamic_string_add bad item |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:Access-list is completely not removed after executing the command
no ip access-list [name]
The command will be accepted but if you do
"show ip access-list ? " then you still will be able to see that deleted access-list name
Conditions:Observed in 6.2.12 code
Workaround:None.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12)E5 |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.23), 7.3(0)SC(0.14), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw97457 | Title: | SVI interfaces are not displayed in "show interface description" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
SVI Vlan interfaces are not displayed in "show interface description" command.
At the same time "show interface brief" displays these SVI interfaces correctly.
Conditions:
This is seen on N77-C7710 chassis with N77-SUP2E supervisor and F2e/F3 linecards installed.
Workaround:
This is a cosmetic issue.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(14) |
|
Known Fixed Releases: * | 7.3(0)D1(0.162), 7.3(0)D1(0.177), 7.3(0)GLF(0.44), 7.3(0)PDB(0.114), 7.3(0)PDB(0.128), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv52259 | Title: | Restrict vpc on port-channels configured for port-security |
|
Status: | Open |
|
Severity: * | 3 Moderate |
Description: | Symptom:
On nexus 7000 series switches, it's currently not supported to run port-security on vpc legs and the system currently disallows to configure it in that order. However the system allows you to configure vpc on port-channels already configured for port-security. This defect is an enhancement to disallow this reverse operation.
Conditions:
On nexus 7000 series switches, vpc and port security can not both configured on a port channel at the same time. This bugs occurs when user configures port-security on a vpc leg.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.55), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut50593 | Title: | N7K - BFD config showing large inaccurate nums in startup config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
BFD command ouput in startup config show large unaccurate number
Conditions:
only startup config shows the issue not running config
Workaround:
need to default the interface and reconfig it
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 5.2(4), 6.1(3), 6.2(8)S9 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.18), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu41125 | Title: | LSA are present after configuring "area 1 range not-advertise" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Component LSA's are present after configuring "area range not-advertise"
Conditions:
After configuring "area range not-advertise"
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)ZD(0.161), 7.3(0)ZN(0.49), 7.3(0.1), 8.3(0)CV(0.162) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.11), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv45849 | Title: | FEX HIF Po load-balancing issue when connected to Nexus 7700 F3 linecard |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Traffic destined to a HIF port-channel (with 2 x HIF ports as members) is distributed only on a HIF port although the forwarding-path shows both HIF ports as outgoing interfaces for two different flows.
Conditions:
FEX model N2K-C2248TP-1GE is connected to a F3 linecard on a Nexus 7700 switch running 6.2(12).
Workaround:
None at the moment.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.41), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty67801 | Title: | SVI should not be allowed for vpls vlan |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
This is a feature request for SVI, where SVI creation has to fail if VFI is configured under a vlan, and vice-versa, VFI configuration under a vlan has to fail if corresponding SVI is created.
Conditions:
If both SVI and VFI are configured for a vlan at the sam time.
Workaround(s):
User has to be careful not to configure both SVI and VFI for a vlan at same time.
Workaround:
User has to be careful not to configure both SVI and VFI for a vlan at same time.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 5.2(0)LV1(0.274), 6.2(1.125)S6 |
|
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.232), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.166), 7.3(0)D1(0.140), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10)S92 |
|
Known Fixed Releases: * | 7.3(0)D1(0.87), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.37), 7.3(0)PDB(0.57), 7.3(0)RTG(0.78), 7.3(0)SC(0.14), 7.3(0)SL(0.115), 7.3(0)ZD(0.102) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv22195 | Title: | Need to add command for show system default interface |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
You can configure the system default interface congestion timeout XXX mode edge/core, however there is no show command to show you what this value is currently set to.
Conditions:
You are using FCoE and have implemented the congestion timeout command. There is no way to run a show command to confirm what the values are set for.
Workaround:
By running the following command you can confirm if there have been changes made to the default command:
show run | i timeout
If you don't get any data back from this command you are still at the defaults, however if you see something like below:
show run | i timeout
system default interface congestion timeout 200 mode edge
This idicates that you have this value currently setup for 200 ms and the default is 500 ms. If the value is still set to the default of 500 ms, you will not see this command above in the show running-configuration.
Further Problem Description:
Resolution Summary:
To be completed once resolved
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.162), 7.3(0)GLF(0.44), 7.3(0)PDB(0.105), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux57492 | Title: | Ip pim pre-build-spt not functioning correctly for SSM in VPC setup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Both the VPC peers do not send PIM joins to the Source on enabling "ip pim pre-build-spt" in PIM SSM over VPC setup.
Conditions:
This condition occurs only with PIM SSM
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)N1(0.231) |
|
Known Fixed Releases: * | 7.3(0)D1(0.186), 7.3(0)N1(0.243), 7.3(0)N1(1), 7.3(0)ZD(0.205), 7.3(0)ZN(0.220) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw51036 | Title: | %ETHPORT-3-IF_UNSUPPORTED_TRANSCEIVER:" for LOROM twinax cable |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Syslog Message:
2015 Sep 2 13:12:31 TXD-SA03-A %ETHPORT-3-IF_NON_CISCO_TRANSCEIVER: Non-Cisco transceiver on interface Ethernet1/9 is detected
Conditions:
When we use the following twinax cable
transceiver trunk
TXD-SA03-A# show int e1/9 transceiver
Ethernet1/9
transceiver is present
type is SFP-H10GB-CU3M
name is CISCO-LOROM
part number is LRHSPB54D030
revision is B0
serial number is LRM191487QD
nominal bitrate is 10300 MBit/sec
Link length supported for copper is 3 m
cisco id is --
cisco extended id number is 4
Workaround:
Issue is cosmetic in nature as switch detects the SFP okay and interface also comes up okay.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(1), 7.2(1)ZD(0.110), 7.2(2)D1(0.1), 7.3(0)D1(0.140), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.80), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw16936 | Title: | N7K - Removing/Adding tunnel dest. throws %LDP-3-OIM_SDB_OPEN: Error |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When removing or adding GRE tunnel destination ip address, the following error message is getting displayed.
%LDP-3-OIM_SDB_OPEN: Error opening volatile:/dev/shm/4/oim_sdb_info, error - 0x0 (ksink_sdb_open() failed) in oim_api_init()
Tue Aug 25 19:02:04 2015:type=update:id=10.110.252.121@pts/0:user=SVC-UDC-PSC:cmd=configure terminal ; interface Tunnel143 ; tunnel source 10.1.15.10 (SUCCESS)
Tue Aug 25 19:02:05 2015:type=update:id=10.110.252.121@pts/0:user=SVC-UDC-PSC:cmd=configure terminal ; interface Tunnel143 ; tunnel destination 10.110.241.155 (SUCCESS)
2015 Aug 25 19:02:05.158 m-awvpdc01-nsw-udc-n7k01-vdc03 %LDP-3-OIM_SDB_OPEN: Error opening volatile:/dev/shm/4/oim_sdb_info, error - 0x0 (ksink_sdb_open() failed) in oim_api_init()
Conditions:
The OIM service must not be running.
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)GLF(0.25), 7.3(0)OTT(0.49), 7.3(0)PDB(0.102), 7.3(0)SC(0.14), 7.3(0)ZD(0.155), 7.3(0)ZN(0.170) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw54273 | Title: | "where" returning empty under profile level config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
The CLI command "where" does not work inside the ethernet link oam profile configuration, CLI submode.
Conditions:
Always happens inside the ethernet oam profile submode. For example:
switch# conf
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# ether oam profile profile-name
switch(config-eoam)# where
Does not happen in other CLI submodes, including the ethernet link oam interface submode.
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.96) |
|
Known Fixed Releases: * | 7.3(0)D1(0.126), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu31339 | Title: | Seeing issue with track config applied when HSRP in INIT state |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
This problem will occur when a down track is configured on VPC peer hsrp . This is NOT recommended as per Cisco VPC best practices (Strong Recommendation: Do not use HSRP/VRRP object tracking in a vPC domain.)
Hsrp in case of vpc config with configured track as down , doesn't take mac to the reserve state even though the hsrp priority decrements lesser than the lower threshold.
"Show hsrp detail" or "show hsrp int <> detail" doesn't show (Lower threshold touched) when the track is down & it decrements the hsrp priority to less than lower threshold value configured(default is 1) and as a result of it , it never brings the Mac of this vpc-peer (with Zero priority) to MAC reserve state.
Conditions:
This issue will occur when HSRP absorbs the track config before it changes it state from init to listen/standby/active.
Such condition can be achieved by configuring a track object which is down on hsrp group before applying the VIP on the hsrp group.
For eg the below config , if the track 1 is down and we apply the below config
n7k-01-S1(config-if)# hsrp 10
n7k-01-S1(config-if-hsrp)# priority 100
n7k-01-S1(config-if-hsrp)# track 1 decrement 150
n7k-01-S1(config-if-hsrp)# ip 10.10.10.10
n7k-01-S1(config-if-hsrp)# end
Then , hsrp group (due to this bug) is not going into the "lower threshold logic".
Workaround:
Bring hsrp group into any state other than init before applying Track config. I.e Configure the hsrp groups with VIP address first and then add track config (which is down).
for eg : If we do config like this
n7k-01-S1(config-if)# hsrp 10
n7k-01-S1(config-if-hsrp)# priority 100 forwarding-threshold lower 10 upper 100
n7k-01-S1(config-if-hsrp)# ip 10.10.10.10
n7k-01-S1(config-if-hsrp)# track 1 decrement 150
n7k-01-S1(config-if-hsrp)# end
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.499) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.9), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut36702 | Title: | F3 / 4-Way HSRP / VMAC Programmed To sup-eth31 On Listen Members |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
HSRP vmac programmed to sup-eth or emulated SWID of vPC peers on routers in HSRP Listen state
Conditions:
vPC peers in listen state due to 4-way HSRP and `no port-channel limit` enabled under vPC domain.
Workaround:
enable port-channel limit under vPC domain
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.69), 7.3(0)DHB(0.31), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.23), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux11029 | Title: | Route tag lost on internal routes when using eigrp wide metric on Nexus |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When we configure wide metric on nexus using command "metric version 64bit", nexus starts ignoring route-tags for internal routes, external route-tags still shows up in routing and topology table. But routes that are internal looses their route-tags.
Conditions:
Using eigrp metric on nexus.
Workaround:
remove eigrp wide metric
Further Problem Description:
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)IB(0.114), 7.3(0)SC(0.14), 7.3(0)ZD(0.194), 7.3(0)ZN(0.210) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux63096 | Title: | CSCuw89606 and CSCut84448 |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Bugid: CSCut84448
In this status, routing information is like below.
NX01 has routes to NX03 and NX04 for 10.x.x.x
NX03 has routes to NX01 and NX02 for 10.x.x.x
NX04 has routes to NX01 and NX02 for 10.x.x.x
As a result, there are loop between NX01-NX03 and NX01-NX04.
NX01 are advertising redistributed static route to NX03 and NX04.
NX01# show ip ospf database
snip
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.x.x.x NX01 2 0xXXXX 0x494 0
10.x.x.x NX02 238 0xXXXX 0xd42e 0
Bugid: CSCuw89606
On a Nexus, piping 'show ip route' or 'show ip static-route' to xml/json will not provide the next hop ip address.
Conditions:
Workaround:
Bugid: CSCut84448
When the ospf is restarted using 'restart ospf 1000' , the route that cause of looping is removed.
Routing information is like below.
NX01 has routes to NX03 and NX04 for 10.x.x.x
NX03 has routes to NX02 for 10.x.x.x
NX04 has routes to NX02 for 10.x.x.x
NX01 are not advertising redistributed static route to NX03 and NX04.
NX01# show ip ospf database
snip
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.x.x.x NX02 238 0xXXXX 0xd42e 0
Debug info : Process prefix 124.243.13.160/32 for type-7/type-5 translation
Bugid: CSCuw89606
On CLI, do not pipe to xml/json to see the next hop ip address.
On NXAPI, poll ascii and parse the output.
Further Problem Description:
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 8.3(0)CV(0.99) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq72316 | Title: | N7K:Static route leak w/ unconfig/config SVIs cause traffic black hole |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Traffic black hole
Conditions:
With Static route configure, unconfigure/configure the SVI.
Workaround:
1. unconfig global static route which is in problematic state
2. Clear any stale route still present globally
3. Config back global static route
Further Problem Description:
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: * | 6.2(10), 6.2(14), 6.2(8)E9, 6.2(8a), 6.2(8b) |
|
Known Fixed Releases: | 6.2(10)E5, 6.2(8)E10, 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.440), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)N1(1), 7.2(0)PDB(0.379), 7.2(0)RTG(0.97) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui05696 | Title: | dcos-ping not removed after unlimited pings via telnet session is killed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
If unlimited ping is issued from a telnet session and then the telnet session is killed, the dcos-ping process remains without being removed and hogs cpu.
Conditions:
Seen only in the case of unlimited ping
Workaround:
Kill the stale dcos-ping process.
Further Problem Description:
|
|
Last Modified: | 22-DEC-2015 |
|
Known Affected Releases: | 6.1(3), 6.2(1.93)S4 |
|
Known Fixed Releases: | 6.0(2)N3(0.340), 6.0(2)N3(1), 6.1(4.97)S0, 6.1(5), 6.1(5.32)S0, 6.2(0)HS(0.10), 6.2(5)BF(0.38), 6.2(5.71)S0, 6.2(6), 7.0(0)BNZ(0.23) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux58308 | Title: | Configuring 'delay restore interface-vlan 30' defaults timer to 10 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When the interface-vlan delay restore timer be configured to 30s, it is still shown 10s in CLI when execute "show running configure vpc all".
Conditions:
This bug will be triggered when the interface-vlan delay restore timer be configured to 30s.
Workaround:
Not applicable.
Further Problem Description:
Not applicable.
|
|
Last Modified: | 22-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.190), 7.3(0)ZD(0.208) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur56960 | Title: | VRRS pathway stuck in "Currently being removed" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
VRRS pathway stuck in "Currently being removed"
Conditions:
When we move from VRRS pathway to VRRP, VRRS pathway stuck in "Currently being removed" state for all slaves. Due to this error, we cannot configure the VIP when we try to move the slave to a vrrp group. The trigger of this issue is to remove the SVI completely.
Workaround:
Instead of removing the SVI completely, remove VRRS pathway config only.
Further Problem Description:
.
|
|
Last Modified: | 22-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.190), 7.3(0)N1(0.246), 7.3(0)N1(1), 7.3(0)ZD(0.208), 7.3(0)ZN(0.222) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux22154 | Title: | Header discarded packets in vrrpv3 |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
When VRRPV3 is configured between L2 & L3 devices, We would see VRRPV3 packets drop happening due to invalid group no. These VRRPV3 packets belong to some other group and is punted to the interface which does not belong to that group. Hence there would not be any functionality impact.
Conditions:
VRRPV3 groups are configured between L3-L2 interfaces.
For example one side VRRPV3 is configured on a VLAN while other side it is configured on a L3 interface.
Workaround:
VRRPV3 groups should ideally be configured between L2-L2 or L3-L3 interfaces.
For example, both sides VRRPV3 groups may either be configured on SVIs or L3 interfaces.
Further Problem Description:
|
|
Last Modified: | 22-DEC-2015 |
|
Known Affected Releases: | 7.3(0)ZN(0.99) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux09435 | Title: | N7K - MSDP SA information not exchange after reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Source Active messages not sent to MSDP peers after router reload.
The MSDP session is established, control messages exchanged periodically to keep state up, but SA not created/exchanged.
Conditions:
Anycast RP with MSDP implementation. Issue occurs after device reload with overlapping RP groups.
Workaround:
The issue clears and SA exchange resumes after MSDP process restart
restart msdp
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.156), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), 7.3(0)D1(0.156), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)N1(0.205) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03144 | Title: | OpenSSH: Evaluation of Multiple OpenSSH CVEs for NX-OS |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Cisco Nexus Operation System (NX-OS), running on the Cisco Nexus 5000 Series Switches, Cisco Nexus 6000 Series Switches, Cisco Nexus 7000 Series Switches and Cisco MDS 9000 Series Multilayer Switches include a version of Open Secure Shell (OpenSSH) software that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-5600, CVE-2015-6563, CVE-2015-6564, CVE-2015-5352 and CVE-2015-6565
This bug was opened to address the potential impact on this product.
Conditions:
Device with default configuration.
Workaround:
Not currently available.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at
http://cve.mitre.org/cve/cve.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5600
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6563
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6564
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6565
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5352
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.9/6.9:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:M/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C&version=2.0
CVE ID CVE-2015-5600, CVE-2015-6563, CVE-2015-6564, CVE-2015-6565, CVE-2015-5352 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 6.2(12), 7.3(0)ZN(0.89) |
|
Known Fixed Releases: * | 6.2(15)S10, 7.2(1)D1(1), 7.2(1)N1(0.331), 7.2(1)N1(1), 7.2(1)ZD(0.98), 7.2(1)ZN(0.92), 7.2(2)D1(0.2), 7.3(0)D1(0.90), 7.3(0)EG(0.3), 7.3(0)FMD(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux21246 | Title: | EIGRP sessions are flapping due to subnet mismatch failure |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
EIGRP neighbors flap due to subnet mismatch failure
Conditions:
After LC reload in a scaled setup.
Workaround:
neighbor stabilizes after one flap. No workaround to prevent this one flap
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.2(2)ZD(0.19) |
|
Known Fixed Releases: * | 8.3(0)CV(0.256), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw18294 | Title: | DME: Memory leak seen in qos scale config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When configuring multiple class-map under a policy-map
from RESTful or CLI, memory for class-map will be leaked.
Specifically, the RESTful requests equivalent to the
following CLI cause a leak.
policy-map type
class type <----- this command
In addition, the following CLI would cause a leak due to
use of "insert-before"
policy-map type
class type insert-before
There will be roughly 200 bytes of memory leaked per
class-map.
Conditions:
The config needs to be sent from RESTful. Config through
CLI will not cause leak unless "insert-before" is used.
If config is sent through CLI, and "insert-before" is not
used, there's no leak
Workaround:
Process restart the process 'ipqosmgr' will release all
leaked memory back to OS. The QoS functionality already
applied in the system will not be affected by the restart.
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 7.0(3)I2(2) |
|
Known Fixed Releases: * | 7.0(3)I2(1.15), 7.0(3)I2(2), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz71139 | Title: | Kernel msg "BAR x: can't allocate mem resource " seen on xbars bringup |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
A Nexus 7000 may log the following --
%KERN-3-SYSTEM_MSG: [ 145.724281] p ci 0000:2e:05.0: BAR 8: can't allocate mem resource [0x10000000-0x3fffffff] - kernel
%KERN-3-SYSTEM_MSG: [ 145.724284] p ci 0000:2e:01.0: BAR 8: can't allocate mem resource [0x1000000-0x1ffffff] - kernel
Conditions:
N7K running 6.1(1). These logs are printed when Xbars are powered up
Workaround:
Upgrade to FPGA version 0.7 (EPLD image for 6.1(1)). The release notes for 6.1(1) have been updated with this information as follows:
"The new hardware introduced in Cisco NX-OS Release 6.1(1) and Release 6.1(2) includes new EPLD images. It is not necessary to upgrade existing EPLD images to use Cisco NX-OS Release 6.1(1) or Release 6.1(2). However, if you plan to migrate from a Supervisor 1 to a Supervisor 2 or Supervisor 2E module, and you have a Fabric 2 module in your system, you must upgrade the EPLD image on the Fabric 2 module. For instructions about upgrading EPLD images, see the Cisco Nexus 7000 Series FPGA/EPLD Upgrade Release Notes, Release 6.1."
Further Problem Description:
|
|
Last Modified: | 24-DEC-2015 |
|
Known Affected Releases: | 6.1(0.281), 6.2(1)TG(0.11), 6.2(8)S35, 7.3(0)ZD(0.161) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw55057 | Title: | urib not updating FIB when the RP has the same admin distance as AM |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
When customer does a IP change for the host in a vlan and check the route for the destination Nexus 7000 shows the best path as the LISP route which is expected but the FIB shows the route which is different than LISP route.
Conditions:
When customer does a IP change for the host in a vlan.
Workaround:
clear ip route is solving the issue.
Further Problem Description:
|
|
Last Modified: | 24-DEC-2015 |
|
Known Affected Releases: * | 6.2(12), 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux44590 | Title: | N7k - Python script errors on 'detail' command |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:When running "show tech-support forwarding l3 unicast detail" within a python script or separate, command will report a traceback exception.
Conditions:Either run command from python script, or load the python interpreter and execute the command separately.
Workaround:None at the moment.
--> Try running the command without "detail" option
--> If "detail" option needs to be given, apply the command from regular VSH shell instead of from Python shell
More Info:
|
|
Last Modified: | 25-DEC-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw56575 | Title: | SNMP TS is missing show run snmp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
sh run snmp output is not coming as a part of excuting "sh tech"
Conditions:
All nexus platforms
Workaround:
Workaround is to run "sh run snmp" separately and share the output with the TAC engineers.
Further Problem Description:
|
|
Last Modified: | 26-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(3)I3(0.196), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.3(0)D1(0.178), 7.3(0)GLF(0.44), 7.3(0)IB(0.113), 7.3(0)SC(0.14), 7.3(0)ZD(0.194) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus61813 | Title: | loop in MST environment after ISSU 6.1(4)->6.2(8a) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
loop in the network after upgrade 6.1(4)->6.2(8a)
Conditions:
upgrade 6.1(4)->6.2(8a)
Workaround:
break physical loop, as spanning-tree cannot do that
Further Problem Description:
|
|
Last Modified: | 26-DEC-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 7.0(3)I3(0.179), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), 7.3(0)D1(0.162), 7.3(0)GLF(0.44), 7.3(0)PDB(0.97), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux55759 | Title: | FabricPath Border Leaf Not Announcing Vlan Membership |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Border Leaf not receiving unknown unicast, multicast, or broadcast traffic for a given vlan. The vlan may be manually created and not have a VNI associated with it.
Conditions:
N7K standalone fabric (DFA) border leaf running 7.2(0)D1(1)
Workaround:
Enable 'ip pim sparse-mode' on the Vlan in question.
or
Disable 'feature fabric multicast'.
Further Problem Description:
|
|
Last Modified: | 28-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus56042 | Title: | Tacacs service crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The TACACS service crashed during a TACACS accounting operation.
Conditions:
This issue only occurs when TACACS accounting is configured.
Workaround:
Disable remote TACACS accounting to avoid this issue.
Further Problem Description:
For some user operations, debugging information is logged. If this log message exceeds the buffer size then this crash can occur.
Fix
---
The debug log buffer size is respected by the logging code.
|
|
Last Modified: | 29-DEC-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(10)S1, 6.2(12), 6.2(9a) |
|
Known Fixed Releases: * | 6.0(2)A5(1.40), 6.0(2)A5(2), 6.0(2)A6(1.114), 6.0(2)A6(2), 6.0(2)U5(1.40), 6.0(2)U5(2), 6.0(2)U6(0.114), 6.0(2)U6(1), 6.1(2)I3(3.103), 6.1(2)I3(4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux01711 | Title: | N7k / N77k - Interface (HIF) counters on Nexus 2348 may be erroneous |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Fex 2348 report erroneous / false counters.
aur_l3_sw1# show int Eth101/1/2
Ethernet101/1/2 is up
admin state is up, Dedicated Interface
Hardware: 100/1000/10000 Ethernet, address: e0d1.732f.4903 (bia
e0d1.732f.4903)
Description: axe1fw01p
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
reliability 255/255, txload 255/255, rxload 255/255
Encapsulation ARPA, medium is broadcast
Port mode is access
full-duplex, 1000 Mb/s
Beacon is turned off
Auto-Negotiation is turned on
Input flow-control is off, output flow-control is on
Auto-mdix is turned off
Switchport monitor is off
EtherType is 0x8100
Last link flapped 6week(s) 4day(s)
Last clearing of "show interface" counters never
4 interface resets
Load-Interval #1: 30 seconds
30 seconds input rate 1481841587208 bits/sec, 371280410 packets/sec
30 seconds output rate 2333645761384 bits/sec, 438267561 packets/sec
input rate 1481.84 Gbps, 371.28 Mpps; output rate 2333.65 Gbps, 438.27
Mpps
This issue is seen when N7k / N77k is a parent switch. Fix on N5k / N6k is available via CSCuv29358
Conditions:
N2k-2348 fex
Workaround:
This is a cosemtic counter bug. please use show inter <> counters / show inter <> summary to get the exact counters values.
Further Problem Description:
|
|
Last Modified: | 31-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(2)FIP(0.158), 7.2(2)ZD(0.47), 7.2(2)ZD(0.48), 7.2(2)ZD(0.49), 7.2(2)ZD(0.50), 7.2(2)ZD(0.51), 7.2(2)ZD(0.52), 7.2(2)ZD(0.55), 7.3(0)D1(0.193), 7.3(0)D1(0.194) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux47982 | Title: | False SNMP trap for OSPF DOWN to INIT FSM state |
|
Status: * | Other |
|
Severity: * | 4 Minor |
Description: | Symptom:
2015 Dec 8 14:06:46.279 RND-SC-2-1 %OSPF-5-NBRSTATE: ospf-CORE [9613] Process CORE, Nbr 10.219.187.1 on Vlan100 from DOWN to INIT, HELLORCVD <== first trap corresponds
2015 Dec 8 14:06:46.279 RND-SC-2-1 %OSPF-5-NBRSTATE: ospf-CORE [9613] Process CORE, Nbr 10.219.187.1 on Vlan100 from INIT to EXSTART, ADJOK
2015 Dec 8 14:06:53.817 RND-SC-2-1 %OSPF-5-NBRSTATE: ospf-CORE [9613] Process CORE, Nbr 10.219.187.1 on Vlan100 from EXSTART to EXCHANGE, NEGDONE
2015 Dec 8 14:06:53.828 RND-SC-2-1 %OSPF-5-NBRSTATE: ospf-CORE [9613] Process CORE, Nbr 10.219.187.1 on Vlan100 from EXCHANGE to FULL, EXCHDONE <== second trap corresponds
2015 Dec 8 14:06:46.279316 ospf: CORE [9613] The OSPF trap ospfNbrStateChange was successfully sent
2015 Dec 8 14:06:53.828565 ospf: CORE [9613] The OSPF trap ospfNbrStateChange was successfully sent
Conditions:
Each time local peer will try to establish OSPF neighborship and move from DOWN to INIT state upon receiving HELLO from its neighbor snmpd will send ospfNbrStateChange trap
Workaround:
None
Further Problem Description:
one
|
|
Last Modified: | 22-DEC-2015 |
|
Known Affected Releases: | 6.2(1X)S8 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux61608 | Title: | sh logging onboard flow-control pause-count doesn't show interface name |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
sh logging onboard flow-control pause-count |pause-events needs actual interface name and not just the port number since the port number is not searchable.
Conditions:
All
Workaround:
None.
Further Problem Description:
None.Resolution Summary:
To be determined once resolved.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 5.2(3a), 6.1(2), 6.2(10)S53 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.51), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut66193 | Title: | MCAST MET table shows negative utilization percentage |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
show hardware capacity forwarding | beg met
Feature Used %Used Free Total mcast-groups
----------------------------------------------------
UFIB ECMP 48 0.14 32720 32768
FCFIB ECMP 0 0.00 32720 32768
MFIB MET 31549 192.55 -15165 16384 28
MFIB MET showing more than 100% utilization.
Conditions:
customer had intermittent multicast packet drops in their network. After troubleshooting it was found that FIB TCAM and MET table were being exhausted.
%IPFIB-SLOT3-4-CLP_FIB_MCASTMET_EXHAUSTED: Met entry allocation from multicast region failed on instance 3
VDC2 %L2MCAST-SLOT3-2-L2MCAST_MAC_FULL_LC: Failed to insert entry in MAC table for FE 3 swidx 332 (0x14c) with err (mac table full).
After fixing the issue, no more logs were seen regarding met table exhaustion. But met utilization still shows wrong numbers.
However, "sh system internal forwarding multicast met utilization" output shows the proper output:
MET usage statistics for Instance 1
Total entries Total Used %Used Free %Free Blk-Used Mgroup
-----------------------------------------------------------------------------------------
16384 204 1.24 16180 98.75 15 24
Workaround:
Can use "show system internal forwarding multicast met utilization" on LC to obtain the same information.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 7.2(1)D1(0.65), 7.2(1)D1(1), 7.2(1)ZD(0.57), 7.3(0)D1(0.107), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.43), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus40106 | Title: | EIGRP might incorrectly advertise tag values in ECMP case |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
There is a route-map which matches tags and set a new value.
This route-map is used in an EIGRP outbound distribute list. One in 10 times
based on the received route tag, the correct route tag value is not set while
advertising out.
Conditions:
The symptom is observed when you use a route map which matches
tags and sets a new tag.
Workaround:
Clear the EIGRP process or re-advertise the route.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.2(0)ZD(0.6) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.17), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 4.2(8), 5.2(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.54), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue01036 | Title: | N7K OSPF unable to set metric for redistributed route as zero |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Unable to set metric for redistributed routes as zero in NxOS OSPF
Conditions:
We can set metric as zero by a route-map. However, in that case NxOS applies the value of default-metric instead of the one set by the route-map.
Workaround:
none.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.0(3) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.46), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
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: | 19-DEC-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.54), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur25927 | Title: | "logging level session-mgr 7" not shown in running config after sso |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Logging level configuration "logging level session-mgr 7" got lost after switchover.
Conditions:
Problem happened only after switchover.
Workaround:
Manually configure "logging level session-mgr 7" again after switchover.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10)S98 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.46), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw34008 | Title: | F1 Fabricpath. Mac not learned when ASA switchover happens |
|
Status: | Open |
|
Severity: * | 4 Minor |
Description: | Symptom:
Mac address not updated on F1 module when ASA switch over takes place.
Conditions:
It appears that if you configure both CE and FP ports on same ASIC on a F1 module (which is not supported, see CSCuq80956), removing mis-configuration does not clear static bit set for the MAC's learned before mis-config was cleared.
Only way to clear mac's with static bit set is to reload the module.
Workaround:
Reloading Module should clear incorrect mac learning
Further Problem Description:
|
|
Last Modified: | 04-DEC-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup01143 | Title: | OSPF unicast packet sent out with CoS 5 |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Ospf packets should be sent out with CoS5 but only unicast packets are sent out with DSCP6/ CoS5.
Conditions:
OSPF unicast packet (LS Acknowledgement/LS update) are always sent out with
CoS5.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(8)S3 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.48), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux58616 | Title: | NTP Session Issue |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
CFS is disabled in version 7.0.(3)
Conditions:
I"NTP Distribute" command need to enable
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: * | 7.0(3)I2(2.14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq62069 | Title: | QSFP BiDi gives out bogus DOM info when DOM is not supported |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
When issuing "show interface transceiver det" on an interface with QSFP BiDI with 6.2.8a and later releases, the output contains all 0 or N/A. The output should be either removed or clarified to indicate that DOM is not supported for BiDi.
Conditions:
Using QSFP BiDi on n7k runnig 6.2.8a and later
Workaround:
Expected behavior, refer to the DOM compatible matrix:
http://www.cisco.com/c/en/us/td/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_8031.html#36364
Further Problem Description:
|
|
Last Modified: | 15-DEC-2015 |
|
Known Affected Releases: | 6.2(8a), 7.3(0)DX(0.18) |
|
Known Fixed Releases: * | 7.3(0)DX(0.40) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk60962 | Title: | Capability to turn off port channel bundling syslog messages |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Require CLI option to turn on/off port channel interface logging per port channel
Conditions:
Configured port channel and member link flap.Current logging event command does not suppress port channel link events.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.37), 7.3(0)PDB(0.53), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu19139 | Title: | "Default information originate always" not working |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
"default-information originate always" not working
Conditions:
When a learnt route replaces the route added and then the learnt route is lost
Workaround:
unconfigure and re-configure the command
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 7.3(0)TD(0.1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.27), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv53208 | Title: | AUTORP info overwritten when two or more update packets are received. |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The N7K overwrites the AUTORP information when two or more packets are received from the mapping agent in the same interval..
The groups in the last message are used to populate its table. The entries from the earlier messages are briefly created and deleted when the last packet arrive.
Conditions:
This is seen when the mapping agent split the AUTORP messages to two or three based on the number of groups in its mapping table.
The mapping agent have 200 or more groups to be sent in its message to 224.0.1.40.
Workaround:
None at this time
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.171), 7.3(0)GLF(0.44), 7.3(0)PDB(0.131), 7.3(0)RTG(0.74), 7.3(0)SC(0.14) |
|
|
| |
| |
|
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: | 19-DEC-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)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.66), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux47551 | Title: | 'sh int po xx trunk' command shows STP forwarding as none on 7.2(1)D1(1) |
|
Status: | Open |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
'sh int po xx trunk' command shows 'STP forwarding' and 'Vlans in spanning tree forwarding state and not pruned' as none
Conditions:
Issue is seen on 7.2(1)D1(1)
Workaround:
None
Further Problem Description:
It is purely cosmetic and there is no impact
|
|
Last Modified: | 26-DEC-2015 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux47124 | Title: | Nexus7700 error count up on link down interface with FET |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
On Nexus7700 , some errors are counted on link down interface with FET.
The port is no shut state but cable is not connected.
Conditions:
Nexus7700
NXOS6.2.10 , 6.2.14
FET-10G
Workaround:
shutdown the port
Further Problem Description:
|
|
Last Modified: | 18-DEC-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(14) |
|
Known Fixed Releases: * | 7.3(0)D1(0.186), 7.3(0)ZD(0.204) |
|
|
| |
| |
|
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: | 19-DEC-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)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.66), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv03431 | Title: | NSSA non-ABR performing LSA7 to LSA5 translation |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
A non-ABR within an NSSA area shows the message "Perform type-7/type-5 LSA translation" when issuing the command "show ip ospf". Only ABRs should display this message.
Conditions:
Router1 is performing the ABR role in a Totally NSSA Area.
Router2 is performing the ASBR role in the same area.
Router2 is injecting external prefixes within the NSSA area
When the command "show ip ospf" is issued on Router2, the following outpout is shown
"
...
Perform type-7/type-5 LSA translation
...
"
Workaround:
Apply the command "area nssa translate type7 never "
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.1(2), 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.54), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | 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: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)EG(0.3), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.45), 7.3(0)RTG(0.50), 7.3(0)SC(0.14), 7.3(0)ZD(0.85), 7.3(0)ZN(0.92) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | 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: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: * | 7.3(0)D1(0.171), 7.3(0)GLF(0.44), 7.3(0)PDB(0.131), 7.3(0)RTG(0.80), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue98013 | Title: | N7K:default cmd "bfd slow-timer 2000" shouldn't appear in "show run bfd" |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Default commands appear on show run
Conditions:
show runn bfd
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)GLF(0.43), 7.3(0)IB(0.40), 7.3(0)PDB(0.112), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun41202 | Title: | Weak CBC mode and weak ciphers should be disabled in SSH server |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
SSH servers on Cisco Nexus devices may be flagged by security scanners due to the inclusion of SSH ciphers and HMAC algorithms that are considered to be weak.
These may be identified as 'SSH Server CBC Mode Ciphers Enabled' and 'SSH Server weak MAC Algorithms Enabled' or similar.
Conditions:
This issue applies to Cisco Nexus 7000 and MDS 9000 series switches. SSH functionality is enabled by default in Cisco NX-OS. The current SSH server status is displayed using the show ssh server command.
Workaround:
None.
Further Problem Description:
If an SSH client configured to use weak ciphers is used to log in to a Cisco device with this fix, the login may fail. The following messages are logged in the switch syslog:
%DAEMON-2-SYSTEM_MSG: fatal: no matching cipher found: client 3des-cbc,blowfish-cbc server aes128-ctr,aes192-ctr,aes256-ctr - sshd[6542]
Reconfigure any SSH clients not to use weak ciphers like 3des-cbc or blowfish-cbc. DCNM uses SSH to manage Cisco devices and must be upgraded to at least Cisco NX-OS 7.2(1) to work with devices with this fix.
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
As per FIPS , CBC ciphers are considered to be weak and hence these ciphers have to be disabled . with this fix, only ctr based ciphers for ssh connections
|
|
Last Modified: | 21-DEC-2015 |
|
Known Affected Releases: | 5.2(8g)S8, 6.2(10)S102, 6.2(13)S17, 6.2(2)S27 |
|
Known Fixed Releases: * | 5.2(8g), 5.2(8g)S9, 6.2(11c), 6.2(11c)S7, 6.2(13)FM(0.66), 6.2(13.1)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110), 7.1(0)AV(0.38) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv11586 | Title: | python urllib2.open unable to resolve url with hostname |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
python urllib2.urlopen function is not able to open url with hostname.
N6001-2# python
Copyright (c) 2001-2012 Python Software Foundation; All Rights Reserved
N6001-2# >>> import cisco
N6001-2# >>> import urllib2
N6001-2# >>> set_vrf('management')
N6001-2# >>> page = urllib2.urlopen('http://www.cisco.com')
Traceback (most recent call last):
File "", line 1, in
File "/isan/python/scripts/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
File "/isan/python/scripts/urllib2.py", line 394, in open
response = self._open(req, data)
File "/isan/python/scripts/urllib2.py", line 412, in _open
'_open', req)
File "/isan/python/scripts/urllib2.py", line 372, in _call_chain
result = func(*args)
File "/isan/python/scripts/urllib2.py", line 1199, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/isan/python/scripts/urllib2.py", line 1174, in do_open
raise URLError(err)
urllib2.URLError:
N6001-2# >>> exit
Conditions:
N/A
Workaround:
Using:
- urllib2.urlopen with an IP address as URL is working.
- cli('copy http://www.site.com/image.com bootflash: vrf management');
Further Problem Description:
|
|
Last Modified: | 20-DEC-2015 |
|
Known Affected Releases: | 7.1(1)N1(0.8) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug64700 | Title: | NX-OS parser: auto-complete functionality for certain QoS commands |
|
Status: | Open |
|
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: | 19-DEC-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)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57), 7.3(0)RTG(0.64), 7.3(0)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus61786 | Title: | Need external loopback test added to GOLD |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Need to add external loopback test to the Generic Online Diagnostics(GOLD) tests.
Conditions:
Applies to platforms that use GOLD such as MDS 9700.
Workaround:
None.
Further Problem Description:
OHMS, which is the internal testing infrastructure on other MDS platforms, does have an external loopback test. GOLD needs to offer similar functionality.
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(13)FM(0.15), 6.2(9) |
|
Known Fixed Releases: * | 6.2(11.4)S0, 6.2(11c), 6.2(11c)S1, 6.2(13)FM(0.31), 6.2(13)FM(0.65), 6.2(13)GS(0.13), 6.2(13.1)S0, 7.1(1.72)S0, 7.2(0.55)S0, 7.3(0)D1(0.71) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtb48863 | Title: | cannot use SVI as source-interface for syslog/AAA group/NTP |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
It isn't possible to use a SVI as source-interface for syslog, AAA (TACACS+/RADIUS) group or NTP while it should be possible to use any physical or logical interface configured as L3 as the source of those protocols.
Conditions:
Workaround:
Make use of a loopback interface to originate packets from.
Further Problem Description:
|
|
Last Modified: | 19-DEC-2015 |
|
Known Affected Releases: | 4.2(1), 4.2(1j) |
|
Known Fixed Releases: * | 5.0(0.201), 5.0(0.214), 5.0(1), 7.0(0)FHS(0.23), 7.1(0)ES(0.24), 7.1(0)ZN(0.231), 7.2(0)BA(0.25), 7.2(0)ZN(0.111), 7.3(0)D1(0.22), 7.3(0)HM(0.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur08416 | Title: | NX-OS python allows users from one VDC to delete files from another VDC |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Cisco Nexus 7000 devices that have been configured with multiple Virtual Device Context (VDC) contain a privilege escalation vulnerability within the Python scripting subsystem
that could allow an authenticated, local attacker to delete files owned by a different VDC on the device.
The vulnerability exists due to incomplete privilege separation of the python scripting engine across multiple VDC's. This could allow an attacker with administrative privileges in a
specific VDC to remove files owned by a separate VDC. This could result in a denial of service condition on the affected device.
Conditions:
Cisco Nexus 7000 devices running an affected version of Cisco NX-OS software.
Devices configured for multiple Virtual Device Contexts.
Workaround:
Restrict access to python related commands to highly trusted users only via AAA policy.
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.6/4.4:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:N/I:C/A:N/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2015-4231 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: | 19-DEC-2015 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)OTT(0.73), 7.3(0)PDB(0.102), 7.3(0)SC(0.14), 7.3(0)ZD(0.155) |
|
|
| |
| |
|
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: | 19-DEC-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)EG(0.3), 7.3(0)IB(0.67), 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)SC(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw53020 | Title: | GRE tunnel traffic dropped with drop index 0xcad or randomly punt to CPU |
|
Status: | Other |
|
Severity: | 6 Enhancement |
Description: | Symptom:
GRE tunnel traffic dropped with drop index 0xcad or some traffic are being randomly punted to CPU
Conditions:
GRE tunnel based on F3 line card
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 18-DEC-2015 |
|
Known Affected Releases: * | 7.2(0)D1(1), 7.3(0)ZD(0.194) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux44200 | Title: | NXOS/ELAM - enhancement for F cards |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
ELAM enhancement
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 07-DEC-2015 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
:
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论